Unverified backups are useless, every sysadmins know that. But manually verifying a backup means wasting time and resources. Moreover it’s boring. You should automatize it!

Charlie Chaplin Modern Times

Backup Checker is a command line software developed in Python 3.4 on GitHub (stars appreciated :) ) allowing users to verify the integrity of archives (tar, gz, bz2, lzma, zip, tree of files) and the state of the files inside an archive in order to find corruptions or intentional of accidental changes of states or removal of files inside an archive.

Backup Checker on github

The new feature of the latest version 1.4 is the control of outdated archives with the new outdated parameter. Lots of data are outdated quite fast, because they are dependent of other data, or because they are only useful in a specific context.

Hey, this database dump is 6 months old, it’s useless today!

Backup Checker now controls the expiration duration and triggers a warning if the given duration starting from the last modification of the archive (mtime) is expired. Short examples of the warning:

WARNING:root:/backups/backups-12022015.tar.gz is outdated. Was good until 01/03/15 00:00:00 – now 22/03/15 21:38:20

You won’t be surprized any more by outdated useless data in your backups.

Installing Backup Checker

It’s also available for your Debian Squeeze or Debian Wheezy. Check how to get it for your specific distributions.

What about you? How and what for do you use Backup Checker? We would be happy to get your feedbacks. The project cares about our users and the outdated feature was a awesome idea in a feature request by one of the Backup Checker user, thanks Laurent!

As a good sysadmin, you thought you had backups for your server but you didn’t verify them before the major migration you attempted? When you need them, they’re empty or full of useless files. And now it’s too late…

Wen you discover that you don’t have usable backups – lesjoiesdusysadmin.fr

You won’t guess how often this situation occurs.

Backup Checker is a command line software developed in Python 3.4 on GitHub (stars appreciated :) ) allowing users to verify the integrity of archives (tar, gz, bz2, lzma, zip, tree of files) and the state of the files inside an archive in order to find corruptions or intentional of accidental changes of states or removal of files inside an archive.

Install Backup Checker from PyPI

The easiest way to install Backup Checker is from PyPi using the following command:

$ pip3.4 install backupchecker

Debian Wheezy and Squeeze packages for Backup Checker

Backup Checker Debian packages are now available for your stable servers Wheezy and Squeeze in the MyTux Debian repositories.

Debian Squeeze

Just copy/paste the following command on your server to add the MyTux Debian Squeeze repository and install Backup Checker:

Using Backup Checker

2 steps are needed to secure your backups. First you need to generate the configuration files of your backups, using the following command:

$ backupchecker -G /backups/backup-08032015.tar.gz

This generates 2 files /backups/backup-08032015.conf and /backups/backup-08032015.list you need to store in order to verify this archive later (the -O option lets you define a custom location to store the files).

Then check if warnings have been sent to /var/log/backupchecker.log. Really simple isn’t it? Scripting this command, your backups are now verified and secured. If any modification occurs, it will be detected and pinpointed.

Backup Checker is a command line software developed in Python 3.4, allowing users to verify the integrity of archives (tar,gz,bz2,lzma,zip,tree of files) and the state of the files inside an archive in order to find corruptions or intentional of accidental changes of states or removal of files inside an archive.

The major feature of this new version is the ability of Backup Checker to use Unix streams. Using classic Unix tools like OpenSSH or wget, Backup Check is able to verify a remote tar.{gz,bz2,xz} archive. The following example verifies a tar.gz archive located on remote server through SSH:

$ ssh -q server "cat /tmp/backup.tar.gz" | ./backupchecker.py -c . -

Another short example with the FTP protocol, to verify a tar.bz2 archive located on a remote server through FTP:

Moreover in this release, a new option –configuration-name allows the user to define a custome name for the files generated by Backup Checker (default is defined from the name of the archive using the -g or -G options).

It is a major step for Backup Checker. It is indeed easier and easier to use Backup Checker in your own scripts, allowing to fully automate your backup controls.

Several companies now use Backup Checker to secure their backups. Let us know if we can help you.

This is a feedback about installing a self hosted instance of Friendica on a Debian server (Jessie). If you’re not interested in why I use Friendica, just go to « Prerequisite for Friendica » section below.

Frustration about social networks

Being a huge user of short messages, I was quite frustated to spend so much time on my Twitter account. To be quite honest, there is no much I like about this social network, except the huge population of people being potentially interested in what I write.

I also have been using Identi.ca (now powered by Pump.io) for a while. But I tried for a while to manage both networks Pump.io and Twitter by hand and it was quite painful. And something was telling me another social network was going to appear from nowhere one of these days and I’ll be just horrible to try to keep it up this way.

Friendica is a content manager you can plug on almost anything: social networks (Facebook, Twitter, Pump.io, Diaspora*,…), but also WordPress, XMPP, emails… I’m in fact just discovering the power of this tool but to plug it on my different social network accounts was quite a good use case for me. And I guess if you’re still reading, for you too.

I tried to use some shared public servers but I was not quite happy with the result, one connector was still missing or public servers were really unstable. So I’m at last self hosting my Friendica. Here is how.

My server hosts several services, so I use a subdomain friendica.mydomain.com. If you use a subdomain, of course check you do have declared this subdomain in your DNS zone.

I use SSL encryption with a wildcard certificate for all my subdomains. My Friendica data are stored in /var/www/friendica. Here is my virtual host configuration for Friendica stored in the file /etc/apache2/sites-available/friendicassl.conf :

Ok, I guess we’re all set, lets launch the installation process! Using your web browser, connect to friendica.mydomain.com. First step you’ll see the installation window which checks the prerequisite before installing. Complete if something is missing.

First window of the Friendica installation process

Second step asks the host/user/password of the database, complete and the installation process starts. Hopefully all goes just fine.

Next you’ll have to create a /var/www/friendica/.htconfig.php with the content that the last page of the installation process provides. Just copy/paste, check the rights of this file and now you can connect again to see the register page of friendica at the url https://friendlica.mydomain.com/register . Pretty cool!

Register a user

That’s a fairly easy step. You just need to check before that your server is able to send emails, because the password is going to be sent to you by email. If it is ok, you should now identify on the welcome page of friendica and access your account. That’s a huge step to broadcast your short messages everywhere, but we have some last steps before being able to send your short messages on all the social networks we need.

A small break, create an app for twitter on apps.twitter.com

To send your short messages to Twitter, you need to create an app on apps.twitter.com. Just check you’re logged in Twitter and connect to apps.twitter.com. Create an app called with a unique name (apparently), then go to the Keys and Access tokens page, note the consumer key and the consumer secret. You’ll later need the name of the app, the consumer key and the consumer secret.

Install and configure the addons

Friendica uses an addon system in order to plug on the different third-parties it needs. We are going to configure Twitter, Pump.io and the Diaspora* plug. Let’s go back to our server and launches some commands:

Connect again to Friendica. Go to settings => social networks, you will see the options for Twitter, Pump.io and Diaspora*. Complete the requested information for each of them. Important options you should not forget to check are:

Pump.io

Enable pump.io Post Plugin

Post to pump.io by default

Should posts be public?

Twitter

Authorize publication on Twitter

Post to Twitter by default

Diaspora*

Post to Diaspora by default

Done? Now it’s time to send your first broadcasted short message. Yay!

Send a short message to your different social networks

Connect to Friendica, click on the network page, write your short message in the « Share » box. Click on the lock , you’ll see the following setup:

It means your short messages will be broadcasted to the three networks. Or more, it’s up to you! That’s my setup, feel free to modify. Now close the lock window and send your message. For me it takes some time to appear on Twitter and Diaspora* and it immediatly appears on Identi.ca.

Last words

Friendica offers to take back the control of your data, by broadcasting content on different media from a single source. While self hosting, you keep your data whatever happends and are not subject to companies losing your data like recently Twitpic. Moreover the philosophy behind Friendica pushed me to dig and test the solution

What about you? How do you proceed to broadcast your short messages? Does Friendica offer a good solution in your opinion? Are you interested in the philosophy behind this project? Feel free to share your thoughs in the comments.

One of my resolutions for 2014 is to keep trying harder to talk about my Debian contributions. So here it is, on a monthly basis this time I hope, quite short this month because I’m leaving for holidays at the end of the week and I think I won’t have time to contribute more this month.

Pycallgraph is one of the first Debian packages I have been maintaining. So when I noticed it was upgraded after so much time I was really eager to package the new version 1.0.1. Now available in Debian Sid! Just belown an example of the generated graph for the application Belier, a sysadmin tool.

3. Belier, the SSH connection generation tool

Nothing really new for Belier, the SSH connection generation tool but I updated the package in order to update the configuration of the Debian package and get rid of some warning messages. Kind of maintenance job I kept avoiding and avoiding, until now.

Bug report

I’d like to take a few seconds to talk about an interesting bug report about the need for a nagios3-dev package I created asking for a new nagios3-dev or nagios3-headers package to offer a simple access to the headers of Nagios for the developers of Nagios external modules.

In Nagios, some headers are generated after the ./configure, meaning it may be platform dependent. I (and not only me, the same request was active already by someone other Nagios module developers) thought it was simple to ask the Nagios3 Debian package maintainer to offer these files in a dedicated package.

It seems until now people just add the missing files in tarball of their app or in their Debian packages, even if these Nagios headers are not really part of this application. In my opinion, that’s why Build-Depends packages are for, don’t you think?

It seems it is not so simple. I could not understand why it was more important to prevent Debian users who need these files to access these files in a convenient way than letting them to put theses files in there own source tarball/repository. The maintainer told me it could break things. Sure. But we all know an external module of any app often relies on a really specific version of this app. That’s nothing new, thats how external modules work. That’s not every apps in the world which could provide a stable API to ease the development of external modules. But at least they give access to their dev files or headers when they are FOSS. But feel free to explain to me. After all, the bug reports are still not tagged as « won’t fix » ;)

Your turn now :) I’d be delighted to have your opinions in the comments of this blog post.