"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." (Robert A. Heinlein)

Wednesday, 4 May 2016

Place the Raspberry PI at the centre of your network


My recent problems with Internet providers, followed by the need to change my ADSL modem-router made me think if it would be wiser to make my home network less router dependent. Local network at my home, like most home networks, relies on the ADSL modem-router for the Dynamic Host Configuration (DHCP). Every time I changed the router I had so to reconfigure its DHCP server in order to restore my network configuration, often not being able to access to some network devices, like the NAS disk, until the DHCP was properly configured.
While looking for a Raspberry DHCP configuration how-to I literally stumbled into this page about using the Raspberry PI as a wireless router. This also inspired me about using the Raspberry also to provide a backup or private WI-FI access.
Hardware set-up
First things first: I already had a Wi-Fi dongle wandering in my drawers, I installed in the Raspberry PI USB port and checked it worked. Not all the wireless interfaces are able to be used in “access point mode”, to check if the one I had was compatible I installed the “iw” utility:
sudo apt-get install iw
executing the command:
iw list
I got a detailed list of the network interface features, among them in the the supported interfaces modes:
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
* mesh point
i got confirm that the interface could work as access point.

Monday, 28 March 2016

Test Drive: Ubuntu Mate 16.04 on the EEEPC


Here I am, again, doing some “test-drive” on the EEEPC 900 and some newly released Linux distribution. Even thought I found, with Xubuntu, a stable lightweight solution for my old netbook still I'm looking curiously to what other lightweight solutions have to offer. After reading about the soon to be released Ubuntu-Mate 16.04 and its new so called “Mutiny” desktop layout, I so decided to download and give it a try.

A quick look ...

After boot Ubuntu Mate 16.04 welcomes you with the usual reassuring old styled desktop. In addition a handy welcome application is started too.

Saturday, 27 February 2016

Monitoring the Raspberry PI with RPI-Monitor


My Raspberry PI is, ,silently and tirelessly, doing its work as a headless server, mostly working as media-server thanks to MiniDLNA and SFPG gallery. Thanks to all this working silent and without asking maintenance I sometimes even forget about the Raspberry PI this is because I felt the need of looking for a tool that allowed me to check the Raspberry status trough a simple web interface.

RPI-Monitor

RPI-Monitor is a web-based monitoring application developed by RPI-Experiences. I got informed about it by reading its description on eLinux.org page. On the same page I also found detailed information on how to set-up repository and install RPI-Monitor package so that installing it has been a mere copy-and-paste exercise.
sudo apt-get install apt-transport-https ca-certificates
sudo wget http://goo.gl/rsel0F -O /etc/apt/sources.list.d/rpimonitor.list
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 2C0D3C0F
sudo apt-get update
sudo apt-get install rpimonitor
Once installed RPI-Monitor is available at port 8888 of Raspberry PI address
The “Start” button brings to RPI-Monitor status page where monitoring information is neatly exposed

Wednesday, 6 January 2016

Ubuntu 15.10: Some post installation fix


After upgrading my desktop computer to Ubuntu-Gnome 15.10 I went on with installing software packages I needed and it took me a while to notice there were problems in my network disk mounts. I had the configuration copied from the previously backed-up “fstab” configuration file. Everything was working fine before upgrading but in the new installation the system started with the configured Samba shares unavailable. Manually re-executing the mount sequence (with command “sudo mount -a”) solved the problem until next reboot.
I checked the system log and got the following error message:

Jan 3 11:15:05 veritons661 kernel: [ 20.826880] CIFS VFS: Error connecting to socket. Aborting operation.
Jan 3 11:15:05 veritons661 kernel: [ 20.827770] CIFS VFS: Error connecting to socket. Aborting operation.
Jan 3 11:15:05 veritons661 mount[680]: mount error(101): Network is unreachable
Jan 3 11:15:05 veritons661 mount[680]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Jan 3 11:15:05 veritons661 kernel: [ 20.828593] CIFS VFS: cifs_mount failed w/return code = -101
Jan 3 11:15:05 veritons661 systemd[1]: media-nas.mount: Mount process exited, code=exited status=32
Jan 3 11:15:05 veritons661 systemd[1]: Failed to mount /media/nas.
Jan 3 11:15:05 veritons661 systemd[1]: Dependency failed for Remote File Systems.
Jan 3 11:15:05 veritons661 systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.
Jan 3 11:15:05 veritons661 systemd[1]: media-nas.mount: Unit entered failed state.
Apparently, during the boot process, the system tried to mount network drives before the network was up and ready. I quickly discovered I wasn't alone with my problem, AskUbuntu pages offered some solutions. The first I tried, using the “_netdev” mount option in order to force the system to wait for the network to be ready, didn't work for me. The second solution has been configuring the network shares to be mounted only at the first access using “noauto” and “x-systemd.automount” mount options.
Here is how my “fstab” configuration looks like:

# NAS
//192.168.0.110/sh_maxx /media/nas cifs noauto,x-systemd.automount,x-systemd.device-timeout=3,uid=maxx,credentials=/home/maxx/.smbcredentials,iocharset=utf8,sec=ntlm,file_mode=0777,dir_mode=0777 0 0
# Public
//192.168.0.110/public /media/public cifs noauto,x-systemd.automount,x-systemd.device-timeout=3,guest,uid=maxx,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0
The network shares are now correctly mounted and there is no noticeable delay at first access. Only Nautilus seems to have been driven a little crazy about it since it shows drive icons doubled.

Thursday, 24 December 2015