I am an avid fan of the Linux utility screen. It allows you to have multiple ‘screenlets’ inside of one command line session on a server, swapping between them as you wish. On top of that, if you get disconnected from your server because you have to do some admin work from a hotel room with a poor internet connection, the screen will keep whatever work you were doing on your server chugging along. If you need to fire up some long running process, but you don’t want to stay SSH’d into your remote server the entire time, screen will also let you ‘detach’ from it, leaving the command running, while you go off to Olive Garden to grab a bite to eat.

I’m not going to go into all the details of how to work screen… instead, I am going to cover what I use in 90% of my interactions with it, which is a surprisingly small list! First, we are going to get it all set up to give you a nicely configured screen session with a few screenlets in it. We can do this by placing a file called .screenrc inside of your home folder. Here are the contents of my .screenrc:

shelltitle ''
vbell on
autodetach on
startup_message off
defscrollback 2048
termcapinfo xterm* ti@:te@

hardstatus alwayslastline "%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%< %=%D %M %d %c" hardstatus string '%{= kK}%-Lw%{= KW}%50>%n%f %t%{= kK}%+Lw%< %{=kG}%-= %d%M %c:%s%{-}'

screen -t r00t 0 bash
screen -t vimTerm 1 bash
screen -t general 2 bash

I can’t take complete credit for that .screenrc. The hardstatus line I pulled off the internet somewhere 😉

It works out really well, it gives a nice bar at the bottom which shows all of your screenlets and highlights whichever one you are now on. It also keeps a clock in the bottom right corner, and will flash the title of a screenlet if a ‘bell’ go’s off in it.

Now that we have a good screenrc, you can fire up screen by running the command ‘screen’ (you may need to install screen from your distributions repository). But we can take this one step further and have your system fire up screen automatically when you SSH into the server by adding a little snippet of code at the end of your .bashrc:

if [ $SSH_TTY ] && [ ! $WINDOW ]; then
  SCREENLIST=`screen -ls | grep 'Attached'`
  if [ $? -eq "0" ]; then
    echo -e "Screen is already running and attached:\n ${SCREENLIST}"
  else
    screen -U -R
  fi
fi

That will fire up a screen session when you SSH in unless someone is already attached to your user accounts screen session. Now that we have screen configured, and we have your server starting it up automatically when you log in, lets learn how to use it!

If you are using the .screenrc that I provided above, you will notice the 3 screenlet’s titles at the bottom (r00t, vimTerm and general). You can adjust those names by editing the .screenrc. In order to swap between different screenlets use the keystrokes Ctrl+a NUMBER. The number will be whatever number of screenlet you want to go to, so if you want to go to screenlet 1, it would be ‘Ctrl+a 1’.

If you want to detach from your screen, leaving everything running, and enabling you to disconnect from the server, use the keystrokes Ctrl+a d.

If you log into the server and you get a message saying that ‘Screen is already running and attached’ you can detach screen from the other location and attach it to you current SSH session with the command ‘screen -D -RR’. That command will do whatever is necessary to get you a screen session… detaching other sessions and attaching, starting a new session, attaching to a detached session etc.

So this blog post is going to cover some basic security do’s and don’ts.  The end goal will be to have an Ubuntu powered server that is not only decently secure, but also not so secure that it is a pain to work with.  I will be covering many things that should be done as part of basic security, some general best practices, and I will also hit on one thing that I find to be a HUGE annoyance than many many… many… people do, thinking that it will make their server more secure, when in reality it does next to nothing.  I will be targeting an Ubuntu 11.10 server in this article, but everything that I have in here should work on anything 10.04 LTS and up.  I am mainly going to be focusing on securing SSH logins. Read on after the break

Recently I built a server to host the blogs and other PHP powered websites of a few family members.  I wanted something lightweight, efficient and fast.  With that in mind I threw out the “standard” of Apache and it’s mod_php and instead went with something else entirely.  This article is going to be geared at people running a server with Ubuntu 10.10 or newer (sorry LTS fans… php5-fpm isn’t available in your repos… but you can backport it fairly easily).  I’m going to be including some config file examples as well, everything you need to get this up and running will be included… and it’s easier than you think 😉  Catch the details after the break

Doing what I do for a living, I tend to see the same mistakes made over and over.  Luckily where I work I am in a position to have a conversation with the person that made the mistakes, offer up a little bit of education, and most times they are very receptive to it.  I am also in a position where I can help them to transition from their currently slow and possibly buggy solution to something that gives them the speed and performance that they want.  This entire post is going to be targeted at Linux powered servers but many of the points will apply equally as well to Windows powered servers.

This one is a little bit long so if you want the full disk, click the link

The majority of this information is for Ubuntu, but if you are running something Red Hat based, such as CentOS, then at the bottom there is a nice command for you.

So I was asked a question the other day… “How do I install LAMP on my linux server?”. First, let me cover a few things about a LAMP server. LAMP is not a piece of software itself, it is a term used to describe a particular server configuration. It stands for Linux Apache MySQL PHP (get it… L-A-M-P). So you don’t install LAMP, you install the software I mentioned earlier (and a few extra pieces to tie them together) and you have what is called a LAMP server.

A LAMP server is pretty much your “cookie cutter” web server. It has PHP for server side web code processing, it has Apache for serving that content, and it has MySQL as a database for storing… uhm… data.

I am not going to cover how to install Linux, there is already some great documentation (like THIS ONE for Ubuntu 10.10 server edition, or if you are an LTS fan THIS ONE for Ubuntu 10.04 LTS).

Installing a LAMP server in Ubuntu is amazingly simple. There is even a TUI (Textual User Interface… think of it as command line graphics with nice colors and such) to make it so simple a caveman can do it. After you have your Ubuntu powered server up and running, log into it. Once logged in, run the following command:

sudo tasksel

This will bring up the tasksel TUI. Next use the up and down arrows to highlight the box next to ‘LAMP server’ and press the spacebar to select it. You should now have an *asterisk* next to it. Then press TAB to highlight the OK button and press enter. Your server will start cranking away turning itself into a full fledged LAMP server. If you don’t see the option for ‘LAMP server’ (which could be the case if this is a brand new installation) then try exiting tasksel, running an `apt-get update` and then going back into tasksel. It will ask you one question as it go’s…

Password for the MySQL root user: This is a prompt asking you what you would like your MySQL root user to have. This is not the same “root” as your root user account, but it serves a similar purpose. This will be the password used to log into the database with full administrative permissions, able to create and delete anything from any database. Definitely make this a strong password and do not share it with anyone that doesn’t absolutely need it. It will ask you for it twice to make sure that you don’t have any typo’s in it.

That’s it… your done… no really… that’s all there is to it… You can now host your own PHP website (perhaps even your own wordpress blog).

Do note that you can have a LAMP server running on any flavor of Linux, but since I am an Ubuntu administrator, and I prefer Ubuntu, I tend to give instructions for ubuntu. Red Hat based distributions have a similar function called groupinstall which you can use by running the command:

sudo yum groupinstall "Web Server"

And if you are on a BattleToads server the command would be:

kindlydotheneedful LAMP

So, to start I am glad that I have received a few requests for topics.  One of them kind of covered two topics, automatic updates and log file management.  I am going to split them up into two different posts, with the first being automatic updates.

Ubuntu, and many other distros, have it built in to enable automatic updates through their package managers.  While you can install updates manually through the command line in Ubuntu through apt-get or aptitude (I prefer aptitude), sometimes you have a system that you want things a little more “hands free”.  In Ubuntu (and other Debian/Debian based distros) this is provided by the unattended-upgrades package, available in your repository.  On the desktop release, it is already installed, on the server release it is not.

First, it would be bad of me to not point out the official documentation on this.  It is targeted at the server, but it applies to the desktop as well: https://help.ubuntu.com/10.10/serverguide/C/automatic-updates.html Note that is for Ubuntu 10.10, but they have similar documentation for other releases as well.

In Ubuntu 10.10 (and 11.04 natty), it is set by default for Security updates only, but it is also only set to update the package list.  The unattended-upgrades package gives quite a bit of control over what it will and will not do, as well as options for letting you know what it did.  In order to get it to actually install the packages automatically, you would need to edit the file /etc/apt/apt.conf.d/10periodic .  In this file you will find a few options, as mentioned, by default the first one is enabled, updating the list of available packages.  All of the settings in this file are how often that task will be performed in days.  Note that this file is part of the package update-notifier-common which is not installed by default on the server release, but you can create it easily.  The default contents of this file are:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";

Or you can install the update-notifier-common package which comes with some other nice goodies as well such as adding some information to your login MOTD if there are updates available, a reboot is required for a package update, and a few other nice things to have.

You can set it to download the new updates (but not install them) with the second option, as mentioned, setting it to 1 would have it do that every day, once per day, 3 would be every 3 days.  The third option is how often you would like it to remove un-installed packages from the local package download cache.  One option that may not be in that file by default (but you can add it) is the option to actually make it install the updated packages.  If you set APT::Periodic::Unattended-Upgrade to a value, then new packages will be installed that often.

Now that we have covered how to make it install upgrades automatically, what if you would like to be notified that it happened?  You can always check /var/log/unattended-upgrades, but that go’s against my first rule… I feel that whenever possible, my servers should come to me, not the other way around.  So now we will make unattended-upgrades let me know when it does something.  For that, we go to the file /etc/apt/apt.conf.d/50unattended-upgrades .

In this file, there is a setting Unattended-Upgrade::Mail, if you un-comment this line, and set it to your email address, your system will email you a summary of packages installed, or any errors encountered.  Please note that for this to work, you will need something that provides /usr/bin/mail.  The package mailx will provide this, it will also work with sendmail, postfix and others.  Do note that because there will be several URL’s, all plain text, and the from address will be root@hostname, that the email will likely be spam filtered (it is for sure by gmail).  After the first email arrives, just check your spam folder and then whitelist the sender of the email.

Also, the default is for unattended-upgrades to only work with security related updates.  This is also modified in the file /etc/apt/apt.conf.d/50unattended-upgrades .  If you would like it to also install updates from sources other than just the security repository, at the very top of this file you will see the entries for the other default repositories.  Any that you un-comment will also get some unattended-upgrade love.  There is also a setting in there to have it automatically reboot the server if a package install requires it… I prefer to leave this one off as I like to be in control of any downtime that my server has.

This pretty much covers how to get off the ground with unattended-upgrades.  If you have any questions about it, or if you want to know if it can do something in particular, leave a comment!