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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide