> Every fresh server install, I have to make up a meaningless string called the 'login'
If you are only doing the occasional install then this really shouldn't be a great hardship. If you are installing many servers you should have this part automated. And ti shouldn't be meaningless either. I think you are doing it wrong.
> Once upon a time, I could use the well known admin login 'root'.
You still can. root login can always be reenabled if you want it that badly. There is also "sudo su" (unless explicitly disabled by your admins) to avoid repeated invocations of sudo while you are performing a long admin task.
> - Here's a better way of doing it:
> Give me a server distro where I don't need a 'login'.
No, no, and thrice no. Far too many newbies will leave it in that state and get hacked to buggery in short order. Even if it is only for local console logins, I'd consider it a bad idea.
No matter how inconvenient it is, server install should default to an insecure state and allowing access without authentication is such a state.
Live CDs often do this, but they are not production systems.
> Meanwhile, why is apache pretending to be a 'user'
Well that much is a valid point. There has been work in this area but non of it has made its way to default setups of most unix-a-like systems.
> There is also "sudo su" (unless explicitly disabled by your admins) to avoid repeated invocations of sudo while you are performing a long admin task.
You can also do 'sudo -s', which keeps you in your normal user's shell. It's pretty slick.
Well, as the old saying goes, those who do not know Unix are doomed to reinvent it.... poorly. I am rarely surprised anymore by the bad ideas I see people come up with.
No, you can have many users, and this way you try to guess everyone's password at the same time. Also, sadly, passwords tend to be repetitive, so now someone can accidentally guess someone else's password.
Uniqueness is not an issue - see my original point - we only create one admin user on servers!
Imagine a team of 3 people running a SaaS webapp on 3 web servers & 1 db server. I guarantee no one will waste their time creating 3 'users' on each server i.e. 3x4 = 12 'users' on that cluster.
> I guarantee no one will waste their time creating 3 'users' on each server i.e. 3x4 = 12 'users' on that cluster.
It sounds — and I don't mean to be rude — like you have not been involved in a "real" production environment.
Modern Unix environments are automatically managed with modular configuration systems such as Puppet or Chef. Sysadmins have little or no need to log into servers to configure them; they just hook the server into Puppet (for example), and Puppet will do everything required to mould the server into its correct state: Create users, install public keys, install packages, write config files etc.
Puppet in particular is so simple that you would want it even if you were managing a single box. Why? Because if that single box dies/is wiped/whatever, you just get a new box and point it at Puppet, and it will become identical (minus whatever data you lost) to the old one. Or need to buy more hardware? Just point the new box at the Puppet server, and you have two, or three, or ten identically configured boxes.
So yes, in a sense you're right; sysadmins won't waste their time creating a bunch of users, because they will let the configuration management system do it. :-)
> Puppet in particular is so simple that you would want it even if you were managing a single box.
You know... that's so blindingly obvious, that it had never even occurred to me. I'm in the middle of a home "IT refresh" right now and I'm trying to update the obscene amounts of documentation needed on how to configure every little thing.
Your comment just gave me a "the code is the documentation" kind of moment; realized I'd much rather have all that documentation checked into a Git repo somewhere as automateable configs. Thanks!
It's really nice having separate users in production for a server. That way, you log sudo and know who issued an admin command. But in a larger system, you don't worry about setting them up on each server; instead, you rely on LDAP.
Unix is the LISP of server operating systems. It's a multiplier. In return, it demands much more from the operator. This is not ideal for a desktop system. It's amazing when you have an admin who knows his shit.
If LDAP ever goes down you might want to retain the ability to login to your box.
I ran into a problem similar to this on a recent DR exercise.
Active Directory (an LDAPish service) was down. Was going to be down for a while. If I could get into my three Windows hosts I could re-jigger the service account for $APP from the AD user to a local account, start things up.
I couldn't login to the servers: my .admin account was in AD. No one had any idea what the local administrator account could be. We were just .. stuck .. until AD came up.
I could have booted the system a rescue disk (linux) and edited the SAM to change the password. Didn't happen then for complicated reasons. And one shouldn't have to resort to heroic methods to get local access back.
And can you imagine doing that for hundreds of hosts?
And can you imagine doing that for hundreds of hosts?
This is why you:
- Always provide redundant, network-local LDAP servers so that LDAP doesn't go down.
- Wire up remotely accessible serial consoles that provide emergency-level local root access.
You can attach a modem to the serial console systems, or a hardline (which is what I did at a previous job) between your data center and offices.
We had a fixed 'role' account for the serial console systems, but it existed only for the purpose of emergency access, could only be accessed from specific local networks (we divided different classes of employees into different VLANs), and the knowledge of the password could be constrained to those that needed rare "server fell over" access.
The serial consoles won't work if the parent poster removes all local accounts and goes 'LDAP only'.
Unless I've misunderstood something about that. It happens.
We do the redundant Active Directory thing. It didn't help during the DR exercise when the AD guy did something foolish (don't remember what) and the AD / DNS host went down for a few hours.
Single host because the DR was limited in scope.
I was fine with my Solaris hosts - had local root access via serial and SSH. I was simply locked out of my Windows hosts, and could not reconfigure those services to work without AD.
This is why we have cfengine (or similar). Because yes, we do have NxM accounts (double and triple figures respectively), and we can all passwordless-ssh to any box we have to and have our dotfiles set up just the way we like them.
But no, we don't "waste our time" creating these accounts. We have tools to do this for us. Revolutionary, I know.
I guarantee no one will waste their time creating 3 'users' on each server i.e. 3x4 = 12 'users' on that cluster.
You're just wrong. Plenty of people will do this. If one of those three people leave the company, you can disable that account without having to change the password for the other two. If you insist everyone use sudo, you get logs of all the commands run via sudo, and that includes who ran it.
This is all really useful. You don't understand why it's useful, but lots of people do understand it.
If you are only doing the occasional install then this really shouldn't be a great hardship. If you are installing many servers you should have this part automated. And ti shouldn't be meaningless either. I think you are doing it wrong.
> Once upon a time, I could use the well known admin login 'root'.
You still can. root login can always be reenabled if you want it that badly. There is also "sudo su" (unless explicitly disabled by your admins) to avoid repeated invocations of sudo while you are performing a long admin task.
> - Here's a better way of doing it:
> Give me a server distro where I don't need a 'login'.
No, no, and thrice no. Far too many newbies will leave it in that state and get hacked to buggery in short order. Even if it is only for local console logins, I'd consider it a bad idea.
No matter how inconvenient it is, server install should default to an insecure state and allowing access without authentication is such a state.
Live CDs often do this, but they are not production systems.
> Meanwhile, why is apache pretending to be a 'user'
Well that much is a valid point. There has been work in this area but non of it has made its way to default setups of most unix-a-like systems.