logrotate is the default application used to rotate all other log files not handled by syslog itself (details on rotating system log files can be found in part 1 of the article). It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large. Read the rest of this entry »

Syslog is the default logging application installed in most Linux distributions. It can be replaced with syslog-ng for better functionality, but about this in a future article. As I explained in the introduction, the log files that are managed by syslog are not rotated with logrotate, but by syslog itself. In the second part I will cover the log files that are handled by logrotate.

Read the rest of this entry »

Logs… Any Linux system will generate many log files by default, containing various information about the operation of the system (normal actions, debugging information, security/authorization messages, web/email events, etc). If no rotation would occur on the various log files, then they will just grow bigger and bigger, filling up the space (on high traffic sites) but most importantly making it very difficult to find any information that we might be looking for in those log files. Fortunately this is handled in most Linux distributions by default and we don’t have anything special to do to set it up… if will function out of the box, rotating the log files by default.

This little how-to will show you how the default log rotation works, based on syslog and logrotate. There are other ways to achieve this, like using syslog-ng instead of syslog that I will cover in a future article.
Understanding how the default setup works, will help you have an idea of what will happen and what logs will be rotated, when will this occur, and how long will they be kept. Also it will show you the places where you can make changes in case you need to do that (if you want to save some log for a longer time, or if you want to rotate it differently from the default). The examples I will present are taken from a Debian system, so if you are running a different system, they might differ a little, but not drastically (like you might have the cron setup to run at a different time, or keep a different number of log iterations by default).

Read the rest of this entry »

I am sure that by now all the world has already found out and tested the cool new tool google launched yesterday: google trends… It is a very nice tool that allows you to see the searches done by peoples, on any keyword you are interested, have evolved over time. This doesn’t show ‘exact’ results, but instead is shows a nice graph with a visual representation of the ‘trend’. Another cool feature is that you get also some details about spikes on searches (on the right), and information about the locations of the peoples doing the searches (on the bottom of the page). You can also restrict the trend search by region or only some year or month in time. Very cool.

Still what I have liked most is the possibility to compare the trend of searches between 2 or more keywords. Let’s look for example on a comparison of the searches performed by peoples containing some linux distribution names. This doesn’t result in how many peoples are actually using linux, or those distributions, but the interest of the general public in those names. Here is a real example:

debian redhat fedora centos

What does this show us? That redhat is going down… (not a surprise after the release of their rhel/fedora projects). Debian is strong and many peoples are still interested into it. Fedora took the interest over redhat (rhel as search term is negligible). Centos? Peoples don’t know to much about this cool project.

Read the rest of this entry »

One of the first rules in security is to keep your servers always updated to the latest security patches. Debian provides a wonderful and very easy mechanism to do this. There have been many questions if it is best to update automatically or manually.
Here are my 2 cents on this issue:

In case you are using (as me) the testing branch of debian on live servers:

• if you are managing a single server then you are probably best to update automatically. Why? Because even if there is a problem with an update you will not have the chance to see this on another running server and fix this (either ignore the update, or fix the problem it is causing).

• if you are managing more servers (maybe similar ones) than it might be a good idea to do this manually. Why? well because if there is a problem with some update then you can save yourself valuable time to not solve the issue introduced by the update on many servers.

In case you are using the stable branch of debian:

• in this case I am all behind automatic updates. The stable branch is very reliable and you should not see any problems caused by the updates.

Depending on how many systems are under management this might be true or not (if there are hundreds of servers, then maybe my above ideas are no longer true). But for someone managing a few servers (as myself) that should be a good option.

Today I will present you the manual approach and leave the automatic approach for a future article.

All you have to do is:
- sync the lists of new/upgradeable packages

aptitude update

- perform the actual update/s:

aptitude upgrade

You can get the same result using apt-get instead of aptitude. Depends on which tool you prefer (though they are very similar).

This will automatically download any updates available and check the dependencies (if needed suggest to get additional packages, etc). If there are any configuration files changed it will ask for an action if to keep your old modified version or install the package default one (this will be done automatically in case you have not changed the configuration file).

In future articles I will show how to tweak various aspects of this very important task: to keep your systems up-to-date.

Well this is the first tool I would install on any new server. What is MC? It is a text-mode full-screen file manager. It uses a two panel interface and a subshell for command execution. It includes an internal editor with syntax highlighting and an internal viewer with support for binary files. Also included is Virtual Filesystem (VFS), that allows files on remote systems (e.g. FTP, SSH, SMB servers) and files inside archives to be manipulated like real files.

Even if I consider that MC should be installed by default on any system, for some reason, not all the distributions install it by default. In fact some don’t provide a package for it at all… Here I will show you how easy it can be installed.

Debian
As any debian package this is very easy to install. Just use:

aptitude install mc

and you are all set.

RHEL4/Centos4
We can install MC with up2date as long as it is available in the packages (as it is for rhel4, cetos4):

up2date mc

Fedora
If you don’t have up2date, we can use yum to retrieve the package:

yum install mc

Others
You can always install it from sources on any linux distribution. Still I would prefer to have it in the package system that will provide the advantage of automatically updates. Anyway if anyone is interested on details on how this can be done, just let me know.

On some older distributions like RHEL3 for example the MC package is missing.
Update 20060605: In case you are looking on how to install MC on RHEL3, please see this post: “Install Mc (Midnight Commander) on RHEL3/Centos3″.