The Apache access.log file is a good place to look for evidence of hacking activity. Code injections, brute force attacks and excessive crawling all show up in there, along with legitimate hits. While searching recently, I was surprised to see that Linux had started to regard the file as binary data:
$ grep something access.logContinue reading
Binary file access.log matches
The Linux firewall is a great way to secure a server, especially one that is Internet facing. Together with ipset and an appropriate blacklist, it can protect your server from the worst the Internet can throw at it. However, netfilter (aka iptables), can generate a lot of messages. By default they go to the kernel logging channel, flooding out log files such as messages, syslog and kern.log.
It is important to keep log files clear so that system issues are not missed. For example, a hardware or memory error message might be written to kern.log, but could be difficult to notice due to many thousands of firewall messages. Worse, over time, the important message will be moved into a historical log files due to the action of logrotate.
This article explains how to send firewall messages to their own log file, using the example of a Raspberry Pi running Raspbian 9 (Debian Stretch). After a small configuration change, netfilter messages go to their own file instead of clogging up the general logs.
Continue readingDebian 8 (jessie) was released in April 2015, ten months ago at the time of writing. Some sites will have upgraded by now, and others might be considering the move. This article provides a list of issues encountered after upgrading several servers from Debian 7 (wheezy) to Debian 8. These are system administration issues in the most part, though some might also be of interest to application support staff. Continue reading
Backups on a LAMP server were much smaller than expected, and the cause was excessively large log files. This post explains the apparent paradox and the steps taken to trace and fix the problem.
The server in question runs the usual set of grandfather-father-son backups. Before each backup, the software prints the expected size of the backup into a log file. On other servers the estimate is usually bang-on. On this server, the backup turned out to be about 12 times smaller than the estimate. Not a problem in itself, but puzzling and indicative of something untoward on the system. Continue reading