🚀 go-pugleaf

On 17 Nov 2000, 501@rael.demon.co.uk () wrote:

> I'm running Mandrake 7.1, and for some reason, no user except for root is 
> recognised by login, as you can tell by the 'from' field on this post.  
> Instead of e.g. 'chris', I'm just user 501.  Recently I have cut out a few 
> services from runlevel 3, although I've done this before with no problems.  
> 
> Any help whatsoever at this point would be greatly appreciated.

For most applications and utilities I expect this is just a simple lookup
in /etc/passwd using the getpwent system call. Did you take off world read
permissions on /etc/passwd?

-- 
Regards,

Richard

On 18 Nov 2000 11:35:59 GMT, Richard Senior <richard@r-senior.demon.co.uk> 
wrote:
>
>For most applications and utilities I expect this is just a simple lookup
>in /etc/passwd using the getpwent system call. Did you take off world read
>permissions on /etc/passwd?
>

Thanks for your reply, Richard.

No, /etc/passwd is still world readable.  Unfortunately, the problem is
transient - after halting the box and then rebooting, user identification is
fine.  Hmm - I've never seen this before, and it's irritating as hell!

> >For most applications and utilities I expect this is just a simple lookup
> >in /etc/passwd using the getpwent system call. Did you take off world
read
> >permissions on /etc/passwd?
> >
>
> Thanks for your reply, Richard.
>
> No, /etc/passwd is still world readable.  Unfortunately, the problem is
> transient - after halting the box and then rebooting, user identification
is
> fine.  Hmm - I've never seen this before, and it's irritating as hell!
Howdy,

Are all other resources fine ?
All required partitions for home directories mounted and not full ?
Out of interest, which servives did you stop in runlevel 3 ?

J0e

J0e Schm0e wrote:

> > >For most applications and utilities I expect this is just a simple
> > >lookup in /etc/passwd using the getpwent system call. Did you take
> > >off world
> read
> > >permissions on /etc/passwd?
> > >
> >
> > Thanks for your reply, Richard.
> >
> > No, /etc/passwd is still world readable.  Unfortunately, the problem
> > is transient - after halting the box and then rebooting, user
> > identification
> is
> > fine.  Hmm - I've never seen this before, and it's irritating as
> > hell!
> Howdy,
> 
> Are all other resources fine ?
> All required partitions for home directories mounted and not full ?
> Out of interest, which servives did you stop in runlevel 3 ?

Incidentally, one of the boxes I maintain at work has a similar 
problem, although it is running RH7.

Everything works fine, it's just that one particular user shows up in 
'ps' listings as its uid, rather than its username. I'm not worrying 
about it, like I say it is all running fine, but I would be interested 
to know what is causing it.

Andy

-- 
Andy Fawcett      |   "In an open world without walls and fences,
andy@athame.co.uk |      we wouldn't need Windows and Gates."
tap@lspace.org    |                              -- anon

In article <2564690.RDqgVLx2np@afawcett.demon.co.uk>, Andy Fawcett
<andy@athame.co.uk> writes
>J0e Schm0e wrote:
>
>> > >For most applications and utilities I expect this is just a simple
>> > >lookup in /etc/passwd using the getpwent system call. Did you take
>> > >off world
>> read
>> > >permissions on /etc/passwd?
>> > >
>> >
>> > Thanks for your reply, Richard.
>> >
>> > No, /etc/passwd is still world readable.  Unfortunately, the problem
>> > is transient - after halting the box and then rebooting, user
>> > identification
>> is
>> > fine.  Hmm - I've never seen this before, and it's irritating as
>> > hell!
>> Howdy,
>> 
>> Are all other resources fine ?
>> All required partitions for home directories mounted and not full ?
>> Out of interest, which servives did you stop in runlevel 3 ?
>
>Incidentally, one of the boxes I maintain at work has a similar 
>problem, although it is running RH7.
>
>Everything works fine, it's just that one particular user shows up in 
>'ps' listings as its uid, rather than its username. I'm not worrying 
>about it, like I say it is all running fine, but I would be interested 
>to know what is causing it.
>
>Andy
>
Might be a RH[1] but could the process in question have been ftp'd from
the same user account on a different box.

It is just that I have a mix of Slackware and RH[2] boxes and until I
synched them the users on the RH box had uid's starting at 500 while
Slackware they ran from 1000. (Similar thing with guid's.)

Most often it would show in ls listings but occasionally in ps.

Russ

[1] Red Herring
[2] Red Hat
-- ----------------------------------------------------------------------------
|                                          Why can't men get Mad Cow disease? |
| Virtual Environment Resource Group Enterprise                               |
| < mailto:RussM@verge.demon.co.uk >                                          |
| < http://www.verge.demon.co.uk/index.htm >                                  |
|                                    'Cause all men are PIGS! (ex-)girlfriend |
-------------------------------------------------------------------------------

On 18 Nov 2000, Chris Medcraft wrote:

> No, /etc/passwd is still world readable.  Unfortunately, the problem is
> transient - after halting the box and then rebooting, user identification is
> fine.  Hmm - I've never seen this before, and it's irritating as hell!

Odd. I was going to suggest checking out the shadow password side of
things next but if it's a transient problem that's probably not the cause.

Have you any idea when the fault appears? You could write a simple script,
that checks for the problem every so often and appends to an output
file. Reboot and see when the problem reappears. You might also want to
increase your syslog output to give you some clues about what was
happening?

-- 
Regards,

Richard

richard@r-senior.demon.co.uk (Richard Senior) writes:
> For most applications and utilities I expect this is just a simple lookup
> in /etc/passwd using the getpwent system call. Did you take off world read
> permissions on /etc/passwd?

At least SuSE and Redhat appear to use nscd (Name Service Cache Daemon)
by default, and so lookups go via this daemon.  This makes it a little
more complicated to diagnose.

I've seen problems with this daemon where lookups get cached far too
long (positive and negative), so newly created users do not show up,
or changes to the DNS are not seen.

-- 
 `O O'  | Nick.Holloway@pyrites.org.uk
// ^ \\ | http://www.pyrites.org.uk/

Nick Holloway wrote:
> 
> richard@r-senior.demon.co.uk (Richard Senior) writes:
> > For most applications and utilities I expect this is just a simple lookup
> > in /etc/passwd using the getpwent system call. Did you take off world read
> > permissions on /etc/passwd?
> 
> At least SuSE and Redhat appear to use nscd (Name Service Cache Daemon)
> by default, and so lookups go via this daemon.  This makes it a little
> more complicated to diagnose.

You had me worried there for a minute, I thought I might have an nscd on
my new RH7 system and I havn't done anything about reconfiguring it to
sanity. But it does not appear. And there is no sign of unwanted dialups
caused by this box[1], which is the biggest problem with nscd IMO. SuSE
does indeed seem to use it by default. Solaris is also guilty. I don't
know about MDK.

> 
> I've seen problems with this daemon where lookups get cached far too
> long (positive and negative), so newly created users do not show up,
> or changes to the DNS are not seen.

This, and the problem with dialups caused by nscd looking up names in
its cache to refresh them in case someone wants them again. Nscd fails
to recognise that DNS has its own caching mechanism and doesn't need
this sort of "help". IMHO if running nscd it should be disabled for DNS.
Nscd might be useful in the sort of large NIS+ networks it seems to have
been designed for but I don't consider it to be of much use otherwise. I
regard it as a bad thing[TM].

Does the OP run NIS? This could also be a symptom of a broken
passwd.byuid map.

Regards, Ian

[1] Not really a box I suppose, as it's a VMWare virtual machine.

Although the problem hasn't resurfaced in a few days, here, for what it's
worth are the services listed in rc3.d.

kudzu, sound, network, random, syslog, crond, inet, lpd, nfslock, dhcpd,
autofs, keytable, usb, gpm, numlock, drakfont, webmin, xfs, kheader,
linuxconf and local.

On a side note, which of these do I absolutely *need* to have running?  I'm
anxious to take as much load off the system as I can..

Cheers,
 Chris

Chris Medcraft wrote:
> 
> Although the problem hasn't resurfaced in a few days, here, for what it's
> worth are the services listed in rc3.d.
> 
> kudzu, sound, network, random, syslog, crond, inet, lpd, nfslock, dhcpd,
> autofs, keytable, usb, gpm, numlock, drakfont, webmin, xfs, kheader,
> linuxconf and local.
> 
> On a side note, which of these do I absolutely *need* to have running?  I'm
> anxious to take as much load off the system as I can..
> 
 these will be all be running as daemons and as such don;t 'load' the
system, they simply sit there listening for things to call them. Don;t
forget also you get everyhting in rc0.d as well AFAIK. do a top to see
what your system load really is. What you *need* running depends on what
you wan to do :) ... I'd pay some attention to /etc/inetd.conf and
basically decide on what you don't need ... ftp? .. telnet? then do a ps
-ef or a top and work down the list .. things like httpd are obvious
candidates.

r.