User Manager Software
One of the most time-consuming tasks of every system administrator (Linux or not) is user account maintenance. Whether adding or removing accounts, or even occasional suspending or enabling, it is definitely something that can be done by a user other than root. Why spend time going through a stack of papers on your desk with one thousand user accounts to modify when the person who wrote the work orders in the first place could just as easily do it?
Now you may ask, “How are these people supposed to do this job? I am not giving out the root password!” Well, to get around the password problem, I have a quite simple response: use sudo (pronounced soo-doo). You can get this neat little gem from http://www.courtesan.com/sudo/. sudo allows a permitted user to execute a command as superuser (real and effective UID is set to 0, and GID is set to root's group ID as set in the password file). Using a utility like this, you can permit certain users to run certain programs, such as an adduser script or a chfn command. Although certain sanity checks must be in place, I have found sudo to be a viable solution to keeping the root password secure.
To get around the problem of letting others mess with user accounts, I created User Manager. Now I rarely spend time dealing with user accounts. User management is done by the technicians, the billing department and the salespeople. User Manager, primarily a Korn shell script, does it all. (The Korn shell can be obtained from ftp://ftp.cs.mun.ca/pub/pdksh/.)
The User Manager script is a framework for your system that can be customized to add in RADIUS support, multi-homing support and domain management. For example, one system I set up builds all DNS, web and stats package configurations and sets up the user account for a multi-home web customer. It was fairly simple to add this support to the script, and it provides a great learning base in system automation.
The User Manager tar archive file can be found at ftp://ftp.inetinc.net/pub/usrmgr/usrmgr.tgz. It includes the usrmgr Korn shell script, a C program and a simple Perl script, a README file, an INSTALL file and an ASCII welcome screen. The C program, newpass.c, helps with encrypting new user passwords and the Perl script, loginterp.pl, generates reports from information logged when User Manager is run.
In order to configure the User Manager software, you should know the locations of several common utilities on your system. Some of these include finger, sed, edquota, sort and mail. You can see the complete list in the sidebar “Programs and their Locations”. Make sure all of these are set correctly in usrmgr before running the script. If they are not, the script will not execute properly—steps may be left out.
Once you have the locations of the programs set up, you have some choices to make. Where do you want your log file to go? Where do you want the scripts to reside? Which administrator (or administrators) will be receiving e-mail messages noting the user's actions? Here are the answers I gave when I set up my system:
Log File -> /usr/local/adm/usrmgr.logfile
Scripts Reside in -> /usr/local/usrmgr
Administrators -> brw,matt,firstname.lastname@example.org
Note that the administrators can be local user names and/or full Internet e-mail addresses. For multiple entries, simply separate each address with a comma and no spaces.
The reports generated by User Manager's Perl script can be very helpful tools, not only for your system administration team but also for the billing and administrative personnel at your company. With sudo installed, the reports list the user name of each person who ran User Manager, instead of just logging everything as root. Listings 1 and 2 show the two different report formats available.
The simple log in Listing 1 is summary information aimed at system administrators. It lists the number of adds, suspends, enables and deletes performed by each user and can be used to track any unwanted or unauthorized users who might be abusing User Manager. If you set up your system to allow only administrators to access User Manager through sudo, you can easily track malicious activity by checking what root is doing. If the machine where I obtained the Listing 1 data was a production machine, I would be very wary of the one add done by root, and would check the detailed logs for more information.
Listing 2 shows a more detailed report that can be turned on or off by setting verbose to 0 or 1 in the loginterp.pl script. My personal recommendation is to leave it on so that you can send these reports to your billing and account managing crew. It is also helpful in investigating any malicious activities which may have shown up in the summary reports.
For example, one entry in the summary report detected root doing an add to a user's record:
Function Performed: User Added Done by: root Login: jhanish Password: ilovesouthpark UID: 1003 GID: 1003 Real Name: Joe Hanish Home: /home/jhanish Shell: /bin/tcsh Date: 07.29.1998
One might deduce that a possible security hole was exploited and now a new user, jhanish, has been added to the system. So, we take a look at the /etc/passwd entry to see what else may have happened.
jhanish:x:0:1003:Joe Hanish:/home/jhanish:/bin/tcshIn this case, after adding himself to the system, he then created a back door to access the system as root if he wished. Of course, a skilled hacker would not leave traces like this, but someone just playing around can easily be caught.
You may want to set a cron job to run loginterp.pl on a weekly or monthly basis to generate report files and send them automatically to administrators through e-mail. For example:
6 0 1 * * root /usr/local/bin/loginterp.pl | mail -s UserMGRLogs root,billing
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Validate an E-Mail Address with PHP, the Right Way
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
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?