autofs misbehaves when DNS RRs returns more ldap servers

autofs misbehaves when DNS RRs returns more ldap servers

[Ondrej Valousek]

[-- Attachment #1.1: Type: text/plain, Size: 1833 bytes --]

  Hi Ian,

I just found out that when using DNS RRs to find a suitable ldapserver to connect to, we do not handle correctly the situation where the 
multiple servers are found. We end up with something like this:

automount[2712]: find_server: trying server uri ldap://dccorka.dublin.ad.s3group.com:389 ldap://dclisaa.dublin.ad.s3group.com:389 
ldap://dcdub1.dublin.ad.s3group.com:389 ldap://dcduba.dublin.ad.s3group.com:389 ldap://dcdubb.dublin.ad.s3group.com:389 
ldap://dcpra1.dublin.ad.s3group.com:389 ldap://dcsjc1.dublin.ad.s3group.com:389 ldap://dcsjca.dublin.ad.s3group.com:389 
ldap://dcwro1.dublin.ad.s3group.com:389 ldap://dccork1.dublin.ad.s3group.com:389

Looking at the source code, this uri does not look valid to me.
Ok "man auto.master" says that LDAP_URI might contain "A space seperated list of server uris of the form <proto>://<server>[/]", but 
ldap_initialize() does not look like it actually supports this - a single server is assumed instead.

Can you clarify this?

In my case above, if connection to ldap://dccorka.dublin.ad.s3group.com:389 fails, autofs never tries the other servers in the list.

Many thanks & happy new year!

Ondrej


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: Whelan House, South County Business Park, Leopardstown, Dublin 18

[-- Attachment #1.2: Type: text/html, Size: 3217 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ian Kent]

On Mon, 2010-12-27 at 13:36 +0100, Ondrej Valousek wrote:
> Hi Ian,
> 
> I just found out that when using DNS RRs to find a suitable ldapserver
> to connect to, we do not handle correctly the situation where the
> multiple servers are found. We end up with something like this:
> 
> automount[2712]: find_server: trying server uri
> ldap://dccorka.dublin.ad.s3group.com:389
> ldap://dclisaa.dublin.ad.s3group.com:389
> ldap://dcdub1.dublin.ad.s3group.com:389
> ldap://dcduba.dublin.ad.s3group.com:389
> ldap://dcdubb.dublin.ad.s3group.com:389
> ldap://dcpra1.dublin.ad.s3group.com:389
> ldap://dcsjc1.dublin.ad.s3group.com:389
> ldap://dcsjca.dublin.ad.s3group.com:389
> ldap://dcwro1.dublin.ad.s3group.com:389
> ldap://dccork1.dublin.ad.s3group.com:389
> 
> Looking at the source code, this uri does not look valid to me.
> Ok "man auto.master" says that LDAP_URI might contain "A space
> seperated list of server uris of the form <proto>://<server>[/]", but
> ldap_initialize() does not look like it actually supports this - a
> single server is assumed instead.

That's right.
I'm supposed to break that list into individual server entries and
attempt a connection to each in turn.

Can you get a debug log for me please.

> 
> Can you clarify this?
> 
> In my case above, if connection to
> ldap://dccorka.dublin.ad.s3group.com:389 fails, autofs never tries the
> other servers in the list.
> 
> Many thanks & happy new year!
> 
> Ondrej
> 
> 
> ______________________________________________________________________
> The information contained in this e-mail and in any attachments is
> confidential and is designated solely for the attention of the
> intended recipient(s). If you are not an intended recipient, you must
> not use, disclose, copy, distribute or retain this e-mail or any part
> thereof. If you have received this e-mail in error, please notify the
> sender by return e-mail and delete all copies of this e-mail from your
> computer system(s). Please direct any additional queries to:
> communications@s3group.com. Thank You. Silicon and Software Systems
> Limited. Registered in Ireland no. 378073. Registered Office: Whelan
> House, South County Business Park, Leopardstown, Dublin 18 
> 
> ______________________________________________________________________
> 

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ondrej Valousek]

[-- Attachment #1.1: Type: text/plain, Size: 6827 bytes --]

  On 28.12.2010 03:24, Ian Kent wrote:
> That's right.
> I'm supposed to break that list into individual server entries and
> attempt a connection to each in turn.
>
> Can you get a debug log for me please.

Please find the debug log attached.
I believe it has primarily nothing to do with DNS SRV support - the problem in general is that autofs man page claims that you can do 
something like this:

LDAP_URI="ldap://server1 ldap://server2"

but in fact this does not work (at least the source code does not look like supporting it). So in general you have 2 options how to resolve 
this:

1) fix the autofs man page and say that the construction above is not possible. DNS SRV lookups must be fixed separately then.
2) fix the automounter so that the construction above works as described in the 'man auto.master' - DNS SRV lookups will then start working 
automatically, too.

Here is the debug log:

Dec 27 12:44:46 dorado_v1 automount[2712]: Starting automounter version 5.0.1-0.rc2.143.el5_5.6, master map auto.master.ldap
Dec 27 12:44:46 dorado_v1 automount[2712]: using kernel protocol version 5.01
Dec 27 12:44:46 dorado_v1 automount[2712]: lookup_nss_read_master: reading master files auto.master.ldap
Dec 27 12:44:46 dorado_v1 automount[2712]: lookup(file): file map /etc/auto.master.ldap missing or not readable
Dec 27 12:44:46 dorado_v1 automount[2712]: lookup_nss_read_master: reading master ldap auto.master.ldap
Dec 27 12:44:46 dorado_v1 automount[2712]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string 
"auto.master.ldap".
Dec 27 12:44:46 dorado_v1 automount[2712]: parse_server_string: lookup(ldap): mapname auto.master.ldap
Dec 27 12:44:46 dorado_v1 automount[2712]: parse_ldap_config: lookup(ldap): ldap authentication configured with the following options:
Dec 27 12:44:46 dorado_v1 automount[2712]: parse_ldap_config: lookup(ldap): use_tls: 0, tls_required: 0, auth_required: 2, sasl_mech: GSSAPI
Dec 27 12:44:46 dorado_v1 automount[2712]: parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: 
DORADO_V1$@DUBLIN.AD.S3GROUP.COM credential cache: (null)
Dec 27 12:44:46 dorado_v1 automount[2712]: parse_init: parse(sun): init gathered global options: (null)
Dec 27 12:44:46 dorado_v1 automount[2712]: get_dc_list: doing lookup of SRV RRs for domain dublin.ad.s3group.com
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_lookup_srv: 10 records returned in the answer section.
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dccorka.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dclisaa.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dcdub1.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dcduba.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dcdubb.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dcpra1.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dcsjc1.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dcsjca.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dcwro1.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed dccork1.dublin.ad.s3group.com [0, 100, 389]
Dec 27 12:44:46 dorado_v1 automount[2712]: find_server: trying server uri ldap://dccorka.dublin.ad.s3group.com:389 
ldap://dclisaa.dublin.ad.s3group.com:389 ldap://dcdub1.dublin.ad.s3group.com:389 ldap://dcduba.dublin.ad.s3group.com:389 
ldap://dcdubb.dublin.ad.s3group.com:389 ldap://dcpra1.dublin.ad.s3group.com:389 ldap://dcsjc1.dublin.ad.s3group.com:389 
ldap://dcsjca.dublin.ad.s3group.com:389 ldap://dcwro1.dublin.ad.s3group.com:389 ldap://dccork1.dublin.ad.s3group.com:389
Dec 27 12:44:46 dorado_v1 automount[2712]: do_bind: lookup(ldap): auth_required: 2, sasl_mech GSSAPI
Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_do_kinit: initializing kerberos ticket: client principal DORADO_V1$@DUBLIN.AD.S3GROUP.COM
Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_do_kinit: calling krb5_parse_name on client principal DORADO_V1$@DUBLIN.AD.S3GROUP.COM
Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_do_kinit: Using tgs name krbtgt/DUBLIN.AD.S3GROUP.COM@DUBLIN.AD.S3GROUP.COM
Dec 27 12:44:46 dorado_v1 pcscd: winscard.c:304:SCardConnect() Reader E-Gate 0 0 Not Found
Dec 27 12:44:46 dorado_v1 last message repeated 3 times
Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_do_kinit: Kerberos authentication was successful!
Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_bind_mech: Attempting sasl bind with mechanism GSSAPI
Dec 27 12:44:46 dorado_v1 automount[2712]: getuser_func: called with context (nil), id 16385.
Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_log_func:100: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more 
information (Unknown code krb5 7)
Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_client_start failed for dccorka.dublin.ad.s3group.com
Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_bind_mech: sasl_client_start: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
failure.  Minor code may provide more information (Unknown code krb5 7)
Dec 27 12:44:46 dorado_v1 automount[2712]: do_bind: lookup(ldap): autofs_sasl_bind returned -1
Dec 27 12:44:46 dorado_v1 automount[2712]: lookup(ldap): couldn't connect to server ldap://dccorka.dublin.ad.s3group.com:389 
ldap://dclisaa.dublin.ad.s3group.com:389 ldap://dcdub1.dublin.ad.s3group.com:389 ldap://dcduba.dublin.ad.s3group.com:389 
ldap://dcdubb.dublin.ad.s3group.com:389 ldap://dcpra1.dublin.ad.s3group.com:389 ldap://dcsjc1.dublin.ad.s3group.com:389 
ldap://dcsjca.dublin.ad.s3group.com:389 ldap://dcwro1.dublin.ad.s3group.com:389 ldap://dccork1.dublin.ad.s3group.com:389
Dec 27 12:44:46 dorado_v1 automount[2712]: do_reconnect: lookup(ldap): failed to find available server



The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: Whelan House, South County Business Park, Leopardstown, Dublin 18

[-- Attachment #1.2: Type: text/html, Size: 10147 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ian Kent]

On Mon, 2011-01-03 at 11:14 +0100, Ondrej Valousek wrote:
> On 28.12.2010 03:24, Ian Kent wrote: 
> > That's right.
> > I'm supposed to break that list into individual server entries and
> > attempt a connection to each in turn.
> > 
> > Can you get a debug log for me please.
> 
> Please find the debug log attached.
> I believe it has primarily nothing to do with DNS SRV support - the
> problem in general is that autofs man page claims that you can do
> something like this:
> 
> LDAP_URI="ldap://server1 ldap://server2"

You are supposed to be able to do this.

> 
> but in fact this does not work (at least the source code does not look
> like supporting it). So in general you have 2 options how to resolve
> this:
> 
> 1) fix the autofs man page and say that the construction above is not
> possible. DNS SRV lookups must be fixed separately then.
> 2) fix the automounter so that the construction above works as
> described in the 'man auto.master' - DNS SRV lookups will then start
> working automatically, too.

I'd prefer to fix it so I'll start by checking automount.

> 
> Here is the debug log:
> 
> Dec 27 12:44:46 dorado_v1 automount[2712]: Starting automounter
> version 5.0.1-0.rc2.143.el5_5.6, master map auto.master.ldap
> Dec 27 12:44:46 dorado_v1 automount[2712]: using kernel protocol
> version 5.01
> Dec 27 12:44:46 dorado_v1 automount[2712]: lookup_nss_read_master:
> reading master files auto.master.ldap
> Dec 27 12:44:46 dorado_v1 automount[2712]: lookup(file): file
> map /etc/auto.master.ldap missing or not readable
> Dec 27 12:44:46 dorado_v1 automount[2712]: lookup_nss_read_master:
> reading master ldap auto.master.ldap
> Dec 27 12:44:46 dorado_v1 automount[2712]: parse_server_string:
> lookup(ldap): Attempting to parse LDAP information from string
> "auto.master.ldap".
> Dec 27 12:44:46 dorado_v1 automount[2712]: parse_server_string:
> lookup(ldap): mapname auto.master.ldap
> Dec 27 12:44:46 dorado_v1 automount[2712]: parse_ldap_config:
> lookup(ldap): ldap authentication configured with the following
> options:
> Dec 27 12:44:46 dorado_v1 automount[2712]: parse_ldap_config:
> lookup(ldap): use_tls: 0, tls_required: 0, auth_required: 2,
> sasl_mech: GSSAPI
> Dec 27 12:44:46 dorado_v1 automount[2712]: parse_ldap_config:
> lookup(ldap): user: (null), secret: unspecified, client principal:
> DORADO_V1$@DUBLIN.AD.S3GROUP.COM credential cache: (null)
> Dec 27 12:44:46 dorado_v1 automount[2712]: parse_init: parse(sun):
> init gathered global options: (null)
> Dec 27 12:44:46 dorado_v1 automount[2712]: get_dc_list: doing lookup
> of SRV RRs for domain dublin.ad.s3group.com
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_lookup_srv: 10 records
> returned in the answer section.
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dccorka.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dclisaa.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dcdub1.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dcduba.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dcdubb.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dcpra1.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dcsjc1.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dcsjca.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dcwro1.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: dns_parse_rr_srv: Parsed
> dccork1.dublin.ad.s3group.com [0, 100, 389]
> Dec 27 12:44:46 dorado_v1 automount[2712]: find_server: trying server
> uri ldap://dccorka.dublin.ad.s3group.com:389
> ldap://dclisaa.dublin.ad.s3group.com:389
> ldap://dcdub1.dublin.ad.s3group.com:389
> ldap://dcduba.dublin.ad.s3group.com:389
> ldap://dcdubb.dublin.ad.s3group.com:389
> ldap://dcpra1.dublin.ad.s3group.com:389
> ldap://dcsjc1.dublin.ad.s3group.com:389
> ldap://dcsjca.dublin.ad.s3group.com:389
> ldap://dcwro1.dublin.ad.s3group.com:389
> ldap://dccork1.dublin.ad.s3group.com:389
> Dec 27 12:44:46 dorado_v1 automount[2712]: do_bind: lookup(ldap):
> auth_required: 2, sasl_mech GSSAPI
> Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_do_kinit: initializing
> kerberos ticket: client principal DORADO_V1$@DUBLIN.AD.S3GROUP.COM
> Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_do_kinit: calling
> krb5_parse_name on client principal DORADO_V1$@DUBLIN.AD.S3GROUP.COM
> Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_do_kinit: Using tgs
> name krbtgt/DUBLIN.AD.S3GROUP.COM@DUBLIN.AD.S3GROUP.COM
> Dec 27 12:44:46 dorado_v1 pcscd: winscard.c:304:SCardConnect() Reader
> E-Gate 0 0 Not Found
> Dec 27 12:44:46 dorado_v1 last message repeated 3 times
> Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_do_kinit: Kerberos
> authentication was successful!
> Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_bind_mech: Attempting
> sasl bind with mechanism GSSAPI
> Dec 27 12:44:46 dorado_v1 automount[2712]: getuser_func: called with
> context (nil), id 16385.
> Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_log_func:100: GSSAPI
> Error: Unspecified GSS failure.  Minor code may provide more
> information (Unknown code krb5 7)
> Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_client_start failed
> for dccorka.dublin.ad.s3group.com
> Dec 27 12:44:46 dorado_v1 automount[2712]: sasl_bind_mech:
> sasl_client_start: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information
> (Unknown code krb5 7)
> Dec 27 12:44:46 dorado_v1 automount[2712]: do_bind: lookup(ldap):
> autofs_sasl_bind returned -1
> Dec 27 12:44:46 dorado_v1 automount[2712]: lookup(ldap): couldn't
> connect to server ldap://dccorka.dublin.ad.s3group.com:389
> ldap://dclisaa.dublin.ad.s3group.com:389
> ldap://dcdub1.dublin.ad.s3group.com:389
> ldap://dcduba.dublin.ad.s3group.com:389
> ldap://dcdubb.dublin.ad.s3group.com:389
> ldap://dcpra1.dublin.ad.s3group.com:389
> ldap://dcsjc1.dublin.ad.s3group.com:389
> ldap://dcsjca.dublin.ad.s3group.com:389
> ldap://dcwro1.dublin.ad.s3group.com:389
> ldap://dccork1.dublin.ad.s3group.com:389
> Dec 27 12:44:46 dorado_v1 automount[2712]: do_reconnect: lookup(ldap):
> failed to find available server
> 
> 
> 
> ______________________________________________________________________
> The information contained in this e-mail and in any attachments is
> confidential and is designated solely for the attention of the
> intended recipient(s). If you are not an intended recipient, you must
> not use, disclose, copy, distribute or retain this e-mail or any part
> thereof. If you have received this e-mail in error, please notify the
> sender by return e-mail and delete all copies of this e-mail from your
> computer system(s). Please direct any additional queries to:
> communications@s3group.com. Thank You. Silicon and Software Systems
> Limited. Registered in Ireland no. 378073. Registered Office: Whelan
> House, South County Business Park, Leopardstown, Dublin 18 
> 
> ______________________________________________________________________
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ondrej Valousek]

[-- Attachment #1.1: Type: text/plain, Size: 1592 bytes --]

  On 06.01.2011 08:09, Ian Kent wrote:
>> LDAP_URI="ldap://server1 ldap://server2"
> You are supposed to be able to do this.
>
Ok I have found the problem. The construction above is working well, indeed.
The problem is, that you call get_dc_list() directly in the while loop in function find_server() where its output is not parsed (normally 
the LDAP_URI config parameter is parsed fine).

I think that to fix it we would need to:
1. call the get_dc_list() before the main "while" loop
2. fix get_dc_list() so it rather than strcatting ldap uris into a single string returns the pure list so that we do not have to parse it 
again. This way it can be directly processed in the main while loop.

But I do not know how would it behave if we had something like this:
LDAP_URI="ldap:///something ldap:///something_else".

Maybe two nested loops would be better - anyway I am sure you know where I am pointing now :-)

Ondrej



The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: Whelan House, South County Business Park, Leopardstown, Dublin 18

[-- Attachment #1.2: Type: text/html, Size: 2448 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ian Kent]

On Thu, 2011-01-06 at 09:48 +0100, Ondrej Valousek wrote:
> On 06.01.2011 08:09, Ian Kent wrote: 
> > > LDAP_URI="ldap://server1 ldap://server2"
> > You are supposed to be able to do this.
> > 
> Ok I have found the problem. The construction above is working well,
> indeed.
> The problem is, that you call get_dc_list() directly in the while loop
> in function find_server() where its output is not parsed (normally the
> LDAP_URI config parameter is parsed fine).
> 
> I think that to fix it we would need to:
> 1. call the get_dc_list() before the main "while" loop
> 2. fix get_dc_list() so it rather than strcatting ldap uris into a
> single string returns the pure list so that we do not have to parse it
> again. This way it can be directly processed in the main while loop.
> 
> But I do not know how would it behave if we had something like this:
> LDAP_URI="ldap:///something ldap:///something_else".
> 
> Maybe two nested loops would be better - anyway I am sure you know
> where I am pointing now :-) 

Thanks for the suggestions.
I'm still on leave so things are still going slowly for now, but I'll
get to it.

> 
> Ondrej
> 
> 
> 
> ______________________________________________________________________
> The information contained in this e-mail and in any attachments is
> confidential and is designated solely for the attention of the
> intended recipient(s). If you are not an intended recipient, you must
> not use, disclose, copy, distribute or retain this e-mail or any part
> thereof. If you have received this e-mail in error, please notify the
> sender by return e-mail and delete all copies of this e-mail from your
> computer system(s). Please direct any additional queries to:
> communications@s3group.com. Thank You. Silicon and Software Systems
> Limited. Registered in Ireland no. 378073. Registered Office: Whelan
> House, South County Business Park, Leopardstown, Dublin 18 
> 
> ______________________________________________________________________
> 

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ondrej Valousek]

[-- Attachment #1.1: Type: text/plain, Size: 482 bytes --]

  On 06.01.2011 15:07, Ian Kent wrote:
> Thanks for the suggestions.
> I'm still on leave so things are still going slowly for now, but I'll
> get to it.
Hi Ian,

Please find the attached patch which fixes the problem for me.
I also changed the "dclist" structure definition from:

struct dclist {
         time_t expire;
         const char *uri;
};

into:

struct dclist {
         time_t expire;
         char **uri;
         int cnt;
};

Hope you'll find it useful :-) .
Ondrej

[-- Attachment #1.2: Type: text/html, Size: 1090 bytes --]

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 4286 bytes --]

diff -u modules.old/dclist.c modules/dclist.c
--- modules.old/dclist.c	2010-07-15 10:40:49.000000000 +0200
+++ modules/dclist.c	2011-01-07 12:33:50.000000000 +0100
@@ -545,8 +545,12 @@
 
 void free_dclist(struct dclist *dclist)
 {
-	if (dclist->uri)
-		free((void *) dclist->uri);
+	if (dclist->uri){
+	    for(; dclist->cnt > 0; dclist->cnt--){
+		free(dclist->uri[dclist->cnt-1]);
+	    }
+	}
+	free(dclist->uri);
 	free(dclist);
 }
 
@@ -599,8 +603,8 @@
 	char buf[MAX_ERR_BUF];
 	char *dn_uri, *esc_uri;
 	char *domain;
-	char *list;
-	int numdcs;
+	char **list;
+	int tot_numdcs = 0;
 	int ret;
 
 	if (strcmp(uri, "ldap:///") && strcmp(uri, "ldaps:///")) {
@@ -679,10 +683,11 @@
 	list = NULL;
 	for (ludp = &ludlist; *ludp != NULL;) {
 		LDAPURLDesc *lud = *ludp;
-		size_t req_len, len;
+		size_t req_len;
 		char *request = NULL;
-		char *tmp;
-		int i;
+		char **tmplist;
+		int start,i;
+		int numdcs;
 
 		if (!lud->lud_dn && !lud->lud_dn[0] &&
 		   (!lud->lud_host || !lud->lud_host[0])) {
@@ -726,36 +731,48 @@
 		dclist_mutex_unlock();
 		free(request);
 
-		len = strlen(lud->lud_scheme);
-		len += sizeof("://");
-		len *= numdcs;
+//		len *= numdcs;
+		start = tot_numdcs;
+		tot_numdcs += numdcs;
 
 		for (i = 0; i < numdcs; i++) {
 			if (dcs[i].ttl > 0 && dcs[i].ttl < min_ttl)
 				min_ttl = dcs[i].ttl;
-			len += strlen(dcs[i].hostname);
-			if (dcs[i].port > 0)
-				len += sizeof(":65535");
 		}
 
-		tmp = realloc(list, len);
-		if (!tmp) {
+		tmplist = realloc(list, sizeof(char *)*tot_numdcs+1);
+		if (!tmplist) {
 			char *estr = strerror_r(errno, buf, MAX_ERR_BUF);
 			error(logopt, "realloc: %s", estr);
 			goto out_error;
 		}
+		list = tmplist;
 
-		if (!list)
-			memset(tmp, 0, len);
-		else
-			strcat(tmp, " ");
+//		if (!list)
+//			memset(tmp, 0, len);
+//		else
+//			strcat(tmp, " ");
 
 		for (i = 0; i < numdcs; i++) {
-			if (i > 0)
-				strcat(tmp, " ");
-			strcat(tmp, lud->lud_scheme);
+			char *tmp;
+			size_t len;
+			
+			len = strlen(lud->lud_scheme);
+			len += sizeof("://");
+			len += strlen(dcs[i].hostname);
+			if (dcs[i].port > 0)
+				len += sizeof(":65535");
+			tmp = malloc(sizeof(char)*len+1);
+			if( !tmp ){
+			    char *estr = strerror_r(errno, buf, MAX_ERR_BUF);
+			    error(logopt, "malloc: %s", estr);
+			    goto out_error;
+			}
+			strcpy(tmp, lud->lud_scheme);
 			strcat(tmp, "://");
 			strcat(tmp, dcs[i].hostname);
+			list[start++] = tmp;
+			list[start] = 0;
 			if (dcs[i].port > 0) {
 				char port[7];
 				ret = snprintf(port, 7, ":%d", dcs[i].port);
@@ -767,7 +784,6 @@
 				strcat(tmp, port);
 			}
 		}
-		list = tmp;
 
 		*ludp = lud->lud_next;
 		ber_memfree(domain);
@@ -777,12 +793,18 @@
 
 	dclist->expire = time(NULL) + min_ttl;
 	dclist->uri = list;
+	dclist->cnt = tot_numdcs;
 
 	return dclist;
 
 out_error:
-	if (list)
-		free(list);
+	if (list){
+	    char *tmp = list[0];
+	    while (tmp){
+		free(tmp);
+	    }
+	    free(list);
+	}    	
 	if (domain)
 		ber_memfree(domain);
 	ldap_free_urldesc(ludlist);
diff -u modules.old/lookup_ldap.c modules/lookup_ldap.c
--- modules.old/lookup_ldap.c	2010-07-15 10:40:49.000000000 +0200
+++ modules/lookup_ldap.c	2011-01-07 12:40:11.000000000 +0100
@@ -571,9 +571,8 @@
 		if (!strstr(this->uri, ":///"))
 			uri = strdup(this->uri);
 		else {
-			if (dclist)
-				uri = strdup(dclist->uri);
-			else {
+			int i = 0;
+			if (!dclist){
 				struct dclist *tmp;
 				tmp = get_dc_list(logopt, this->uri);
 				if (!tmp) {
@@ -581,8 +580,17 @@
 					continue;
 				}
 				dclist = tmp;
-				uri = strdup(dclist->uri);
 			}
+			while(dclist->uri[i] != NULL){
+			    uri = dclist->uri[i++];
+			    debug(logopt, "trying server uri %s", uri);
+			    ldap = connect_to_server(logopt, uri, ctxt);
+			    if (ldap) {
+				info(logopt, "connected to uri %s", uri);
+				break;
+			    }
+			}
+			if(ldap) break;    
 		}
 		if (!uri) {
 			if (dclist) {
@@ -644,9 +652,12 @@
 	}
 
 	uris_mutex_lock(ctxt);
-	if (ctxt->dclist)
-		uri = strdup(ctxt->dclist->uri);
-	else if (ctxt->uri)
+	if (ctxt->dclist){
+/* this is probably wrong - not what we want */
+//		uri = strdup(ctxt->dclist->uri);
+		uris_mutex_unlock(ctxt);
+		goto find_server;
+	} else if (ctxt->uri)
 		uri = strdup(ctxt->uri->uri);
 	else {
 		uris_mutex_unlock(ctxt);

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ian Kent]

On Fri, 2011-01-07 at 14:12 +0100, Ondrej Valousek wrote:
> On 06.01.2011 15:07, Ian Kent wrote: 
> > Thanks for the suggestions.
> > I'm still on leave so things are still going slowly for now, but I'll
> > get to it.
> Hi Ian,
> 
> Please find the attached patch which fixes the problem for me.
> I also changed the "dclist" structure definition from:
> 
> struct dclist {
>         time_t expire;
>         const char *uri;
> };
> 
> into:
> 
> struct dclist {
>         time_t expire;
>         char **uri;
>         int cnt;
> };
> 
> Hope you'll find it useful :-) .

Sorry I didn't get onto this earlier.
I could have saved you quite a bit of time.

Now that I've had a look I see I've already worked on this problem.
See:
http://www.kernel.org/pub/linux/daemons/autofs/v5/autofs-5.0.5-check-each-dc-server.patch

Ian

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ondrej Valousek]

[-- Attachment #1.1: Type: text/plain, Size: 798 bytes --]

  Hi Ian,

Did you have any chance to take a look at this patch yet?
Thanks,

Ondrej

On 07.01.2011 14:12, Ondrej Valousek wrote:
> On 06.01.2011 15:07, Ian Kent wrote:
>> Thanks for the suggestions.
>> I'm still on leave so things are still going slowly for now, but I'll
>> get to it.
> Hi Ian,
>
> Please find the attached patch which fixes the problem for me.
> I also changed the "dclist" structure definition from:
>
> struct dclist {
>         time_t expire;
>         const char *uri;
> };
>
> into:
>
> struct dclist {
>         time_t expire;
>         char **uri;
>         int cnt;
> };
>
> Hope you'll find it useful :-) .
> Ondrej
>
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs


[-- Attachment #1.2: Type: text/html, Size: 1911 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ian Kent]

On Wed, 2011-02-02 at 15:40 +0100, Ondrej Valousek wrote:
> Hi Ian,
> 
> Did you have any chance to take a look at this patch yet?

Yes, and replied on the 11/01, did you miss it?

> Thanks,
> 
> Ondrej
> 
> On 07.01.2011 14:12, Ondrej Valousek wrote: 
> > On 06.01.2011 15:07, Ian Kent wrote: 
> > > Thanks for the suggestions.
> > > I'm still on leave so things are still going slowly for now, but I'll
> > > get to it.
> > Hi Ian,
> > 
> > Please find the attached patch which fixes the problem for me.
> > I also changed the "dclist" structure definition from:
> > 
> > struct dclist {
> >         time_t expire;
> >         const char *uri;
> > };
> > 
> > into:
> > 
> > struct dclist {
> >         time_t expire;
> >         char **uri;
> >         int cnt;
> > };
> > 
> > Hope you'll find it useful :-) .
> > Ondrej
> > 
> > _______________________________________________
> > autofs mailing list
> > autofs@linux.kernel.org
> > http://linux.kernel.org/mailman/listinfo/autofs
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ondrej Valousek]

[-- Attachment #1.1: Type: text/plain, Size: 450 bytes --]


> Yes, and replied on the 11/01, did you miss it?
>
Ok I must have missed it - now I see you have taken a different approach - you are constructing a single looong string with all ldap uris 
and then you parse them again.
I must say I do not like it too much as:
a) it is wasted effort (merging together and then splitting again)
b) potentially can ldap uri contain spaces I think

But if you like it more, I am fine with it, too.

Regards,
Ondrej


[-- Attachment #1.2: Type: text/html, Size: 881 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ian Kent]

On Tue, 2011-02-08 at 10:16 +0100, Ondrej Valousek wrote:
> 
> > Yes, and replied on the 11/01, did you miss it?
> > 
> Ok I must have missed it - now I see you have taken a different
> approach - you are constructing a single looong string with all ldap
> uris and then you parse them again.
> I must say I do not like it too much as:
> a) it is wasted effort (merging together and then splitting again)
> b) potentially can ldap uri contain spaces I think

Don't think so, in this case anyway.

The uris used here aren't full uris, they can only have the proto, host
name and port. AFAIK, host names can't have spaces in them yet.

> 
> But if you like it more, I am fine with it, too.

Yeah, your points above are well taken but had already been done and
committed to the repo so to change would be more work with the potential
for mistakes.

Ian

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Wolfe, Allan]

A copy of the RFC for LDAP URI formatting can be found at
http://www.faqs.org/rfcs/rfc2255.html it documents how the URI should be
constructed/interpreted.

-----Original Message-----
From: autofs-bounces@linux.kernel.org
[mailto:autofs-bounces@linux.kernel.org] On Behalf Of Ian Kent
Sent: Tuesday, February 08, 2011 9:50 PM
To: Ondrej Valousek
Cc: autofs@linux.kernel.org
Subject: Re: [autofs] autofs misbehaves when DNS RRs returns more ldap
servers

On Tue, 2011-02-08 at 10:16 +0100, Ondrej Valousek wrote:
> 
> > Yes, and replied on the 11/01, did you miss it?
> > 
> Ok I must have missed it - now I see you have taken a different 
> approach - you are constructing a single looong string with all ldap 
> uris and then you parse them again.
> I must say I do not like it too much as:
> a) it is wasted effort (merging together and then splitting again)
> b) potentially can ldap uri contain spaces I think

Don't think so, in this case anyway.

The uris used here aren't full uris, they can only have the proto, host
name and port. AFAIK, host names can't have spaces in them yet.

> 
> But if you like it more, I am fine with it, too.

Yeah, your points above are well taken but had already been done and
committed to the repo so to change would be more work with the potential
for mistakes.

Ian


_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Anadarko Confidentiality Notice: This electronic transmission and any 
attached documents or other writings are intended only for the person 
or entity to which it is addressed and may contain information that is 
privileged, confidential or otherwise protected from disclosure. If you 
have received this communication in error, please immediately notify 
sender by return e-mail and destroy the communication. Any disclosure, 
copying, distribution or the taking of any action concerning the contents 
of this communication or any attachments by anyone other than the 
named recipient is strictly prohibited.

Re: autofs misbehaves when DNS RRs returns more ldap servers

[Ondrej Valousek]

[-- Attachment #1.1: Type: text/plain, Size: 2378 bytes --]

  Ok,
LDAP URI can not contain spaces, Ian was right...
Ondrej

On 09.02.2011 15:57, Wolfe, Allan wrote:
> A copy of the RFC for LDAP URI formatting can be found at
> http://www.faqs.org/rfcs/rfc2255.html it documents how the URI should be
> constructed/interpreted.
>
> -----Original Message-----
> From: autofs-bounces@linux.kernel.org
> [mailto:autofs-bounces@linux.kernel.org] On Behalf Of Ian Kent
> Sent: Tuesday, February 08, 2011 9:50 PM
> To: Ondrej Valousek
> Cc: autofs@linux.kernel.org
> Subject: Re: [autofs] autofs misbehaves when DNS RRs returns more ldap
> servers
>
> On Tue, 2011-02-08 at 10:16 +0100, Ondrej Valousek wrote:
>>> Yes, and replied on the 11/01, did you miss it?
>>>
>> Ok I must have missed it - now I see you have taken a different
>> approach - you are constructing a single looong string with all ldap
>> uris and then you parse them again.
>> I must say I do not like it too much as:
>> a) it is wasted effort (merging together and then splitting again)
>> b) potentially can ldap uri contain spaces I think
> Don't think so, in this case anyway.
>
> The uris used here aren't full uris, they can only have the proto, host
> name and port. AFAIK, host names can't have spaces in them yet.
>
>> But if you like it more, I am fine with it, too.
> Yeah, your points above are well taken but had already been done and
> committed to the repo so to change would be more work with the potential
> for mistakes.
>
> Ian
>
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs
>
> Anadarko Confidentiality Notice: This electronic transmission and any
> attached documents or other writings are intended only for the person
> or entity to which it is addressed and may contain information that is
> privileged, confidential or otherwise protected from disclosure. If you
> have received this communication in error, please immediately notify
> sender by return e-mail and destroy the communication. Any disclosure,
> copying, distribution or the taking of any action concerning the contents
> of this communication or any attachments by anyone other than the
> named recipient is strictly prohibited.
>
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs


[-- Attachment #1.2: Type: text/html, Size: 3695 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs