All of the Linux distributions come with facilities for automating the process of adding, modifying and removing users. All include shell scripts or programs such as adduser, useradd, usermod and userdel. Some distributions, notably Caldera and Red Hat, come with additional programs to do the job. Caldera uses its LISA program to handle adding and deleting users. Red Hat's usercfg, for use in a graphical (X11) environment, not only handles user additions and deletions, but also helps manage groups.
All accomplish certain basic chores beyond just adding a line to the /etc/passwd file and appropriate entries to the /etc/group file. Given the sensitivity of the /etc/passwd file and the consequences of corrupting this file, that alone would warrant its use. A system no one (not even root) can log into isn't much use. In fact, if you do edit /etc/passwd with an editor, you shouldn't keep it open long. This file is accessed by numerous programs for login and authentication purposes, and holding this file open (especially if another user decides to change his password) could cause system instability.
All these scripts and programs prompt you through the information needed to create the new account. If you need to add or delete group accounts, the groupadd and groupdel (delgroup, addgroup, groupmod, etc.) programs can be found on most systems to accomplish this task.
The use of Network Information Services (NIS), formerly known as the Yellow Pages (a trademark of British Telecom) and still carrying the “yp” prefix on the programs, will necessarily change some of the procedures I've discussed, but the basics remain the same. NIS is used at larger sites to ease the administrative burden of pushing changes to each machine. But accounts still need to be set up. NIS just centralizes and distributes files from the master server instead of changing files on each machine individually. If you do work at a large site that uses NIS, you'll still have some normal accounts set up on each machine for those times when maintenance requirements dictate bringing the machine up in single user or non-networked modes.
Since I've been mentioning security from the beginning of this article, I thought I would mention a few programs to help you maintain security on your system.
The first program, npasswd (no relation to the file created by reversing the shadow password conversion), does some sanity checking when users change their password. This program is used in place of the regular passwd program by renaming the passwd binary (/usr/bin/passwd not /etc/passwd) to something like passwd.orig and creating a link to npasswd from passwd.
Another program you may be interested in is pwgen. This program generates random passwords containing mixed upper and lower case characters, numbers and legal (for a password) punctuation. Personally, I find these passwords too difficult to remember, and since writing them down is a security no-no, I devise my own (hopefully) secure passwords.
I mention the pwdutils package only for those using NIS. This package contains NIS compatible programs. Those contemplating using NIS or shadow files need to ensure that the programs they use for system administration (particularly user administration) work with NIS or the shadow suite. Above all, before you begin installing either NIS or the shadow suite, RTFM—read the fine manual (and keep an emergency boot disk handy).
Among the myriad things you can do that will make your life easier as a systems administrator is to maintain certain files and subdirectories. One such subdirectory that is often overlooked is /etc/skel. This subdirectory is the skeleton used by all (that I'm aware of) scripts and programs to create the new user's $HOME directory. You've seen how administration programs add users to /etc/passwd. You've noticed that at the same time a /home/$USER subdirectory is created with proper permissions and a few common files, such as .bashrc, .cshrc, etc. All this is done by copying /etc/skel with all its files and subdirectories to the user's new home directory and changing the ownership (chown) to the new user. Use the /etc/skel directory to keep all the files you wish new users to have—maybe a default .fvwmrc for their X sessions or some changes to their .bashrc files. Then the new user will be ready to start working as soon as you've run the adduser program.
If you view some of the programs I've discussed, you'll note some are binaries and some are scripts. I prefer to use a modified adduser script in which I have included a couple of lines for something I occasionally forget. My Caldera boxes run a modified fvwm (from LST) that writes to the file /var/run/xlaunch/$USER/background-:0.0. While not a fatal error if the directory doesn't exist, I don't like to see error messages scrolling through my console box. So, my modified script includes two lines to create this subdirectory and then touch the file name. You can modify your scripts in a similar manner.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Dynamic DNS—an Object Lesson in Problem Solving
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Please correct the URL for Salt Stack's web site
2 hours 45 min ago
- Android is Linux -- why no better inter-operation
5 hours 57 sec ago
- Connecting Android device to desktop Linux via USB
5 hours 29 min ago
- Find new cell phone and tablet pc
6 hours 27 min ago
7 hours 56 min ago
- Automatically updating Guest Additions
9 hours 4 min ago
- I like your topic on android
9 hours 51 min ago
- This is the easiest tutorial
16 hours 27 min ago
- Ahh, the Koolaid.
22 hours 5 min ago
- git-annex assistant
1 day 4 hours ago