A Sampling of Best of Tech

Best of Technical Support is a regular Linux Journal feature in which our experts take on hard new questions and offer new insights on old debates. See this month's issue for more questions and answers.

I have a question for you. Our regular system Administrator has always stuck with the traditional UNIX format of the first initial of the first name and then up to seven characters of the last name, for a total of no more than eight characters. A new technician, however, has created the logins using our full first name and full last name. The question is: what is the disadvantage of this format?

--Michael Rider, NavyIntel2@aol.com

First, I would say that the convention of "first initial and up to seven characters of last name" is only moderately widespread. I generally let users pick their own login names within reason. My login name usually has been jimd, and in cases where jdennis has been imposed on me it was, well, an imposition.

The eight character maximum is old; but it's handy if you can stick with that if they is any chance that any of your system will be older--if you ever merge with another company that's maintaining older systems with an 8-character login name limit.

Modern Linux systems for the last few years have supported 31-character usernames. Please understand that this is a library issue. To the kernel user identities are numeric (UIDs)--Linux currently is using 16-bit UIDs and GIDs, but the newest kernel (2.6.x) supports 32-bit UIDs and GIDs. The libc (glibc) that Linux has used for several years has supported the long user names and group names. They've also supported larger UIDs and GIDs. So these transitions have been relatively smooth.

Naturally you could always come across some obscure software, driver or utility that fails as result of such changes--software that assumes user names are limited to eight characters rather than using the sysconf(3) function to dynamically adjust to whichever version of UNIX or Linux it's hosted on. As you might suspect from my comment, I consider such cases to be bugs.

Ultimately it's a local policy decision. I tend to prefer to keep the login names short if possible, because it minimizes the hassle (and cost) if we come across support issues with proprietary software or old systems (esp. proprietary versions of UNIX) with which we might want full interoperation. Synchronized passwd and group mappings across the enterprise is basically a sanity requirement if you use NFS at all and generally is a good practice, regardless of whether you accomplish this over NIS/NIS+, LDAP, custom rsync/rdist scripts with flat files or a Hesiod/Kerberos infrastructure.

--Jim Dennis, jimd@starshine.org

The eight-character username limit on older UNIX systems wasn't just tradition, it was hard-coded in as the absolute limit. Early Linux distributions followed this same limit, though most modern implementations no longer have such a restriction (ones based on glibc don't, for sure). The current limit for the username string is 32 characters. [I notice that Jim Dennis is saying it's 31, I tried on my RH9 system and I did actually get 32, tried 33 and it said eh uh.]

That being said, however, does not mean it's necessarily a great idea to exceed the 8-character filename tradition right away. Depending on what type of services you are running on your network and how homogeneous or heterogeneous it is, many things may be inadvertently broken. For instance, certain services (e.g. NIS) may have difficulties with longer usernames and could truncate them down to eight characters (or do something even worse), making usernames appear non-unique when in fact they actually are. Or even simpler than that, commands like ps or w (older versions) may squash names down to eight characters, so if you are looking to find all processes owned by LinuxKid, you will also unwittingly find those belonging to LinuxKiddos and that too could have some obviously undesirable results.

I would look into all services running on your network providing anything with usernames or passwords or are even partially related to such things before changing to longer usernames, just to be safe. Then try it out, gradually, so you can discover any unforeseen issues before they reach the general user pool.

--Timothy Hamlin, thamlin@zeus.nmt.edu

I'd say compatibility with other (old mostly) systems is the key issue here. To get around this, what I have done to get the best of both worlds is: set the user name as, say, jsmith. If the requirement is to have the full name (maybe for email purposes mainly), such as john.smith or johnsmith, then create and alias in /etc/aliases with lines like:

johnsmith:  jsmith
john.smith: jsmith

and run the newaliases command. Other ways to accomplish this are available, of course.

--Felipe Barousse Boué fbarousse@piensa.com

Don Marti is Editor in Chief of Linux Journal

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix