Here we go again… phpAdsNew is a great software, but anyone using it will know that we need to be very careful to patch it quickly to avoid to have our system exploited by many of the bugs that are constantly discovered (this is not only true for phpAdsNew, but most of the popular php scripts have this problem…). Anyway, yesterday (20061024) there was new bugfix version released, 2.0.8-pr1, and anyone logging in the phpAdsNew admin interface was warned to perform the upgrade as soon as possible.

Read the rest of this entry »

After covering the basics of Yum in my first article, let’s move on to the second part. In this article I’d like to cover some things about keeping your system up to date with Yum on a CentOS 4 system. But these information will also apply with little changes to any other system using Yum like Fedora Core for example.

Let’s begin with a scheduled update of your system: To activate an automatic nightly update, just enter these lines as root:
chkconfig yum on
service yum start


Yum will now check every night for new software versions in your configured Yum repositories and install them. If you didn’t configure any special repositories, at least the normal CentOS update repository is used, so you won’t miss any critical security updates.

But if you configured any 3rd party repositories (like many people do) you should keep the following things in mind: If you add more and more repositories to your Yum configuration, there is a high chance that important system files that were installed from official CentOS repositories (like base and update) are replaced by versions originating from your added 3rd party repositories.
Read the rest of this entry »

There are many situations when you will need regular users to have more privileges than the normal user account they have. What situations? This will depend very much on a case by case basis but believe me there will be such cases… For example if a regular user needs to run a program that will change some some protected folder or file, or just a special root command (like shutdown for example).
What can be done in such situations? Well this depends: if you can go around it by assigning proper file/folder permission then this is great. But if not:

• you can give them the root password and place them in the group allowed to ’su’ and you are done. I never liked this option as it will allow them to do anything on the system, and this is not what we were trying to achieve.

• you can use a program like sudo, to fine tune the proper commands that you will allow the user to run. This is more likely what I would do in this situation…

So the magical solution to this problem is sudo (superuser do), a program that allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user. And all the commands will be logged for your reference.

The installation, in case you don’t already have sudo on the system, is very simple, but in case you want it you can check out some simple details about installing sudo on Debian, or Rhel, Fedora, Centos, and some details about the configuration files location and default state.
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.