[ANNOUNCE] autofs 5.0.0 beta2

[ANNOUNCE] autofs 5.0.0 beta2

[Ian Kent]

Hi all,

It's time for an updated beta.

autofs
======

The package can be found at:

ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5

It is autofs-5.0.0_beta2.tar.[gz|bz2]

No source rpm is there as it can be produced by using:

rpmbuild -ts autofs-5.0.0_beta2.tar.gz

and the binary rpm by using:

rpmbuild -tb autofs-5.0.0_beta2.tar.gz

See the INSTALL file for information about configure options and
kernel requirements.

Here are the entries from the CHANGELOG which outline the updates:

9/5/2006 autofs-5.0.0_beta2
---------------------------
- re-organize functions for direct mount and expire to eliminate
  pthread compile error.
- reap return code from child at startup.
- add check for self inclusion when including maps.
- add plus map inclusion depth limit.
- fix logic to check if map update is needed.
- fix shutdown wait for submounts again (and again ...).
- add check for filesystem autofs in /proc/filesystems in case
  it's complied in the kernel.
- update Gentoo ebuild.
- updated man pages based on feedback from Jeff Moyer.

Ian

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Guillaume Rousse]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

Ian Kent wrote:
> Hi all,
> 
> It's time for an updated beta.
> 
> autofs
> ======
> 
> The package can be found at:
> 
> ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5
> 
> It is autofs-5.0.0_beta2.tar.[gz|bz2]
> 
> No source rpm is there as it can be produced by using:
> 
> rpmbuild -ts autofs-5.0.0_beta2.tar.gz
> 
> and the binary rpm by using:
> 
> rpmbuild -tb autofs-5.0.0_beta2.tar.gz
> 
> See the INSTALL file for information about configure options and
> kernel requirements.
I couldn't test it really yet, as mandriva development kernel is still
2.6.14, however here are a few remarks:

First, stripping binaries by default, especially during compilation, is
opposite behaviour of standard autotools-based procedure, where it only
occurs if you install with "make stripinstall". I need to have debug
symbols present when building a package, as they are automatically for
extracting them in a separate debug package. I've found that "make
DEBUG=1" would prevent stripping, but it also defines an additional
CFLAG with unknown result :/

Second, the two attached patches don't apply anymore:
- autofs-4.1.4-signal-race-fix.patch seems to refer to parts of
automount.c not existing anymore
- autofs-4.1.1-get-best-mount.patch refer to a 4 args get_best_mount()
function that only has 3 args nowadays

Third, the following patches still apply, but I got no clue about their
usefulness:
- autofs-4.1.0-hesiod-bind.patch
- autofs-4.1.0-loop.patch

I'd prefer to see those patches merged, rather than maintaining a
patched package.

[-- Attachment #2: autofs-4.1.0-hesiod-bind.patch --]
[-- Type: text/plain, Size: 1752 bytes --]

--- autofs-4.1.0/modules/lookup_hesiod.c.orig	2003-09-29 04:22:35.000000000 -0400
+++ autofs-4.1.0/modules/lookup_hesiod.c	2004-02-18 11:56:01.000000000 -0500
@@ -34,6 +34,9 @@
 
 struct lookup_context {
 	struct parse_mod *parser;
+#ifdef HESIOD_BIND
+	void *hesiod_context;
+#endif
 };
 
 int lookup_version = AUTOFS_LOOKUP_VERSION;	/* Required by protocol */
@@ -54,6 +57,13 @@ int lookup_init(const char *mapfmt, int 
 	/* Initialize the resolver. */
 	res_init();
 
+#ifdef HESIOD_BIND
+	/* Initialize the hesiod context. */
+	if (hesiod_init(&(ctxt->hesiod_context)) != 0) {
+		syslog(LOG_CRIT, MODPREFIX "hesiod_init(): %m");
+		return 1;
+	}
+#endif
 	/* If a map type isn't explicitly given, parse it as hesiod entries. */
 	if (!mapfmt)
 		mapfmt = MAPFMT_DEFAULT;
@@ -83,7 +93,11 @@ int lookup_mount(const char *root, const
 	chdir("/");		/* If this is not here the filesystem stays
 				   busy, for some reason... */
 
+#ifdef HESIOD_BIND
+	hes_result = hesiod_resolve(ctxt->hesiod_context, name, "filsys");
+#else
 	hes_result = hes_resolve(name, "filsys");
+#endif
 
 	if (!hes_result) {
 		syslog(LOG_NOTICE, MODPREFIX "entry \"%s\" not found in map\n", name);
@@ -94,7 +108,11 @@ int lookup_mount(const char *root, const
 		  name, hes_result[0]));
 	rv = ctxt->parser->parse_mount(root, name, name_len, hes_result[0],
 				       ctxt->parser->context);
+#ifdef HESIOD_BIND
+	hesiod_free_list(ctxt->hesiod_context, hes_result);
+#else
 	free(hes_result);
+#endif
 	return rv;
 }
 
@@ -104,6 +122,9 @@ int lookup_done(void *context)
 {
 	struct lookup_context *ctxt = (struct lookup_context *) context;
 	int rv = close_parse(ctxt->parser);
+#ifdef HESIOD_BIND
+	hesiod_end(ctxt->hesiod_context);
+#endif
 	free(ctxt);
 	return rv;
 }

[-- Attachment #3: autofs-4.1.0-loop.patch --]
[-- Type: text/plain, Size: 489 bytes --]

--- autofs-4.1.0/modules/mount_autofs.c.org	2004-02-18 12:04:40.000000000 -0500
+++ autofs-4.1.0/modules/mount_autofs.c	2004-02-18 12:05:37.000000000 -0500
@@ -95,12 +95,12 @@ int mount_mount(const char *root, const 
 	}
 
 	if (options) {
-		char *p = options;
+		char *p = options - 1;
 		do {
 			argc++;
 			if (*p == ',')
 				p++;
-		} while ((p = strchr(p, ',')) != NULL);
+		} while ((p = strchr(p + 1, ',')) != NULL);
 	}
 	argv = (char **) alloca((argc + 1) * sizeof(char *));
 

[-- Attachment #4: autofs-4.1.1-get-best-mount.patch --]
[-- Type: text/plain, Size: 475 bytes --]

--- autofs-4.1.2/modules/mount_nfs.c.orig	2004-04-14 12:02:29.917549312 -0400
+++ autofs-4.1.2/modules/mount_nfs.c	2004-04-14 12:02:40.815892512 -0400
@@ -378,7 +378,7 @@ int mount_mount(const char *root, const 
 		/* No colon, take this as a bind (local) entry */
 		local = 1;
 	} else if (!nosymlink) {
-		local = get_best_mount(whatstr, what, 0, 0);
+		local = get_best_mount(whatstr, what, 1, 0);
 		if (!*whatstr) {
 			warn(MODPREFIX "no host elected");
 			return 1;

[-- Attachment #5: autofs-4.1.4-signal-race-fix.patch --]
[-- Type: text/plain, Size: 358 bytes --]

--- autofs-4.1.3/daemon/automount.c.orig	2004-08-18 11:23:49.430470256 -0400
+++ autofs-4.1.3/daemon/automount.c	2004-08-18 11:24:45.047015256 -0400
@@ -919,8 +919,8 @@ static int st_expire(void)
 		return 1;
 
 	case EXP_STARTED:
-		ap.state = ST_EXPIRE;
 		sigprocmask(SIG_SETMASK, &ready_sigs, NULL);
+		ap.state = ST_EXPIRE;
 		return 0;
 	}
 	return 1;

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

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

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Ian Kent]

On Wed, 10 May 2006, Guillaume Rousse wrote:

Thanks for the feedback Guillaume.

> Ian Kent wrote:
> > Hi all,
> > 
> > It's time for an updated beta.
> > 
> > autofs
> > ======
> > 
> > The package can be found at:
> > 
> > ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5
> > 
> > It is autofs-5.0.0_beta2.tar.[gz|bz2]
> > 
> > No source rpm is there as it can be produced by using:
> > 
> > rpmbuild -ts autofs-5.0.0_beta2.tar.gz
> > 
> > and the binary rpm by using:
> > 
> > rpmbuild -tb autofs-5.0.0_beta2.tar.gz
> > 
> > See the INSTALL file for information about configure options and
> > kernel requirements.
> I couldn't test it really yet, as mandriva development kernel is still
> 2.6.14, however here are a few remarks:
> 
> First, stripping binaries by default, especially during compilation, is
> opposite behaviour of standard autotools-based procedure, where it only
> occurs if you install with "make stripinstall". I need to have debug
> symbols present when building a package, as they are automatically for
> extracting them in a separate debug package. I've found that "make
> DEBUG=1" would prevent stripping, but it also defines an additional
> CFLAG with unknown result :/

If this is what I think it is then there may be a patch around that I can 
use.

I'm not completely clear on what your saying though.
Could you give more details please.

> 
> Second, the two attached patches don't apply anymore:
> - autofs-4.1.4-signal-race-fix.patch seems to refer to parts of
> automount.c not existing anymore

This patch is not relevant any more.
The signal handling in the threaded environment is completely different.

> - autofs-4.1.1-get-best-mount.patch refer to a 4 args get_best_mount()
> function that only has 3 args nowadays

This patch makes get_best_mount use a long timeout always instead of a 
short timeout followed by long timeout if it the first rpc_ping fails.

I think that get_best_mount was not falling back to the long timeout so 
this patch was used to work around it. I'm fairly sure that was fixed.

Anyway, get_best_mount will go away soon as the server selection code is 
being re-written.

> 
> Third, the following patches still apply, but I got no clue about their
> usefulness:
> - autofs-4.1.0-hesiod-bind.patch

OK. I've seen this patch several times.
No one has yet been able to explain what it's for.

> - autofs-4.1.0-loop.patch

I've seen this patch before as well.
Not sure why this patch is not included.
I'll review it again.

Ian

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Ian Kent]

On Wed, 17 May 2006, Ian Kent wrote:

> 
> > - autofs-4.1.1-get-best-mount.patch refer to a 4 args get_best_mount()
> > function that only has 3 args nowadays
> 
> This patch makes get_best_mount use a long timeout always instead of a 
> short timeout followed by long timeout if it the first rpc_ping fails.
> 
> I think that get_best_mount was not falling back to the long timeout so 
> this patch was used to work around it. I'm fairly sure that was fixed.
> 
> Anyway, get_best_mount will go away soon as the server selection code is 
> being re-written.
> 

Oh .. nearly forgot.

If you really want to continue to use this patch to force the use of a 
long timeout then I think removing the fourth parameter is all that is 
needed.

Ian

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Jeff Moyer]

==> Regarding Re: [autofs] [ANNOUNCE] autofs 5.0.0 beta2; Guillaume Rousse <Guillaume.Rousse@inria.fr> adds:

Guillaume.Rousse> Ian Kent wrote:
>> Hi all,
>> 
>> It's time for an updated beta.
>> 
>> autofs ======
>> 
>> The package can be found at:
>> 
>> ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5
>> 
>> It is autofs-5.0.0_beta2.tar.[gz|bz2]
>> 
>> No source rpm is there as it can be produced by using:
>> 
>> rpmbuild -ts autofs-5.0.0_beta2.tar.gz
>> 
>> and the binary rpm by using:
>> 
>> rpmbuild -tb autofs-5.0.0_beta2.tar.gz
>> 
>> See the INSTALL file for information about configure options and kernel
>> requirements.
Guillaume.Rousse> I couldn't test it really yet, as mandriva development
Guillaume.Rousse> kernel is still 2.6.14, however here are a few remarks:

Guillaume.Rousse> First, stripping binaries by default, especially during
Guillaume.Rousse> compilation, is opposite behaviour of standard
Guillaume.Rousse> autotools-based procedure, where it only occurs if you
Guillaume.Rousse> install with "make stripinstall". I need to have debug
Guillaume.Rousse> symbols present when building a package, as they are
Guillaume.Rousse> automatically for extracting them in a separate debug
Guillaume.Rousse> package. I've found that "make DEBUG=1" would prevent
Guillaume.Rousse> stripping, but it also defines an additional CFLAG with
Guillaume.Rousse> unknown result :/

Try the attached patch.  It was made against the 4.1.3 Red Hat packages,
but you get the idea.  Basically, "make -DDONTSTRIP."

Guillaume.Rousse> Second, the two attached patches don't apply anymore: -
Guillaume.Rousse> autofs-4.1.4-signal-race-fix.patch seems to refer to
Guillaume.Rousse> parts of automount.c not existing anymore -
Guillaume.Rousse> autofs-4.1.1-get-best-mount.patch refer to a 4 args
Guillaume.Rousse> get_best_mount() function that only has 3 args nowadays

Why would you apply 4.1.x patches to 5.x?  *Quite* a lot has changed.  I
suggest dropping the patches.

Guillaume.Rousse> Third, the following patches still apply, but I got no
Guillaume.Rousse> clue about their usefulness: -

Guillaume.Rousse> autofs-4.1.0-hesiod-bind.patch

I'll do some digging on this one tomorrow.

Guillaume.Rousse> autofs-4.1.0-loop.patch

Drop this one.

-Jeff

--- autofs-4.1.3/Makefile.rules.orig	2006-04-05 12:33:53.000000000 -0400
+++ autofs-4.1.3/Makefile.rules	2006-04-05 13:15:15.000000000 -0400
@@ -22,10 +22,16 @@ CFLAGS    = -O2 -g -DDEBUG
 LDFLAGS   = -g
 STRIP     = :
 else
+ifdef DONTSTRIP
+CFLAGS    = -O2 -g
+LDFLAGS   = -g
+STRIP     = :
+else # normal compile
 CFLAGS    = -O3 -fomit-frame-pointer -Wall
 LDFLAGS   = -s
 STRIP     = strip --strip-debug
-endif
+endif # DONTSTRIP
+endif # DEBUG
 
 CC        = gcc
 CXX       = g++

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Guillaume Rousse]

Ian Kent wrote:
> On Wed, 10 May 2006, Guillaume Rousse wrote:
> 
> Thanks for the feedback Guillaume.
> 
>> Ian Kent wrote:
>>> Hi all,
>>>
>>> It's time for an updated beta.
>>>
>>> autofs
>>> ======
>>>
>>> The package can be found at:
>>>
>>> ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5
>>>
>>> It is autofs-5.0.0_beta2.tar.[gz|bz2]
>>>
>>> No source rpm is there as it can be produced by using:
>>>
>>> rpmbuild -ts autofs-5.0.0_beta2.tar.gz
>>>
>>> and the binary rpm by using:
>>>
>>> rpmbuild -tb autofs-5.0.0_beta2.tar.gz
>>>
>>> See the INSTALL file for information about configure options and
>>> kernel requirements.
>> I couldn't test it really yet, as mandriva development kernel is still
>> 2.6.14, however here are a few remarks:
>>
>> First, stripping binaries by default, especially during compilation, is
>> opposite behaviour of standard autotools-based procedure, where it only
>> occurs if you install with "make stripinstall". I need to have debug
>> symbols present when building a package, as they are automatically for
>> extracting them in a separate debug package. I've found that "make
>> DEBUG=1" would prevent stripping, but it also defines an additional
>> CFLAG with unknown result :/
> 
> If this is what I think it is then there may be a patch around that I can 
> use.
> 
> I'm not completely clear on what your saying though.
> Could you give more details please.
With a standard autotools (autoconf + automake), running ./configure && 
make && make install installs unstripped binaries. With current autofs 
build system, the same command install stripped binaries. This may be 
considered as couter-intuitive and non standard.

In a rpm building scenario, rpm takes cares of stripping them 
automatically after installation, so you may consider to be harmless to 
perform stripping during build, as the final result is the same. 
However, when you enable automatic debug package creation, rpm first 
extract debug symbols before stripping binaries, still in the final 
installation step. In this case, it is harmful to strip binaries during 
compilation.

Hence my advocacy to revert to only strip installed binaries, through a 
dedicated install target.

>> Second, the two attached patches don't apply anymore:
>> - autofs-4.1.4-signal-race-fix.patch seems to refer to parts of
>> automount.c not existing anymore
> 
> This patch is not relevant any more.
> The signal handling in the threaded environment is completely different.
> 
>> - autofs-4.1.1-get-best-mount.patch refer to a 4 args get_best_mount()
>> function that only has 3 args nowadays
> 
> This patch makes get_best_mount use a long timeout always instead of a 
> short timeout followed by long timeout if it the first rpc_ping fails.
> 
> I think that get_best_mount was not falling back to the long timeout so 
> this patch was used to work around it. I'm fairly sure that was fixed.
> 
> Anyway, get_best_mount will go away soon as the server selection code is 
> being re-written.
OK.

>> Third, the following patches still apply, but I got no clue about their
>> usefulness:
>> - autofs-4.1.0-hesiod-bind.patch
> 
> OK. I've seen this patch several times.
> No one has yet been able to explain what it's for.
> 
>> - autofs-4.1.0-loop.patch
> 
> I've seen this patch before as well.
> Not sure why this patch is not included.
> I'll review it again.
Jeff just suggested to drop it :)

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Guillaume Rousse]

Ian Kent wrote:
> On Wed, 17 May 2006, Ian Kent wrote:
> 
>>> - autofs-4.1.1-get-best-mount.patch refer to a 4 args get_best_mount()
>>> function that only has 3 args nowadays
>> This patch makes get_best_mount use a long timeout always instead of a 
>> short timeout followed by long timeout if it the first rpc_ping fails.
>>
>> I think that get_best_mount was not falling back to the long timeout so 
>> this patch was used to work around it. I'm fairly sure that was fixed.
>>
>> Anyway, get_best_mount will go away soon as the server selection code is 
>> being re-written.
>>
> 
> Oh .. nearly forgot.
> 
> If you really want to continue to use this patch to force the use of a 
> long timeout then I think removing the fourth parameter is all that is 
> needed.
As is doesn't seem to be really needed, i'll jsut drop it.

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Guillaume Rousse]

Jeff Moyer wrote:
> ==> Regarding Re: [autofs] [ANNOUNCE] autofs 5.0.0 beta2; Guillaume Rousse <Guillaume.Rousse@inria.fr> adds:
> 
> Guillaume.Rousse> Ian Kent wrote:
>>> Hi all,
>>>
>>> It's time for an updated beta.
>>>
>>> autofs ======
>>>
>>> The package can be found at:
>>>
>>> ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5
>>>
>>> It is autofs-5.0.0_beta2.tar.[gz|bz2]
>>>
>>> No source rpm is there as it can be produced by using:
>>>
>>> rpmbuild -ts autofs-5.0.0_beta2.tar.gz
>>>
>>> and the binary rpm by using:
>>>
>>> rpmbuild -tb autofs-5.0.0_beta2.tar.gz
>>>
>>> See the INSTALL file for information about configure options and kernel
>>> requirements.
> Guillaume.Rousse> I couldn't test it really yet, as mandriva development
> Guillaume.Rousse> kernel is still 2.6.14, however here are a few remarks:
> 
> Guillaume.Rousse> First, stripping binaries by default, especially during
> Guillaume.Rousse> compilation, is opposite behaviour of standard
> Guillaume.Rousse> autotools-based procedure, where it only occurs if you
> Guillaume.Rousse> install with "make stripinstall". I need to have debug
> Guillaume.Rousse> symbols present when building a package, as they are
> Guillaume.Rousse> automatically for extracting them in a separate debug
> Guillaume.Rousse> package. I've found that "make DEBUG=1" would prevent
> Guillaume.Rousse> stripping, but it also defines an additional CFLAG with
> Guillaume.Rousse> unknown result :/
> 
> Try the attached patch.  It was made against the 4.1.3 Red Hat packages,
> but you get the idea.  Basically, "make -DDONTSTRIP."
I can achieve the same result without the patch with make CFLAGS="-O2 
-g" LDFLAGS="-g"  STRIP=":"
However, I find a bit cumbersome to need top pass arguments both to 
configure and to make invocation. And I wanted to point out it was not 
standard behaviour.

> Guillaume.Rousse> Second, the two attached patches don't apply anymore: -
> Guillaume.Rousse> autofs-4.1.4-signal-race-fix.patch seems to refer to
> Guillaume.Rousse> parts of automount.c not existing anymore -
> Guillaume.Rousse> autofs-4.1.1-get-best-mount.patch refer to a 4 args
> Guillaume.Rousse> get_best_mount() function that only has 3 args nowadays
> 
> Why would you apply 4.1.x patches to 5.x?  *Quite* a lot has changed.  I
> suggest dropping the patches.
Mainly because I don't know what they are meant for, I'm taking over 
package maintainership.

> Guillaume.Rousse> Third, the following patches still apply, but I got no
> Guillaume.Rousse> clue about their usefulness: -
> 
> Guillaume.Rousse> autofs-4.1.0-hesiod-bind.patch
> 
> I'll do some digging on this one tomorrow.
Thanks.

> Guillaume.Rousse> autofs-4.1.0-loop.patch
> 
> Drop this one.
OK.

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Jeff Moyer]

==> Regarding Re: [autofs] [ANNOUNCE] autofs 5.0.0 beta2; Guillaume Rousse <Guillaume.Rousse@inria.fr> adds:

Guillaume.Rousse> I couldn't test it really yet, as mandriva development
Guillaume.Rousse> kernel is still 2.6.14, however here are a few remarks:
Guillaume.Rousse> First, stripping binaries by default, especially during
Guillaume.Rousse> compilation, is opposite behaviour of standard
Guillaume.Rousse> autotools-based procedure, where it only occurs if you
Guillaume.Rousse> install with "make stripinstall". I need to have debug
Guillaume.Rousse> symbols present when building a package, as they are
Guillaume.Rousse> automatically for extracting them in a separate debug
Guillaume.Rousse> package. I've found that "make DEBUG=1" would prevent
Guillaume.Rousse> stripping, but it also defines an additional CFLAG with
Guillaume.Rousse> unknown result :/
>> Try the attached patch.  It was made against the 4.1.3 Red Hat packages,
>> but you get the idea.  Basically, "make -DDONTSTRIP."

Guillaume.Rousse> I can achieve the same result without the patch with make
Guillaume.Rousse> CFLAGS="-O2 -g" LDFLAGS="-g" STRIP=":" However, I find a
Guillaume.Rousse> bit cumbersome to need top pass arguments both to
Guillaume.Rousse> configure and to make invocation. And I wanted to point
Guillaume.Rousse> out it was not standard behaviour.

Well, patches are welcome, I'm sure.  =)

I've still not gotten to the hesiod patch.  I hope to do it by the end of
the week.

Thanks!

Jeff

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Guillaume Rousse]

Jeff Moyer wrote:
> ==> Regarding Re: [autofs] [ANNOUNCE] autofs 5.0.0 beta2; Guillaume Rousse <Guillaume.Rousse@inria.fr> adds:
> 
> Guillaume.Rousse> I couldn't test it really yet, as mandriva development
> Guillaume.Rousse> kernel is still 2.6.14, however here are a few remarks:
> Guillaume.Rousse> First, stripping binaries by default, especially during
> Guillaume.Rousse> compilation, is opposite behaviour of standard
> Guillaume.Rousse> autotools-based procedure, where it only occurs if you
> Guillaume.Rousse> install with "make stripinstall". I need to have debug
> Guillaume.Rousse> symbols present when building a package, as they are
> Guillaume.Rousse> automatically for extracting them in a separate debug
> Guillaume.Rousse> package. I've found that "make DEBUG=1" would prevent
> Guillaume.Rousse> stripping, but it also defines an additional CFLAG with
> Guillaume.Rousse> unknown result :/
>>> Try the attached patch.  It was made against the 4.1.3 Red Hat packages,
>>> but you get the idea.  Basically, "make -DDONTSTRIP."
> 
> Guillaume.Rousse> I can achieve the same result without the patch with make
> Guillaume.Rousse> CFLAGS="-O2 -g" LDFLAGS="-g" STRIP=":" However, I find a
> Guillaume.Rousse> bit cumbersome to need top pass arguments both to
> Guillaume.Rousse> configure and to make invocation. And I wanted to point
> Guillaume.Rousse> out it was not standard behaviour.
> 
> Well, patches are welcome, I'm sure.  =)
Even one that would replace existing Makefile.in with automake-generated 
ones ? That's the easiest way I know :)

> I've still not gotten to the hesiod patch.  I hope to do it by the end of
> the week.
Don't worry, there is no emergency at all for me, as I still don't have 
the correct kernel to test autofs 5 anyway :/

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Ian Kent]

On Thu, 18 May 2006, Guillaume Rousse wrote:

> > 
> > Why would you apply 4.1.x patches to 5.x?  *Quite* a lot has changed.  I
> > suggest dropping the patches.
> Mainly because I don't know what they are meant for, I'm taking over package
> maintainership.

Distribution?

Ian

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Guillaume Rousse]

Ian Kent wrote:
> On Thu, 18 May 2006, Guillaume Rousse wrote:
> 
>>> Why would you apply 4.1.x patches to 5.x?  *Quite* a lot has changed.  I
>>> suggest dropping the patches.
>> Mainly because I don't know what they are meant for, I'm taking over package
>> maintainership.
> 
> Distribution?
Mandriva Linux.

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Ian Kent]

On Fri, 19 May 2006, Guillaume Rousse wrote:

> Ian Kent wrote:
> > On Thu, 18 May 2006, Guillaume Rousse wrote:
> > 
> >>> Why would you apply 4.1.x patches to 5.x?  *Quite* a lot has changed.  I
> >>> suggest dropping the patches.
> >> Mainly because I don't know what they are meant for, I'm taking over package
> >> maintainership.
> > 
> > Distribution?
> Mandriva Linux.

Cool.

What kernel version?
You'll probably need to come up to speed with the kernel patches that have 
made their way into 2.6.x kernels for your older supported versions.

Ian

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Guillaume Rousse]

Ian Kent wrote:
> On Fri, 19 May 2006, Guillaume Rousse wrote:
> 
>> Ian Kent wrote:
>>> On Thu, 18 May 2006, Guillaume Rousse wrote:
>>>
>>>>> Why would you apply 4.1.x patches to 5.x?  *Quite* a lot has changed.  I
>>>>> suggest dropping the patches.
>>>> Mainly because I don't know what they are meant for, I'm taking over package
>>>> maintainership.
>>> Distribution?
>> Mandriva Linux.
> 
> Cool.
> 
> What kernel version?
2.6.16 since yesterday.

> You'll probably need to come up to speed with the kernel patches that have 
> made their way into 2.6.x kernels for your older supported versions.
I've asked integretation of the autofs 5.0 patch, but I had no answer
from the kernel team sofar...

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Jeff Moyer]

Guillaume.Rousse> Third, the following patches still apply, but I got no
Guillaume.Rousse> clue about their usefulness: -

Guillaume.Rousse> autofs-4.1.0-hesiod-bind.patch

jmoyer> I'll do some digging on this one tomorrow.

OK, it took me a while longer than expected to get to this.  Sorry!

The hesiod resolve patch is wanted.  Actually, I think in v5 we can just
get rid of the old calls to hes_resolve.

If you look at the implementation that currently is there in lookup_hesiod.c,
it has some bugs.  It will free a pointer that the library will
subsequently try to free, and it also leaks memory.  This is, in part, due to
the horrible definition of the interface at the time, I believe.

At any rate, we should move to hesiod_init, hesiod_resolve, etc.  It's
probably best to check that the hesiod library supports the new interfaces
at configure time.  If not, just disable the building of the hesiod
modules.

Ian, let me know what you think of the attached patch.

Thanks!

Jeff

--- autofs-5.0.0_beta3/modules/lookup_hesiod.c.orig	2006-05-22 23:28:48.000000000 -0400
+++ autofs-5.0.0_beta3/modules/lookup_hesiod.c	2006-05-26 18:47:04.000000000 -0400
@@ -29,6 +29,7 @@
 
 struct lookup_context {
 	struct parse_mod *parser;
+	void *hesiod_context;
 };
 
 int lookup_version = AUTOFS_LOOKUP_VERSION;	/* Required by protocol */
@@ -51,6 +52,11 @@ int lookup_init(const char *mapfmt, int 
 	/* Initialize the resolver. */
 	res_init();
 
+	/* Initialize the hesiod context. */
+	if (hesiod_init(&(ctxt->hesiod_context)) != 0) {
+		crit(MODPREFIX "hesiod_init(): %m");
+		return 1;
+	}
 	/* If a map type isn't explicitly given, parse it as hesiod entries. */
 	if (!mapfmt)
 		mapfmt = MAPFMT_DEFAULT;
@@ -73,6 +79,11 @@ int lookup_read_map(struct autofs_point 
    record in hesiod.  If it's an AFS or NFS filesyste, parse it out.  If
    it's an ERR filesystem, it's an error message we should log.  Otherwise,
    assume it's something we know how to deal with already (generic). */
+/*
+ *  Note that the hesiod library functions are not thread-safe.  If there
+ *  is a chance of multiple simultaneous calls to lookup_mount, these
+ *  need to be serialized.  --JM
+ */
 int lookup_mount(struct autofs_point *ap, const char *name, int name_len, void *context)
 {
 	char **hes_result;
@@ -86,9 +97,10 @@ int lookup_mount(struct autofs_point *ap
 	chdir("/");		/* If this is not here the filesystem stays
 				   busy, for some reason... */
 
-	hes_result = hes_resolve(name, "filsys");
-
+	hes_result = hesiod_resolve(ctxt->hesiod_context, name, "filsys");
 	if (!hes_result || !hes_result[0]) {
+		/* Note: it is not clear to me how to distinguish between
+		 * the "no search results" case and other failures.  --JM */
 		warn(MODPREFIX "entry \"%s\" not found in map", name);
 		return NSS_STATUS_UNAVAIL;
 	}
@@ -111,9 +123,13 @@ int lookup_mount(struct autofs_point *ap
 
 	debug(MODPREFIX "lookup for \"%s\" gave \"%s\"", name, best_record);
 
+	/* The error code needs to be converted to an NSS_ code There are
+	 * several places we can get a failure returned.  0 is always
+	 * success, -1 or 1 could be failure.  */
 	rv = ctxt->parser->parse_mount(ap, name, name_len, best_record,
 				       ctxt->parser->context);
-	free(hes_result);
+	hesiod_free_list(ctxt->hesiod_context, hes_result);
+
 	return rv;
 }
 
@@ -123,6 +139,8 @@ int lookup_done(void *context)
 {
 	struct lookup_context *ctxt = (struct lookup_context *) context;
 	int rv = close_parse(ctxt->parser);
+
+	hesiod_end(ctxt->hesiod_context);
 	free(ctxt);
 	return rv;
 }
--- autofs-5.0.0_beta3/configure.in.orig	2006-05-26 16:54:52.000000000 -0400
+++ autofs-5.0.0_beta3/configure.in	2006-05-26 17:35:16.000000000 -0400
@@ -143,7 +143,7 @@ AC_ARG_WITH(hesiod,
 if test -z "$HAVE_HESIOD"
 then
 	HAVE_HESIOD=0
-	AC_CHECK_LIB(hesiod, hes_resolve, HAVE_HESIOD=1 LIBHESIOD="$LIBHESIOD -lhesiod", ,
+	AC_CHECK_LIB(hesiod, hesiod_resolve, HAVE_HESIOD=1 LIBHESIOD="$LIBHESIOD -lhesiod", ,
 		     $LIBRESOLV)
 	if test "$HAVE_HESIOD" == "1"; then
 		AC_DEFINE(WITH_HESIOD,1,

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Ian Kent]

On Fri, 2006-05-26 at 18:56 -0400, Jeff Moyer wrote:
> Guillaume.Rousse> Third, the following patches still apply, but I got no
> Guillaume.Rousse> clue about their usefulness: -
> 
> Guillaume.Rousse> autofs-4.1.0-hesiod-bind.patch
> 
> jmoyer> I'll do some digging on this one tomorrow.
> 
> OK, it took me a while longer than expected to get to this.  Sorry!
> 
> The hesiod resolve patch is wanted.  Actually, I think in v5 we can just
> get rid of the old calls to hes_resolve.
> 
> If you look at the implementation that currently is there in lookup_hesiod.c,
> it has some bugs.  It will free a pointer that the library will
> subsequently try to free, and it also leaks memory.  This is, in part, due to
> the horrible definition of the interface at the time, I believe.
> 
> At any rate, we should move to hesiod_init, hesiod_resolve, etc.  It's
> probably best to check that the hesiod library supports the new interfaces
> at configure time.  If not, just disable the building of the hesiod
> modules.
> 
> Ian, let me know what you think of the attached patch.

Looks good.

I'll check more closely today and merge it if I don't see any problems.

Thanks Jeff.

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Ian Kent]

On Fri, 2006-05-26 at 18:56 -0400, Jeff Moyer wrote:
> Guillaume.Rousse> Third, the following patches still apply, but I got no
> Guillaume.Rousse> clue about their usefulness: -
> 
> Guillaume.Rousse> autofs-4.1.0-hesiod-bind.patch
> 
> jmoyer> I'll do some digging on this one tomorrow.
> 
> OK, it took me a while longer than expected to get to this.  Sorry!
> 
> The hesiod resolve patch is wanted.  Actually, I think in v5 we can just
> get rid of the old calls to hes_resolve.
> 
> If you look at the implementation that currently is there in lookup_hesiod.c,
> it has some bugs.  It will free a pointer that the library will
> subsequently try to free, and it also leaks memory.  This is, in part, due to
> the horrible definition of the interface at the time, I believe.
> 
> At any rate, we should move to hesiod_init, hesiod_resolve, etc.  It's
> probably best to check that the hesiod library supports the new interfaces
> at configure time.  If not, just disable the building of the hesiod
> modules.
> 
> Ian, let me know what you think of the attached patch.
> 

I've checked this out and ended up with this, the configure part is
due to the change in configure.in:

diff --git a/CHANGELOG b/CHANGELOG
index 1428424..1ef0f2c 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -6,6 +6,10 @@
 - merge don't strip debug info macro patch (Jeff Moyer).
 - merge patch to add sanity checks on rmdir_path and unlink (Jeff Moyer).
 - merge patch fix e2fsck error code check (Jeff Moyer).
+- update hesiod module (Jeff Moyer).
+  - add mutex to protect against overlapping mount requests.
+  - update return from mount request to give more sensible NSS_*
+    values.
 
 23/5/2006 autofs-5.0.0_beta3
 ----------------------------
diff --git a/configure b/configure
index 613a731..f032bf0 100755
--- a/configure
+++ b/configure
@@ -3168,9 +3168,9 @@ fi;
 if test -z "$HAVE_HESIOD"
 then
 	HAVE_HESIOD=0
-	echo "$as_me:$LINENO: checking for hes_resolve in -lhesiod" >&5
-echo $ECHO_N "checking for hes_resolve in -lhesiod... $ECHO_C" >&6
-if test "${ac_cv_lib_hesiod_hes_resolve+set}" = set; then
+	echo "$as_me:$LINENO: checking for hesiod_resolve in -lhesiod" >&5
+echo $ECHO_N "checking for hesiod_resolve in -lhesiod... $ECHO_C" >&6
+if test "${ac_cv_lib_hesiod_hesiod_resolve+set}" = set; then
   echo $ECHO_N "(cached) $ECHO_C" >&6
 else
   ac_check_lib_save_LIBS=$LIBS
@@ -3188,11 +3188,11 @@ extern "C"
 #endif
 /* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
-char hes_resolve ();
+char hesiod_resolve ();
 int
 main ()
 {
-hes_resolve ();
+hesiod_resolve ();
   ;
   return 0;
 }
@@ -3219,20 +3219,20 @@ if { (eval echo "$as_me:$LINENO: \"$ac_l
   ac_status=$?
   echo "$as_me:$LINENO: \$? = $ac_status" >&5
   (exit $ac_status); }; }; then
-  ac_cv_lib_hesiod_hes_resolve=yes
+  ac_cv_lib_hesiod_hesiod_resolve=yes
 else
   echo "$as_me: failed program was:" >&5
 sed 's/^/| /' conftest.$ac_ext >&5
 
-ac_cv_lib_hesiod_hes_resolve=no
+ac_cv_lib_hesiod_hesiod_resolve=no
 fi
 rm -f conftest.err conftest.$ac_objext \
       conftest$ac_exeext conftest.$ac_ext
 LIBS=$ac_check_lib_save_LIBS
 fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_hesiod_hes_resolve" >&5
-echo "${ECHO_T}$ac_cv_lib_hesiod_hes_resolve" >&6
-if test $ac_cv_lib_hesiod_hes_resolve = yes; then
+echo "$as_me:$LINENO: result: $ac_cv_lib_hesiod_hesiod_resolve" >&5
+echo "${ECHO_T}$ac_cv_lib_hesiod_hesiod_resolve" >&6
+if test $ac_cv_lib_hesiod_hesiod_resolve = yes; then
   HAVE_HESIOD=1 LIBHESIOD="$LIBHESIOD -lhesiod"
 fi
 
diff --git a/configure.in b/configure.in
index 1e01795..0e875f8 100644
--- a/configure.in
+++ b/configure.in
@@ -143,7 +143,7 @@ AC_ARG_WITH(hesiod,
 if test -z "$HAVE_HESIOD"
 then
 	HAVE_HESIOD=0
-	AC_CHECK_LIB(hesiod, hes_resolve, HAVE_HESIOD=1 LIBHESIOD="$LIBHESIOD -lhesiod", ,
+	AC_CHECK_LIB(hesiod, hesiod_resolve, HAVE_HESIOD=1 LIBHESIOD="$LIBHESIOD -lhesiod", ,
 		     $LIBRESOLV)
 	if test "$HAVE_HESIOD" == "1"; then
 		AC_DEFINE(WITH_HESIOD,1,
diff --git a/modules/lookup_hesiod.c b/modules/lookup_hesiod.c
index 391b646..cf9331c 100644
--- a/modules/lookup_hesiod.c
+++ b/modules/lookup_hesiod.c
@@ -29,8 +29,11 @@ #define HESIOD_LEN 512
 
 struct lookup_context {
 	struct parse_mod *parser;
+	void *hesiod_context;
 };
 
+static pthread_mutex_t hesiod_mutex = PTHREAD_MUTEX_INITIALIZER;
+
 int lookup_version = AUTOFS_LOOKUP_VERSION;	/* Required by protocol */
 
 /* This initializes a context (persistent non-global data) for queries to
@@ -51,6 +54,13 @@ int lookup_init(const char *mapfmt, int 
 	/* Initialize the resolver. */
 	res_init();
 
+	/* Initialize the hesiod context. */
+	if (hesiod_init(&(ctxt->hesiod_context)) != 0) {
+		char *estr = strerror_r(errno, buf, MAX_ERR_BUF);
+		crit(MODPREFIX "hesiod_init(): %s", estr);
+		return 1;
+	}
+
 	/* If a map type isn't explicitly given, parse it as hesiod entries. */
 	if (!mapfmt)
 		mapfmt = MAPFMT_DEFAULT;
@@ -69,15 +79,17 @@ int lookup_read_map(struct autofs_point 
 	return NSS_STATUS_UNKNOWN;
 }
 
-/* Lookup and act on a filesystem name.  In this case, lookup the "filsys"
-   record in hesiod.  If it's an AFS or NFS filesyste, parse it out.  If
-   it's an ERR filesystem, it's an error message we should log.  Otherwise,
-   assume it's something we know how to deal with already (generic). */
+/*
+ * Lookup and act on a filesystem name.  In this case, lookup the "filsys"
+ * record in hesiod.  If it's an AFS or NFS filesystem, parse it out.  If
+ * it's an ERR filesystem, it's an error message we should log.  Otherwise,
+ * assume it's something we know how to deal with already (generic).
+ */
 int lookup_mount(struct autofs_point *ap, const char *name, int name_len, void *context)
 {
 	char **hes_result;
 	struct lookup_context *ctxt = (struct lookup_context *) context;
-	int rv;
+	int status, rv;
 	char **record, *best_record = NULL, *p;
 	int priority, lowest_priority = INT_MAX;	
 
@@ -86,11 +98,16 @@ int lookup_mount(struct autofs_point *ap
 	chdir("/");		/* If this is not here the filesystem stays
 				   busy, for some reason... */
 
-	hes_result = hes_resolve(name, "filsys");
+	status = pthread_mutex_lock(&hesiod_mutex);
+	if (status)
+		fatal(status);
 
+	hes_result = hesiod_resolve(ctxt->hesiod_context, name, "filsys");
 	if (!hes_result || !hes_result[0]) {
+		/* Note: it is not clear to me how to distinguish between
+		 * the "no search results" case and other failures.  --JM */
 		warn(MODPREFIX "entry \"%s\" not found in map", name);
-		return NSS_STATUS_UNAVAIL;
+		return NSS_STATUS_NOTFOUND;
 	}
 
 	/* autofs doesn't support falling back to alternate records, so just
@@ -113,8 +130,21 @@ int lookup_mount(struct autofs_point *ap
 
 	rv = ctxt->parser->parse_mount(ap, name, name_len, best_record,
 				       ctxt->parser->context);
-	free(hes_result);
-	return rv;
+
+	hesiod_free_list(ctxt->hesiod_context, hes_result);
+
+	status = pthread_mutex_unlock(&hesiod_mutex);
+	if (status)
+		fatal(status);
+
+	/*
+	 * Unavailable due to error such as module load fail 
+	 * or out of memory, etc.
+	 */
+	if (rv == 1 || rv == -1)
+		return NSS_STATUS_UNAVAIL;
+
+	return NSS_STATUS_SUCCESS;
 }
 
 /* This destroys a context for queries to this module.  It releases the parser
@@ -123,6 +153,8 @@ int lookup_done(void *context)
 {
 	struct lookup_context *ctxt = (struct lookup_context *) context;
 	int rv = close_parse(ctxt->parser);
+
+	hesiod_end(ctxt->hesiod_context);
 	free(ctxt);
 	return rv;
 }

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Ian Kent]

On Sat, 2006-05-27 at 16:13 +0800, Ian Kent wrote:
> On Fri, 2006-05-26 at 18:56 -0400, Jeff Moyer wrote:
> > Guillaume.Rousse> Third, the following patches still apply, but I got no
> > Guillaume.Rousse> clue about their usefulness: -
> > 
> > Guillaume.Rousse> autofs-4.1.0-hesiod-bind.patch
> > 
> > jmoyer> I'll do some digging on this one tomorrow.
> > 
> > OK, it took me a while longer than expected to get to this.  Sorry!
> > 
> > The hesiod resolve patch is wanted.  Actually, I think in v5 we can just
> > get rid of the old calls to hes_resolve.
> > 
> > If you look at the implementation that currently is there in lookup_hesiod.c,
> > it has some bugs.  It will free a pointer that the library will
> > subsequently try to free, and it also leaks memory.  This is, in part, due to
> > the horrible definition of the interface at the time, I believe.
> > 
> > At any rate, we should move to hesiod_init, hesiod_resolve, etc.  It's
> > probably best to check that the hesiod library supports the new interfaces
> > at configure time.  If not, just disable the building of the hesiod
> > modules.
> > 
> > Ian, let me know what you think of the attached patch.
> > 
> 
> I've checked this out and ended up with this, the configure part is
> due to the change in configure.in:
> 

Oops and this.

diff --git a/modules/lookup_hesiod.c b/modules/lookup_hesiod.c
index cf9331c..c4e4635 100644
--- a/modules/lookup_hesiod.c
+++ b/modules/lookup_hesiod.c
@@ -107,6 +107,9 @@ int lookup_mount(struct autofs_point *ap
 		/* Note: it is not clear to me how to distinguish between
 		 * the "no search results" case and other failures.  --JM */
 		warn(MODPREFIX "entry \"%s\" not found in map", name);
+		status = pthread_mutex_unlock(&hesiod_mutex);
+		if (status)
+			fatal(status);
 		return NSS_STATUS_NOTFOUND;
 	}

Re: [ANNOUNCE] autofs 5.0.0 beta2

[Jeff Moyer]

==> Regarding Re: [autofs] [ANNOUNCE] autofs 5.0.0 beta2; Ian Kent <raven@themaw.net> adds:

raven> On Sat, 2006-05-27 at 16:13 +0800, Ian Kent wrote:
>> On Fri, 2006-05-26 at 18:56 -0400, Jeff Moyer wrote: > Guillaume.Rousse>
>> Third, the following patches still apply, but I got no >
>> Guillaume.Rousse> clue about their usefulness: -
>> > 
>> > Guillaume.Rousse> autofs-4.1.0-hesiod-bind.patch
>> > 
>> > jmoyer> I'll do some digging on this one tomorrow.
>> > 
>> > OK, it took me a while longer than expected to get to this.  Sorry!
>> > 
>> > The hesiod resolve patch is wanted.  Actually, I think in v5 we can
>> just > get rid of the old calls to hes_resolve.
>> > 
>> > If you look at the implementation that currently is there in
>> lookup_hesiod.c, > it has some bugs.  It will free a pointer that the
>> library will > subsequently try to free, and it also leaks memory.  This
>> is, in part, due to > the horrible definition of the interface at the
>> time, I believe.
>> > 
>> > At any rate, we should move to hesiod_init, hesiod_resolve, etc.  It's
>> > probably best to check that the hesiod library supports the new
>> interfaces > at configure time.  If not, just disable the building of
>> the hesiod > modules.
>> > 
>> > Ian, let me know what you think of the attached patch.
>> > 
>> 
>> I've checked this out and ended up with this, the configure part is due
>> to the change in configure.in:
>> 

raven> Oops and this.

Yeah, with the added unlock this looks good.

Thanks,

Jeff