This is the first post of my emerging server guide. The guide will show you how to reproduce my server setup, what decisions I made and why I made them (in case it’s not just based on personal taste, or, well, maybe even then ;) ). This should serve as a reference for you, just because it seemed right for me doesn’t mean it’s right for you, too. Don’t shut down your brain when following this. Read my comments, and the comments in the config files. Still, this guide is written for, well, maybe not Linux beginners but for beginners starting to be intermediates on the command line, who see themselves confronted with managing a system solely by the command line. If you don’t understand something, read about it on the web! For basic stuff, I’ll only tell you what to do, but in case commands or terms I use are new to you, stop reading and learn about them. Try to understand what you actually do there, if you don’t you’ll end up wit a system you can’t handle. Chances are you’ll get hacked and held accountable for all that spam sent out from your server. You’re warned.
Before you get any service running, you need a solid foundation to work with. This entry covers the basics of how to set up your working environment on the server, and some tricks & hints to ease your future work.
Let’s assume you just installed Debian Squeeze on your server machine or just got the root password from your provider and logged in.. Do you feel the power? ;) First thing is to make sure the door you just entered through gets closed, so no one can follow you.
# Change your root password! And make sure you remember it, # resetting the root password is unnecessary work. You've better things to do! passwd # Change the sources.list at the bottom to include squeeze-backports (for a newer tmux version) vi /etc/apt/sources.list => # backports for tmux deb http://backports.debian.org/debian-backports squeeze-backports main => # Debian Squeeze is quite old now. (Maybe not in Debian scales..) # A lot of security holes in the shipped software got fixed by then, # so upgrading will take time, but still, as always, get all upgrades immediately. aptitude update aptitude upgrade
Well, so far it was trivial. Next step is to install the tools you need.
- Well, my favourite editor. If you never used any editor on the terminal, you might want to give nano or pico a try, and read http://www.rudism.com/s/vimcreep .
- zsh (seperate post)
- My favourite shell. If you just used bash (the standard shell) so far, just follow what I write here and you’ll end up with a shell with amazing autocompletion features.
- Last point in the favourites line-up, git is the distributed version control system I use most. etckeeper works with mercurial and bazaar, too, so you can install whatever you like.
- This is the terminal equivalent of your graphical process monitor on your desktop. Start it up, and you’ll see the cpu and memory usage of the machine and all running processes sorted by their cpu usage.
- tmux (seperate post)
- Desktop terminal emulators usually have the feature of tabbed terminals. tmux does something similar on the server side, it’s a terminal window manager where you can create, switch and close windows, and especially leave them open and running when you disconnect from the server. You should try to work inside a tmux window on the server, so when you get interrupted, you can always just detach the window and log off while e.g. upgrades, compiles, backups or other long-lasting operations still keep running.
- etckeeper (seperate post)
- etckeeper is a tool to get all of your config files beneath /etc under a version control repository. If you use it from the beginning, you can always get back to any revision of your config files in case something goes wrong, and it even creates an automatic revision if you install something with aptitude.
Oh, and by the way, I like to make notes on paper or in a text file to record what and how I configure a server (actually I do that for desktop / laptop installations, too) to keep track of the problems I ran into and how one can solve them. Very handy if you have to reproduce your setup after a fresh install, and as you might have guessed now, this guide is actually based on the notes I made for the latest server. ;)
From now on, when I put something in <pointy brackets>, that’s the stuff you have to replace with your own parameters.
# Install your favourite tools to work with the server aptitude install vim zsh git htop etckeeper aptitude -t squeeze-backports install tmux # One shouldn't be logged in and work as root if one doesn't need to. Create a normal user for yourself, later we'll even forbid root logins. adduser <username> logout # reconnect as the newly-created user ssh <username>@<host> # Now we start to secure the ssh daemon. Open the sshd config file: su vim /etc/ssh/sshd_config # Find the line saying PermitRootLogin Yes, and change it to PermitRootLogin No # For now, you should use your own random port for ssh, choose a number between 10000 and 65000 # You can leave it at 22 though, in case you want to use ss(l)h later on. (will be a separate post again. ;) ) Port <port> # Close your editor again, and restart the ssh server. Hope that everything you entered was right. service ssh restart # You installed etckeeper already. We just made the first change to a config file in etc, so we # commit the changes and create a new revision. # There'll be a seperate post on that, too. git add /etc/ssh git commit -m "Changed ssh port and prohibited root login." logout # On your local machine again, you can create a config file for ssh. # This will enable auto completion for ssh hosts on zsh, # and ssh <hostname> will be enough to connect in the future. vim ~/.ssh/config # Add these lines Host <host> User <username> Port <port> # and close the editor again
ssh public private key authentication
Especially when using Port 22 as the ssh port for your machine, you’ll notice automatic bots hammering against your ssh login soon.
This should make you aware that everybody who can guess your username and your password owns your machine. There’s a much more secure alternative to logging in with passwords, ssh supports logging in with public private key pairs, the very same concept used with PGP etc.
Combined with an ssh-agent, this has the advantage of not needing to type a password anymore for logging in to your remote machines, so go for it! ;)
# Generate a new rsa key pair in ~/.ssh/ # id_rsa is your private key. If you don't enter a passphrase while generating the key, # everybody who has this key file can login to every server you allowed it to. No passphrase # makes sense for automatic login in scripts, but for your personal use, you should enter one. # id_rsa.pub is your public key file, this can be safely shared with anybody. ssh-keygen -t rsa # This copies your public key file as an authorized key to the specified machine. Afterwards, # you can log in using the private key. ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<host> # Try to log in, you should be asked to enter the passphrase for your key instead of the password. ssh <username>@<host> logout
Now to the ssh-agent. If you are a KDE user like me, you can install ksshaskpass to get that integrated into KWallet. Create the file ~/.kde4/Autostart/ksshaskpass and enter the following in there:
#!/bin/sh export SSH_ASKPASS=/usr/bin/ksshaskpass ssh-add </dev/null
And you’re done! Next time you log in to your local machine, the usualy KWallet authorization dialogue should pop up, and after you entered your passphrase next time you log in to your remote server, it’ll never ask again. :)
# console tip: # You can find out the absolute path of any binary, e.g. ksshaskpass, with which ksshaskpass
Concerning other desktop environments or the usage of ssh-agent without any additional program - I know it does work, (e.g. there’s gnome-ssh-askpass, I guess this does the same as ksshaskpass but for the gnome keyring) but I have no idea how.
The places your search engine of least distrust will take you will have much better explanations to this than everything I can provide. Good luck!
Why I chose Debian
The biggest advantage of Debian for personal servers is that nearly everyone uses Debian for their servers, so most documentation and tutorials are written for Debian / Ubuntu Server in mind, especially if you want to set up a service on a single, small server with very moderate usage. (For a high-traffic failover server cluster, CentOS or whatever might be better suited.)
But while I appreciate Canonical’s plans to get out on phones and TVs, I’m not a big fan of Ubuntu, so I chose Debian. ;)
One year ago I was tired of the old software you get with debian stable and updated to testing, but then I learned why you actually want to have a stable distribution for your server: Your setup doesn’t break with updates. No new features being added to the installed software, no new versions but only security fixes in the repositories means that your setup which works now will almost definitely work after the update, too, and you only have the hassle of updating once in about two years, when a new Debian gets to stable.
And in case you need newer software than provided with Debian stable, there might be an official backport and many projects have their own repository for debian where they ship the latest stable version.
Why I use aptitude and not apt-get & apt-cache
Mainly because I prefer to have one command for searching, installing and managing packages. :D But as far as I know, aptitude has its own database for dependencies between your installed packages and is able to purge a dependency when there’s no program installed anymore that pulled in the dependency. That database is the reason why you should choose betwen apt-get and aptitude and then stay with your choice, too.
Debian mailing lists
As soon as you running a Debian server, you should subscribe to the debian-announce and debian-security-announce mailing list to get announcement mails for new debian releases and security fixes.
Next post will be a shorter one about tmux. I hope to get this out, soon. :) :wq