> ----- Original Message -----
> From: lf...@cruziero.com
> Sent: 04/02/13 10:41 AM
> To: BLFS Support List
> Subject: Re: [blfs-support] Autofs problem on LFS7.2
>
> > Date: Sun, 31 Mar 2013 09:38:25 -0400
> > From: "Cliff McDiarmid" <cliffhan...@gardener.com>
> > To: "BLFS Support List" <blfs-support@linuxfromscratch.org>
> > Subject: Re: [blfs-support] Autofs problem on LFS7.2
> >
> > > Cliff McDiarmid wrote:
> > >
> > > > Got it! After starting autofs with 'automount -v -f -d
> .
> .
> > >
> > > Cliff, it would be nice to write up a short summary of what was wrong
> > > and the ultimate fix.
> >
> > Right, I'm going to attempt to summarise a very long thread which addressed
> > an automount problem(once again I must thank akhiezer for his help and
> > patience in solving it).
> >
> > Autofs-5.0.7 was built according to the compile/install instructions for
> > autofs in the blfs book, but I did a 'client-only' install of
> > OpenLDAP-2.4.33 and at one point compiled it against MIT Kerberos
> > V5-1.10.3, but this was later removed.
> > Either way I don't believe this had any bearing on the outcome.
> >
> > Autofs- 5.0.7 always started from boot up but failed create any dir.
> > specified in the '/etc/automaster' file or to mount it when a usbstick was
> > inserted.
> >
> > I believe(correct me if I'm wrong akhiezer)that the solution boiled down to
> > two changes that were made.
> >
> > 1) I reverted a change made by the
> > 'autofs-5.0.6-fix-libtirpc-name-clash.patch' to the file 'lib/rpc_subs.c'
> > in the source distrib, and commented-out the code:
> >
> > ---
> > #ifdef WITH_LIBTIRPC
> > #undef auth_destroy
> > #define auth_destroy(auth) \
> > do { \
> > int refs; \
> > if ((refs = auth_put((auth))) == 0) \
> > ((*((auth)->ah_ops->ah_destroy))(auth));\
> > } while (0)
> > #endif
> > ---
> > thus:
> > ===
> > /*
> > #ifdef WITH_LIBTIRPC
> > #undef auth_destroy
> > #define auth_destroy(auth) \
> > do { \
> > int refs; \
> > if ((refs = auth_put((auth))) == 0) \
> > ((*((auth)->ah_ops->ah_destroy))(auth));\
> > } while (0)
> > #endif
> > */
> > ===
> >
> > I then recompiled Autofs.
> >
> > 2) I adjusted the '/etc/auto.master' file to read:
> >
> > ---
> > /testautomount file:/etc/auto.testautomount
> > ---
> >
> > rather than:
> >
> > ---
> > /testautomount /etc/auto.testautomount
> > ---
> >
> > This was to be more explicit about the type of map that was being used. A
> > minor change, but one that worked.
> >
> >
> > *Please note that the 'auto.testautomount' dir. was a test point and this
> > would normally be 'auto.misc'.*
> >
> >
> > Cliff
> >
>
>
> I'd expect that 'reason 2)' is a bit of a red-herring: it's likely a
> 'chmod 644 /etc/auto.testautomount' change that would make the difference;
> the
> 'file:' stuff is really only to override any exec-permissions that are still
> on '/etc/auto.testautomount' . Here, on autofs-5.0.5, having any exec-perms
> on
> '/etc/auto.testautomount', and no 'file:' or 'file,sun:' &c labels in
> auto.master, causes automount to erroneously try to interpret the map-file as
> being a program. Then, if I do use 'file:' or 'file,sun:' in auto.master, and
> whether '/etc/auto.testautomount' has any exec-permissions set or not, then
> automount interprets the map-file as being an ordinary file and not as a
> program
> or any other type.
Just to say that my '/etc/auto.testautomount' always had permissions 644. In
fact autofs-5.0.7 installs permissions 644 to the 'auto.master' file from the
outset, at least here. Sorry if i gave the wrong impression originally.
> As for 'reason 1)': per earlier note today, one would really want to do the
> recompile with the original libtirpc code in its original form (i.e. _NOT_
> commented-out), and using the './configure ...... --without-...
> --without-hesiod
> --without-libtirpc --without-... ....', and with '/etc/auto.testautomount'
> having
> permissions 644; and see if all works ok.
>
> If it works ok, then one would go 'round the loop again with the sole, single
> change of omitting the '--without-libtirpc' from the './configure ...' line,
> and
> see if things now _don't_ work ok.
>
> If it does break, then go 'round the loop again but this time make the sole,
> single change of commenting-out the libtirpc block of code, and see if things
> now work ok.
>
> Without that or similar methodology, in particular (in this case) changing
> just
> one thing at a time, then one can't really put good reliable info into
> book/wiki,
> or in report to upstream, or even into one's own notes.
You are right of course. This needs doing and I will try it in the near future
and get back. This thread just won't lay down.
regards
Cliff
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
