Bug#487104: nis: map values containing non-ascii characters vanish
severity 487104 important kthxbye On Fri, Aug 15, 2008 at 05:12:43PM +0100, Jonathan H N Chin wrote: The problem causes data loss, so it is grave at minumum: http://www.debian.org/Bugs/Developer#severities (At my site at least, the data loss is serious, as I explained in my previous message, but I grant that this may not be the case elsewhere.) Please don't drop people from the CC list if you're going to make a major change like this to the status of a bug. The first time I found out that this was upgraded to RC severity was when I noticed that my closure message went to the release critical bugs list. As previously discussed while I do think this should be fixed for lenny I really don't think this is a severe enough problem to warrant removing the package from the distribution; the definition of data loss is being stretched a bit here (the data is still present and accessible via interfaces other than ypcat) and the package continues to function well in the overwhelming majority of use cases. Like I say, I appreciate that this is something which is very important in your system and do think this is something that should be fixed for the next release but given the choice between having this bug and not shipping at all it seems much more constructive to ship with the bug. Incidentally, my testing also seemed to indicate that it was quite hard to get a Debian system to generate UTF-8 data which had this problem - I ended up using a hex editor to get the encoding that you had, other encodings worked fine. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
aurelien wrote: - Are the accounts really locked, or the problem only appears with ypcat? Unfortunately I did not make any notes on the procedure I used. I think it was just: - create an account on nis server with gecos containing non-ascii - set passwd: nis in /etc/nsswitch.conf on nis client - try to login to nis client on console or via ssh However I cannot replicate the login problem anymore. I wonder if I forgot to change /bin/tcsh (which doesn't exist on my linux boxes) to /bin/bash when I tested previously. - Does the 'id' command works for the accounts using non-ascii chars? I don't know how to login to an account that has non-ascii characters in it so I can't test that. - Could you please run the ypcat command using: 'LC_ALL=en_GB.ISO-8859-1 LANG=en_GB.ISO-8859-1 ypcat' (note that you may have to generate the corresponding locale) This works. -jonathan -- Jonathan H N Chin | deputy computer | Newton Institute, Cambridge, UK [EMAIL PROTECTED] | systems manager | tel/fax: +44 1223 767091/330508 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Aug 15, 2008 at 03:15:21PM +0100, Jonathan H N Chin wrote: aurelien wrote: - Are the accounts really locked, or the problem only appears with ypcat? Unfortunately I did not make any notes on the procedure I used. I think it was just: - create an account on nis server with gecos containing non-ascii - set passwd: nis in /etc/nsswitch.conf on nis client - try to login to nis client on console or via ssh However I cannot replicate the login problem anymore. I wonder if I forgot to change /bin/tcsh (which doesn't exist on my linux boxes) to /bin/bash when I tested previously. Do you mean that you are now able to login on those accounts? - Does the 'id' command works for the accounts using non-ascii chars? I don't know how to login to an account that has non-ascii characters in it so I can't test that. Actually you don't need to login on an account, you can just 'id username' to query the different users. - Could you please run the ypcat command using: 'LC_ALL=en_GB.ISO-8859-1 LANG=en_GB.ISO-8859-1 ypcat' (note that you may have to generate the corresponding locale) This works. This seems to say that the problem is in the nis package instead of the glibc package. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
aurelien wrote: Do you mean that you are now able to login on those accounts? I don't normally have user accounts on my linux servers. The test accounts that I have just created let me log in, yes. Actually you don't need to login on an account, you can just 'id username' to query the different users. Yes, it works. 'LC_ALL=en_GB.ISO-8859-1 LANG=en_GB.ISO-8859-1 ypcat' This works. This seems to say that the problem is in the nis package instead of the glibc package. There's only one way to find out... FIGHT! -jonathan -- Jonathan H N Chin | deputy computer | Newton Institute, Cambridge, UK [EMAIL PROTECTED] | systems manager | tel/fax: +44 1223 767091/330508 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Aug 15, 2008 at 04:40:36PM +0200, Aurelien Jarno wrote:
On Fri, Aug 15, 2008 at 03:15:21PM +0100, Jonathan H N Chin wrote:
- Could you please run the ypcat command using:
'LC_ALL=en_GB.ISO-8859-1 LANG=en_GB.ISO-8859-1 ypcat'
(note that you may have to generate the corresponding locale)
This works.
This seems to say that the problem is in the nis package instead of the
glibc package.
The ypcat program is just a thin wrapper around glibc routines. It uses
yp_all to ask glibc to iterate over all the keys in the map doing this:
static int
print_data (int status, char *inkey, int inkeylen, char *inval,
int invallen, char *indata __attribute__ ((unused)))
{
if (status != YP_TRUE)
return status;
if (kflag (inkeylen 0))
{
if (inkey[inkeylen - 1] == '\0')
--inkeylen;
fprintf (stdout, %*.*s , inkeylen, inkeylen, inkey);
}
if (invallen 0)
{
if (inval[invallen -1] == '\0')
--invallen;
fprintf (stdout, %*.*s\n, invallen, invallen, inval);
}
else
fputs (\n, stdout);
return 0;
}
In any case, the major issue reported was with login and account lookups
which are handled by the NSS module provided by glibc, the RCness being
due to the inability to log in.
--
You grabbed my hand and we fell into it, like a daydream - or a fever.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Aug 15, 2008 at 03:53:52PM +0100, Mark Brown wrote: On Fri, Aug 15, 2008 at 04:40:36PM +0200, Aurelien Jarno wrote: On Fri, Aug 15, 2008 at 03:15:21PM +0100, Jonathan H N Chin wrote: In any case, the major issue reported was with login and account lookups which are handled by the NSS module provided by glibc, the RCness being due to the inability to log in. No as Jonathan just confirmed, this actually does not prevents login, this only prevents the entries from being displayed with ypcat. In short the glibc correctly fetch the account entries via the NSS module, but then ypcat fails to print them. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
severity 487104 important thanks On Fri, Aug 15, 2008 at 05:08:37PM +0200, Aurelien Jarno wrote: No as Jonathan just confirmed, this actually does not prevents login, this only prevents the entries from being displayed with ypcat. Downgrading the bug, then - as I said, the original justification for the bug being RC was that logins were not possible. In short the glibc correctly fetch the account entries via the NSS module, but then ypcat fails to print them. What makes you belive that ypcat is using NSS for this? As I said in my previous mail it is using the yp_all() API with the callback routine I posted. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
broonie wrote:
In any case, the major issue reported was with login and account lookups
which are handled by the NSS module provided by glibc, the RCness being
due to the inability to log in.
For clarity, my problem was that I was silently losing apache accounts
(make passwd on my Solaris NIS server ssh's to my debian webserver
and runs a perl script that uses ypcat to update apache's htpasswd file)
which prevented users authenticating. This was brought to my attention
when someone was unable to access financial information that they should
have been able to view.
I tried creating some test shell accounts to see if the problem was
bigger than that but as I just wrote, I may have tested badly, as I
cannot now replicate that problem.
I still silently lose accounts when I run ypcat on the linux server.
(Apparently the locale setting is the culprit, so there is a workaround.)
I consider that this to be serious data loss. At the very least it
is data loss, so downgrade to grave would not bother me if people
are unhappy with it being marked critical.
Note that on a Solaris 10 box, with UTF locale, ypcat does not lose
accounts:
$ LC_ALL=en_GB.UTF-8 ypcat passwd|grep Marks|awk -F: '{print $5}'|od -c
000 K . M a r k s t r 367 m \n
015
-jonathan
--
Jonathan H N Chin | deputy computer | Newton Institute, Cambridge, UK
[EMAIL PROTECTED] | systems manager | tel/fax: +44 1223 767091/330508
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
severity 487104 grave thanks The problem causes data loss, so it is grave at minumum: http://www.debian.org/Bugs/Developer#severities (At my site at least, the data loss is serious, as I explained in my previous message, but I grant that this may not be the case elsewhere.) -jonathan -- Jonathan H N Chin | deputy computer | Newton Institute, Cambridge, UK [EMAIL PROTECTED] | systems manager | tel/fax: +44 1223 767091/330508 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Aug 15, 2008 at 04:42:39PM +0100, Jonathan H N Chin wrote: I still silently lose accounts when I run ypcat on the linux server. (Apparently the locale setting is the culprit, so there is a workaround.) I consider that this to be serious data loss. At the very least it is data loss, so downgrade to grave would not bother me if people are unhappy with it being marked critical. I don't consider this sufficiently critical to justify removing anything from the release - it's only going to affect a relatively small proportion of users and doesn't actually delete data as such. Note that on a Solaris 10 box, with UTF locale, ypcat does not lose accounts: Could you confirm which locale are you using on your Debian system when this fails? The bug log suggests it'll be a UTF-8 one since it's a fresh etch install. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
reassign 487104 nis thanks On Fri, Aug 15, 2008 at 04:15:34PM +0100, Mark Brown wrote: severity 487104 important thanks On Fri, Aug 15, 2008 at 05:08:37PM +0200, Aurelien Jarno wrote: No as Jonathan just confirmed, this actually does not prevents login, this only prevents the entries from being displayed with ypcat. Downgrading the bug, then - as I said, the original justification for the bug being RC was that logins were not possible. In short the glibc correctly fetch the account entries via the NSS module, but then ypcat fails to print them. What makes you belive that ypcat is using NSS for this? As I said in my previous mail it is using the yp_all() API with the callback routine I posted. Sorry, I hadn't read the nis code before. You are right that yp_all() is used by ypcat, however I am now convinced that the problem is in nis and not in glibc: For each entry, yp_all() calls the callback with the string and the number of bytes in the string. ypcat uses this string and the number of bytes with fprintf(), while fprintf actually takes the length of the string, which can be different in a non-C locale. Moreover ypcat explicitly switches the locale from C to the environment locale at the beginning of main(). I don't expect ypcat to print a correct string when the encoding of the NIS server and the locale of the client do not match, but at least it should not drop the line, and either print the line with broken characters or print an error message. Aurélien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Aug 15, 2008 at 06:20:04PM +0200, Aurelien Jarno wrote: I don't expect ypcat to print a correct string when the encoding of the NIS server and the locale of the client do not match, but at least it should not drop the line, and either print the line with broken characters or print an error message. Could you please identify where in the current code the lines are dropped? Unless yp_all() passes in an error status the data is going to get passed to fprintf() which I would expect to produce some (potentially mangled) output. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
broonie wrote: I don't consider this sufficiently critical to justify removing anything from the release - it's only going to affect a relatively small proportion of users and doesn't actually delete data as such. If I put data into the database, I expect exactly the same data to come back when I perform a query. If not, an error must be returned. Silent data loss is not acceptable. (As Aurelien may have found the problem, we seem to be close to a resolution anyway, so I expect this disagreement is academic.) Could you confirm which locale are you using on your Debian system when this fails? The bug log suggests it'll be a UTF-8 one since it's a fresh etch install. Yes, it is. -jonathan -- Jonathan H N Chin | deputy computer | Newton Institute, Cambridge, UK [EMAIL PROTECTED] | systems manager | tel/fax: +44 1223 767091/330508 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Aug 15, 2008 at 05:31:09PM +0100, Mark Brown wrote: On Fri, Aug 15, 2008 at 06:20:04PM +0200, Aurelien Jarno wrote: I don't expect ypcat to print a correct string when the encoding of the NIS server and the locale of the client do not match, but at least it should not drop the line, and either print the line with broken characters or print an error message. Could you please identify where in the current code the lines are dropped? Unless yp_all() passes in an error status the data is going to get passed to fprintf() which I would expect to produce some (potentially mangled) output. fprintf drops the line, and return a negative value, because the length of the string does not correspond to the give value. This can be seen from strace: fprintf(0x7fa39d0b4780, %*.*s\n, 61, 61, aurel32:x:1000:1000:Aurelien Jar...aurel32:x:1000:1000:Aurelien Jarno,,,:/home/aurel32:/bin/bash) = 62 fprintf(0x7fa39d0b4780, %*.*s\n, 45, 45, test:x:1001:1002:T\351st,,,:/home/...) = -1 One of the solution is to check for an error in fprintf(), or to let the program running in a C locale, by removing the switch at the beginning of main. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Aug 15, 2008 at 05:42:00PM +0100, Jonathan H N Chin wrote: If I put data into the database, I expect exactly the same data to come back when I perform a query. If not, an error must be returned. Silent data loss is not acceptable. I'm not saying that this a great thing, just that it's a sufficiently specialised problem to warrant removing it from the distribution. It only affects ypcat and has never previously been supported in UTF-8 locales. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Tue, Jul 01, 2008 at 04:44:41PM +0100, Jonathan H N Chin wrote:
aurelien wrote:
Would it be possible to test that with libc6_2.7-12 ?
Fails, with apparently same behaviour as 2.3.6.ds1-13etch5 :
$ dpkg -l libc6|awk '/^.i/{print $3}'
2.7-12
$ ypcat passwd|grep Mark|awk -F: '{print $5}'|od -c
000
I don't have a Solaris server, so it is actually difficult to reproduce
the problem. However using a Linux server (nis package), I have been
able to partly reproduce the problem: if the file /etc/passwd is encoded
in ISO-8859-1 (the default in sarge) and the environment in which ypcat
is running is UTF-8 (the default in etch and later), the lines with
non-ascii chars are dropped, just as in your examples. ypcat works fine
when using an ISO-8859-1 environment.
However, I am still able to login to the system with the accounts using
non-ascii chars.
That's why I have a few questions:
- Are the accounts really locked, or the problem only appears with
ypcat?
- Does the 'id' command works for the accounts using non-ascii chars?
- Could you please run the ypcat command using:
'LC_ALL=en_GB.ISO-8859-1 LANG=en_GB.ISO-8859-1 ypcat'
(note that you may have to generate the corresponding locale)
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
Jonathan H N Chin a écrit : broonie wrote: ...here you are talking about specific NIS package versions rather than a change from sarge to etch. Can you please confirm that the issue you are seeing manifests when changing distributions rather than being specifically the result of an upgrade of the nis package? Yes. Sorry, I wasn't clear. I was using nisversion as a shorthand for the system that has the broken packages, whatever they are, presumably libc6. As I mentioned in passing, the two libc6 versions I am using are: libc6_2.3.2.ds1-22sarge6 - nis works libc6_2.3.6.ds1-13etch5 - nis is broken Would it be possible to test that with libc6_2.7-12 ? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
aurelien wrote:
Would it be possible to test that with libc6_2.7-12 ?
Fails, with apparently same behaviour as 2.3.6.ds1-13etch5 :
$ dpkg -l libc6|awk '/^.i/{print $3}'
2.7-12
$ ypcat passwd|grep Mark|awk -F: '{print $5}'|od -c
000
-jonathan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
broonie wrote: Reassigning there as a result but please provide further information on what has changed between a working and non-working system - I strongly expect that you will also have changed other packages. I have a webserver running sarge. I'm building a replacement using etch. It's not an upgrade, it's a fresh install. So, everything is different. The bug is simple enough to replicate: Just create a password entry containing non-ascii in the gecos such as in the example I gave, set passwd: nis in /etc/nsswitch.conf and then try to login. An additional note: I created two test entries in my Solaris auto_common map (used by my auto_master on Solaris, but that isn't relevant). One with the key containing non-ascii, one where the value did. When I used ypcat to retrieve the map, both entries were present on Solaris 10 and debian nis 3.13-2. However with nis 3.17-6, the non-ascii key was not found at all and the non-ascii value was corrupted, containing part of another map entry instead of the expected content: sol-10$ ypcat -k auto_common|grep test|od -c 000 t e s t 2 367 m w i b b l e : / 020 p a t h 2 \n t e s t 1 w i b b 040 l e : / p a t h 1 367 m \n 054 nis_3.13-2$ ypcat -k auto_common|grep test|od -c 000 t e s t 2 367 m w i b b l e : / 020 p a t h 2 \n t e s t 1 w i b b 040 l e : / p a t h 1 367 m \n 054 nis_3.17-6$ ypcat -k auto_common|grep test|od -c 000 t e s t 1 m a p l e e d g e 020 : / e x p o r t / p k g / m a p 040 l e / 9 . 5 \n 047 -jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
On Fri, Jun 20, 2008 at 11:32:05AM +0100, Jonathan H N Chin wrote: I have a webserver running sarge. I'm building a replacement using etch. It's not an upgrade, it's a fresh install. So, everything is different. You say this but... When I used ypcat to retrieve the map, both entries were present on Solaris 10 and debian nis 3.13-2. However with nis 3.17-6, the non-ascii key was not found at all ...here you are talking about specific NIS package versions rather than a change from sarge to etch. Can you please confirm that the issue you are seeing manifests when changing distributions rather than being specifically the result of an upgrade of the nis package? As I said previously, code from the NIS package is not involved in reading data from the server for use when logging in so it is very unlikely that this issue is in the nis package. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
broonie wrote: ...here you are talking about specific NIS package versions rather than a change from sarge to etch. Can you please confirm that the issue you are seeing manifests when changing distributions rather than being specifically the result of an upgrade of the nis package? Yes. Sorry, I wasn't clear. I was using nisversion as a shorthand for the system that has the broken packages, whatever they are, presumably libc6. As I mentioned in passing, the two libc6 versions I am using are: libc6_2.3.2.ds1-22sarge6 - nis works libc6_2.3.6.ds1-13etch5 - nis is broken -jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
Subject: nis: map values containing non-ascii characters vanish
Package: nis
Version: 3.17-6
Severity: critical
Justification: breaks the whole system
Solaris 10 and Debian nis package 3.13-2 both accept non-ascii
characters in maps:
sol-10$ ypcat passwd|grep Mark|awk -F: '{print $5}'|od -c
000 K . M a r k s t r 367 m \n
015
nis_3.13-2$ ypcat passwd|grep Mark|awk -F: '{print $5}'|od -c
000 K . M a r k s t r 367 m \n
015
However, 3.17-6 does not:
nis_3.17-6$ ypcat passwd|grep Mark|awk -F: '{print $5}'|od -c
000
This breaks login access to the system.
Custom maps may also not behave as expected, which leads to
silent corruption of other data on the system. For example,
I build my apache htpasswd files using NIS password data and
users with non-ascii in their gecos are silently excluded.
-- Package-specific info:
nm-tool is not installed
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages nis depends on:
hi debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy
hi libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii libdbus-1-31.0.2-1 simple interprocess messaging syst
ii libdbus-glib-1-2 0.71-3simple interprocess messaging syst
hi libgdbm3 1.8.3-3 GNU dbm database routines (runtime
ii libglib2.0-0 2.12.4-2 The GLib library of C routines
ii libslp11.2.1-6.2 OpenSLP libraries
hi lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip
hi make 3.81-2The GNU version of the make util
hi netbase4.29 Basic TCP/IP networking system
hi portmap5-26 The RPC portmapper
nis recommends no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
Addendum: I can't see much difference between nis 3.13-2 and 3.17-6. However, there are lots of differences in libc6 going from 2.3.2.ds1-22sarge6 to 2.3.6.ds1-13etch5. Since ypcat is just a wrapper to yp_all calls (from libnsl ?), perhaps this bug should be reassigned to libc6. -jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487104: nis: map values containing non-ascii characters vanish
reassign 487104 libc6 thanks On Thu, Jun 19, 2008 at 05:02:01PM +0100, [EMAIL PROTECTED] wrote: Solaris 10 and Debian nis package 3.13-2 both accept non-ascii characters in maps: However, 3.17-6 does not: This breaks login access to the system. As Jonathan said, ypcat is just a thin wrapper around libc APIs - in fact, as far as tools like login are concerned the NIS package has no involvement beyond binding to the NIS server. All parsing of data provided by the server is done outside of the NIS package. Reassigning there as a result but please provide further information on what has changed between a working and non-working system - I strongly expect that you will also have changed other packages. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
