Image by pdweinstein via Flickr
It seems quite a bit of my time has
been taken up with system administration related tasks these days. If
I’m not contemplating system monitoring solutions for one client, I must be busy migrating a mail service from one server location
to another.
Naturally, I was hardly surprised when
I got an email from an old high school friend recently asking for
assistance in setting up a Linux, Apache, MySQL and PHP (LAMP) server
on Red Hat Enterprise Linux (RHEL).
Now said friend is hardly a technical
novice and Google is happy to provide one with plenty of step-by-step
how to’s on the subject. So instead of running down the usual I
figured, since he understands the technical side, but is probably
more at home with Microsoft-based solutions, that I would give him
some tips to orient himself.
Thus here is a quick and dirty “what’s
happening” (instead of the more common how to) on installing LAMP
on a RHEL based system.
Since most, if not all, of these
commands deal with system-wide alterations first and foremost one
will need to have “superuser” access. That can be
accomplished in one of two ways:
root user: root is the
conventional name of the user who has rights to all files and
programs on a Unix-based system such as Red Hat Enterprise Linux.
In other words root is the main administrator for the
system and can do anything at anytime.
sudo: sudo is a
command that allows users to run programs with the security
privileges of another user (normally the superuser, root). sudo
usage needs to be granted to a user before it can be used and can be
limited to a subset of privileges if needed.
There are plenty of commands that one
can execute at the command line. Just remembering them all can be
hard, let alone remembering how exactly each command works, in what
context and with what arguments. For that alone one should always
remember that help is always one command away:
man: man is a
command (and format) for displaying the on-line manual pages. The
man command followed by the name of the command who’s documentation
you wish to view will provide an display of that documentation.
For example to view the
manual pages in regards to the man command itself:
$ man man
A key characteristic of Unix-centric
systems is the use of plain text for data storage. This means that
the focus of data manipulation is based on the fundamentals of text
processing. It also means that data can be “piped” from one
command-line tool to another for performing a task that might be more
complicated for just one tool to complete.
While text processing isn’t necessary
for setting up a LAMP server what is necessary to know and have ready to use is at least one general, text-based tool; a text
editor.
vi: vi, vim, emacs or pico each
is a command line text editor and while I try to be agnostic in the
eternal debate about which is better, I will mention that for as
long as I’ve been a Unix user/admin (some 15 years now) no matter
what system I am on, be it a Red Hat distribution of Linux or a
proprietary system chances are vi
or vim has been
installed and is available.1
Red Hat Enterprise Linux uses a
software package format called rpm. Each software package
consists of an archive of files along with information about the
package like its version and a description of the software within.
As a general practice packages are
broken up into two separate packages; One contains the compiled
executable, while a second one contains the source files for building
the software from scratch2.
The source code packages will usual have a “-devel”
appended to their name field.3
However, back in the early days of rpm
it was discovered that managing individual rpm packages is a
pain and time consuming4.
As such, a number of rpm-based Linux distributions have adopted tools
such as yum. yum assists in managing the identification of
dependencies for a given software package as well as installing said
packages, tracking updates for a given package from a specified
repository and removing installed software from the system as
desired.
Identification
Using yum with
the list argument will provide information about a
given package’s availability. For example to check on the Apache Web
Server, which is officially known as the Apache HTTP Server:
$ yum list httpd Loaded plugins: fastestmirror Installed Packages httpd.i386 2.2.3-31.el5.centos.2 installed Available Packages httpd.i386 2.2.3-31.el5.centos.4 updates
As you can see httpd is not only
available, but is also already installed5.
Installing
If, however, the Apache HTTP Server
wasn’t the install argument for yum would
do the trick.
$ yum install httpd Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: mirror.cisp.com * base: yum.singlehop.com * extras: mirror.sanctuaryhost.com * updates: mirrors.liquidweb.com Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package httpd.i386 0:2.2.3-31.el5.centos.4 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================== Package Arch Version Repository Size ================================================================== Installing: httpd i386 2.2.3-31.el5.centos.4 updates 1.2 M Transaction Summary ================================================================== Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 1.2 M Is this ok [y/N]:
Now it so happens that installing of
Apache HTTP Server on the example system at the given time, didn’t
require any additional software packages to for the installation.
This might not always be the case and as such, yum will
identify and list any packages it determines are missing from the
system to be installed at the same time, for the Apache Software
Foundation’s web server to be useful.
Updating
One of the key advantages of a package
management system such as yum in the ability to easily track
updates. The update feature can be used in two distinct
manners. If used without explicitly naming a given packages,
update will check for and then update every currently installed
package that has a newer package available from the repository.
If, on the other hand, one or more
packages are specified, yum will only update the listed
package. As with installing the initial package, while updating,
yum will ensure that all dependencies are installed.
Removing
Of course if yum
can install and update software, it only makes sense that it can also
remove the installed software from a given system. The remove
argument is used to remove a
specified package from the system as well as removing any
packages which depend on the package being removed.
Note that this
is basically the exact opposite of the install option. Install will
add any software the package requires to run and the requested
software itself. Remove, however, removes the requested software and
any software that depends on it.
Once each component is installed, it’s
time to go about configuring each one. The general convention for
Unix-based systems such as Red Hat’s Enterprise Linux is to place
system-wide configuration files in the /etc directory. If fact, while
the specifics can vary, the directory structure from Unix system to
Unix system will general follow the same over all pattern.
Again staying with our web server
example, the main Apache HTTP Server configuration file can be found
at /etc/httpd/conf/httpd.conf on a Red Hat Enterprise Linux system.
To open the configuration file for review and possible modification
using the vi text editor is as simple as:
$ vi /etc/httpd/conf/httpd.conf
Another common directory convention
is /var for variable files. Here are files whose content is expected
to continually change during normal operation of the system. This is
of note in regards to Apache and MySQL since /var is where database
(/var/db) or website file hierarchies reside (/var/www).
Last, but not least is starting these
various services. For that there is the service command which
runs a standardized script created for controlling the operation of
the software in question. Thus to start the httpd web service the
command would be”
$ service httpd start Starting httpd: [ OK ]
Of course starting a service manually
and having it automatically start when the system boots are two
different realities. The chkconfig command provides a simple
command-line tool for denoting if a service is to start at boot time
or not. To turn on the Apache httpd service at boot:
$ chkconfig --add httpd $ chkconfig httpd on
As noted in its man page, chkconfig
has five distinct functions: adding new services for management,
removing services from management, listing the current startup
information for services, changing the startup information for
services, and checking the startup state of a particular service.
Thus if service is akin to rpm
form manually controlling a specific service via its control script,
than chkconfig is akin
to yum for managing a
group of services, controlling the when and how of availability.
The
–add argument for chkconfig
adds a new service for management. Equally, the –del will remove a service from management and the –list will list all of the
services which chkconfig
knows about or, if a name is specified, information only about the
named service.
One of
the key concepts in regards to services, such as a web or database
service on a Unix-centric system, is the concept of a runlevel. In
standard practice, runlevel relates to the state the system is in and
what is enabled for execution. Runlevel zero, for example, halts all
execution of any running service, an denotes a halted, off, system.
Runlevels 1 to 5 differ in terms of
which drives are mounted and which services, such as a web server
are started. Default runlevels are typically 3, 4, or 5. Lower run
levels (1) are useful for maintenance or emergency repairs, since they
usually don’t offer any network services and can help in eliminating
sources of trouble.
This is important to note since in
managing a service, chkconfig
needs to know at which runlevels a service should run. Moreover, it
is important to note what runlevels other depended services are
enabled for. That is, if runlevel 1, which is single-user state akin to a “safe mode” is configured to not run any networking
service, it makes little sense to enable the Apache HTTP server to
execute at this runlevel.
Just
as other how-tos are entry points into getting going, this little
what’s happening is a quick “step beyond” the how to’s last step,
moving one towards understand what is going on “behind the scenes.”
Hopefully this next step provides a helpful point of moving into a
greater understanding and into the grand world of system
administration.
To
that end here is a quick list of books on subject of system
administration for Unix systems such as Red Hat Enterprise Linux:
1 More
on using vi:
http://heather.cs.ucdavis.edu/~matloff/UnixAndC/Editors/ViIntro.html
2 Remember
one of the major tenets at the heart of GNU/Linux is the ability to
have access to view and modify the source materials.
3 More
about the rpm naming convention can be found here:
http://en.wikipedia.org/wiki/RPM_Package_Manager#Package_label
4 Often
refereed to as RPM Hell
5 A
trained eye will note that this command was actually executed on a
CentOS system. CentOS, as noted on their site, is a “CentOS is an
Enterprise-class Linux Distribution derived from sources freely
provided to the public by a prominent North American Enterprise
Linux vendor.” Can you guess which one?
Thanks for providing all the essential steps for successfully setting up LAMP with a Red Hat server. Plenty of practical information.