You may have read some of my post about RF433 and Raspberry PI. Basically with RPI 1, I was using wiringPi interrupt handler to manage the RF433 decoding. The problem is that with RPI2 and RPI B+ the delay to take an interrupt that was becomes unpredictable. And the timing constraints are not respected. As a consequence part of the messages are loss because for these delay.
One of the solution (the software one) is to be more efficient to proceed the interrupts and the way to do this is to compile a kernel driver for directly handling the interrupts. This is what this post is about. This comes to complete the RFRPI code and associated hardware. A complete source code and software for using it is on the rfrpi bitbucket repository.
Challenge of the coming days : write a kernel driver to manage interruption quicker on a raspberry pi 2. I’m happy to find a lot of example on Internet and in particular this one, that is really looking like what I’m trying to do. This post is describing all the step needed to do this.
The new version of kernel now activate the device-tree standard, it means that instead of having all module activated by default with some stopped by a blacklist system, now, all are disable and activated only when described in a device tree.
Device tree details the system architecture and dependencies following configuration files. The device tree can be owned by the shield itself in an attached eprom.
As a consequence, now, i2c / spi are not activated by default. So if you need to activate it on startup. For this, edit /boot/config.txt and add line at the end like :
dtparam=i2c_arm=on # for i2c 1
dtparam=i2c_vc=on # for i2c 0
CentOS 7 have selinux activated, so when you decide to change your default httpd directories you have to give the right selinux permission to these directories otherwize the https server will not be able to access the files.
CentOs 7 have a built-in configuration to close the inactive ssh session. In term of security it is a good thing but when killing a session after 1 minute of inactivity start to be a mess when you have multiple session opened in parallel.
This can be avoid on the client side by configuring a keep-alive period on the client side. To activate a such keepalive, you just have to connect with the following command line:
ssh -o ServerAliveInterval=5 firstname.lastname@example.org
This will configure client to send a NULL packet every 5 seconds to keep the session opened.
Posted in Systems
Tagged CentOs, ssh
If you try to access a remote database with nginx or httpd server, you will have a connection problem with error code (13) even if mysql/mariadb client works well in command line. The reason for that is a security limitation set by default not allowing httpd servers sur connect a remote DB.
To disable this limitation and make all work, just type in the command line :
# setsebool -P httpd_can_network_connect 1
You can list all the existing flags for httpd by using getsebool
# getsebool -a | grep httpd
In case you expect SELinux to be the cause of your problem, you can enable / disable it with the following functions
# setenforce 1
# setenforce 0
If you need to check what is the permission missing for SELinux you can run the audit
# tail -100 /var/log/audit/audit.log | audit2allow
With the growing firewall constraints accessing a server over ssh is not always a pleasant journey ; I’ve read a korben post on GateOne html5 server side ssh client and I just got an opportunity to deploy it for a test. This post will detail how to install it and secure it a little bit.
Posted in Systems
Tagged html5, ssh, unix, web
Synology is providing a Glacier backup tool which seems to be an easy way to backup data on the low cost amazon solution. I will not describe how to configure it a log of blogs are doing it and I do not like to be redundant. The question I did not find an easy answer was : will I be able to restore my backup even if my synology crashed and I would not be able to get one other…
These two last days, I was participating to devoxx in Paris. One of the star topic of the event this year was Docker so I attempt different talk about this container technology I already has discovered in a previous JUG session. It was not an evidence that this technology was more than something interesting for DEV needing small, fast starting, small memory footprint, environment for testing. With my OPS hat, I did not catch the interest. This was before Devoxx and the different talk. The aspects I’ll detailed in this post have not been addressed during Devoxx, as much as I have seen, as mostly the DEV aspects have been addressed, I going to synthesize my opinion.