Time: 13 minutes – okay, that’s after doing this half a dozen times 😉
Setting up a server, also called provisioning by the gurus, is an exciting first step after purchasing a new VPS or dedicated machine. It’s a time when we can experiment, learn and explore all of the latest offerings by the open-source world. It’s our opportunity to configure the server to our needs without needing to cross our fingers as we make changes, hoping not to disrupt the services currently running on the box.
Depending on the hosting provider you chose, your server will be pre-provisioned to an extent. Some providers will configure a server to your exact specifications, some install the LAMP stack only, while others provide you with nothing but a root password and the ability to SSH in to the machine.
If you are in the last bucket, essentially you have been given keys to a car that has an engine, but no gas pedal, steering wheel or radio. Depending on your point of view, this could been seen as a disadvantage. I encourage you to be more excited about your new skeleton of a server.
Having a server fully provisioned for you is a time-saver, no doubt. But for the most part, you will be getting a server that has a cookie cutter configuration that is not only out of date, but consumes more disk space and memory that you’ll need.
So let’s see what it takes to put some meat on that skeleton. It should be noted that the instructions below are geared towards a CentOs distribution. Although, many apply to all distributions.
Choosing a Server Template
If you’re provisioning a VPS or Cloud instance, you might be given the option to apply a “template” to the server. This template indicates which distribution to install, but also can offer installation of other software, such as the LAMP stack.
I’d encourage you to avoid installing anything except for the bare-bones distribution itself. I’ve struggled to “clean up” after these templates have installed packages far too many times.
Creating a non-root superuser account.
The very first thing you should do is say goodbye to that root login. Don’t ever use it again. It’s not worth ever putting the root password at risk. Okay, but how will I gain admin privileges to the server?
passwd myusername (then choose a password)
Great, you have a new user account. Now let’s give it superpowers:
Locate the line that looks like this:
root ALL=(ALL) ALL
Then, create another similar looking line directly under it:
myusername ALL=(ALL) ALL
What is this program, I can’t type anything! You’re using an age-old tool called vi, it’s not user-friendly at all, but there are die-hard linux fans that would dive in front of a bullet for it (yes, I have tried to physically harm the software program vi from time to time).
Press the i key on your keyboard to allow editing.
When you’re done, press the Esc key, then colon, then the letters w, then q.
Indexing the filesystem search database
While you’re provisioning the server, you’ll probably find yourself using the locate command to find utilities. Depending on your host, they may or may not have setup a cron job to auto-index the search database daily. If not, you’ll need to do this before issuing your first locate command.
Yup, that’s it!
Well, unless you don’t have the mlocate tool installed. Not to worry:
yum install mlocate
Install the Remi Repo for CentOS 7
sudo yum install epel-release wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm rpm -Uvh remi-release-7.rpm Edit /etc/yum.repos.d/remi.repo and set enabled = 1 under the PHP56 repo block.
Installing your web server, development tools and database
Otherwise known as the LAMP stack, Apache, MySQL and PHP (or Python/Perl) are your most common installs for a web server. Being so common, it’s not a real heavy lift to get these installed.
There are a few ways to install packages, the two most common are:
- From source (requires us to compile the source code on our server)
- RPM (software comes packaged and installation is managed by the package)
I typically choose the RPM method as it’s works for my needs 90% of the time. Occasionally, you’ll find yourself compiling from source (it’s easier than it sounds), but I encourage you to stick with RPM until it’s no longer sufficient.
yum is an excellent front-end tool that leverages the RPM packaging system. With yum, you are able to use common names for packages and install them with a single command. Let’s start with Apache.
yum install httpd httpd-devel
yum install mod_ssl
It’s a good ideal to install Apache’s development tools (httpd-devel), as you’ll find them necessary when you add modules such as OpenSSL and others. The same goes for other services such as PHP and MySQL; if a development tools library is available, it usually doesn’t hurt to install it.
You’ll also notice that we’ve install mod_ssl. Might as well while we’re at it.
Now, here’s the kicker. Depending on your version of CentOS, you might be greeted by a server error when you enter your server’s IP address in a web browser. The reason is that the default firewall rules are blocking port 80.
No problem, drop in these commands and you should be good to go:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT iptables -I INPUT -p tcp --dport 443 -j ACCEPT service iptables save
If that doesn’t work, try adding these lines to /etc/sysconfig/iptables:
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
:OUTPUT ACCEPT [3:440]
Then running service iptables save.
Installing Development Tools
At some point, you will need to compile from source, so it makes sense to have the development tools “suite” on your machine:
yum groupinstall "Development Tools"
I like to grab the most recent PHP version. The problem is that most servers, when first provisioned, don’t know about it. They typically use out-of-date repositiories that identify where these RPM packages are on the web. You may need to Google a bit to find a suitable repository for your linux distribution that has more recent packages. I personally use this one:
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum --enablerepo=remi install php php-common php-devel
You may discover that you don’t have the remi repos on your system. In that case, for CentOs 6:
wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm sudo rpm -Uvh remi-release-6*.rpm
yum --enablerepo=remi,remi-test install mysql mysql-server mysql-devel
Update for CentOS 7
CentOs 7 will try to install something called MariaDB, which is apparently a drop-in replacement for MySQL. Avoid this by installing the MySQL Community repo first.
rpm -Uvh http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm yum install mysql mysql-server mysql-devel
Installing PHP Modules
Now that MySQL is installed, let’s install the PHP modules necessary to connect to MySQL. While we’re at it, we should snag as many other useful modules as possible
yum --enablerepo=remi install php-mysql php-pgsql php-pecl-mongo php-sqlite php-pecl-memcache php-pecl-memcached php-gd php-mbstring php-mcrypt php-xml php-pecl-apc php-cli php-pear php-pdo
As I mentioned before, unless you’re a die-hard, you won’t be happy with the vi text editor that comes installed on the server. nano is a step up, something you might more closely equate with Windows Notepad.
yum install nano
Verifying your mail sender
It’s likely that you distribution will include sendmail by default, but it’s possible that it won’t. In some cases, by doing:
It appeared to me that sendmail was actually installed. But when I tried to test it (as shown below), it returned errors. Sendmail wasn’t actually installed.
If this happens, you can easily install it with yum.
yum install sendmail
Then, verify it’s working using this sendmail test snippet.
Fire it up!
Now that you have everything installed, it’s time to start Apache and MySQL.
You can call these programs directly:
/etc/init.d/httpd start /etc/init.d/mysqld start
Or, you can use the service command to start them. service is basically a convenience utility to start, stop or restart any daemon located in the /etc/init.d directory.
service httpd start service mysqld start
Make ’em last forever
Once you start your services, you’re good to go. For now. But what happens when you need to restart your server (or it restarts automatically for some unforeseen reason, like a power outage)?
Thankfully, the chkconfig command has been provided to use to manage our starting lineup. To ensure that both Apache and MySQL start automatically on boot, issue the following two commands:
chkconfig httpd on chkconfig mysqld on
On CentOS 7
systemctl enable httpd systemctl enable mysqld
Uncomment this line:
Then, add any VirtualHost stanzas required, either directly in httpd.conf, or preferably within a separate file. Many use the convention of having a separate file for virtual host directives, called vhosts.conf
After you’re done setting up your virtual hosts, restart apache.
service httpd graceful
By using the graceful argument, you’re telling Apache not restart in the middle of a request. Of course, when first provisioning your server, it’s not likely that you’re getting production requests from your web site. But, it’s a good idea to get in the habit of gracefully restarting your web server.
I’ve found that some of my CentOs servers tend to fall out of sync with time. The NTP service can be used to keep the server’s time in sync against a remote time service.
#install ntp sudo yum install ntp # make sure it's starts up after reboot sudo /sbin/chkconfig ntpd on # start the ntp service now sudo /etc/init.d/ntpd start
"Then, create another similar looking line directly under it:
myusername ALL=(ALL) ALL"
No – this is poor sysadmin. Don't add individual usernames to the sudoers file. Your sudoers file probably already contains a line to grant full root sudo privileges to some group. Use it. It may be commented out by default, in which case enable it.
Red Hat, for example, defines the group "wheel" for this purpose:
# %wheel ALL=(ALL) ALL
Un-comment that line, then
# usermod -a -G wheel myusername
Alternatively, include "-G wheel" on the initial useradd command when creating the account.
Also, a real newbie completely unfamiliar with vi would probably be well served by advice to install nano before editing sudoers.
Good comment Will. I have not yet edited the sudoers file with nano. The sudoers file notes at the top:
So, I've been wary about it.
As to not giving sudo access to individual users, this is the first argument I've heard against it. What are the possible issues that come with adding users to the sudoers file? I would actually think more problems would arise if you granted group access, as you might unknowingly add a user to a group that should not have sudo.