Howto

It is quite easy to set up a mailing system on your own server, but more often than not the recipients of your mails find them in their spam or junk folder – if at all. The reason is that most mail providers establish procedures to block unsolicited mails we have to deal with nowadays.

When AWStats data shall be taken over from another, e.g. older, profile do the following.

First, ensure that during this procedure no unwanted updates of profiles take place by, say, removing all AWStats update commands from crontab.

There are different methods to get a sandbox environment. Here, we use the  Firejail Security Sandbox, which allows to assign a private sealed scope to a service and all associated processes; this includes resources like network access, process table or filesystem. Therewith, the service only sees its own processes and can only access the part of the filesystem that has been assigned tio it.

The following situation arises (for me the first time after years of usage): AWStats runs by crontab,  but all of a sudden no statistics are generated anymore; an error related to the execution of crontab can be ruled out. A manual call like

/usr/lib/cgi-bin/awstats.pl -config=<config> -update

where <config> stands for the configuration in question,  results in an error message like

Git provides different approaches to solve this task. Here, we use the git-subtree command to create branches from the subtrees to be detached. Then, these branches will be imported from another repository. Sources were the manpage (man git-subtree) and this answer on stackoverflow along with some comments listed there.

Update: The script talked about in the text has been replaced by a new version with simplfied usage. For details see the comment New Version with Simplified Usage.

Unix systems including Linux have a mechanism that automatically can execute programs at a specified time – for instance daily at a certain time of day or weekly or monthly at a given day and here again at a certain time of day. All of this is triggered by a file named crontab which usually resides in the directory /etc (i. e., /etc/crontab) and contains the particular indications.

This howto is a short description for experienced Drupal administrators who want a check list for system updates. Thus, it is assumed that the basic update mechanism including the server directory structure is known. Furthermore, it is assumed that all administrative actions on the website are performed with appropriate permissions.

After updating a KDE3-based Linux system (in my case openSUSE) to a new version based on KDE4, it may happen that the login screen cannot be changed by the login manager of KDE4 (System Settings|System|Login Manager) anymore. Even though the settings taken there are stored correctly at the dedicated location

/usr/share/kde4/config/kdm