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

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState