1. You should do "apt-get dist-upgrade" to get new kernel packages as well, otherwise you are stuck on an old kernel. (You might want that. I prefer updated kernel for the security, firefoxen, etc.). "apt-get upgrade" will only update existing packages - but the kernel updates require new packages to be installed.
2. If you're on ubuntu, root already has no password, and your initial setup user (whether it is called "deploy" or "kilroy") is in the sudoers file.
3. Other things I install in the "5 minutes with server" are: htop molly-guard screen git-core etckeeper
git-core because I prefer my etckeeper in git, but if you want it in bzr you don't need git-core. INSTALL AND CONFIGURE ETCKEEPER AS SOON AS YOU CAN, seriously. You need it. You'll thank me when you try to figure out when and how something in /etc got borked. (you need to edit /etc/etckeeper/etckeeper.conf if you use gif. You need to do "etckeeper init" and then "etckeeper commit" to establish the baseline)
molly-guard stops you from rebooting the wrong server
screen (or alternatively tmux) lets you keep your session open through ssh session disconnects (e.g. when moving from wifi to 3G, or between 3G towers that give you different external IP). The most useful way to use screen is "screen -xR" which also lets you share your session with someone else should you need to.
"screen -x" requires a session to already exist, whereas "screen -xR" will join one if it already exists, but will create one if it does not. At least it does in v4.00 which I use. If you have a "screen" call in your @reboot, you already have a session, so they will work the same.
I'm not sure I get your "on the contrary". Any configuration change on a managed configuration file is transient and bound to overwritten next time state is restored. This makes etckeeper absolutely less useful compared to a system where there is no way to restore state and an unfortunate "rm /etc/passwd" has little remedy. It does not make it "useless", but it's definitely less needed.
Possibly my misunderstanding, but I thought chef and puppet only push changes on the files that they are configured to control - There are tens of files in /etc/, some possibly modified by an "apt-get upgrade", then reverted by chef, some that chef/puppet do not try to modify.
etckeeper is a net that gives you an idea of how /etc looked on a given date or apt-run, not just how it was supposed to look (Which is what you get from the chef/puppet logs).
Question to chef/puppet users: do you restore the state continuously? or only when you've made a change?
Yes, it's true that chef/puppet do not overwrite your entire etc, just a subset of it, but presumably, you'll have your critical components backed by it (otherwise, there is not much point in using a configuration management system). So it is still useful on such a system, but not to the same extent of a system without configuration management.
> but presumably, you'll have your critical components backed by it
Often, the way you discover something is critical is after the first time it breaks. Backups may help, but proper version history is probably going to give better insight into what happened.
It is the point that you "never do that". However, it's been my experience that e.g. when troubleshooting, people always make local modifications, and don't always remember to revert them / restore from configuration management.
I have no experience with chef/puppet, so I might be mistaken, but I'm under the impression that they only push changes when asked to - which means a local change may survive for several weeks before it is overwritten. But I could be wrong about that.
2. If you're on ubuntu, root already has no password, and your initial setup user (whether it is called "deploy" or "kilroy") is in the sudoers file.
3. Other things I install in the "5 minutes with server" are: htop molly-guard screen git-core etckeeper
git-core because I prefer my etckeeper in git, but if you want it in bzr you don't need git-core. INSTALL AND CONFIGURE ETCKEEPER AS SOON AS YOU CAN, seriously. You need it. You'll thank me when you try to figure out when and how something in /etc got borked. (you need to edit /etc/etckeeper/etckeeper.conf if you use gif. You need to do "etckeeper init" and then "etckeeper commit" to establish the baseline)
molly-guard stops you from rebooting the wrong server
screen (or alternatively tmux) lets you keep your session open through ssh session disconnects (e.g. when moving from wifi to 3G, or between 3G towers that give you different external IP). The most useful way to use screen is "screen -xR" which also lets you share your session with someone else should you need to.