Most log files do not contain personally-identifiable information or other sensitive data. And even if they do, encryption of all personal data is not mandatory under GDPR. Still, on occasion, for testing and troubleshooting purposes you may want to log potentially sensitive information. It would be a very good idea not to let these logs get away from you.

You can certainly run the encryption process separately from log rotation via cron or some such. But this would be an extra step with extra problems. You can actually use logrotate directly to handle encryption. Basically, you will tell logrotate use gpg instead of the usual gzip.

Here’s an example of my /etc/logrotate.d/squid:


Older kernels warning

Kernels with logrotate version prior to 3.8 have an issue with the compressoptions not taking spaces. There’s a simple workaround, though: create a script that contains the command (such us gpg) and all the options and put it in /usr/bin/gpg-logrotate (don’t forget to make it executable, obviously):

However, since log rotation runs via cron you would either need to source root profile (along with GPG keys), or temporarily extract the relevant GPG key ID to be used for encryption. From a security standpoint, the latter is safer. Here’s what your gpg-logrotate script may look like in this case:

And then the logrotate config file from the example above would look like this:

Following log rotation, you should see something like this in the log destination:

Log rotation frequency

By default, log rotation process would run once a day. This is fine if you specified daily or weekly in your config. If you want to run the process hourly, you would need to copy /etc/cron.daily/logrotate into /etc/cron.hourly/ directory. Naturally, in your logrotate config file you would also need to specify hourly with the desired retention period.

And, I guess, a couple of words on how to set up gpg and keys. If you have an existing key, copy the public portion of it to your server and add it to the keyring:

You can then list all the keys on your server:

If you don’t already have a key, you should create a passphrase-protected key. It is also a good idea not to keep the private half of the key on the server.

Generating new key

In the following example we create a new passphrase-protected non-expiring private key.

You see the key you just created:

As I mentioned, you shouldn’t be keeping your private key on the server. Generate the key on a less-exposed machine, extract the public key, and import it on your server. Here’s an example:



Leave A Reply

Please enter your comment!
Please enter your name here