Once your system is installed and most of the services configured, it's time to add users. You may not have given this task much thought yet, but you should.
If you're like many Linux beginners, you may not understand the implications of giving someone access to your system. Perhaps, for some time, you've been using a Unix variant, in which the basic decisions have been handled for you. Indeed, some installation programs, such as Caldera's LISA (Linux Installation and System Administration), start the process for you by adding a user during the install process and then allow you to continue using it to add and delete users from the system. So what else is there to know?
For starters, adding users entails thinking about how you wish to administer the system overall. Security is directly affected by such things as groups and passwords. Their administration shouldn't be left to chance or the whims of the installation program—at least, not without exploring their impact.
When you add a user, however you do it (I'll mention some programs later), you add an entry to the /etc/passwd file. This file consists of seven colon-separated fields, specified all on one line:
The fields are: user login name, password, UID, GID, comment (gecos) field, user's home directory and user's default shell.
If you decide to edit the /etc/passwd file manually, please be sure to make a backup copy first, so that if something goes wrong, you can start over. In general, I recommend using one of the programs specifically designed to edit the /etc/passwd file.
The first field is fairly self-explanatory. The system matches this entry with the next field as the user's login name/password pair. Each name must be unique. This is the only field required to be unique; I will explain the implications of keeping certain other fields unique below. Beyond that, making the user name meaningful helps to quickly identify who sent a 10MB file to the printer when the boss needs a hard copy of his budget for a Board of Directors meeting in ten minutes. In most Unix variants, including Linux, the login name is limited to 8 characters.
The second field is the password. This field can contain any of a number of things, but normally contains an encrypted password. The encrypted password must be 13 characters in length, composed of a two character seed plus the encrypted password. Other entries often seen in the password field include: “*”,“LOCKED” and “VOID”. If you see an “x” in this field, you'll want to read about shadow files below. These, or any other incorrect entries, effectively lock this user out. If you wish to lock a user out without losing the password they are using, you can insert an apostrophe as the first character. An apostrophe can never be used as part of the “scrambled eggs”, so apart from being illegal as part of a seed, you have also made the field size 14 characters. To allow the user access, just remove the apostrophe.
Also note that this field might be empty. Always check the /etc/passwd file to ensure that the second field is not empty. A field is defined as empty or NULL if the two colons delineating this field are next to each other with nothing in between, not even a space. If it is empty, no password is required to log in. The implications of this are obvious.
The third field is the UID (user identification). Valid UID ranges are from 0 to 65534. A UID of 0 has a special significance to the system; it is the omnipotent “superuser”, a term derived from the su (substitute user) program normally used by a normal user to become root. When invoked without an argument (user name) or with only a hyphen (-), root is the default.
A UID of 65534 is commonly reserved for “nobody”, a user with no privileges as opposed to a non-privileged user. This UID is often used for individuals accessing your system via FTP or HTTP.
Custom dictates that the numbers 1 to 99 are reserved for system users, such as wheel, daemon, lp, operator, news, mail, etc. These numbers are more than sufficient for most system requirements. Also, you may want to reserve 100 to 999 for semi-privileged (for lack of a better term) users. These users are administrators who don't need total root powers, but who do some administration and thus need more privileges than those given to non-privileged users. Reserve 1000 to 9999 for local users and 10000 to 65534 for remote users (if any).
Reserving groups of numbers for particular users helps if you ever need to search through logs for suspicious user activity. Some distributions, like Caldera, start UIDs at 100, others, like Red Hat, at 500, and still others, like Debian, at 1000 for non-privileged users. Just decide on a scheme and stick to it. Since each distribution does its own thing, in order to mix distributions within an organization, you have to intervene manually if the systems are networked. This is particularly true if you want to use NIS or NFS to mount common directories (e.g., /var/spool/mail, /home).
Contrary to popular belief, the UID field does not have to be unique. In fact, one method that keeps “wanna-be” system crackers busy is to use the technique discussed above and put an apostrophe as the first character in the password field for root. Then create another entry, perhaps tuber, with a UID of 0. Some systems require the root entry to exist and be the first entry.
But beware: a non-unique field can cause problems. For example, if you are logged in as tuber (UID 0) and activate a password-protected screen lock, when you attempt to unlock it, you will find you've outsmarted yourself. The kernel knows you by your UID; it looks up UID 0 beginning with the top of the /etc/passwd file and finds it as the first entry corresponding to “root”--that's where it stops; it doesn't look any further. But root's password has been locked with an invalid entry. At this point, your choices are to telnet in and kill the screen-lock process or to reboot the machine. The other possibility for getting out is to use an unlocked virtual terminal if you have one running to which you can switch. (Sometimes, the “extra” virtual terminals come in handy.)
Before I leave UIDs, here are two more things to think about. First, if you have any “rhosts” files with references to other systems outside your own network, make sure your user names are unique not only in your system, but between systems. If you have a jonesd (for Donna Jones) and the other system has a jonesd (for Danny Jones), and they use rlogin to remotely log in to each other's systems, they'll have access to each other's files (as the other person). These files can cause many problems and probably should not be used.
The second thing is the find command, which is used extensively by systems-administration programs and can be used to find user's files for deletion or changing owners (chown) before (or after) the files become orphaned. Learn this command, and incorporate it into your tool box. See the side bar “A Few Words About the Find Command”.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 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