On Jul 28 20:51, Denis Excoffier wrote:
> On 2014-07-28 11:21, Corinna Vinschen wrote:
> > Ping?
> >
> > On Jul 18 21:18, Corinna Vinschen wrote:
> >>
> >> We really should do that to avoid collisions with system accounts, IMHO.
> >>
> >> But maybe we should handle it as a border case of a borde
On 2014-07-28 11:21, Corinna Vinschen wrote:
> Ping?
>
> On Jul 18 21:18, Corinna Vinschen wrote:
>>
>> We really should do that to avoid collisions with system accounts, IMHO.
>>
>> But maybe we should handle it as a border case of a border case, and
>> reliably. Rather than using the default
Ping?
On Jul 18 21:18, Corinna Vinschen wrote:
> On Jul 17 08:33, Denis Excoffier wrote:
> > On 2014-07-16 15:51, Corinna Vinschen wrote:
> > > It occured to me that there's another way to do that. The problem
> > > you're mentioning above could be alleviated if the first Cygwin process
> > > in
On Jul 17 08:33, Denis Excoffier wrote:
> On 2014-07-16 15:51, Corinna Vinschen wrote:
> > It occured to me that there's another way to do that. The problem
> > you're mentioning above could be alleviated if the first Cygwin process
> > in a process tree fetches all POSIX offsets of all trusted do
On 2014-07-16 15:51, Corinna Vinschen wrote:
> It occured to me that there's another way to do that. The problem
> you're mentioning above could be alleviated if the first Cygwin process
> in a process tree fetches all POSIX offsets of all trusted domains right
> at the start, rather than fetching
On Jul 15 18:29, Denis Excoffier wrote:
> On 2014-07-14 15:48 Corinna Vinschen wrote:
> > On Jul 14 11:51, Corinna Vinschen wrote:
> >> On Jul 12 15:39, Denis Excoffier wrote:
> >>> On 2014-07-09 12:12 Corinna Vinschen wrote:
> >
> > I have encountered this case in real life. The domain ad
Greetings, Denis Excoffier!
>>> A POSIX offset of 0 is bad. If other trusted domains have no functional
>>> POSIX offset value, but are set to 0 instead, they won't have different
>>> UID values for accounts of different domains. Two users from different
>>> domains, both with RID 1000 will both
On 2014-07-14 15:48 Corinna Vinschen wrote:
> On Jul 14 11:51, Corinna Vinschen wrote:
>> On Jul 12 15:39, Denis Excoffier wrote:
>>> On 2014-07-09 12:12 Corinna Vinschen wrote:
>
> I have encountered this case in real life. The domain admins have set
> the trustPosixOffset of the seco
On Jul 14 11:51, Corinna Vinschen wrote:
> On Jul 12 15:39, Denis Excoffier wrote:
> > On 2014-07-09 12:12 Corinna Vinschen wrote:
> > >>
> > >> I have encountered this case in real life. The domain admins have set
> > >> the trustPosixOffset of the secondary domain to zero. This value is
> > >>
On Jul 12 15:39, Denis Excoffier wrote:
> On 2014-07-09 12:12 Corinna Vinschen wrote:
> >>
> >> I have encountered this case in real life. The domain admins have set
> >> the trustPosixOffset of the secondary domain to zero. This value is
> >> therefore
> >> never recorded and the cldap->open occ
On 2014-07-09 12:12 Corinna Vinschen wrote:
>>
>> I have encountered this case in real life. The domain admins have set
>> the trustPosixOffset of the secondary domain to zero. This value is therefore
>> never recorded and the cldap->open occurs again and again.
>
> Ouch. Why on earth are admins
On Jul 8 21:22, Denis Excoffier wrote:
>
> On 2014-07-07 13:07, Corinna Vinschen wrote:
>
> >
> > For enumerating a non-primary domain, I get exactly two calls to
> > cyg_ldap::open which actually do a connect. The first call opens the
> > domain for enumeration. The second call opens the pri
On 2014-07-07 13:07, Corinna Vinschen wrote:
>
> For enumerating a non-primary domain, I get exactly two calls to
> cyg_ldap::open which actually do a connect. The first call opens the
> domain for enumeration. The second call opens the primary domain (NULL)
> to fetch the POSIX offset value f
On Jul 3 22:56, Denis Excoffier wrote:
> On 2014-06-25 23:13 Corinna Vinschen wrote:
> >
> > You asked for errors being propagated up the chain to the
> > getpwent/getgrent calls and that's exactly what happens now. There are
> > a lot of LDAP error codes. How is Cygwin supposed to handle every
On 2014-06-25 23:13 Corinna Vinschen wrote:
>
> You asked for errors being propagated up the chain to the
> getpwent/getgrent calls and that's exactly what happens now. There are
> a lot of LDAP error codes. How is Cygwin supposed to handle every one
> of them? Do we need a list of ignorable an
On Jun 25 22:44, Denis Excoffier wrote:
> On 2014-06-25 12:15, Corinna Vinschen wrote:
> >> Stay tuned. I'm rewriting the LDAP access code to perform all critical
> >> LDAP calls in interruptible threads. The Windows LDAP calls don't
> >> provide any kind of synchronization, only timeouts. I hop
On 2014-06-25 12:15, Corinna Vinschen wrote:
>> Stay tuned. I'm rewriting the LDAP access code to perform all critical
>> LDAP calls in interruptible threads. The Windows LDAP calls don't
>> provide any kind of synchronization, only timeouts. I hoped to get away
>> with short timeouts but it see
On Jun 24 17:58, Corinna Vinschen wrote:
> On Jun 23 22:38, Denis Excoffier wrote:
> > On 2014-06-23 11:09, Corinna Vinschen wrote:
> > > On Jun 19 19:53, Denis Excoffier wrote:
> > >
> > > Do you really *want* to enumerate 500K users when accessing the DCs
> > > remote over a slow DSL line? Isn'
On Jun 23 22:38, Denis Excoffier wrote:
> On 2014-06-23 11:09, Corinna Vinschen wrote:
> > On Jun 19 19:53, Denis Excoffier wrote:
> >
> > Do you really *want* to enumerate 500K users when accessing the DCs
> > remote over a slow DSL line? Isn't this a situation in which you'd
> > rather like to
On 2014-06-23 11:09, Corinna Vinschen wrote:
> On Jun 19 19:53, Denis Excoffier wrote:
>
> Do you really *want* to enumerate 500K users when accessing the DCs
> remote over a slow DSL line? Isn't this a situation in which you'd
> rather like to avoid enumerating accounts or restrict it to an
> es
On Jun 19 19:53, Denis Excoffier wrote:
> On 2014-06-18 20:01, Corinna Vinschen wrote:
> > On Jun 18 10:33, Corinna Vinschen wrote:
> >>
> >>
> >> The idea I was proposing was just to drop all attempts to seconds guess
> >> how fast a DC replies. We're going to use LDAP with default settings
> >
On 2014-06-18 20:01, Corinna Vinschen wrote:
> On Jun 18 10:33, Corinna Vinschen wrote:
>>
>>
>> The idea I was proposing was just to drop all attempts to seconds guess
>> how fast a DC replies. We're going to use LDAP with default settings
>> and that's it. Default settings means, every operat
On Jun 18 10:33, Corinna Vinschen wrote:
> On Jun 18 00:41, Denis Excoffier wrote:
> > On 2014-06-17 12:00, Corinna Vinschen wrote:
> > > I'm wondering if the timeout, at least for enumerating accounts, should
> > > go away entirely. In case of a connection problem this could result in
> > > a han
On Jun 18 00:59, Denis Excoffier wrote:
> On 2014-06-17 12:30, Corinna Vinschen wrote:
> > On Jun 17 12:00, Corinna Vinschen wrote:
> >> On Jun 16 22:39, Denis Excoffier wrote:
> >>> Another (unrelated and less important) problem is that 'getent'
> >>> happily produces lines with some extra ‘:’, in
On Jun 18 00:41, Denis Excoffier wrote:
> Hi Corinna,
>
> On 2014-06-17 12:00, Corinna Vinschen wrote:
> >
> > So I expect an LDAP_SUCCESS with ldap_count_entries() == 0 and then
> > repeat the request. But the code doesn't expect LDAP_TIMEOUT in this
> > case. Do I have to handle LDAP_TIMEOUT
On Jun 17 14:52, Corinna Vinschen wrote:
>On Jun 17 12:30, Corinna Vinschen wrote:
>> On Jun 17 12:00, Corinna Vinschen wrote:
>> > On Jun 16 22:39, Denis Excoffier wrote:
>> > > Another (unrelated and less important) problem is that 'getent'
>> > > happily produces lines with some extra ‘:’, in pa
On 2014-06-17 14:51, Corinna Vinschen wrote:
> On Jun 17 12:30, Corinna Vinschen wrote:
>> On Jun 17 12:00, Corinna Vinschen wrote:
>>> On Jun 16 22:39, Denis Excoffier wrote:
Another (unrelated and less important) problem is that 'getent'
happily produces lines with some extra ‘:’, in pa
On 2014-06-17 12:30, Corinna Vinschen wrote:
> On Jun 17 12:00, Corinna Vinschen wrote:
>> On Jun 16 22:39, Denis Excoffier wrote:
>>> Another (unrelated and less important) problem is that 'getent'
>>> happily produces lines with some extra ‘:’, in particular when the
>>> gecos field itself contai
Hi Corinna,
On 2014-06-17 12:00, Corinna Vinschen wrote:
>
> So I expect an LDAP_SUCCESS with ldap_count_entries() == 0 and then
> repeat the request. But the code doesn't expect LDAP_TIMEOUT in this
> case. Do I have to handle LDAP_TIMEOUT here as well?
LDAP_TIMEOUT can occur there. I can even
On Jun 17 12:30, Corinna Vinschen wrote:
> On Jun 17 12:00, Corinna Vinschen wrote:
> > On Jun 16 22:39, Denis Excoffier wrote:
> > > Another (unrelated and less important) problem is that 'getent'
> > > happily produces lines with some extra ‘:’, in particular when the
> > > gecos field itself con
On Jun 17 12:00, Corinna Vinschen wrote:
> On Jun 16 22:39, Denis Excoffier wrote:
> > Another (unrelated and less important) problem is that 'getent'
> > happily produces lines with some extra ‘:’, in particular when the
> > gecos field itself contains ‘:’.
>
> Wow, that *is* important. All fiel
Hi Denis,
On Jun 16 22:39, Denis Excoffier wrote:
> Hello,
>
> I’ve exercised ‘getent' a little bit those days (with 'db_enum: all’
> in /etc/nsswitch.conf), and it seems to me that the timeout ‘tv' (3
> seconds, in ldap.cc) is probably too small for servers not so quickly
> responsive or with ma
Hello,
I’ve exercised ‘getent' a little bit those days (with 'db_enum: all’ in
/etc/nsswitch.conf), and it seems to me
that the timeout ‘tv' (3 seconds, in ldap.cc) is probably too small for servers
not so quickly responsive
or with many (50, fake or real) users around (see the call to
ldap
33 matches
Mail list logo
