Dedicated Server School

This is the third part of a series on KVM. If you have not already read them, you should begin with part 1 and continue with part 2.

Once you have KVM installed, you should make sure that you have libvirt installed as well. If not, install it now.

# yum install libvirt

Next, restart the libvirt service to get KVM running.

# service libvirtd restart

Now verify that the kvm module is loaded:

$ lsmod | grep kvm

The output will look something like this:

kvm_intel 41253 0

kvm 231774 1 kvm_intel

To give a local user the ability to run a virtual machine, you will need to add the user to the kvm group. For example, to add the user “dss”:

# usermod -a -G kvm dss

If you are logged in as this user, log out to allow the new settings to take effect. When you log back in, you can verify the group inclusion with:

$ id

You will then need to repeat this step for the libvirt group.

Next, verify that your user “dss” can access qemu:

$ virsh -c qemu:///system sysinfo

Finally, change the permissions of the default images directories:

$ sudo chown root:libvirt /var/lib/libvirt/images

$ sudo chmod g+rw /var/lib/libvirt/images

In part 4 of this series, you learn how to setup a virtual machine and use it in your server environment.

Many of today’s dedicated servers run Linux distributions (such as CentOS) or Unix-like operating systems (such as FreeBSD). Therefore, it is very important to be familiar with Unix commands and how to get the most out of them, even if you spend most of your time managing your server from the comfort of a web-based control panel. On some occasions, you will need to log in to your server via SSH and get your hands a little dirty on the command line.

The copy command is a powerful tool that you can use put files exactly where you need them to be. The command for copy is “cp”. The most basic copy command is to copy from one location to another:

cp /home/user/fileone /home/user/backup/fileone

In order to copy multiple files, you can use the “*” wildcard. For example:

cp /home/user/* /home/user/backup

In this example, it will copy the files in the parent directory to the backup directory, but it will not copy the backup directory as well. Instead it will say:

cp: omitting directory: '/home/user/backup'

To copy directories, use the “-r” (recursive) option:

cp -r /home/user/directory1 /home/user/backup

The copy command has many other options that you can use. For a full list of them and complete information regarding their functions, type “man cp” from the command line or visit the manual page online.

In the event that something happens to the software you have installed on your server, you may need to reinstall it. YUM, the package manager for Red Hat Enterprise Linux, Fedora, and CentOS, allows you to reinstall packages whenever necessary.

To reinstall a package with YUM, do the following:

# yum reinstall name-of-package

YUM will prompt you before proceeding

Reinstall 1 Package(s)

Total download size: 147 k

Installed size: 380 k

Is this ok [y/N]: y

Type in “y” and press Enter. YUM will then reinstall your package the way that it was meant to be originally, even if you had previously deleted or altered crucial files.

Assuming all goes well, any of the changes to system files will be overwritten by the reinstallation. It is important to note here, however, that not all files will be overwritten in a reinstall. If you have specific local configuration files, the reinstallation may or may not affect them. If that is what you need to fix, the best course of action may be to remove the offending configuration files from their directories. In most cases, non-local configuration files (such as those in /etc) will not be saved after a “yum remove” command.

Linux dedicated servers have a very easy system for making files hidden. In general this is not an ironclad security measure but can be used to prevent users from accidentally disturbing critical configuration directories or files. You might also use it to trim down directories to make only the files you actually need access to visible.

To make a file hidden in Linux, simply rename it with a “.” in front of the name. For example:

mv filename .filename

It will appear in your directory only if you use the “-a” in the list command:

ls -al

-rw-rw-r– 1 dss dss 0 2012-05-14 13:54 .filename

When users login to your server via FTP, you can tell your server to keep hidden files hidden from FTP users. For example, you can use the IgnoreHidden option in Proftpd, but keep in mind that files like .htaccess will also be hidden.

In pretty much every other way, hidden files and directories in Linux function just as they would if they were not hidden. You can copy, move, delete, and rename them just as you would normal files.

This guide will describe how to install and setup KVM on a Red Hat/CentOS server. The end result will be a system capable of hosting multiple virtual machines, all of which operate on a bridge network, meaning they are equally accessible within the same LAN and would appear to a remote user as though they were each separate machines.

Before you begin, there are a few system requirements that you need to meet to use KVM:

1. Hardware virtualization support on your processor, either Intel-VT or AMD-V. Your server specs should include this information. You may also need to enable it in your bios. All server-quality processors will have it. If you are using a laptop to create a test server, you will need to check.
2. Enough RAM to dedicate portions of it to each guest OS. Remember, you will be running entire instances of servers side-by-side.
3. Enough disk space for each instance of a complete OS.

You can check for hardware virtualization capabilities on your system by running this command:

$ egrep ‘vmx|svm’ /proc/cpuinfo

The output will look like this for each processor/core:

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt xsave avx lahf_lm arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid

I have highlighted the “vmx” to show you the example of my system, which has support for Intel hardware virtualization. If it were an AMD system, you would see “svm” if it had hardware support.

If your system is cleared for launch, you can go ahead and install kvm:

# yum install kvm

In the next part of this guide, we will install some more features and learn how to setup KVM for virtual machines.

Virtualization is one of most important advancements in computing. It allows the user to run one operating system within another, accessing and interacting with the hardware as though it were running natively. Over the past decade, the technology has progressed to the point where you can now run a virtual machine at nearly the same efficiency as the host operating system.

There are a wide variety of virtualization options on the market, from proprietary options like VMware to large open source projects like Xen. Since Linux is one of the most widely adopted server operating systems, all virtualization software supports it and offers ways for users to utilize it as the guest or host OS.

In order to make virtualization more easily accessible and improve performance, the Linux kernel has its own built-in virtualization system called KVM (kernel-based virtual machine). It is free and open source and available in most, if not all Linux distribution software repositories.

Over the next few posts, we will provide a brief setup guide to installing and configuring KVM on a Red Hat Enterprise Linux or CentOS server. To get a basic overview of KVM and learn about its history first, you can visit the project’s website.

One of the oldest methods for transferring files from your computer to your server is called FTP (file transfer protocol). Unfortunately, this method is not secure, and if you need to transfer sensitive data and also protect your username and password, you should use a method that provides better security. SFTP is one option.

Most modern FTP clients can also use secure FTP by logging you into your server using your SSH username and password. In this example, we will use the free and open source FTP client called FileZilla, since it is available for Windows, Mac OS X, and Linux.

You can download FileZilla from the project’s website and then follow these instructions:

1. Click the button on the far left to open the “Site Manager”
2. Click the “New Site” button
3. For “host” enter your domain name (without http) or IP address
4. In the port box, enter your server’s port (if different from the default SSH port 22)
5. For “Protocol”, select “SFTP – SSH File Transfer Protocol”
6. For login type, you can leave it as “Normal” unless you have specific circumstances
7. Type your username and password
8. Click “Connect”

If you have never connected to the server via SSH from that computer, you will be asked if you want to add it to your trusted hosts. Once you have done that, you should be able to connect whenever you need to transfer files.

DNS is one of the most important features of your server. It is what connects your server’s true identity, its IP address, to its human-readable name, also known as its domain name. In order to add domains, sub-domains, or mail server addresses, you need to edit DNS zone entries for your domains. Using a web-based control panel, such as cPanel, you can accomplish this task rather painlessly.

The following are some of the DNS terms you should know before working with DNS zones:

A record – The most fundamental DNS record, an A record, connects the base domain to the server’s IP address.

CNAME – A CNAME record serves as an alias for a domain name. This is useful when you want multiple domains or sub-domains pointing to the same place.

MX – An MX record is for mail servers. You can define the address for multiple mail servers with MX.

NS – These are the authoritative nameservers and are the most important records. The servers specified here actually host your DNS and should be different from your own server.

There are many other DNS records, but the above are the most commonly used. You can view a complete list of DNS records online.

Hosting Automation refers to software that makes web hosting as easy as clicking buttons on a graphical interface. For those who have worked with naked Linux or Unix servers, this is a dramatic contrast from the command line interface to which you may be accustomed. Most hosting automation comes in the form of a web-based control panel.

Control panels usually require a flat fee or subscription license per server, although some, such as Webmin and Virtualmin are free of charge and/or open source. One of the most popular non-free control panels is cPanel and its server administrative interface: WHM (WebHost Manager).

Hosting automation can simplify many tasks. For example, editing DNS zone files can be daunting and risky even for experienced system administrators. Using a control panel, they can edit the files more easily and also rely on the interface to warn them when they make mistakes. Moreover, it is much more convenient for end users who may not want to delve too deeply into the technical aspects web hosting. It is also more visually appealing than the alternative.

Most importantly, hosting automation can save time, particularly for tasks that may require several steps, such as multiple user management or the creation of cron jobs. Control panels can make life easier for system administrators and user alike.

If you are new to dedicated servers, your primary experience with hosting management has probably been from within the comfortable pages of a web-based control panel. Without a doubt, control panels like cPanel/WHM provide system administrators with robust tools to tackle most of the issues they may encounter. Nevertheless, there will still be times when you will need to get a little more intimate with your server. SSH is just the tool for the job.

SSH stands for SecureShell and is a secure method of accessing a Linux or Unix server remotely. When you login to your server via SSH, you are logging into the system shell, a virtual console that is essentially like standing in front of the server with a keyboard and screen. From within SSH, you can control every aspect of your server’s operating system. This makes it both powerful and dangerous.

By default any user with shell login access can also login via SSH. That includes the root administrator user. Therefore, as a safety precaution, you should not login to your server directly as root, and you can even configure the server to deny root login attempts. Instead, you can login as a user with limited privileges and then either use “sudo” or “su” to become root when the need arises.

SSH has a variety of other uses beyond command line access. You can use it to provide secure encrypted transfer of files, for tunneling various other protocols, and for secure backups of your server through rsync. SSH is a versatile and powerful tool, and once you get the hang of it, you will likely use it on a regular basis.

Web applications, as the name plainly states, are applications that run on the web rather than on a person’s personal computer or laptop. This makes them extremely versatile, since any device capable of connecting to the web can use them. The methods for developing and deploying web apps vary, but the end result is essentially the same. The user gets a fully functional application within his or her web browser.

Most modern web applications use a combination of server-side scripting (such as PHP, Perl, or Ruby) with some client-side scripting (such as Javascript). For data storage, they may use some form of database, such as MySQL, PosgreSQL, or SQLite. The server-side scripts are accessed by the user’s web browser and then call on the databases to deliver the relevant information. Finally, the web server (such as Apache) displays the information in HTML or a combination of HTML and Javascript, which can be used to make effects that simulate desktop applications.

There are three primary ways that you can use web apps on your website:

1. Develop and deploy your own web applications. This requires knowledge of how they work and programming skills.
2. Purchase a web app or download a free one. There are hundreds of thousands of free web applications, such as content management systems and image galleries.
3. Use a cloud-based web application. Some cloud hosting providers will provide the tools necessary to integrate their cloud apps into your website, without hosting them on your server.

Unix and Linux servers are much more common than Windows servers, so there is a good chance that you will encounter at least one during your time as a system administrator. Therefore, it is a good idea to be familiar with the peculiarities of the file systems, which differ in many ways from Windows desktops.

Since we are going back to the basics, the most basic unique features of a *nix file system is that it uses forward slashes, just like URLs on the web. In other words, your web documents directory may look like this /home/user/web/docs rather than F:\home\user\web\docs. Moreover, these server file systems do not use drive letters for physical drives or virtual drives. Every attached media will be located under the top-level “/” directory. Mounted drives are commonly found under /mnt or /media.

Another unique feature of Linux and Unix file systems is that files often do not have extensions. You are certainly welcome to give files extensions, but the OS does not require it. For example, the file for the command “grep” is indeed the word “grep” with no extension. On Windows, it would likely be “grep.exe”. For the web, most of your files will still have extensions (i.e. .html, .jpg, and .ogg).

These are a couple of the basic differences between Unix-like file systems and Windows file systems. For a more detailed look at a typical Linux file system structure, see our earlier post on the subject.

When covering application security, there are three basic application types you should consider:

1. Standard applications that you install directly on your server’s operating system and run only when you need them
2. Applications that are run as daemons or services, starting at boot time and continuing to run as long as the server is on
3. Web applications that run with server-side scripting systems such as PHP or Perl, or client-side applications, such as those written in Javascript.

To secure each type, you need to take unique precautions.

For standard applications, the most important thing you can do to secure them is keep them updated. Anytime an update comes out for an application on your server, there is a good chance that there are security fixes in the update. Therefore, updating is the best way to avoid unnecessary security holes.

Daemons also need updates, but since they run on your virtual private server all the time, you should also consider adjusting how they are executed. The most obvious way to start a daemon and keep it running on your server is to run it as the root user, but this is definitely not the most secure method. Instead, you should create a unique user (or users) for running your services.

Web applications should be written well, checked for vulnerabilities, and updated frequently. You should also consider using an application firewall to add another layer of security. We will take a closer look at web applications in part 10 of this “Back to Basics” series.

The security of your operating system can be very complex. It is a large collection of software that has direct access to your hardware. Therefore, it is crucial to maintain an ongoing security policy for protecting your server’s OS.

The following items should be at the top of your server OS security list:

• Kernel updates – The kernel is the core of your OS, and an exploit in it can bring your server to its knees. Keep the kernel updates and secure
• Vulnerability scan – Scan your dedicated server regularly for potential security holes.
• Password strength – It sounds trivial, but weak passwords are often the culprits in security breeches. Make sure your password is strong and enforce strong passwords among your users.
• File system security – Your server’s file system can be an open door for attackers if you do not make it difficult for hackers to gain access to directories such as /tmp.
• File permissions – If a user does not need access to a particular file, it should be off limits. Files should be readable or writable only for the users who need them.

Your operating system is only as secure as you make it, and your server will only be secure when your OS is properly protected.

In order for a network to be secure, you need to have some type of firewall in place. Firewalls typically protect your server from a wide variety of network attacks, all of which focus on weaknesses or holes in your network. For example, an cyber-criminal may scan your server for an open, unused port and then use that port to launch an attack.

The ideal situation for a dedicated server is to have two firewalls in place: one on the router and the other on the server itself. The router firewall will generally block ports that your server does not use and may even protect against some types of specific attacks. The firewall software on your server will take it a step further, providing internal network security and also protecting from specific dangers, such as brute force attacks.

On a Linux dedicated server, there is a built-in firewall for the kernel, and you can use iptables to configure it. If you prefer another type of firewall frontend, APF (Advanced Policy Firewall) is a very popular choice and is much easier to configure.

Choosing your operating system and web server software is only the beginning. If you need a custom dedicated server built to your specifications, you will need to specify several other types of software, including database system, DNS, mail transfer agent (MTA), scripting languages (PHP, Ruby, Perl, etc.), firewall, virtualization, and more.

DNS – The management of your domain name system (DNS) is of the utmost importance if you are connecting your server to the Internet in any way. You need a DNS system that is consistent and secure. For Linux and Unix servers, the de facto standard is Bind (or nameD).

Databases – Database usage varies widely. Before you decide on software, you will need to decide on a type of database. You can choose from relational database management systems (RDMS) or non-relational databases, and then there are countless variations within those two categories. For example, if you choose RDMS, you may prefer a robust database server like MySQL or a simple database library that requires no running service, such as SQLite.

Scripting Languages – Today’s dynamic web applications all use scripting languages. Some may even use multiple languages within the same application. PHP and Perl are among the most popular, but there are plenty of other options. In most cases, you will want to use a server-side scripting language, but there may be some instances where a client-side language, such as Java, is required.

Other Software – For Linux distributions, it may be easier to decide on software, since many of them come with their own set of packages. You can mix and match the ones you like and build your ideal server without spending a lot of money.

As we continue our overview of the very basics of dedicated server hosting, it is appropriate at this time to look at web servers. Dedicated servers have a wide variety of uses, from application hosting to gaming, but web hosting is one of the most prominent. As the entertainment and business worlds become more integrated into the web, we may even see web servers used for applications and gaming.

When it comes to web server software, there is one dominant force that stands alone, far above the rest. That is Apache HTTP Server. It is by far the most widely-used web server software on the Internet. It has been hosting millions of websites for well over a decade and is regarded as generally secure, reliable, and scalable.

Nevertheless, there are other web server options, all of which have their strengths and weaknesses. Among the top web servers after Apache are Microsoft IIS, Nginx, and Lighttpd. There are also many proprietary derivatives of Apache and some smaller web server projects that certain system administrators might find useful.

Your choice of web server may depend on several factors, including:

• The type of web applications and programming languages you use
• Your operating system choice (IIS, for example, runs exclusively on Microsoft Windows servers)
• The volume of daily traffic on your site
• The depth of features and extensibility you require

Various web servers may claim to have advantages over others in terms of speed and security, but much of that is based on your own configurations and application performance.

In the third part of our “Back to the Basics” series, we will look at the operating systems that power today’s servers. Just as there is a diverse amount of hardware available on the server market, so too are there a great number of operating systems. They are not all equal in all aspects of web hosting, and they are certainly not all alike.

Deciding on the best operating system is not simply a matter of preference. You should carefully consider numerous factors, including:

• the type of hardware you will use
• the system requirements for the software you want to install
• the programming languages and databases you will use for your web applications
• your budget limitations for software
• the purpose and goal of your server (i.e. for business, recreation, community, or no-profit)

Once you begin to answer these questions, you can start checking off the operating systems that fit your requirements. For example, if you require a particular software package from a specific vendor, that vendor may only make their software available on Windows. That would limit your options unless you look to virtualization. When it comes to budget, you may prefer a free operating system like CentOS over one that requires licensing, like Red Hat Enterprise Linux, even though the two may be equal in actually performance.

In the second post of our “Back to Basics” series, we will take a look at server networking. Generally speaking, as a system administrator, you will not have to worry about the actual networking infrastructure. If you have an in-house server, your company will likely hire someone to establish connectivity, and if you are renting a remote server, your web host will handle all of that. However, when it comes to meeting Internet standards, managing traffic, and establishing security, you may be the one responsible for making things work.

The following are a few networking concerns you should address as you start a new dedicated server:

1. Name servers – According to Internet standards, your name servers should be hosted on at least two distinct servers in addition to your own. You should have a primary name server (ns1.yourdomain.tld) and at least a secondary name server (ns2.yourdomain.tld) in case the first one is unresponsive.
2. Reverse DNS – Every server has DNS, as it is the only way for your website to be identifiable on the web. Unfortunately, some servers do not have proper reverse DNS, which is required to ensure that the identity of a server is in fact valid.
3. Network firewall – A good network for your server will have a firewall at both the router level and at the operating system level. There is no reason to neglect one or the other. Any attacks that sneak by your first line of defense will be met with the second.

Over the next couple of weeks, Dedicated Server School will post several articles in a series called “Back to the Basics”. Much of this will be a rehash of content we have already published, but it will be provided in a more uniform set of informative posts for those new to dedicated servers.

Part 1: Server Hardware

A server is only as good as its hardware. When shopping around for a server, it is easy to get drawn in by the software, especially if you are looking to lease a remote server. You may never see the hardware in person, but that does not mean you should neglect it or be ignorant of its technical details.

When you shop for hardware, you will want to consider factors like processing power, memory, storage capacity, and backup storage, but that is not the end of it. You should also consider data center security features, cooling technology, environmental responsibility, and network infrastructure.

As we have mentioned before, some hardware can have misleading naming systems. You cannot tell exactly how powerful an Intel processor is just by looking at the name or number of gigahertz. Clock speed is only part of the equation, and it would behoove you to research the benchmark comparisons of each processor you consider. The same is true of storage hardware and RAM.

Does the data center provide backup power? Is the cooling energy efficient? Is the hardware easily swappable in case of failure? Is there any redundancy in place for unforeseen disasters? These are all questions you should ask about your server and its hardware.

Recent reports have indicated that Linux continues to gain a larger share of the server market, while Microsoft Windows and variations of Unix continue to lose significant market shares. Linux has become the dominant server OS type of choice, and for web servers in particular, Linux is almost the default.

Nevertheless, to call Linux a single operating system would be a mistake. Linux is the kernel present in any number of operating systems, from Ubuntu to Android. The variations of the GNU/Linux OS are often called “distributions”, and they perhaps number in the hundreds.

In the past, we have highlighted some of those distributions. But which one is the best for servers? CentOS has become very popular, and it is the OS that cPanel users typically prefer, but they might also use Red Hat Enterprise Linux or even FreeBSD. For package management, some system administrators swear by Debian, believing its APT package management system to be the best thing since sliced bread. Still others love Gentoo for its superior optimization capabilities and easy of customization.

The truth is, much of this depends on preference. All of the major server-based Linux distributions are configured to meet a variety of needs and security concerns. You should study the features, documentation, and performance ratings of each distribution before making your decision. Moreover, make sure all of your hardware is supported, and make sure the OS you choose has all of the applications you want in its repository, or at least supports the apps you want to install.

Protecting your dedicated server from cyber-attacks is always a critical part of system security. You have, after all, invested time and money into protecting your websites and the websites of any clients you might have. Nevertheless, you should not assume that everything is fine with your server simply because it appears to be functioning. It may actually be an unwillingly participant in cyber-attacks.

The recent botnet sting initiated by Microsoft should serve as a reminder that all servers are potential targets for attacks but may also be used as platforms for the attackers. In a botnet attack, the cyber-criminals find vulnerabilities in “agent” servers that allow them to install their botnet software. Those servers may not exhibit the symptoms of being infiltrated, but they will still silently and unknowingly carry out attacks on other servers. Attackers can use this silent exploitation for sending spam, operating phishing schemes,distributing viruses, or even for executing a distributed denial of service (DDoS) attack.

Although you may not be able to easily notice exploits like this on your server, the sometimes subtle effects on performance, bandwidth consumption, and system resources can add up over time, costing you money and reducing the quality of your server. Because of this, it is in your best interest to make sure your server is secure and not easy to exploit. Being reactionary in this case will not prevent cyber-criminals from using your server to attack others, but by being proactive and implementing preventative security measures, you can protect your server and do a public service for the web as a whole.

The Apache configuration file is deceptively simple. It is just a plain text file filled with mostly plain words. It does not require a registry, hex editing, or any other form of complex configuration. Still, with one misstep, one typo, or one incorrectly placed directive, you can bring your web server to its knees.

Rather than run the risk of causing a server-wide outage every time you change a configuration setting in Apache, you can use a little tool called configtest. It is one of the many options available for the “apachectl” command. Using it you can scan your httpd.conf file to make sure it will work properly the next time you restart Apache. If there are any problems, configtest will output the errors for you.

For example, to test your current httpd.conf settings, you would type the following from the command line:

apachectl configtest

If all goes well, it will give you this output:

Syntax OK

When things do not go well, configtest will display an error message like this:

Syntax error on line 33 of /usr/local/apache/conf/httpd.conf:

Invalid command ‘sserversignature’, perhaps misspelled or defined by a module not included in the server configuration

You can then go back to your httpd.conf file and edit the line mentioned in the error message. In this way, you can repeatedly test your configuration until it passes with “Syntax OK”. Then, you will know that it is safe to actually restart Apache and let your configuration changes take effect.

System administrators do not normally concern themselves with web development, and blogs like Dedicated Server School are not normally in the business of discussing web design techniques, but there are some exceptions. The first notable exception occurs when the actions of web developers directly affect the performance of a server. Such is the case with HTML5 storage.

When dynamic websites became the norm for most servers, databases of various kinds became necessary. This added one more component that system administrators were responsible for managing. The new HTML5 specifications call for another storage option, one that may help increase server performance and also limit the amount of data management needed from the sysadmin.

In the past, the primary way to store important information related to a user visiting a website was to use a cookie, a small text file stored on the user’s computer. The only effective alternative would be to use some type of authentication system and store the information on the server side (such as PHP+MySQL). Web storage is a reasonable alternative that is more secure than cookies and much faster than any other previous alternative.

The benefits of web storage are clear. If the data you need to save for a user is not something you need on your server but also not something your user would want stored in a cookie, web storage can fill that void. For more information about the technical details of HTML5 web storage, visit w3schools.

One of the important things you can do with a dedicated server is to check it to ensure it is running smoothly and not experiencing any hidden problems. On Linux and Unix servers, log files can provide vital information about key components of your server. The following log files are ones you should routinely check:

1. Web server /var/log/httpd/ – For Apache web server, there is a directory that contains access logs, error logs, and possibly others. For other web servers, see your software’s documentation for the exact location of the logs.
2. Mail server /var/log/maillog – Normally, the mail log will not give you any vital information, but if you are trying to track down a spammer or someone attempting to execute a brute force attack using your mail server, this log may help.
3. Authentication /var/log/auth.log – When users login or even attempt logins, the authentication log will keep track of it. Your server may also have vital login information in /var/log/secure.
4. Kernel /var/log/kern.log – The kernel is the single most important component of your server, and whenever there are important kernel events, this log will list them. Under normal use, you should not see much activity in this log, but if you have issues with a hard drive or other hardware, this log might reveal important information.
5. MySQL /var/log/mysqld.log – Your databases likely hold the majority of data for your websites. As such, it is important to monitor this log for any unusual events.

In the early days of the web, site traffic was pretty straightforward. If a person accessed a page and/or images, the web server would display the static content and use bandwidth proportionate to the size of the files. As the web evolved, however, dynamic content became more prominent and today, dominates the web. Accessing a site often involves server-side scripting, which requires the web server to do much more than simply loading a page. All of this uses more CPU power and more RAM.

Under average use, a web server may never experience problems, even with rich dynamic content, such as a site with social media elements; however, a site with a high amount of traffic may experience lag. One possible remedy for slow dynamic sites is web server caching. There are benefits and disadvantages to this process.

Pros:

1. Faster load times
2. Less bandwidth usage
3. Less stress on the server

Cons:

1. May require high technical expertise to configure it just right
2. Will not work for content that is constantly being updated

For many system administrators, especially those with the skills to implement a caching system, the pros greatly outweigh the cons. Caching can make your websites run more smoothly for visitors and lessen the burden on your dedicated server.

With the now common use of dynamic web sites, especially content management systems, your web hosting users may want to use .htaccess files to set Apache web server configuration directives. At times, these directives may be necessary for the proper functionality of their CMS or other dynamic web applications.

It is easy to use .htaccess, and many free and open source web apps, such as WordPress, will make use them automatically with no direct intervention required on the part of the user. For more advanced .htaccess features, however, you may want to limit the amount of power users can have over their virtual host web server configuration. Using the “AllowOverride” directive in your Apache configuration file (httpd.conf), you can place limitations on .htaccess files or even disable them completely.

The reason for doing this is simple. While you may have taken great strides to make sure your web server is secure, your web hosting users may not have the same level of security acumen. The results could be disastrous, even if only for their individual websites.

If, for example, your users only need to use .htaccess to override directory indexing for their content management systems, you can use the AllowOverride directive as follows:

AllowOverride Indexes

All other directives placed in an .htaccess file will cause an “Internal Server Error” on the site that uses them.

For more information about Apache’s AllowOverride directive and .htaccess files, see the online Apache documentation.

When you are logged in via SSH, the easiest way to read documentation of commands on a Linux server is to use the “man” command. When you are managing your server from a control panel, however, why should you be restricted from seeing critical documentation? Webmin has a built-in tool that allows you to read man pages and more.

To read server documentation, click the “System” menu item and then click “System Documentation”. The documentation module allows you to search any or all of the following sources:

• Manual pages – using the “man” command
• Webmin help – control panel help
• Package documentation – documentation for programs
• Perl module documentation – server-side Perl module docs
• Google search engine – A relevant search of the web

To use the tool, simply type in the keyword you want to search. If you know the exact command, package, or topic, you can just type that. You can also choose to match all keywords, any of them, those matching names only, or those matching the name and contents of documentation.

The system documentation module allows for customization. You can change the path to your man pages, change the way documents are displayed, and add directories for additional documentation specific to your server.