Use the Raspberry Pi as a Syslog server using rsyslog

I recently discovered that my home router, a Netgear DG834G, is able to forward its log messages to a given syslog server. So, I thought: why not use my new shiny Raspberry Pi as a syslog server? The following post explains how to do it, using the rsyslog daemon.

Why rsyslogd instead if syslogd-ng?

For some reasons, all the guides I found on google explain how to setup a syslog-ng server on the Pi. I think that the proper question should be: why syslogd-ng instead of rsyslogd? The latter is already installed on Raspbian! See this answer for other reasons why you may want to prefer rsyslogd.

Prerequisites

This post assumes that your Pi is running Raspbian and that your router is able to run the Syslog protocol.

Step 1: enable port 514 on the Pi

Since the rsyslog daemon is already installed and running, you can just tell it to listen for syslog connections on the default port 514.
This is as simple as uncommenting the following lines from /etc/rsyslog.conf :

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514

Now your Pi will listen on port 514 for incoming syslog connections, using both the UDP and TCP protocols (some routers might only support one of the two).

Step 2: create your log file

You have to save somewhere on the Pi disk the logs that you are going to receive. You are supposed to save them in the /var/log directory, so just create a new file there, for instance:

$ sudo touch /var/log/netgear.log

Step 3: configurate your logs

Now you have to tell rsyslogd to use the file you just created. You can do it by creating a new configuration file in the /etc/rsyslog.d/ directory. Call this file as you wish and put in it the following content (credits to this blog post):

$template NetworkLog, "/var/log/netgear.log"
:fromhost-ip, isequal, "192.168.0.1" -?NetworkLog
& ~

Just make sure to replace 192.168.0.1 with the IP of your router and netgear.log with the log file that you created in the previous step.

Step 4: restart rsyslog

You are almost done. Just restart the rsyslog daemon with the following command:

$ sudo service rsyslog restart

Step 5: start the syslog protocol on your router

The final step is to enable the syslog protocol from the router side (that is the client side). This is different from router to router, so you should check your router’s documentation. For example, on my router I just need to provide the IP of the syslog server!

You should finally see the log entries of your router in your log file, as soon as something is logged by the router.

Step 6: configure logrotate

It’s a good idea to rotate your log file, especially if your router creates a lot of log entries.
Just create a file in the /etc/logrotate.d/ directory (call it as you wish) with the following content:

/var/log/netgear.log {
        rotate 7
        size 500k
        notifempty
        compress
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Again, replace netgear.log with the name of your log file.

That’s it! Happy logging with your Pi.

Install ownCloud in a subdirectory using nginx

During the last holidays I found the time to buy a Raspberry Pi (B+), at last. My main use case will be an ownCloud server within my home’s LAN. I will also access to it from outside the LAN thanks to the DDNS service provided by (e.g.) no-ip.

Owncloud by default depends on the apache webserver, but it works fine with the lighter nginx server, which is recommended to not stress too much the Pi. You have to manually install owncloud, though. I followed this guide and it worked fine (even installing php5-curl worked for me, required for the External Storage application). Note that you can actually skip the steps 1c, 1d and the last part of step 9. Owncloud works just fine without messing with GPU memory, CPU overclock and swap.

That guide though, as well as the official owncloud guide, assumes that the owncloud installation will be accessible from the root of your server, e.g. from example.com. What if you want it to be like example.com/owncloud ?
Actually the solution it’s quite easy, even though it’s not so easy to find it on the web. So, the following is a working nginx configuration file for the discussed setup. Basically I’ve just rewrited the location blocks and the rewrite directives from the configuration file suggested by the linked guides.

upstream php-handler {
    server 127.0.0.1:9000;
    #server unix:/var/run/php5-fpm.sock;
}
 
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}
 
server {
    listen 443 ssl;
    server_name example.com;
 
    ssl_certificate /etc/ssl/nginx/cert.pem;
    ssl_certificate_key /etc/ssl/nginx/cert.key;
 
    root /var/www;
 
    client_max_body_size 1000M; # set max upload size
    fastcgi_buffers 64 4K;        
 
    # ownCloud blacklist
    location ~ ^/owncloud/(?:\.htaccess|data|config|db_structure\.xml|README) {
        deny all;
        error_page 403 = /owncloud/core/templates/403.php;
    }
    
    location / {
        index index.html;
    }
 
    location /owncloud/ {           
        error_page 403 = /owncloud/core/templates/403.php;
        error_page 404 = /owncloud/core/templates/404.php;
 
        rewrite ^/owncloud/caldav(.*)$ /remote.php/caldav$1 redirect;
        rewrite ^/owncloud/carddav(.*)$ /remote.php/carddav$1 redirect;
        rewrite ^/owncloud/webdav(.*)$ /remote.php/webdav$1 redirect;
 
        rewrite ^(/owncloud/core/doc[^\/]+/)$ $1/index.html;
 
        # The following rules are only needed with webfinger
        rewrite ^/owncloud/.well-known/host-meta /public.php?service=host-meta last;
        rewrite ^/owncloud/.well-known/host-meta.json /public.php?service=host-meta-json last;
        rewrite ^/owncloud/.well-known/carddav /remote.php/carddav/ redirect;
        rewrite ^/owncloud/.well-known/caldav /remote.php/caldav/ redirect;
 
        try_files $uri $uri/ index.php;
    }
 
    location ~ \.php(?:$|/) {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        fastcgi_pass php-handler;
    }
 
    # Optional: set long EXPIRES header on static assets
    location ~* ^/owncloud(/.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf))$ {
        expires 30d;
        access_log off;  # Optional: Don't log access to assets
    }
}

On Raspbian/Debian this configuration file is /etc/nginx/sites-available/default, but on different systems it may be located somewhere else. Don’t forget to reload (or restart) nginx after you edit the configuration file.

Gcc 4.9 colors and sudo

Since version 4.9, the gcc compiler is finally able to shows a colored output, one of the many good clang features. This is so helpful to locate warnings and errors that you quickly become addicted to it. Unfortunately, for some questionable reasons, this feature is turned off by default. In order to use it you have to either define the environment variable GCC_COLORS (e.g. by export GCC_COLORS=1) or use the flag -fdiagnostics-color=auto.

The problem is: when you sudo make install a CMake-generated Makefile, you get no colors. That’s because, for security reasons, sudo resets the environment and thus GCC_COLORS is not defined anymore. In particular this is due to the line Defaults env_reset in the file /etc/sudoers.

While I was looking for a fix to this problem, I realized that there not exists a clean solution, at least to my likings.

What I have done, at the end, is adding this line to /etc/sudoers (you have to use sudo visudo):

Defaults        env_keep += "GCC_COLORS"

While this is an hacky solution, is the least hacky for my tastes, until I find something better.
Other possible solutions, which I discarded but may be useful to others, are the following:

  1. Define the GCC_COLORS variable in /etc/profile.d/ or /etc/bash.bashrc or /etc/profile. This works only using sudo -i or sudo su - instead of sudo and I don’t want to.

  2. Use sudo -E instead of sudo. This preserves the whole environment and can be a security mess.

  3. Use sudo env "GCC_COLORS=$GCC_COLORS" make install. But obviously this is annoying and alias for it would be ugly.

  4. Add always the flag -fdiagnostics-color=auto. This is even more annoying.

I’m sorry, but I have to say that the only sane solution would be enabling by default the colors, like clang does.

New features incoming for Ark

Ark, the KDE archive manager, has been around for a while (almost 17 years) but for the last few years its development has been slowed due to lack of manpower. In the past few weeks I have been started getting familiar with the Ark codebase and now the first results are going to be availables.
Starting from KDE Applications 14.12 (scheduled for December), Ark will receive a couple of new features which have been requested for years:

  • the ability to show a context menu when right-clicking on an archived entry
  • the ability to open an archived file with a chosen application

ark-contextual-menu

The above screenshot shows the contextual menu and the available actions. As you can see, now there is a new Open With... action, which will extract the selected file to a temporary location and will open it with your preferred application. For example in the following screenshot I’ve opened the file using Kate:

ark-tmpfile

This means that now you can quickly work on a single file with just a single click, while before you had to extract that single file and save it on a particular location, before you could edit it.
I’d like to thank Volker Härtel, the original author of this patch, and Raphael Kubo da Costa, the Ark maintainer, who has reviewed it.

This is just the beginning. I’m working on other features, for example the ability to create password-protected archives and the ability to move and rename entries within an archive. Stay tuned!

Status of libc++ on Linux

Eventually it comes a time when you have to use a C++11 piece of software which, by default, doesn’t compile on Linux. This happens because Linux distributions use the GNU libstdc++ library as the default implementation of the C++ standard. Unfortunately the libstdc++ is not (yet) C++11 features-complete, because there are some C++11 features which are currently not implemented.
Consider for instance the following C++11 program:

#include <fstream>

int main() 
{
    auto stream = std::ifstream("~/test.txt");

    return 0;
}

Even such a trivial program cannot be compiled using gcc (gcc 4.9.1 at the time of writing). If you try, you’ll get this kind of error:

$ g++ -std=c++11 test.cpp 
test.cpp: In function ‘int main()’:
test.cpp:5:45: error: use of deleted function ‘std::basic_ifstream<char>::basic_ifstream(const std::basic_ifstream<char>&)’
     auto stream = std::ifstream("~/test.txt");
                                             ^

A good solution to this problem is to switch to a C++ implementation which is C++11 complete: we are talking about the LLVM libc++ library.
This library has been created mainly due to license problems, since Apple and the BSDs don’t like the GPLv3 used by libstdc++. So, we can say that Linux is not a first class target of libc++ developers, and there are also some religious debates about whether Linux users should use libc++ in their systems.
But actually I’ve just tested libc++ on my Debian Sid and it works remarkably well. You just need to install these packages:

  • libc++1
  • libc++-dev
  • libc++abi
  • libc++abi-dev

You need also to install and use clang instead of gcc, since at the moment I don’t think it’s possible to use gcc togheter with libc++.
You can finally compile every C++11 program using: clang++ -std=c++11 -stdlib=libc++

Of course on other distributions different from Debian, the name of those packages may slightly change.
The great thing is that libc++ and libstdc++ are coinstallable and they can perfectly coexist. If you want you can use libc++ just for C++11 programs and libstdc++ for all the other stuff.

Kronometer 1.5 is out

Kronometer has just been released with the version 1.5.0. This release brings a couple of new features and an important bugfix.
First of all, you can take laps annotations: Kronometer now lets you place a custom text note over a certain lap time. This can be useful in many use cases. For example, if you are using Kronometer to time your presentation tests, you may want to time each single slide, or two by two slides.
Check the Note column in the right of the following screenshot to understand how it will works:

kronometer-notes

Another new feature, which has been implemented after a request, is the ability to completely disable the laps recording feature. This might be useful if you never use the laps and if you want a less crowded user interface. The following screenshot shows the resulting Kronometer UI: as you can see, the lap button and the lap table are gone.

kronometer-no-laps

To disaple the laps recording as showed, go to Settings -> Configure Kronometer -> Interface settings and uncheck the Enable laps recording checkbox.

The last new feature is the support of the AppData specification, whose content is already available in 14 languages, thanks to the KDE localization team.

Finally, Kronometer 1.5 has an important bugfix. Now if there are multiple Kronometer windows opened and if one or more Kronometer settings are changed, those changes will be applied to all those windows.

How to fix the broken shutdown on ThinkPad Edge E130

My current laptop is a ThinkPad Edge E130 and I really like it, except for a terribly annoying bug which affects lots of Linux distributions (possibly all of them): if you shutdown your distro, you might have your laptop rebooting instead of shutting down as expected. If you don’t even know that this bug exists, you might experience bad situations like shutting down your pc, put it in your bag and then realize, many hours later, that the battery of your laptop is gone. Of course this is something that actually happened to me.
It’s still not clear where the bug comes from, since it affects many different ThinkPad models and even some non-ThinkPad laptops (e.g. some Acer models). That’s why you may find lots of solutions in the web, but which one is the right one? Some people reports that the bug is defeated by installing the laptop-mode-tools package. According to other people there are some kernel modules to be removed just before the shutdown.
I’ve finally managed to find the right fix for the ThinkPad Edge E130 and I will share it in this post.
I’ve tested it on a Debian Sid system which uses systemd as init manager. It should also work for other systemd distributions.

Step 1: the solution

The solution that makes the ThinkPad always shutting down as requested is a simple bash script with the following content:

#!/bin/sh

for i in /sys/bus/*/devices/*/power/control; do
	echo on > $i
done

exit 0

This script has to be run just before the system shutdown in order to fix the bug. What does the script actually do? It’s hard to tell, but somehow the kernel takes a complete power-management control and is able to make a working shutdown. The value on written by the script overwrites many existing auto values, and probably one (or more) of them causes the bug.

Step 2: creating the solution

You can put the above script wherever you want. In this example we’ll use /usr/local/bin/shutdown-fix.sh. You just have to make sure to make it executable:

$ cd /usr/local/bin
$ sudo chmod +x shutdown-fix.sh

Step 3: installing the solution

The script has to be run before the system shutdown. In the systemd world, this means that you have to create a custom service which executes the script at the right moment.
You should create a shutdown-fix.service file in either /etc/systemd/system/ or in /usr/lib/systemd/system with the following content:

[Unit]
Description=Shutdown Fix Script

[Install]
WantedBy=multi-user.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/usr/local/bin/shutdown-fix.sh

The ExecStart entry is executed on system startup and that’s why we use /bin/true, which does nothing. We are interested only in the ExecStop entry and that’s where you have to put the script from the previous step.

Finally, you have to enable the service and we’re done:

$ sudo systemctl --system enable shutdown-fix.service

So, this solution is systemd specific. If you still use the old sysvinit or Upstart or OpenRC, you have to use your distro specific’s way to run scripts on shutdown.

Kronometer 1.4.2 released and KF5 port completed

Kronometer 1.4.2 has been released.
It’s a minor release with just a couple of small fixes. The option to hide the statusbar, which was added in the 1.2.1 version, has been removed since it’s already provided by the standard KDE libraries: just go to the Settings menu and then click the Show Statusbar entry.
In the meantime, I have completed the port to KF5, introduced in my previous post. What I still have to do is decide how to release the ported version, since KF5 is not that much spread across distributions, at this time. Probably I’ll wait the other Extragear applications and I’ll see how they will handle the new releases after their ports.
Btw, if you want to have a look at the KF5 port, it’s just a matter of few git commands:

$ git clone git://anongit.kde.org/kronometer
$ cd kronometer
$ git checkout frameworks

Then you compile as always:

$ mkdir build && cd build 
$ cmake ..
$ sudo make install

You’ll find the compiled port installed at /usr/local/bin/kronometer.

Kronometer ported to KDE Frameworks 5

I’m very happy to announce that Kronometer has been ported to KDE Frameworks 5 (KF5), the new generation of KDE libraries provided to build KDE apps.

kronometer-kf5

As you can see in the screenshot, the frameworks version used is the 5.0, which has been released the past 7 July. However the Plasma version is still 4.13 and not the new Plasma 5.0, but I don’t think that will be a problem.
The kronometer version in the screenshot is 2.0.0 but only as a placeholder, I have not yet decided how to release the KF5 port. Currently all the work has been done in the frameworks branch on the git repository.

What’s working

The main use case, of course.You can start/pause/reset the stopwatch and record the lap times.
All the Kronometer Settings are working too.

What’s not working

The stopwatch persistence feature. So, at the moment is not possibile to restore a saved stopwatch or save a running stopwatch.
The motivation is that I was too eager to complete the port and this feature is the most boring to port.
Further, as you can see, the stopwatch digits are awfully “sides-cutted”, I still have to figure out what’s going on and how to fix it.

Kronometer 1.4 brings translations

I’m glad to announce that Kronometer 1.4 is now localized in over 12 languages. This is the first time that Kronometer brings translations to its users.
Thanks to the effort of the KDE translation team, Kronometer is completely localized in:

  • Brazilian Portuguese
  • Czech
  • Dutch
  • Finnish
  • French
  • German
  • Low Saxon
  • Polish
  • Portuguese
  • Spanish
  • Swedish
  • Ukrainian

Bosnian, Hungarian and Slovak translations are not completed, though.
Even the Kronometer Handbook is going to be translated and at the moment is available in Dutch, Swedish and Ukrainian.
The release 1.4 brings also a new feature and an important bugfix. The new feature is the automatic highlighting of the latest lap time recorded. This means that the latest lap time is always visible, while in the older releases it wasn’t. The bug fixed is the bug 336904, which was preventing the reset of the stopwatch under certain circumstances.
Finally, the release 1.4 is the first one hosted on the KDE servers, instead of this server. In this way you can use the KDE mirrors scattered all around the globe.

UPDATE (2014/07/09)

The release 1.4.1 fixes a small bug which was preventing the removal of the old upper toolbar (which was in the releases < 1.3.0) from the Kronometer UI.