on the shell

First of all I'm happy we are using monit and monit is having an eye on the rsyslog daemon. This is how I even realised that rsyslog isn't running and refusing to start or at least I could see that monit tried to restart rsyslogd multiple times a day.

After some digging into the issue I could see that rsyslogd refused to start. I tried some obvious things like stopping the service, deleting it's pid file but the service did not start. A reboot did not solve the issue, as well. Manually starting /usr/sbin/rsyslogd just exited with this output:

rsyslog startup failure: error reading "fork pipe": No such process

Looking into the log files wasn't really helpful for obvious reasons, there was no log daemon running...
All I had so far were entries like the following in the kernel ring buffer (output from dmesg):

traps: rs:action 0 que[31409] trap stack segment ip:5650eb6fb31c sp:7fcbda075b30 error:0 in rsyslogd[5650eb6d5000+92000]

Google did not help me. All I found were some different issues like rsyslogd crashing after running for hours and bugs with some modules. But I didn't change anything on the system and my behaviour was quiet different.

A few days ago I faced a problem with finding a proper way of doing backups. While it is a bad idea to use root especially for remote logins, it is the easiest way to be sure you can read all files you would like to be backed up.

In general I do backups using ccollect, which uses rsync to transfer files. All the backup logic (configuration, schedule) is located at the backup server (including ssh-keys to allow ssh access to the "client"). Also the access is initiated by the backup server. Therefore the backup server needs most security.

While it may be good enough to restrict root access to the IP address of the backup server by using openssh's Match support and further restricting logins to key-file authentication, some may want to not use root remote logins at all. Here is a way to achieve this...

Today I read about dangerous commands while on CLI. That's why I'd like to write about how to avoid some mistakes:

When using rm, use -rf only if you have to. If you only intend to delete some files, just use rm. If you have to delete whole folders, use ls before running rm -rf to see what would be deleted. Especially if you need to use some wildcards/globs. This will safe you from mistakes like the following:

OK, today I saw something interesting.

Drazenko Djuricic posted something about lynis and vulnerability scanning and in his command line I found it. My first thought was, why not use a pipe here, but then I realized it.

And here it is:
./lynis --check-all -Q | tee >( aha > /tmp/lynis-report.html)

The interesting part is starting at the tee. Normally tee is used to see the output while writing to a file, in the same time. In this case, tee is used to see the output, while used as STDIN for another command, also.

I'm still thinking about the possibilities. Here some stuff that came into my mind:

Today I learnt something new, which motivated me to create this blog.

While using the find command with the option -exec command {} \;, the used command gets called by -exec for every found file/directory. If there are many hits, this will take some time and increase the load of your system.

Instead of using \; to end the -exec command line, as most of us are used to, you can use a +

You can test the behavior by using this command line:

find ./ -type f -exec echo '{}' +

and compare it to this:

find ./ -type f -exec echo '{}' \;