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
32 matches
Mail list logo
