Bug#493217: libnfsidmap-0.21 is available
On Wed, Aug 27, 2008 at 12:20 PM, Steve Dickson [EMAIL PROTECTED] wrote:
Kevin Coffman wrote:
--- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200
+++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200
@@ -101,7 +101,7 @@
char plgname[128];
int ret = 0;
- snprintf(plgname, sizeof(plgname), %s%s.so, PLUGIN_PREFIX,
method);
+ snprintf(plgname, sizeof(plgname), %s%s.so.0, PLUGIN_PREFIX,
method);
dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL);
if (dl == NULL) {
Getting back to this. I'm curious if there is a specific reason why
the *.so symlink was not there? Adding the .0 shouldn't be
necessary. But there may be a reason for not including the .so
symlink that I am not aware of.
The reason the version (or a version) number is need is because
some distros only installed the .so with the -devel package which
is not normally installed... The question is how do we get the
version to change automagically when the soname changes?
steved.
OK. I will add something. Maybe the patch you sent privately. I'll
look into the possibility of tying it with the autoconf stuff when the
version changes.
Also for the list: I'll move this code to a git repository next week
to make things more open.
K.C.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
Kevin Coffman wrote:
--- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200
+++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200
@@ -101,7 +101,7 @@
char plgname[128];
int ret = 0;
- snprintf(plgname, sizeof(plgname), %s%s.so, PLUGIN_PREFIX, method);
+ snprintf(plgname, sizeof(plgname), %s%s.so.0, PLUGIN_PREFIX,
method);
dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL);
if (dl == NULL) {
Getting back to this. I'm curious if there is a specific reason why
the *.so symlink was not there? Adding the .0 shouldn't be
necessary. But there may be a reason for not including the .so
symlink that I am not aware of.
The reason the version (or a version) number is need is because
some distros only installed the .so with the -devel package which
is not normally installed... The question is how do we get the
version to change automagically when the soname changes?
steved.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
On Fri, Aug 1, 2008 at 6:57 PM, Paul Collins [EMAIL PROTECTED] wrote:
Kevin Coffman [EMAIL PROTECTED] writes:
On Fri, Aug 1, 2008 at 9:41 AM, Paul Collins [EMAIL PROTECTED] wrote:
Kevin Coffman [EMAIL PROTECTED] writes:
Did you run ldconfig? I was trying to find the right thing to force
that, but from what I saw, when you install in /usr/local/lib, libtool
knows better. If anyone has the answer on that, let me know.
The convention on Debian seems to be to install plugins as
/usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path.
OK, I'll update the code and put out a -0.22 ASAP, but it might not be
for a few days.
Having had some sleep, I realized a quicker fix is to just change the
dlopen calls to do e.g. dlopen(libfoo.so.0, ...). This would avoid
any tussling with libtool and the autogar, which is always a plus.
I've tried that out here and it works nicely. Patch below.
BTW, this is the kind of comments I was looking for since putting the
beta out in April, but received none. I guess I was asking in the
wrong places. :-/
You may have to just be bold and trick people into testing your betas by
calling them releases. I'm happy to complain about anything that ends
up in Debian unstable, but I tend not to grab stuff from upstream much.
--- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200
+++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200
@@ -101,7 +101,7 @@
char plgname[128];
int ret = 0;
- snprintf(plgname, sizeof(plgname), %s%s.so, PLUGIN_PREFIX, method);
+ snprintf(plgname, sizeof(plgname), %s%s.so.0, PLUGIN_PREFIX,
method);
dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL);
if (dl == NULL) {
Getting back to this. I'm curious if there is a specific reason why
the *.so symlink was not there? Adding the .0 shouldn't be
necessary. But there may be a reason for not including the .so
symlink that I am not aware of.
My default install in /usr/local/lib shows:
lrwxrwxrwx 1 root root29 2008-07-30 16:59
/usr/local/lib/libnfsidmap_nsswitch.so -
libnfsidmap_nsswitch.so.0.0.0
lrwxrwxrwx 1 root root29 2008-07-30 16:59
/usr/local/lib/libnfsidmap_nsswitch.so.0 -
libnfsidmap_nsswitch.so.0.0.0
-rwxr-xr-x 1 root root 17141 2008-07-30 16:59
/usr/local/lib/libnfsidmap_nsswitch.so.0.0.0
Thanks,
K.C.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
Kevin Coffman [EMAIL PROTECTED] writes: Getting back to this. I'm curious if there is a specific reason why the *.so symlink was not there? Adding the .0 shouldn't be necessary. But there may be a reason for not including the .so symlink that I am not aware of. My default install in /usr/local/lib shows: lrwxrwxrwx 1 root root29 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so - libnfsidmap_nsswitch.so.0.0.0 lrwxrwxrwx 1 root root29 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so.0 - libnfsidmap_nsswitch.so.0.0.0 -rwxr-xr-x 1 root root 17141 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so.0.0.0 This looks like a reasonable result from make install in a regular autotooled source distribution. The libfoo.so link is used by the linker to find the library based on the -lfoo switch. The object resulting from the link will refer to libfoo.so.X and then that will be a symlink to libfoo.so.X.Y.Z. So far, so good. With typical libraries on Debian, libfoo.so will be provided, along with the required headers, by libfoo-dev (or perhaps libfooX-dev, depending on how it has been packaged). libfoo.so.X and libfoo.so.X.Y.Z will be in the libfooX package (or perhaps libfoo, if X has never changed), and applications linked to libfoo will depend on that package, as will libfoo-dev. Of course, the shared objects we're talking about are not regular libraries and so should be handled specially. This could mean altering the dlopen calls as per my suggestion, or overriding the autotools stuff and installing them as libnfsidmap_foo.so somewhere or other. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
On Wed, Jul 30, 2008 at 06:41:04PM -0400, Kevin Coffman wrote: A new version of libnfsidmap is now available from http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/libnfsidmap-0.21.tar.gz Changes since libnfsidmap-0.20: - The main library has been changed to load plugin libraries to perform the mappings. This decouples the main library from any ldap (and sasl, etc.) dependencies. - Several translation methods (plugins) may now be specified in the idmapd.conf file. While a plugin returns -ENOENT, the next is called until a mapping is found, or there are no more plugins to try. See the notes in the updated sample idmapd.conf configuration file. - A static mapping plugin from David Härdeman [EMAIL PROTECTED] has been added. - A gums mapping plugin from Olga Kornievskaia [EMAIL PROTECTED] has been added. Olga also did most of the work to convert the code to use this new plugin architecture. - The interface is changed to add two new functions, nfs4_gss_princ_to_ids_ex(), and nfs4_gss_princ_to_grouplist_ex() which allow extra information to be passed to these mapping functions. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493217 Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: On Fri, Aug 01, 2008 at 11:40:32PM +1200, Paul Collins wrote: Package: libnfsidmap2 Version: 0.21-1 Severity: grave Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: $ sudo rpc.idmapd -f -v rpc.idmapd: libnfsidmap: using domain: wgtn.ondioline.org rpc.idmapd: libnfsidmap: processing 'Method' list rpc.idmapd: libnfsidmap: Unable to load plugin: libnfsidmap_nsswitch.so: cannot open shared object file: No such file or directory rpc.idmapd: libnfsidmap: requested translation method, 'nsswitch', is not available rpc.idmapd: Unable to create name to user id mappings. $ dpkg -L libnfsidmap2 | grep nsswitch /usr/lib/libnfsidmap_nsswitch.so.0.0.0 /usr/lib/libnfsidmap_nsswitch.so.0 Since these newly separated plugins are not general-purpose shared libraries, perhaps they should be shipped as /usr/lib/libnfsidmap2/nsswitch.so and so forth, or something along those lines. -- Paul Collins Wellington, New Zealand signature.asc Description: Digital signature
Bug#493217: libnfsidmap-0.21 is available
Did you run ldconfig? I was trying to find the right thing to force that, but from what I saw, when you install in /usr/local/lib, libtool knows better. If anyone has the answer on that, let me know. On Fri, Aug 1, 2008 at 8:15 AM, Aníbal Monsalve Salazar [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2008 at 06:41:04PM -0400, Kevin Coffman wrote: A new version of libnfsidmap is now available from http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/libnfsidmap-0.21.tar.gz Changes since libnfsidmap-0.20: - The main library has been changed to load plugin libraries to perform the mappings. This decouples the main library from any ldap (and sasl, etc.) dependencies. - Several translation methods (plugins) may now be specified in the idmapd.conf file. While a plugin returns -ENOENT, the next is called until a mapping is found, or there are no more plugins to try. See the notes in the updated sample idmapd.conf configuration file. - A static mapping plugin from David Härdeman [EMAIL PROTECTED] has been added. - A gums mapping plugin from Olga Kornievskaia [EMAIL PROTECTED] has been added. Olga also did most of the work to convert the code to use this new plugin architecture. - The interface is changed to add two new functions, nfs4_gss_princ_to_ids_ex(), and nfs4_gss_princ_to_grouplist_ex() which allow extra information to be passed to these mapping functions. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493217 Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: On Fri, Aug 01, 2008 at 11:40:32PM +1200, Paul Collins wrote: Package: libnfsidmap2 Version: 0.21-1 Severity: grave Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: $ sudo rpc.idmapd -f -v rpc.idmapd: libnfsidmap: using domain: wgtn.ondioline.org rpc.idmapd: libnfsidmap: processing 'Method' list rpc.idmapd: libnfsidmap: Unable to load plugin: libnfsidmap_nsswitch.so: cannot open shared object file: No such file or directory rpc.idmapd: libnfsidmap: requested translation method, 'nsswitch', is not available rpc.idmapd: Unable to create name to user id mappings. $ dpkg -L libnfsidmap2 | grep nsswitch /usr/lib/libnfsidmap_nsswitch.so.0.0.0 /usr/lib/libnfsidmap_nsswitch.so.0 Since these newly separated plugins are not general-purpose shared libraries, perhaps they should be shipped as /usr/lib/libnfsidmap2/nsswitch.so and so forth, or something along those lines. -- Paul Collins Wellington, New Zealand -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiS/lkACgkQgY5NIXPNpFUEIwCeMFaqLcd6mpgQZO0A6SH1bJ8d zfMAniS2YmUgosrfYbgIs9hCnUq+GZn5 =s8E4 -END PGP SIGNATURE- ___ NFSv4 mailing list [EMAIL PROTECTED] http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
Kevin Coffman [EMAIL PROTECTED] writes:
Did you run ldconfig? I was trying to find the right thing to force
that, but from what I saw, when you install in /usr/local/lib, libtool
knows better. If anyone has the answer on that, let me know.
The convention on Debian seems to be to install plugins as
/usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
OK, I'll update the code and put out a -0.22 ASAP, but it might not be
for a few days.
BTW, this is the kind of comments I was looking for since putting the
beta out in April, but received none. I guess I was asking in the
wrong places. :-/
On Fri, Aug 1, 2008 at 9:41 AM, Paul Collins [EMAIL PROTECTED] wrote:
Kevin Coffman [EMAIL PROTECTED] writes:
Did you run ldconfig? I was trying to find the right thing to force
that, but from what I saw, when you install in /usr/local/lib, libtool
knows better. If anyone has the answer on that, let me know.
The convention on Debian seems to be to install plugins as
/usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
Kevin Coffman [EMAIL PROTECTED] writes:
On Fri, Aug 1, 2008 at 9:41 AM, Paul Collins [EMAIL PROTECTED] wrote:
Kevin Coffman [EMAIL PROTECTED] writes:
Did you run ldconfig? I was trying to find the right thing to force
that, but from what I saw, when you install in /usr/local/lib, libtool
knows better. If anyone has the answer on that, let me know.
The convention on Debian seems to be to install plugins as
/usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path.
OK, I'll update the code and put out a -0.22 ASAP, but it might not be
for a few days.
Having had some sleep, I realized a quicker fix is to just change the
dlopen calls to do e.g. dlopen(libfoo.so.0, ...). This would avoid
any tussling with libtool and the autogar, which is always a plus.
I've tried that out here and it works nicely. Patch below.
BTW, this is the kind of comments I was looking for since putting the
beta out in April, but received none. I guess I was asking in the
wrong places. :-/
You may have to just be bold and trick people into testing your betas by
calling them releases. I'm happy to complain about anything that ends
up in Debian unstable, but I tend not to grab stuff from upstream much.
--- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200
+++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200
@@ -101,7 +101,7 @@
char plgname[128];
int ret = 0;
- snprintf(plgname, sizeof(plgname), %s%s.so, PLUGIN_PREFIX, method);
+ snprintf(plgname, sizeof(plgname), %s%s.so.0, PLUGIN_PREFIX, method);
dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL);
if (dl == NULL) {
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
