Friday, 6 July 2012

User Setup

The default pi user has sudoer (super user) privileges which provides access to administrative functions which might be beyond the scope of the average user or even dangerous to the security of the system.

The best approach (one which I have not done until now) is to create user accounts for each individual user who will be using the shell and setting appropriate privileges to each user.  The following describes how this can be achieved for a new user called tykus:
$sudo useradd tykus
This has created a user, but we now need to set a password for this user:
$sudo passwd tykus
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
$
We are asked to enter a new UNIX password and to confirm it.  We're not quite done just yet because this method does not automatically create the new user's home directory, although it does assume it will be located at /home/tykus (in this case).  So our next step is to create that directory:
$sudo mkdir /home/tykus
If we run a list command ($ls -l), we are given information about the contents of the /home directory
$cd /home
$ls -l
total 8
drwxr-xr-x 16 pi   pi   4096 Jul  6 10:11 pi
drwxr-xr-x  2 root root 4096 Jul  6 11:29 tykus
$
The information provided tells use what is in the directory, who owns it and what permissions are associated with it, specifically each line tells us:
  • Field 1: permission flags (10 of them!)
  • Field 2: link count
  • Field 3: owner of the file
  • Field 4: associated group for the file
  • Field 5: size in bytes
  • Field 6-8: date of last modification
  • Field 9: name of file
Currently, the /home/tykus directory is owned by the root user - if we were to login as tykus now, we would be unable to write to the directory although we (along with any other users) could read and execute the contents. For example, if we try to create a file new_file in /home/tykus as the pi user, we will not be allowed
$touch /home/tykus/new_file
touch: cannot touch `new_file': Permission denied
$
Whereas, if we try to execute a python script in the same directory (as pi), we can do that:
$python /home/tykus/hello.py
Hello World!
$
We need to give the directory to its rightful owner:
$sudo chown tykus:tykus /home/tykus
Note: if there were already contents in this directory (such as the python script above), we should include a -R option to recursively change permissions for all directories and files in the directory. For security reasons we will also change permissions so that only the owner can read, write and execute the home directory:
$sudo chmod 700 /home/tykus
Preferred Shell If we check the /etc/passwd file, our new user is added to the end; included details are colon (:) separated as follows: Username:Password:User ID:Group ID:Comment:Home directory:Shell (more information here)
tykus:x:1002:1002::/home/tykus:/bin/sh
So tykus will log in to the sh shell, whereas we prefer the Bourne shell (bash), so we can change /bin/sh to /bin/bash (or whatever shell is preferred) We can now login as tykus and keep all of our files private from other users!

Tuesday, 3 July 2012

GPU Capability

The latest MagPi, the Raspberry Pi community’s free-to-download magazine, came out today and within it was a section on tweaks and fixes along with some of the free software which can be installed, one of which was the omxplayer. I had come across this package previously and played with it briefly on my Ubuntu Server, which was ultimately intended to run headless, so combined with the crappy performance I was seeing anyway, I didn't spend very much time with.  But given the RPi's Broadcom BCM2835 chipset, which is designed to handle intensive multimedia, it was an opportunity to have a look at the packages capabilities again. OMXplayer is run from the command line, meaning there is no GUI overhead in terms of a desktop environment from which it must be run.

Installing OMXPlayer

The debian package was liberated as follows:
wget http://seyrsnys.myzen.co.uk/rpi/omxplayer_0.0.1-arm.deb
and installed
sudo dpkg -i omxplayer_0.0.1-arm.deb
along with dependencies (-f fixes broken dependencies resulting from the previous line):
sudo apt-get -f install

Mounting Shared Folders

The omxplayer package was now installed, but I hadn't yet mounted my shares from the server on the RPi. In order to get this sorted out. I have Samba on the Ubuntu server because I share to Windows machines elsewhere on my network, so to keep things simple, I went the same route for the RPi mountings also.
The first step is to create a credentials file in the home folder of the default pi user:
sudo nano .smbcredentials
Within this file there are two lines:
username=my_username
password=my_password
Because this is not an entirely secure means of storing username and password data, the file is then set as read-only for the root user, although any user with access to root will be able to read it - which on the RPi's default user is anyone!
sudo chown root:root ~/.smbcredentials
sudo chmod 600 ~/.smbcredentials
The next step was to create mount points for the shared music and video folders:
sudo mkdir /mnt/music /mnt/video
Next, I changed the File System Table file /etc/fstab which will mount shared folders to those local folders whenever the RPi boots:
sudo nano /etc/fstab
Add in this file I added a line for each folder to be mounted as follows:
//server/music /mnt/music smbfs credentials=/home/pi/.smbcredentials,uid=1000,gid=1000
//server/video /mnt/video smbfs credentials=/home/pi/.smbcredentials,uid=1000,gid=1000
A quick reboot and we're done; checking the contents of /mnt/video shows the contents of the server's shared folder as expected.

Playing a video

The last thing to do is actually play a video and see what happens! The video of choice is Big Buck Bunny, an open source video which was made using open source software such as Ubuntu, Inkscape, Blender and GIMP. What's more, this is a high definition video, outputting 1080p, which whould really exercise the RPi's GPU!  And the result? Pin sharp rendering which my P&S camera simply cannot do justice to!



The only issue I now need to overcome is putting the audio out through the HDMI port along with video, but in the interim the audio socket on the RPi is doing the job perfectly.

Quite hungry in terms of CPU demand!!


Credits for the post must go to:
http://www.themagpi.com
https://help.ubuntu.com/community/MountWindowsSharesPermanently
http://www.bigbuckbunny.org