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
> previo
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
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
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 w
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
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 e
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 lo
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
-
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
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 justifica
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 t
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 th
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 dif
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 se
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 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
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 t
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 u
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. S
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 p
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
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 wr
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
-
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
24 matches
Mail list logo
