A Sampling of Best of Tech
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, firstname.lastname@example.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, email@example.com
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é firstname.lastname@example.org
Don Marti is Editor in Chief of Linux Journal
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development