At 06:23 PM 5/1/97 +0100, David Wright wrote: >On Wed, 30 Apr 1997, Dirk Herr-Hoyman wrote: >> If you look at /usr/sbin/deluser directly, you'll see it's a Perl script. >> A quickly hack too, judging both on the comments and on the functionality. >> >> I just went thru the exercise of setting up a Debian based server for a >> community network, and I ended up modifying both adduser and deluser (and >> delgroup) for our purposes. Is is just me, or is it really the case that >> no Unix has decent tools for administering user accounts :-), I've pretty >> much had to do this on every Unix system I've touched over the years ... >> but now I'm straying :-) > >Well, what exactly do you want a deluser command to do? If you accidently >create a new account and get it wrong, there may be a case for deleting it >and starting over. But once a user has been on a system for a while, is it >really sensible to remove them /without trace/. > >In particular, do you remove all their files. If you do, what about other >people's dependencies on them. If you don't, then you really need to leave >a trace of the deleted user. Otherwise you might reissue their UID number >and someone will inherit those files. >
I'd certainly like to have the option of deleting the user account, completely. And this would include entries not only in /etc/passwd, but /etc/group too. I have to mess with /usr/bin/delgroup to get it to work AT ALL, and it's still not perfect. Neither deluser nor delgroup are particularly sophisticated, unlike adduser which does account for many more cases. >> So, just like Debian has put forth a great deal of effort in the dpkg, and >> I take my hat off to it, there ought to be a similar effort put forth for >> user account administration. My question here, is whether there is such an >> effort under way? > >It would be interesting to hear what you think ought to be contained >therein (and what sort of modifications you had to make for your own >purposes). The issues that caused me to modify adduser/deluser/delgroup were these: * Users were in 2 groups, ordinary and information providers. And neither were to get to a standard shell, the shell would be a script that ends up running lynx. The meant we need more then just admins and users. Each group of user needs it's own set of groups and skel files for the home directory. * The information providers got directories created outside their home directory. This would be under a web server. We didn't want to use the ~username URL, thus we created dirs elsewhere. Most of what I ended up doing was changes to adduser. What was missing was a sense of multiple groups of users. This was done primarily by adding a -cfg option to let you call in your own configuration file. Additionally, provision was made in the conf to call a custom script, instead of the universal one in /etc/adduser.local. I basically borrowed this idea from AIX (gosh, AIX *is* good for something). Now, once you go down the road of a custom action when add an account, then you need one when you delete it too. Thus, the simplistic deluser/delgroup are insufficient for our needs. I ended up writing script that called these, but also did other actions on it's own. None of this is rocket science. And as others have noted, the SysV useradd and userdel do provide a more comprehensive and somewhat standard interface into the passwd and group. But, even if it's not rocket science, it still needs to be done and I don't like to think about it when I do it. Nor should you, as that means you WILL make mistakes. What still strikes me as odd is that given the age of Unix, we are still editing the passwd with vi. My real target user for this account administration is not me and no doubt this would be common. My target user is knowledgable, but busy. He just wants to be sure new accounts get added correctly, more than anything else. -- Dirk Herr-Hoyman <[EMAIL PROTECTED]> DANEnet, Connecting Dane County's Communities http://danenet.wicip.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
