Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.ecn.uoknor.edu!news.cis.okstate.edu!newsfeed.ksu.ksu.edu!news.physics.uiowa.edu!math.ohio-state.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!newsfeed.internetmci.com!news.kei.com!news.texas.net!nntp.primenet.com!news.goodnet.com!rtd.com!dgy
From: dgy@rtd.com (Don Yuniskis)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Removing Users from FreeBSD 2.0
Date: 25 May 1996 17:51:52 GMT
Organization: CICDO
Lines: 29
Message-ID: <4o7hbp$81e@baygull.rtd.com>
References: <4nvobf$dvu@news.starnet.net> <4nvuc8$622@atlas.uniserve.com> <4o1uvb$55j@baygull.rtd.com> <Pine.LNX.3.91.960524021033.4176B-100000@gallup.cia-g.com>
NNTP-Posting-Host: seagull.rtd.com
In article <Pine.LNX.3.91.960524021033.4176B-100000@gallup.cia-g.com>,
Stephen Fisher <lithium@cia-g.com> wrote:
>
>That just suspends the users. What if you want to delete them all in
>all? You need to delete home directories, crontabs, mailbox, etc.. along
And `find / -user foo -exec rm {} \;'... and remove their entries from
NIS, /etc/groups, /etc/alias*, etc.
>with the password entires. Especially if you're a medium/large site that
>can't have those things laying around for dead users.
That was understood. *My* point was to not to recycle UIDs until it
was necessary. Or, rely on your off-line log of all the UIDs ever
assigned at valid dates associated therewith. Seems easier to keep them in
/etc/passwd until the UIDs are needed again... Also handy for recording
login names of recent users so "bob" doesn't cancel his account and a
*new* bob comes along and ends up with old bob's mail, etc.
The flip side is worrying that you may reassign their UID to a new user
*before* you've removed *every* vestige of the old user's account.
>On 23 May 1996, Don Yuniskis wrote:
>
>> Hmmm.... I'd advocate replacing their shell with /nonexistent and *leaving*
>> everything else where it is. In other words, keep the record of their UID
>> (etc.) and don't reuse the ID number.
>>
>> Unless, of course, you have **lots** of users or are a "casual" site.