Bug 623648

correction: ldap server are running Sun ONE DS5.2

(In reply to comment #0)
> Description of problem:
> 
> Autofs just get the last entry in the auto.master information coming from ldap
> server.
> 
> Version-Release number of selected component (if applicable):
> 
> Fedora 13, autofs5 and ldap
> 
> How reproducible:
> add several server to ldap:auto.master list
> 
> Steps to Reproduce:
> 1. Have an entry like this in ldap server
> 
> # /home, auto.master,
> dn: cn=/home,nisMapName=auto.master,dc=one,dc=two,dc=three
> nisMapEntry:
> ldap:host1.one.two.three,host2.one.two.three,host3.one.two.three,:nismapname=auto.home,dc=one,dc=two,dc=three

Is there some specific reason you must use this obsolete
map entry format?

correction: ldap server are running Sun ONE DS5.2

Hi Ian

Well, we use that map because it come from the past, we use two maps, one for solaris machines that use the following schema:

dn: automountKey=,automountmapname=auto_home,dc=,dc=,dc=
        automountInformation: 
        automountKey: 
        objectClass: automount
        objectClass: top


And the other (obsolete ??) for linux box's:

dn: cn=,nisMapName=auto.home,dc=,dc=,dc=
        nisMapEntry: 
        cn: 
        nisMapName: auto.home
        objectClass: nisObject
        objectClass: top

When we moved from NIS+ to LDAP linux box's didn't support solaris schema. So we created two parallels maps.

(In reply to comment #4)
> Hi Ian
> 
> Well, we use that map because it come from the past, we use two maps, one for
> solaris machines that use the following schema:

Oh no, I wasn't talking about the schema, sorry.
Although your Solaris schema should work OK.

I was talking about the Linux autofs format.
The ldap: ... stuff.

I'm not sure that specifying multiple servers was ever supposed to work
but I think it probably did work quite a while ago. My point is that, now,
multiple servers can be set in a different ways. First, you can specify
them in the ldap client configuration file. If you chose not to do that
you can set them in the autofs configuration. The autofs configuration
file comments describe this. Then, in the map entry, specify no server
at all and autofs will use the configured servers.

You can go further than that with the setup so that you only need to
specify the map name and nothing else, similar to what you might
do with Solaris.

Hi Ian

Ok

I want to explain a bit deeper how is our system running. 
We have a host entry in the client /etc/ldap.conf configuration file.
The client connect to the first host to get ldap information then the server answer a list of server where desired information can be located and the stored format (automountmapname, nismapname ...).

i.e. 

/home ldap:server1,server2,server3,:nismapname=auto.home,dc=one,dc=two,dc=three
/data ldap:server1,server2,server3,:nismapname=auto.data,dc=one,dc=two,dc=three
/opt ldap:server1,server2,server3,:nismapname=auto.opt,dc=one,dc=two,dc=three
/pub ldap:server1,server2,server3,:nismapname=auto.pub,dc=one,dc=two,dc=three

Here is where the client fails because just get the store format and the last server in the list. 

jineta automount[7852]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "ldap:server3:nismapname=auto.pub,dc=one,dc=two,dc=three".
jineta automount[7852]: parse_server_string: lookup(ldap): server "ldap://server3/", base dn "nismapname=auto.pub,dc=one,dc=two,dc=three"


So if this server in not contactable, for any reason, the information is never catch because does not switch over to the next server(simply is the last one).

 
Do you mean adding an LDAP_URI entry in /etc/sysconfig/autofs?.

We try uncommented this lines  in the file but do not add any LDAP_URI.
#
MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="automountMapName"
ENTRY_ATTRIBUTE="automountKey"
VALUE_ATTRIBUTE="automountInformation"
#

Then change /etc/auto.master last line from +auto.master to +auto_master (solaris way), and works.

Then modify the firewall to block traffic to the first server defined in /etc/ldap.conf and still works, after a time out the client contacted to the second server and get the information needed by automounter.


This means we have to modify all the clients, I would prefer the other way round when you just modify in the server and then data is populated.

But works, so thanks a lot.

(In reply to comment #6)
> Hi Ian
> 
> Ok
> 
> I want to explain a bit deeper how is our system running. 
> We have a host entry in the client /etc/ldap.conf configuration file.
> The client connect to the first host to get ldap information then the server
> answer a list of server where desired information can be located and the stored
> format (automountmapname, nismapname ...).
> 
> i.e. 
> 
> /home ldap:server1,server2,server3,:nismapname=auto.home,dc=one,dc=two,dc=three
> /data ldap:server1,server2,server3,:nismapname=auto.data,dc=one,dc=two,dc=three
> /opt ldap:server1,server2,server3,:nismapname=auto.opt,dc=one,dc=two,dc=three
> /pub ldap:server1,server2,server3,:nismapname=auto.pub,dc=one,dc=two,dc=three

How do your Solaris machines handle this?
How do they know what to fail over to?

> 
> Here is where the client fails because just get the store format and the last
> server in the list. 
> 
> jineta automount[7852]: parse_server_string: lookup(ldap): Attempting to parse
> LDAP information from string
> "ldap:server3:nismapname=auto.pub,dc=one,dc=two,dc=three".
> jineta automount[7852]: parse_server_string: lookup(ldap): server
> "ldap://server3/", base dn "nismapname=auto.pub,dc=one,dc=two,dc=three"
> 
> 
> So if this server in not contactable, for any reason, the information is never
> catch because does not switch over to the next server(simply is the last one).

I got that from your original post.
I also said that this may have worked previously but that it was
never explicitly supported.

There is probably a reason I did it the way it has been done.
I just can't remember now, its been a fair while.

I think the current ldap function call that takes the server name,
if it is given, requires a specific format (unlike the now depricated
call that was previously used). I also suspect it will not fail over
properly either, so this could be quite a bit of work. I will check
and see but it won't be a high priority since this is essentially an
enhancement request.

> 
> 
> Do you mean adding an LDAP_URI entry in /etc/sysconfig/autofs?.

Yes, if you wish, or ldap.conf, as you tried below.

> 
> We try uncommented this lines  in the file but do not add any LDAP_URI.
> #
> MAP_OBJECT_CLASS="automountMap"
> ENTRY_OBJECT_CLASS="automount"
> MAP_ATTRIBUTE="automountMapName"
> ENTRY_ATTRIBUTE="automountKey"
> VALUE_ATTRIBUTE="automountInformation"
> #

That's not necessary, although it does save automount from
having to work it out.

> 
> Then change /etc/auto.master last line from +auto.master to +auto_master
> (solaris way), and works.

That will only work if you do not have a file /etc/auto_master
on the local machine. If you set MASTER_MAP_NAME to "auto_master"
and rename /etc/auto.master to /etc/auto_master then autofs will
know you don't mean to recursively include /etc/auto_master, and
move on to the next nss source, so no-one can cause a problem
by accidentally creating a /etc/auto_master without it being
noticed. This, of course, assumes /etc/nsswitch.conf has
"automount: files ldap" in it.

> 
> Then modify the firewall to block traffic to the first server defined in
> /etc/ldap.conf and still works, after a time out the client contacted to the
> second server and get the information needed by automounter.
> 
> 
> This means we have to modify all the clients, I would prefer the other way
> round when you just modify in the server and then data is populated.
> 
> But works, so thanks a lot.    

As I say, I'll check, maybe we can improve the situation, but
I'm not sure yet how much work it will be.

Ian

Hi Ian

Solaris client work with two files(once set /etc/nsswitch.conf and /etc/auto_master).

/var/ldap/ldap_client_file
/var/ldap/ldap_client_cred

The first one is where you define with other things the server list, preferred server list, and profile.

NS_LDAP_FILE_VERSION= 
NS_LDAP_SERVERS= 
NS_LDAP_SEARCH_BASEDN= 
NS_LDAP_AUTH= 
NS_LDAP_SEARCH_REF= 
NS_LDAP_SEARCH_SCOPE= 
NS_LDAP_SEARCH_TIME= 
NS_LDAP_SERVER_PREF= 
NS_LDAP_CACHETTL= 
NS_LDAP_PROFILE= 
NS_LDAP_CREDENTIAL_LEVEL= 
NS_LDAP_SERVICE_SEARCH_DESC= 
NS_LDAP_SERVICE_SEARCH_DESC= 
NS_LDAP_SERVICE_SEARCH_DESC= 
NS_LDAP_SERVICE_SEARCH_DESC= 
NS_LDAP_BIND_TIME= 

In the second file is defined the user and encrypted password to bind to server.

With this information the client contact to the server (the first of the list if available) to get information defined in the profile the client holds to. Then with this, the client knows how to get information and where can find them.

# /usr/lib/ldap/ldap_cachemgr -g

cachemgr configuration:
server debug level          0
server log file "/var/ldap/cachemgr.log"
number of calls to ldapcachemgr     431158

cachemgr cache data statistics:
Configuration refresh information: 
  Previous refresh time: 2010/08/16 08:09:09
  Next refresh time:     2010/08/16 08:19:09
Server information: 
  Previous refresh time: 2010/08/16 08:09:09
  Next refresh time:     2010/08/16 08:14:19
  server: XX.XX.XX.XX, status: UP
  server: XX.XX.XX.XX, status: UP
  server: XX.XX.XX.XX, status: UP
  server: XX.XX.XX.XX, status: UP
Cache data information: 
  Maximum cache entries:          256
  Number of cache entries:          0


So if you modify the profile you will modify the client configuration, also you can have multiple profiles, this let us isolate telescopes from network failure quite well.

If this way is deprecated in linux we will move to the current one. I do not want to insist in this. Thanks for advice.


I tested this and do not work for us.

# grep autom /etc/nsswitch.conf
automount:  files ldap
#

Create a /etc/auto_master

# cat /etc/auto-master
+auto_master
#

set in /etc/sysconfig/autofs

MASTER_MAP_NAME="auto_master"

and comment the following.
#
#MAP_OBJECT_CLASS="automountMap"
#ENTRY_OBJECT_CLASS="automount"
#MAP_ATTRIBUTE="automountMapName"
#ENTRY_ATTRIBUTE="automountKey"
#VALUE_ATTRIBUTE="automountInformation"
#

After restart autofs do not list my user for example.

The way it work is removing the comments to the above five params.

Cheers

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.