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
Things to consider when hosting a website
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
WordPress app for webOS!
So I just installed the WordPress app for webOS on my HP touchpad. Hopefully now that I can update this thing from anywhere I will post more.
First impressions so far are good. They have done a very nice job with it. The ui is very clean, it makes good use of cards and sliding panes. I can view the blog stats with it (had to install jetpack on the blog for that, but that’s not a big deal).
Now if I can just get people to stop thinking this thing is a friggin iPad, lol.
How to make a LAMP server
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:
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:
Enabling automatic updates on Ubuntu
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!
First post… YAY!
So in my efforts of being lazy, because I think all Linux administrators should strive to be lazy (more on that later). I have decided to start a blog. This will be a place where I will use as a general dumping ground for thoughts, fixes, maybe even discussions. Reason being, sometimes I find a problem that makes me scratch my head… that issue may make others scratch theirs also! Once I find a fix for it, then it would be nice to have it out there on the internet somewhere so that others can benefit from my journeys… There will also be times that I come up with a neat trick that others may be interested in, and it would be nice if they could find it, and it would also be nice if I could point them somewhere for instructions rather than having to walk them through it every time.
I think the topic for this first post will be why I feel that all Linux admins are, and if not, should be LAZY! In Linux we have these wonderful scripting languages… bash, python, perl as well as others. The nice thing about them is that whenever you use one to do something, it does it the exact same way… every time… While a good Linux admin should be more than capable of doing it on their own, the problem comes when you have a whole team of admins, all doing it on their own. Everyone has “their way” instead of doing it “the way”. That isn’t to say that “the way” is the best method, but it is good to have a method that everyone uses. That way if I set up something on a system, then someone jumps on that system later, they are familiar with how it is set up, and how it is controlled.
The other nice thing about scripting things is something I already mentioned, but didn’t expand on yet. They do it the exact same way, EVERY TIME. This means that you take out the chance for human error, or PEBKAC (Problem Exists Between Keyboard And Chair). Many commands in Linux can be dangerous if used incorrectly, almost any Linux admin will know that a typo while using `dd` can wipe out all of the data on a hard drive. If it is scripted, then you can also script in checks to make sure that doesn’t happen.
Oh, and the lazy part… once it is scripted, you can do the entire task in one (typically short) command and let it run… instead of running command after command after… you get the idea…
That said, there are good scripts, there are bad scripts. Not every script is safe, not every script is formatted well. Part of writing a good script is writing it in a method where someone else can come by later, look at the code in it, and know what it does… making a change if needed. But good scripting is more of a topic for a later post.
If anyone has a topic that they would like me to cover, let me know! Leave it as a comment to this post, or you can catch me on IRC. I am typically on irc.freenode.net with the nick cryptk. I run a bouncer so even if I am not there, I will get the message next time I log in! (Hey, that sounds like a good topic… /me jots that down…)