Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Configuration

sstephenson.us

Post reply on HN
Print view View original

41–50 of 55 posts

Re: On Configuration

#41

Post by pyre »

moe wrote: post #38
jaylevitt wrote: post #34

Earlier quoted context omitted.

You're saying it's better for sysadmins to all log in as "prod" or "root"? How do you figure?

Firstly on properly automated hosts you very rarely have to login. And when you do then 'prod' and 'root' work just fine. Scattering user-accounts across machines is a maintenance headache (trust graph, sudo passwords or passwordless sudo, filesystem permissions) and encourages bad practices ("i'll just run this small script, quickly"). If you're serious about auditing then wtmp and notoriously incomplete shell-histo…

  > properly automated hosts

  > Scattering user-accounts across machines is a
  > maintenance headache
Seems to me that properly automated hosts could easily have user accounts automated too, no?

Re: On Configuration

#42

Post by stack_underflow »

bejar37 wrote: post #15

Sort of OT: Does anyone know any good examples (on github or otherwise) of a dotfiles repo that can easily be installed on a machine? I've been wanting to do this for a while, but I'm sort of a noob on symlinking and such

I've designed my dotfile repo to be easily installable on any machine I happen to be on with the help of a script that backs up any existing dotfiles that may conflict with those in my repo. This allows me to backup any existing configs, link my own temporarily, then restore the old ones and 'rm -rf ' so it's as if I never even touched the original configuration.

If you want to try it out just run the following commands:

    git clone git://github.com/acx0/etc.git ~/etc
    cd ~/etc
    git submodule update --init     # my link script is in a separate repository so it's a submodule in my dotfile repo

    cd link.sh
    ./link.sh                       # this will show the status of any conflicting files
    ./link.sh -b                    # backup any conflicting files
    ./link.sh -wf                   # force write (symlink) my set of config files
And everything's set up. If you want to install the vim plugins I use, just run

    vim -c 'BundleInstall'
and let Vundle download the plugins (you have to restart vim to use the plugins).

Then when you're ready to restore your ~/ back to its original state, run

    ./link.sh -r                    # restore any configs that were backed up
which also takes care of deleting the configs you didn't have (so if you backed up with no conflicting files (backup dir empty), and then restore, it'll just remove all the existing symlinks)

If you didn't run the backup command, you can simply run

    ./link.sh -d
to delete the symlinks for all the files in the repo. Then just remove any traces of the repo with 'rm -rf ~/etc'.

Re: On Configuration

#43

Post by moe »

donavanm wrote: post #40
moe wrote: post #38

Earlier quoted context omitted.

Firstly on properly automated hosts you very rarely have to login. And when you do then 'prod' and 'root' work just fine. Scattering user-accounts across machines is a maintenance headache (trust graph, sudo passwords or passwordless sudo, filesystem permissions) and encourages bad practices ("i'll just run this small script, quickly"). If you're serious about auditing then wtmp and notoriously incomplete shell-histo…

Let me know how your compliance audits go. I'm sure the pci dudes won't mind that "root" logged in from 20 different hosts.

Why would a human login at all?

In serious deployments people don't login to production hosts outside of extra-ordinary incidents. This entire discussion is based on a broken premise.

Re: On Configuration

#44

Post by bdunbar »

moe wrote: post #38
jaylevitt wrote: post #34

Earlier quoted context omitted.

You're saying it's better for sysadmins to all log in as "prod" or "root"? How do you figure?

Firstly on properly automated hosts you very rarely have to login. And when you do then 'prod' and 'root' work just fine. Scattering user-accounts across machines is a maintenance headache (trust graph, sudo passwords or passwordless sudo, filesystem permissions) and encourages bad practices ("i'll just run this small script, quickly"). If you're serious about auditing then wtmp and notoriously incomplete shell-histo…

And when you do then 'prod' and 'root' work just fine.

They do until you have to show auditors who logged in and when.

Scattering user-accounts across machines is a maintenance headache

That's why God invented Active Directory.

Re: On Configuration

#46

Post by possibilistic »

groby_b wrote: post #13

Don't worry, it's a phase. You'll go back to configuring at some point, just more judiciously. And then you go back to "Vanilla install ONLY!". And then you start to tinker again, just even more carefully. At least that's my experience over the last 20+ years. You need - for all the reasons outlined - the ability to work on stock systems, because you never know if you'll have all your favorite tools. At the same time…

Hey, you stole a line from my hosts file! :)

Re: On Configuration

#47

Post by jaylevitt »

moe wrote: post #43
donavanm wrote: post #40

Earlier quoted context omitted.

Let me know how your compliance audits go. I'm sure the pci dudes won't mind that "root" logged in from 20 different hosts.

Why would a human login at all? In serious deployments people don't login to production hosts outside of extra-ordinary incidents. This entire discussion is based on a broken premise.

In single-server deployments, you're logging in because you're the only employee.

In ten-server deployments, you're logging in because every machine is trying to take on a new role or aspect and you're still learning how to automate that.

In thousand-server deployments you're logging in because the latest batch of Seagate drives has a statistically significant failure rate and you need to try some experimental firmware they wrote for you.

When do you get "serious"?

I don't always log into my production boxes... but when I do, I log in as 'jay'.

Re: On Configuration

#48

Post by pyre »

jaylevitt wrote: post #34
moe wrote: post #33

Earlier quoted context omitted.

more important than ever to argue for individual user accounts, not role accounts, on production machines. For security and logging, of course. That's a terrible idea on so many levels, I hope you're being sarcastic.

You're saying it's better for sysadmins to all log in as "prod" or "root"? How do you figure?

If you're worried about logging who did what under the user, you can disable password access, and use ssh keys. IIRC, ssh can log which key was used to log in. I'm not sure how audit-able this would be (for example) in determining which user logged into 'prod' ran the malicious process.

Re: On Configuration

#49

Post by moe »

bdunbar wrote: post #44
moe wrote: post #38

Earlier quoted context omitted.

Firstly on properly automated hosts you very rarely have to login. And when you do then 'prod' and 'root' work just fine. Scattering user-accounts across machines is a maintenance headache (trust graph, sudo passwords or passwordless sudo, filesystem permissions) and encourages bad practices ("i'll just run this small script, quickly"). If you're serious about auditing then wtmp and notoriously incomplete shell-histo…

And when you do then 'prod' and 'root' work just fine. They do until you have to show auditors who logged in and when. Scattering user-accounts across machines is a maintenance headache That's why God invented Active Directory.

They do until you have to show auditors who logged in and when.

SSH has logging. Also if you have audit-requirements then the login-log is normally the least of your worries.

That's why God invented Active Directory.

That must be one cruel god you have there...

Re: On Configuration

#50

Post by moe »

jaylevitt wrote: post #47
moe wrote: post #43

Earlier quoted context omitted.

Why would a human login at all? In serious deployments people don't login to production hosts outside of extra-ordinary incidents. This entire discussion is based on a broken premise.

In single-server deployments, you're logging in because you're the only employee. In ten-server deployments, you're logging in because every machine is trying to take on a new role or aspect and you're still learning how to automate that. In thousand-server deployments you're logging in because the latest batch of Seagate drives has a statistically significant failure rate and you need to try some experimental firmwa…

In ten-server deployments [...] still learning to automate

That's why your original comment tipped me off.

It's hard to recover from bad patterns like the one you proposed, it's easier when you try to get as many things right as possible from the start.

In thousand-server deployments you're logging in because

I take it you have not worked in such an environment before. I can assure you nobody manually logs into hundreds of hosts to "try some experimental firmware" - or to do anything really.

Beyond a couple dozen hosts pdsh and "knife exec" simply don't work anymore (rollback? what rollback?).

Post reply on HN