Jacques Amar is close (see the October 2014 Letters). The year 2000 was a leap year.
A year is a leap year if it is a multiple of 400 or is a multiple of four and not a
multiple of 100.
—
fest3er8
Regarding Samuel Bucquet's article in the October 2014 issue, it looks like the author is running everything as root. This seems to be
fairly common in articles about the Raspberry Pi or BBB where the hardware
is accessed, as Linux puts up some security barriers to protect these
ports from the ordinary user. There are reasonable ways to work around
this limitation, such as exporting the pins in a boot script. Also,
WebIOPi looks like a well put together solution for the Raspberry Pi that
could be ported to the BBB. LJ should not be encouraging running as root,
particularly on hardware that frequently ends up as mini-Web servers.
—
Mike Beaver
Samuel Bucquet replies: Thank you, Mr Beaver, for pointing this out.
The access of the IO ports needs a lot of attention in a multi-user scenario. In the same way, if there is a possibility of multiple tasks accessing the same hardware simultaneously, you need to consider some locking mechanism. The majority of the tasks I described in the article are hardware administration tasks, but the reading and writing on the IO ports can be done as a regular user, like the user a Web server is running with to allow access of IO ports from a Web page.
Serial ports:
In order to use them as a regular user, there is nothing special to do, as long as the user is in the dialout group (check with “id”).
GPIO:
You will have to initialize, as root, the GPIO that will be used, and position the permissions accordingly (like this for the Debian default user):
# echo 48 > /sys/class/gpio/export
# chgrp -R debian /sys/class/gpio/gpio48/
# find /sys/class/gpio/gpio48/ -type f -exec chmod 664 {} \;
# find /sys/class/gpio/gpio48/ -type d -exec chmod 775 {} \;
But beware, you don't want multiple users fidgeting with the same GPIOs at the same time!
Then you can access the gpio with the “debian” user.
Components on the i2c bus:
As with the serial ports, if the user is in the “i2c” group, she can access components on the bus as a regular user. But there are a lot of sensitive components on an i2c bus, so if the integrity of the system is at risk, take great care as to who can access what.
Analog reading:
In the same way you did for the GPIO, put the permissions in /sys/bus/iio/devices/iio\:device0/ for the user, and again do not allow simultaneous access to the ADC.
Handling of the permissions may vary a little, and udev can be put to good use for other devices not automatically recognized, but the essential part is here.
I might add that the solution I chose to handle for this is a one and only process to access an IO port.
A shared memory server relays readings and writings to the IO handling process. I use redis as a back end for the following reasons:
It allows me access to the IO from the network from multiple clients (rarely multiple writing though).
It allows me to dispose of IO readings in a coherent way with transactions.
It allows me to attach a validity period to each item of data.
And it even allows a PUS/SUB mechanism.
Of course, there is a good Python module too.
Writing letters to LJ is becoming habit-forming this month.
Shawn Powers left out the scariest part of SSH tunnels in his article
“This Is Why We Can't Have Nice Things: SSH” in the October
2014 issue. It takes some thought and effort
to set it up right, root access is needed, and public/private keys are required, but
it's relatively easy to set up PPPoS (PPP over SSH) using pon and poff.
Then, you configure
NAT as needed at each end of the link to obtain Internet access unfettered by a
firewall. Finally, redirect internal nodes to use the internal system that hosts that
end of the tunnel as their default gateway. That should be enough to make the toughest
admin blanch.
—
fest3er8
Ha! Indeed, SSH is like the light saber of the tech world. It's super amazing, but it's fairly easy to cut your arm off!—Shawn Powers
I am responding to Shawn Powers' article in the August 2014 issue titled “First Health, Now Recreation”. Since he mentioned Audible, I would like to ask if he has tried converting Linux Journal into an audio file?
I love Audible, mainly because I can maximize the way I absorb information in a crowded train or while driving. (I just caught up on the last two LJ issues on flight when I was traveling to a conference yesterday.)
I have been thinking that if I could listen to LJ, that would be very productive! With the
fact that most of the time 75% of the book is readable, maybe Dragon Speech (which I
don't have) would work?
—
Leo Chan
That's an interesting question, Leo. One of my writing tricks is that I have the computer read back the text to me so I can hear any mistakes that my eyes glance over. I'm not sure the robotic voice reading an entire issue would be great, especially when it comes to the code sections, but I wonder if folks with assistive reading devices have luck with Linux Journal's text. Any text-to-speech listeners out there?—Shawn Powers