What is the automount entry in /etc/nsswitch.conf?

The goal, here, is to make things work like Solaris.  We'll work to fix this so
that you don't have to use separate maps.

Thanks for this comprehensive bug report!

For completeness I'd like to see /etc/openldap/ldap.conf and the debug logs for
the case you want to work (the Solaris auto_master).

$ grep automount /etc/nsswitch.conf
automount:  files ldap

BTW, it was good to meet you at the Red Hat Summit in Nashville.  The
automounter is probably our single biggest source of tickets and complaints here
at TI and I'm very excited to see the hard work you've put into autofs-5.0!  I
want to help test and improve it as much as possible so let me know if you need
any more details from me or if you want me to test something.

Jeff Bastian

Yes, it was good to meet you, too.  I have to give all of the credit for v5 to
Ian.  He's been working his tail off for the past 5 months on the thing.  We
wouldn't be anywhere near where we are without his hard work!

We've got a deadline looming, so we really need to get this code in shape.  If
you have time to dedicate to testing and feedback, it would be greatly
appreciated!  I'm mucking about in the LDAP module now, so I'll take a look at
your issues straight away.  Comments and suggestions about configuration are
also welcome.  Get them in now, before we freeze!

Thanks, and don't forget to post your ldap.conf and debug logs.  ;)

One last comment before the weekend: on Solaris, the /etc/auto_master file only
needs
  +auto_master
and it will find the map in LDAP.  If I don't need to put
  +automountMapName=auto_master,ou=dal.design
in the Linux /etc/auto.master, that would be great!

(In reply to comment #0)
> Description of problem:
> The new autofs doesn't read & parse our auto_master map from LDAP.

But it "will" when we've finished here.

> 
> My fc6test1 system is configured as an LDAP client and I can authenticate and
> login as a user from LDAP, but the new automounter is having problems.
> 
> I currently have two different auto_master maps in my LDAP server:
>   auto_master:        used for Solaris LDAP clients
>   auto_master_linux:  used for Linux (RHEL3 & RHEL4) LDAP clients
> I will attach the two auto_master maps to this BZ.
> 
> I configured my fc6test1 system's /etc/sysconfig/autofs file for the LDAP schema
> that we're using (automountKey, automountInformation, etc.) but when I started
> autofs it did not find the auto_master map from LDAP.

Yes. Perhaps there's something to be learned about the way Solaris
looks for it's maps that's not in the published documentation.

Could you also change the DEFAULT_MASTER_MAP_NAME from auto.master
to auto_master in /etc/sysconfig/autofs.

> 
> Next, I changed the /etc/auto.master file to
>   +auto_master
> but that didn't help.

With the nsswitch configuration you're using, if there's
no /etc/auto_master this should also find the map in LDAP
the way we expect.

> 
> After reading the man page for the new auto.master, I changed /etc/auto.master to
>   +automountMapName=auto_master,ou=dal.design
> and turned on "debug" level logging.  After restarting the automounter, I
> finally got somewhere: it found the auto_master in my LDAP server, but it didn't
> find any of the other maps because it looked for the other maps in /etc instead
> of in LDAP.  This was left in /var/log/messages:
>   read_file_source_instance: file map /etc/auto_home not found

Mmmm ... I'll investigate this.

> 
> I was hoping that the new automounter would use the same format for auto_master
> as Solaris so that I could delete the special auto_master_linux table, but I
> guess not.

No, this should use your existing maps and we will make it do so.

> 
> Next, I changed /etc/auto.master to
>   +automountMapName=auto_master_linux,ou=dal.design
> and restarted the automounter.  This time it failed to find the map in the LDAP
> server.  I used the same syntax as the previous step -- I just changed the map
> name -- but it left this in /var/log/messages
>    lookup_init: lookup(file): file map
> /etc/automountMapName=auto_master_linux,ou=dal.design missing or not readable
> 
> The map is there and readable via 
>   ldapsearch -x -LLL -b automountMapName=auto_master_linux,ou=dal.design
> but the automount daemon can't read it.
> 
> Apparently the daemon is checking for auto.master and auto_master and when it
> found the non-standard name auto_master_linux, it decided to treat it like a
> file map instead of an LDAP map.  So, I next tried
>   +//ldapservername/automountMapName=auto_master_linux,ou=dal.design
> and restarted autofs.  This time it recognized the syntax as an LDAP map and it
> tried to read the map, but it didn't like the map; it left this in
/var/log/messages
>   master_error: syntax error while parsing map.
> 
> Even if this did work, it's not very desirable because I don't want to have to
> put the LDAP server name in the auto.master file.  The automount daemon should
> be able to read that from /etc/ldap.conf and /etc/openldap/ldap.conf so it's
> redundant to put it in auto.master.

Not quite like that I hope.

We don't want to read product specific LDAP config files.
I thought it reasonable to assume that the LDAP defaults
would be configured as required in these files. They are
used to supply default values for LDAP library functions.

> 
> It looks like I'm going to have to create another auto_master map that uses the
> new syntax //ldapserver/dn in the automountInformation field.  I'd rather not
> have to do that, though.  The automounter should be able to read the same style
> auto_master map that Solaris uses to be able to get to the rest of the maps; the
> Solaris auto_master only specifies the map name and the mount options and it
> uses nsswitch.conf to search files, NIS, LDAP, etc. for this map.

Please, no, don't make life hard for yourself.
We need autofs to work for us not against us.

> 
> At the very least, it should be somewhat backwards compatible with autofs-4.x
> and use the same auto_master_linux map that we're using in production today.
> 
> Version-Release number of selected component (if applicable):
> autofs-5.0.0_beta4-11

I don't think it will improve the situation but it would be
best if we worked with the latest package from Rawhide for this.

Look for autofs-5.0.0_beta5-3 or later in Rawhide (hopefully
it will be on the RedHat server by Monday) if not use -2.

(In reply to comment #5)
> 
> BTW, it was good to meet you at the Red Hat Summit in Nashville.  The
> automounter is probably our single biggest source of tickets and complaints here
> at TI and I'm very excited to see the hard work you've put into autofs-5.0!  I
> want to help test and improve it as much as possible so let me know if you need
> any more details from me or if you want me to test something.

It's fantastic that RedHat have given me the oppertunity
to make this happen. I've spent years wanting desperately
to give Linux autofs a comparable feature set to other industry
automounters have always had to give priority to earning a
living and ended up to tierd at days end to really make a
difference.

Both Jeff and I have are putting in a big effort on this.
Thanks.

(In reply to comment #13)

First I'd like to appologize. If I'd known you would be at work
on Saturday I would have posted "in progress patches" which would
have saved you a bunch of time.

I haven't finished working on this yet but it's Sunday and I've
got a few things to do so I probably won't complete this till your
Monday morning.

> Created an attachment (id=131482) [edit]
> /var/log/debug messages for autofs with various settings
> 
> To summarize, it looks like you want me to try:
> 1. Enable daemon.* in syslog.conf
> 2. Change DEFAULT_MASTER_MAP_NAME from auto.master to auto_master
>    in /etc/sysconfig/autofs
> 3. Upgrade to autofs-5.0.0_beta5-3
> 4. Explain /etc/automap
> 
> First, let me tackle #4.  The /etc/automap/* stuff is something local to TI. 
> One of our sys admins, Victor Burns, wrote a daemon called dmapd that generates
> and keeps up-to-date the /etc/automap/* automount maps which are used by
> ClearCase.  (An article on this was published recently in Sys Admin magazine:
> http://www.samag.com/articles/2006/0606/).  So, for the purposes of our
> testing, you can ignore all /etc/automap related errors since I haven't even
> attempted to install ClearCase on fc6test1.

Great.
Well probably see that over here in a month or two.

> 
> Next, I turned on 'daemon.*  /var/log/debug' on my syslog config to capture
> more details.

We will probably need that anyway.

> 
> Then I ran 'yum update autofs' and it upgraded it to autofs-5.0.0_beta5-2. 
> After doing so, though, I can't even get as far as I did yesterday.  Now it
> seems to have problems connecting to our LDAP server at all.  I've tried
>   +auto_master
>   +automountMapName=auto_master,ou=dal.design
>   +//dsbdirnh04.itg.ti.com/automountMapName=auto_master,ou=dal.design
> in /etc/auto.master and it can't connect to the LDAP server with any of those. 
> I'll attach the /var/log/debug file with the messages from starting the daemon
> with each of these three lines.

Don't wast any more time on this.
Let me complete my analysis and testing on the existing report.
I have found and fixed several problems.

> 
> Finally, I changed DEFAULT_MASTER_MAP_NAME from auto.master to auto_master in
> /etc/sysconfig/autofs, but that didn't help either.  The debug messages are
> also included in the log.

Yes. But we will need to do that for now.
Jeff and I will need to discuss how we will handle the dual names.

> 
> Question: do I need an /etc/autofs_ldap_auth.conf file?  I can query the
> automount maps from the LDAP server with no encryption and with an anonymous
> bind so I don't think I should need to set anything in this file.  (Only the
> encrypted password is hidden and it requires an authenticated user with TLS to
> get this information.)

You do but an appropiate default isn't installed by the package.
I may need to do more on this but having a default file with everything
disabled will be enough.

Another suupid mistake on my part. 
I've already fixed this.

Ian

Created attachment 131494 [details]
Correct spelling error in default config.

Thought I'd fixed this ages ago.
Cut and paste is a wonderful thing especially when you
copy a mistake everywhere.

I found that, for some reason I haven't figured out yet
that the package update didn't install a .rpmnew when I
made this change. So keep your eye out. The change is
quite straight forward as you can see from the patch.

Created attachment 131495 [details]
Fix default auth config not being installed.

This mistake is really dumb.
It got past both Jeff and I.

Created attachment 131496 [details]
Change LDAP query method as my test db was incorrect.

This is what caused much of the trouble.
I had an additional attribute in my LDAP entries.
I don't remember whay I did that but it's simply not the way it
is in practice.

As you can see from the patches the CHANGELOG is updated by them so they
need to be allpied in the order posted.

They were created against autofs-5.0.0_beta5-3 so they will need to
be applied to that for the same reason. You have that revision now so
that should be fine.

I haven't quite finished working on this but I'm hopefull that these
patches will get autofs working with your Solaris maps. The
auto.master -> auto_master and the change for the default schema should
be the only changes needed.

(In reply to comment #13)
> Created an attachment (id=131482) [edit]
> /var/log/debug messages for autofs with various settings
> 

Each of these log segments show the bug caused by the ldap auth
config file not being installed.

For now I've altered the install to install it with all options
disabled (autofs-5.0.0_beta5-auth-config.patch above) but there
may be more work needed to make sure this problem doesn't come
up again in a different form.

Created attachment 131534 [details]
Correct spelling error in default config.

Created attachment 131535 [details]
Change ldap defaults code to handle missing auth config.

Created attachment 131537 [details]
Fix mistake in parsing old style LDAP specs.

Created attachment 131538 [details]
Update LDAP so that new query methos also works for old syntax.

Created attachment 131539 [details]
Fix couple of compile warnings.

Hi Jeff,

These patches may resolve the issues that you have. I've done a fair
bit of testing with them.

I've commited all this and pushed it to Rawhide.
To save you the hasstle of applying the patches yourself I can
put rpms for the archs you need on kernel.org.

Which would you like?

Ian

(In reply to comment #14)
> First I'd like to appologize. If I'd known you would be at work
> on Saturday I would have posted "in progress patches" which would
> have saved you a bunch of time.

Oh, don't worry about it.  I usually don't work on Saturdays, but I was curious
 to see if you and Jeff had replied to my latest post, and since you had, I
decided to run a couple more tests with the latest version of autofs.  I
apologize for making you work on the weekend!

(In reply to comment #25)
> I've commited all this and pushed it to Rawhide.
> To save you the hasstle of applying the patches yourself I can
> put rpms for the archs you need on kernel.org.
> 
> Which would you like?


If you have an i386 RPM, that'd be great.  And if you have the src RPM, I can
use that to rebuild for other archs if I need them.

(In reply to comment #27)
> (In reply to comment #25)
> > I've commited all this and pushed it to Rawhide.
> > To save you the hasstle of applying the patches yourself I can
> > put rpms for the archs you need on kernel.org.
> > 
> > Which would you like?
> 
> 
> If you have an i386 RPM, that'd be great.  And if you have the src RPM, I can
> use that to rebuild for other archs if I need them.

I've put them on kernel.org in my people directory:
http://www.kernel.org/pub/linux/kernel/people/raven

They are revision -4.
Hopefully they will improve the situation.

Ian

(In reply to comment #14
> > 
> > Question: do I need an /etc/autofs_ldap_auth.conf file?  I can query the
> > automount maps from the LDAP server with no encryption and with an anonymous
> > bind so I don't think I should need to set anything in this file.  (Only the
> > encrypted password is hidden and it requires an authenticated user with TLS to
> > get this information.)
> 
> You do but an appropiate default isn't installed by the package.
> I may need to do more on this but having a default file with everything
> disabled will be enough.
> 
> Another suupid mistake on my part. 
> I've already fixed this.

Actually, you don't need to have this file installed.  If the file does not
exist, we should fall back to an anonymous bind.

If you want to do authenticated binds, then the file is necessary.  I still
haven't documented how to set it up yet, though.  I'll get around to that once
I've got it fully working!

Out of curiosity, I ran wireshark (after hunting for a while to find
where ethereal went) to sniff traffic between my fc6test1 box and the
LDAP server while running 'service autofs start'.  I think I found a
problem: my box never attempted to bind or query anything from the LDAP
server.

In the 5 minutes that I let wireshark run, there were only 10 packets
between my system and the LDAP server, and those were just keep-alive
packets and ACKs for them.  (I assume those came from nscd/nss_ldap.)

I downgraded to autofs-5.0.0_beta4-11 (as shipped with fc6test1) and
repeated the experiment.  This time there was lots of traffic between my
system and the LDAP server.

I upgraded to autofs-5.0.0_beta5-4 again and the network traffic
disappeared.

It seems that something changed between beta4 and beta5 that broke how
autofs tries to connect to the LDAP server.

Well, I can't argue with your test results, but according to the logs you
provided, it seems the autofs is attempting an anonymous bind.  To further muddy
the waters, I can't reproduce this problem.

I'll continue to look at this and keep you posted.

Sometimes running a packet sniffer inside a VMware machine is problematic due to
the way VMware and promiscuous mode work together, so again, out of curiosity, I
ran ethereal on the host OS instead of inside the virtual machine.

I got the same results: running 'service autofs start' produced no traffic
between the fc6test1 system and the LDAP server.

However, I tried launching /usr/sbin/automount by hand, and there was a lot of
network traffic!

Ian, are you sure all of your patches made it into the -4 build?  I noticed that
the spelling error
  DEFAULT_MAP_OBJECT_CALSS="..."
is still in the default /etc/sysconfig/autofs file for autofs-5.0.0_beta5-4.

> Ian, are you sure all of your patches made it into the -4 build?  I noticed 
> that the spelling error
>   DEFAULT_MAP_OBJECT_CALSS="..."
> is still in the default /etc/sysconfig/autofs file for autofs-5.0.0_beta5-4.

That's probably due to the %config(noreplace) for /etc/sysconfig/autofs.

I looked through the diffs from beta4 to beta5 and nothing is jumping out at me.
 I walked through the ldap initialization path in the beta5 code, and it also
looks sane.  If anything, things should work better than before!  From your
logs, it seems that an ldap_simple_bind_s is failing.  The only reasons I can
guess for this is that either we initialized with the wrong server, or we've
corrupted the LDAP data structure.

I've got an srpm up on http://people.redhat.com/jmoyer/ti/ that adds in an extra
debug statement.  It will print out the server name we are using in the
ldap_init call.  I don't expect this will reveal anything interesting.  Most
likely, we are passing in NULL.  However, it will help remove one variable in
the equation.

So, give it a chance when you have time.  You only need to run once with this
rpm and let us know what the logs say.

I'm comparing the /etc/init.d/autofs script to see what it's doing vs me just
firing up /usr/sbin/automount and I noticed that the init script only reads
/etc/sysconfig/autofs if the file is executable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
if [ -x $confdir/autofs ]; then
        . $confdir/autofs
fi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
however, the /etc/sysconfig/autofs file does *not* have the execute bit turned
on when autofs is installed:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ ls -l /etc/syconfig/autofs
-rw-r--r-- 1 root root 1409 Jun 26 16:50 /etc/sysconfig/autofs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

However, running 'chmod +x /etc/sysconfig/autofs' still doesn't help the
automounter start correctly with 'service autofs start'...

(In reply to comment #37)
> However, running 'chmod +x /etc/sysconfig/autofs' still doesn't help the
> automounter start correctly with 'service autofs start'...


I was just browsing the automount source code and I found the
defaults_read_config() function in lib/defaults.c which reads the
/etc/sysconfig/autofs file and sets the variables appropriately.  It looks like
the chunk of code in the init script can actually be deleted since it's redundant.

(In reply to comment #38)
> (In reply to comment #37)
> > However, running 'chmod +x /etc/sysconfig/autofs' still doesn't help the
> > automounter start correctly with 'service autofs start'...
> 
> 
> I was just browsing the automount source code and I found the
> defaults_read_config() function in lib/defaults.c which reads the
> /etc/sysconfig/autofs file and sets the variables appropriately.  It looks like
> the chunk of code in the init script can actually be deleted since it's redundant.

True.
It originally wasn't in the init script but, for some reason I can't
remember, we decided to put it in.

Not a big issue atm.

(In reply to comment #34)
> Ian, are you sure all of your patches made it into the -4 build?  I noticed that
> the spelling error
>   DEFAULT_MAP_OBJECT_CALSS="..."
> is still in the default /etc/sysconfig/autofs file for autofs-5.0.0_beta5-4.

I had the same.
Mentioned that with the patch in #15.

(In reply to comment #35)
> > Ian, are you sure all of your patches made it into the -4 build?  I noticed 
> > that the spelling error
> >   DEFAULT_MAP_OBJECT_CALSS="..."
> > is still in the default /etc/sysconfig/autofs file for autofs-5.0.0_beta5-4.
> 
> That's probably due to the %config(noreplace) for /etc/sysconfig/autofs.
> 

I was hoping to see a ".rpmnew" created.

(In reply to comment #30)
> (In reply to comment #14
> > > 
> > > Question: do I need an /etc/autofs_ldap_auth.conf file?  I can query the
> > > automount maps from the LDAP server with no encryption and with an anonymous
> > > bind so I don't think I should need to set anything in this file.  (Only the
> > > encrypted password is hidden and it requires an authenticated user with TLS to
> > > get this information.)
> > 
> > You do but an appropiate default isn't installed by the package.
> > I may need to do more on this but having a default file with everything
> > disabled will be enough.
> > 
> > Another suupid mistake on my part. 
> > I've already fixed this.
> 
> Actually, you don't need to have this file installed.  If the file does not
> exist, we should fall back to an anonymous bind.

And the patch in #21 should make autofs work if it's not present.
I haven't tested that yet but the change was fairly straight forrward.

(In reply to comment #36)
> Created an attachment (id=131575) [edit]
> Attached is a log of both methods of starting the automounter.
> 
> Curiously, after it gets started, I still can't mount anything.  And if I try
> to run
>   mount server:/path/to/whatever /mnt
> by hand, the command just hangs.  I wonder why I can't do NFS now...
> 

Not that I want to point the finger but I spent several hours
wondering why I was having similar problems before looking in the
messages log only to find a raft of selinux "denied" messages.

What is your selinux setting?

(In reply to comment #40)
> (In reply to comment #34)
> > Ian, are you sure all of your patches made it into the -4 build?  I noticed that
> > the spelling error
> >   DEFAULT_MAP_OBJECT_CALSS="..."
> > is still in the default /etc/sysconfig/autofs file for autofs-5.0.0_beta5-4.
> 
> I had the same.
> Mentioned that with the patch in #15.


I know, that's why I mentioned it here.

Just to be sure I'm not going crazy, I did
   rpm -e autofs
   rpm -Uvh autofs-5.0.0_beta5-4.i386.rpm
so it was installed from scratch (i.e., no .rpmsave or .rpmnew files), and the
/etc/sysconfig/autofs file that was installed still had the spelling mistake
'CALSS' in it and the permissions were 644 instead of 755.

So, I looked at the source RPM and I see that your patch fixes the spelling error in
   samples/autofs.conf.default.in
but it doesn't touch
   redhat/autofs.sysconfig.in
   gentoo/net-fs/autofs/files/autofs.conf

I'm guessing that the patch against the samples file doesn't affect the redhat
and gentoo files.

  

(In reply to comment #39)
> True.
> It originally wasn't in the init script but, for some reason I can't
> remember, we decided to put it in.

Maybe for other distros that don't have an /etc/sysconfig (or similar)
directory?  If it relies on environment variables, those can be set with the
init script.  Of course, this init script goes looking for that file in a
sysconfig-like directory, so maybe that's not it...
 
> Not a big issue atm.

True, there are more important bugs to be fixed right now.  I just thought I'd
mention it.

(In reply to comment #43)
> Not that I want to point the finger but I spent several hours
> wondering why I was having similar problems before looking in the
> messages log only to find a raft of selinux "denied" messages.
> 
> What is your selinux setting?

I had SELinux set to enforcing, and I was checking /var/log/messages for 'avc'
errors but I didn't see any.  Just to be sure, I disabled SELinux and rebooted.
 I also noticed that even though I had the firewall disabled, the boot messages
showed it was still setting ip6tables and when it finished booting, 'ip6tables
-L' listed all kinds of IPv6 firewall rules.  This might need another BZ opened.
 In the meantime, I just disabled the ip6tables init script and I added 'alias
net-pf-10 off' to my /etc/modprobe.conf so I wouldn't have to worry about IPv6
getting in the way.

So, with SELinux disabled, no firewalls, and no IPv6, I tried to do an NFS mount
and it worked!  Of course, unlike a good scientist, I changed too many variables
at once and I'm not sure which was the culprit now, but at least I can make NFS
mounts.  :)

With that working, and with a freshly installed autofs-5.0.0_beta5-4, I edited
my /etc/sysconfig/autofs and uncommented our LDAP schema (and fixed the spelling
error), and I edited the /etc/auto.master file and changed '+auto.master' to
'+auto_master' and I ran 'service autofs start' and ... voila!  The automounter
started and it's mounting everything I ask it to!

It appears that SELinux, ip6tables, or just IPv6 in general was causing the
problems I was having earlier with no network traffic going to the LDAP server.
 I suspect it's ip6tables since I didn't see any 'avc' lines in
/var/log/messages, but I'm not sure yet.  I'll do some more testing on Wednesday
(I'm out of the office tomorrow).

Thanks for all your hard work and patience!  It's starting to look good!

Jeff B

Ooh...  one final note for tonight.  It was almost mounting everything I wanted.
 Our /apps tree makes use of the $OSREL and other variables, and we override the
default value of $OSREL from the kernel version with -DOSREL=rhel_3.0 or
-DOSREL=rhel_4.0 (otherwise our NFS servers will get lots of symlinks for the
various kernel versions).

I noticed that my /apps weren't mounting correctly, and I remembered the default
permissions on /etc/sysconfig/autofs were 644 so the /etc/init.d/autofs script
wasn't passing -DOSREL=... to the automount daemon, so I tried
  chmod 755 /etc/sysconfig/autofs
  service autofs restart
and I got this:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Starting automount: *** glibc detected *** automount: realloc(): invalid
pointer: 0x00e01822 ***
======= Backtrace: =========
/lib/libc.so.6(__libc_realloc+0x302)[0xb2958b]
automount(macro_global_addvar+0x105)[0xdf7d05]
automount(macro_parse_globalvar+0x9e)[0xdf7ece]
automount(main+0x156)[0xde3596]
/lib/libc.so.6(__libc_start_main+0xdc)[0xad7794]
automount[0xde2a91]
======= Memory map: ========
00111000-0011c000 r-xp 00000000 08:02 1674099    /lib/libgcc_s-4.1.1-20060619.so.1
0011c000-0011d000 rwxp 0000a000 08:02 1674099    /lib/libgcc_s-4.1.1-20060619.so.1
00ac2000-00bef000 r-xp 00000000 08:02 1674094    /lib/libc-2.4.90.so
00bef000-00bf1000 r-xp 0012d000 08:02 1674094    /lib/libc-2.4.90.so
00bf1000-00bf2000 rwxp 0012f000 08:02 1674094    /lib/libc-2.4.90.so
00bf2000-00bf5000 rwxp 00bf2000 00:00 0 
00ca8000-00caa000 r-xp 00000000 08:02 1674095    /lib/libdl-2.4.90.so
00caa000-00cab000 r-xp 00001000 08:02 1674095    /lib/libdl-2.4.90.so
00cab000-00cac000 rwxp 00002000 08:02 1674095    /lib/libdl-2.4.90.so
00d48000-00d58000 r-xp 00000000 08:02 1674098    /lib/libpthread-2.4.90.so
00d58000-00d59000 r-xp 0000f000 08:02 1674098    /lib/libpthread-2.4.90.so
00d59000-00d5a000 rwxp 00010000 08:02 1674098    /lib/libpthread-2.4.90.so
00d5a000-00d5c000 rwxp 00d5a000 00:00 0 
00d8d000-00d8e000 r-xp 00d8d000 00:00 0          [vdso]
00d8e000-00da7000 r-xp 00000000 08:02 1674093    /lib/ld-2.4.90.so
00da7000-00da8000 r-xp 00018000 08:02 1674093    /lib/ld-2.4.90.so
00da8000-00da9000 rwxp 00019000 08:02 1674093    /lib/ld-2.4.90.so
00dde000-00e01000 r-xp 00000000 08:02 2395545    /usr/sbin/automount
00e01000-00e02000 rw-p 00023000 08:02 2395545    /usr/sbin/automount
080c5000-080e6000 rw-p 080c5000 00:00 0          [heap]
b7f1e000-b7f1f000 rw-p b7f1e000 00:00 0 
b7f3a000-b7f3c000 rw-p b7f3a000 00:00 0 
bf8e0000-bf8f5000 rw-p bf8e0000 00:00 0          [stack]
/etc/init.d/autofs: line 37:  2888 Aborted                 $prog $OPTIONS
                                                           [FAILED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That looks like fun...

(In reply to comment #44)
> (In reply to comment #40)
> > (In reply to comment #34)
> So, I looked at the source RPM and I see that your patch fixes the spelling
error in
>    samples/autofs.conf.default.in
> but it doesn't touch
>    redhat/autofs.sysconfig.in
>    gentoo/net-fs/autofs/files/autofs.conf
> 
> I'm guessing that the patch against the samples file doesn't affect the redhat
> and gentoo files.

Oops.

(In reply to comment #46)
> (In reply to comment #43)
> 
> With that working, and with a freshly installed autofs-5.0.0_beta5-4, I edited
> my /etc/sysconfig/autofs and uncommented our LDAP schema (and fixed the spelling
> error), and I edited the /etc/auto.master file and changed '+auto.master' to
> '+auto_master' and I ran 'service autofs start' and ... voila!  The automounter
> started and it's mounting everything I ask it to!
> 
> It appears that SELinux, ip6tables, or just IPv6 in general was causing the
> problems I was having earlier with no network traffic going to the LDAP server.
>  I suspect it's ip6tables since I didn't see any 'avc' lines in
> /var/log/messages, but I'm not sure yet.  I'll do some more testing on Wednesday
> (I'm out of the office tomorrow).
> 
> Thanks for all your hard work and patience!  It's starting to look good!

That's fantastic.
With the Solaris maps unchanged?

We have work to do for our selinux policy that's for sure.
But we know about it and it should be fairly straight forward once
we have a better understanding of how to setup selinux policy.

(In reply to comment #47)
> Ooh...  one final note for tonight.  It was almost mounting everything I wanted.
>  Our /apps tree makes use of the $OSREL and other variables, and we override the
> default value of $OSREL from the kernel version with -DOSREL=rhel_3.0 or
> -DOSREL=rhel_4.0 (otherwise our NFS servers will get lots of symlinks for the
> various kernel versions).
> 
> I noticed that my /apps weren't mounting correctly, and I remembered the default
> permissions on /etc/sysconfig/autofs were 644 so the /etc/init.d/autofs script
> wasn't passing -DOSREL=... to the automount daemon, so I tried
>   chmod 755 /etc/sysconfig/autofs
>   service autofs restart
> and I got this:
> 

Ha.

Looking at that crash, spectacular is the word that comes to mind.

Jeff, I really appreciate your effort testing this, we just don't get
enough people doing this.

(In reply to comment #47)
> Ooh...  one final note for tonight.  It was almost mounting everything I wanted.
>  Our /apps tree makes use of the $OSREL and other variables, and we override the
> default value of $OSREL from the kernel version with -DOSREL=rhel_3.0 or
> -DOSREL=rhel_4.0 (otherwise our NFS servers will get lots of symlinks for the
> various kernel versions).
> 
> I noticed that my /apps weren't mounting correctly, and I remembered the default
> permissions on /etc/sysconfig/autofs were 644 so the /etc/init.d/autofs script
> wasn't passing -DOSREL=... to the automount daemon, so I tried
>   chmod 755 /etc/sysconfig/autofs
>   service autofs restart
> and I got this:
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Starting automount: *** glibc detected *** automount: realloc(): invalid
> pointer: 0x00e01822 ***

Revision autofs-5.0.0_beta5-6 has made it to the Rawhide server this
morning. Those release guys do a great job.

It fixes this problem.
Turned out to be fairly simple.

It also updates the config files that you spotted, that I missed.

Give it a try when you have time please.

Ian

I had actually just run
  yum check-update autofs
a few minutes ago to see if a new version was available and then you updated the
ticket.

I've upgraded to autofs-5.0.0_beta5-6 and now the automounter doesn't panic on
start up, however, I still had to run
  chmod +x /etc/sysconfig/autofs
in order to get the init script to actually read the file and pass in
'-DOSREL=...' as a command line option.

I notice the autofs.spec file has
  install -m 644 redhat/autofs.sysconfig $RPM_BUILD_ROOT/etc/sysconfig/autofs

That should be
  install -m 755

The good news, though, is that it's working!  It's automounting everything I ask
it to now including /apps mounts with a custom $OSREL.

Thank you!
Jeff

(In reply to comment #52)
> That should be
>   install -m 755


I take it back.  The /etc/sysconfig/* files aren't really scripts so they
shouldn't be executable.  The autofs init script is the only one that does
  if [ -x $confdir/autofs ]; then
    . $confdir/autofs
  fi

All the other init scripts simply run
  . /etc/sysconfig/foo
without checking for executable permissions.  I think the autofs init script
should either remove the -x check or change it to -r.

Jeff

By the way, I am using the Solaris auto_master map, i.e., no special map for
Linux needed!

I'm also leaving the default auto.master map name set to auto.master in
/etc/sysconfig/autofs, and I'm modifying /etc/auto.master to use '+auto_master'.
 This will allow us to use a local map if we need to for whatever reason.

(In reply to comment #53)
> (In reply to comment #52)
> > That should be
> >   install -m 755
> 
> 
> I take it back.  The /etc/sysconfig/* files aren't really scripts so they
> shouldn't be executable.  The autofs init script is the only one that does
>   if [ -x $confdir/autofs ]; then
>     . $confdir/autofs
>   fi
> 
> All the other init scripts simply run
>   . /etc/sysconfig/foo
> without checking for executable permissions.  I think the autofs init script
> should either remove the -x check or change it to -r.

Thought I'd already done that.
So will do, Thanks.

(In reply to comment #54)
> By the way, I am using the Solaris auto_master map, i.e., no special map for
> Linux needed!
> 
> I'm also leaving the default auto.master map name set to auto.master in
> /etc/sysconfig/autofs, and I'm modifying /etc/auto.master to use '+auto_master'.
>  This will allow us to use a local map if we need to for whatever reason.
> 

That's always my choice, more flexibility and this stuff can usually be
added to a standard build without much hastle.

Excellent, exactly what we want.

I've done some experimenting with SELinux, ip6tables, and IPv6 in general this
morning and SELinux does indeed seem to be the cause of the problems I was
having earlier with the automounter.  In fact, after re-enabling SELinux, I
noticed that other services like ntp also broke.  It seems the new SELinux
policies in fc6test1 are overly aggressive.  Should I open a new BZ on this?

Yes, please file a bug against either selinux-policy-targeted (I think that's
the right one).

Thanks!

See BZ 197089.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197089

(In reply to comment #55)
> Thought I'd already done that.
> So will do, Thanks.


I just upgraded to autofs-5.0.0_beta6-2 on my fc6test1 box and I've verified the
init script uses -r instead of -x for /etc/sysconfig/autofs now.

I think this covers everything for this BZ so we can probably close it now.  The
only item left is the SELinux policy getting in the way and there's a separate
BZ for that.

Thanks again!
Jeff

(In reply to comment #60)
> (In reply to comment #55)
> > Thought I'd already done that.
> > So will do, Thanks.
> 
> 
> I just upgraded to autofs-5.0.0_beta6-2 on my fc6test1 box and I've verified the
> init script uses -r instead of -x for /etc/sysconfig/autofs now.
> 
> I think this covers everything for this BZ so we can probably close it now.  The
> only item left is the SELinux policy getting in the way and there's a separate
> BZ for that.
> 
> Thanks again!

Thank you for your perseverance.
Ian