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.