You are here
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
Multiple subtrees of a Git repository shall be extracted and transferred to a new archive while keeping the version history.
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.
Want to upgrade system to new openSUSE distribution without using media like DVD, CD, USB sticks or the like. Instead, just performing an upgrade from the running system.
Events triggered by crontab will not happen, if the PC is off-state at the time specified.
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.
A Drupal system shall be updated within the 6.x series – core, custom modules or both.
Settings taken by the KDE4 login manager have no effect on the login screen.
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