Linux System Administration: A User's Guide
By the time you get this issue of Linux Journal, my new book, Linux System Administration: A User's Guide, will have hit the shelves. Because they are just so darn cool, the folks at Linux Journal have given me some space in this month's issue to give you a teaser from the book.
Being the kind of guy that I am, I ached over what to present while trying to keep it short. After all, there's so much to choose from. Setting up a scanner? A CD writer? Blocking unwanted access to your network? Printing? Backups? Sendmail tweaks? What? In the end, I decided to talk about something that doesn't get enough press in today's internet world, and that's good old-fashioned user security. What you are about to read is an excerpt from Chapter Seven of the book, “Users and Groups”. It is not the complete chapter, nor are all the pieces in order. “The chef has been sipping too much of his own wine”, you say? Not at all. In fact, like my alter ego, I wanted to use this space to give you a sample, a taste if you will, of what you might find in the pages of my new book. Think of it as nibbling from a buffet table. As Chef Marcel would say, Bon appétit!
Linux is a multiuser operating system, meaning that one or more users can work on it at the same time. Every user is referenced by their user name. Each user name has a user ID (UID) associated with it and one or more groups. Like user names, group names are also represented by a numeric identifier, this time called a group ID (GID). A user's UID is unique as is a group's GID.
When it comes to your files and directories, security on a Linux system is defined by means of permissions, which directly relate to the user ID. Users are either administrative users or regular users. The chief administrative user is called root. A user's ID is used to decide what commands can be executed and what files can be read from or written to.
Each user ID also has a password associated with it. That password can and should be changed on a regular basis.
The short answer here is that you should never use the root user unless you absolutely have to. The danger lies in the fact that the root user is virtually omnipotent on the system. A mistake can have serious implications that can wipe out your entire system. Unless you absolutely have to, it is best to work as a nonadministrative user. There are other reasons as well.
The first is security. Because the root user has access to everything, it makes sense that only those who really need to have access are given the root password. The fewer people who have access to root, the better. Let me give you a few good reasons for jealously guarding root access: it makes it easier to maintain security, it decreases the risk of dangerous code and errors do not (usually) have global implications. Yes, it is still possible for a nonroot user to do great damage to a system, but the risk is much, much smaller.
As if you didn't already have enough things to do, here's yet another job. On a regular basis, you should run a report to identify accounts or logins that have gone dormant. This is a nice way of saying “people who are gone and who are not coming back anytime soon”.
An earlier chapter of the book explains the finger command, which displays information relating to the last time an account was used. Try typing this command to list each user ID and to check the last login time. Note that the single quotes (just before the sort command and just before the pipe symbol) are actually back quotes (or back ticks). The back quote is usually found with the tilde (~) just under the Esc key on most keyboards.
finger 'sort /etc/passwd | cut -f1 -d":"' | grep -i log | more
The output of this command looks something like this:
Login: aeinstein Name: A. Einstein Never logged in. Login: guitux Name: Tux the Penguin Last login Mon Jan 8 14:54 (EST) on tty2 Login: halt Name: halt Never logged in. Login: lp Name: lp Never logged in. Login: mail Name: mail Never logged in. Login: mgag Name: Marcel Gagné Last login Wed Mar 7 17:29 (EST) on 1 from website Login: named Name: Named Never logged in. Login: natika Name: Natika the CatWarning: you must use your good judgment (an absolute requirement for system administration) on this one. Some of these accounts—sync and lp, for instance—are system accounts. It only makes sense that no one will have ever logged in through them. On the other hand, Mr. Einstein (at the top of the list) has never logged in either and his is certainly not an administrative login. It could be that this is a new account (and it is) or that you created an account for a user that never was used. In the latter case, you should probably get rid of that account.
Now, I used that example to give you a feel for your command-line prowess. However, I should tell you that there is a cleaner way to do this. Your Linux system comes with a handy little command called lastlog that does just this sort of thing:
[root@scigate /root]# lastlog | more Username Port From Latest root tty1 Wed Mar 7 17:18:40 -0500 2001 bin **Never logged in** daemon **Never logged in** adm **Never logged in** lp **Never logged in** sync **Never logged in** shutdown **Never logged in** mgagne 1 scigate Wed Mar 7 17:29:55 -0500 2001 postgres **Never logged in** www **Never logged in** natika 8 localhost.locald Thu Dec 7 14:30:15 -0500 2000 guitux tty2 Mon Jan 8 14:54:55 -0500 2001
Geek trivia: you can't edit or modify this file, but the lastlog command information comes from the file /var/log/lastlog.
Here is another thing you should do. Every once in a while, run the command pwck. By default, it walks through your /etc/passwd and /etc/shadow files and does some basic integrity checks, such as making sure that the right number of fields are present and that each name is uniquely identified. For the group file, there is a companion command called grpck.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
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.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- 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