Volume 3: nginx: A Successful Foundation

(This is part of My ownCloud Adventure)

The Final Fron… Errrr… Wrong adventure.

In the end I have chosen to utilize Nginx to host my personal ownCloud… At least until I have a reason to change my mind, probably for an arbitrary or subjective reason.

Nginx is rather new to me, bug generally speaking, remembering how to pronounce its name was more difficult than getting things working.

Just like getting lighttpd working, I took advantage of Win32 Disk Imager to write an image to the SD card with all of the prep work covered by the Preface completed.

  1.  sudo apt-get update
  2. sudo apt-get install nginx php5-cgi php5-fpm curl libcurl3 php5-curl php5-common php5-gd php-xml-serializer php5-mysql
  3. cd /etc/nginx/sites-available
  4. sudo nano siteName-ssl
    1. copy/paste the Nginx config from ownClouds docs
    2. Edits
      • “root /var/www/owncloud”
      • Find:  “location ~ ^/(data|config|\.ht|db_structure\.xml|README)”
        • Change to (Thanks Dave!):
          • “location ~ ^.*/?(data|config|\.ht|db_structure\.xml|README)”
      • comment out:  fastcgi_pass 127.0.0.1:9000;
      • uncomment:  fastcgi_pass unix:/var/run/php5-fpm.sock
    3. save and exit
  5. cd ../sites-enabled
  6. sudo rm default
  7. sudo ln -s ../sites-available/siteName-ssl
  8. sudo service nginx restart

At this point a choice needs to be made.  One can continue installing the php-apc module, or one can go ahead and do the initial ownCloud configuration… Getting things to work and experiencing the load times as-is… Providing a great before-and-after comparison to fully appreciate what php-apc accomplishes.

PHP-APC

Regardless of which choice is made, the php-apc module is a required addition… And a very quick install.

  1. sudo apt-get install php-apc
  2. sudo service php5-fpm restart

And it is now ready and working!

ownCloud Initial Configuration

The first time you bring up ownCloud, which with the above steps can be found at https://server.ip.or.fqdn/owncloud, you are presented with a pretty simple initial configuration page.

For anyone following this path, I believe its pretty self explanatory.  It only needs a few sets of information…

  • Initial username & password
  • ownCloud’s data directory
  • Database details

Some details may be hidden via an Advanced Options link.

The data directory configuration item is the one that may need the most consideration depending on circumstances.  At this early point, with little experience, I did not have a need to divert from the default.

A Little Tuning

There are a couple of options that I would recommend doing.

So lets go into the ownCloud Admin section.

The most important configuration change to make with under the “Cron” section.  While the default is set to “Ajax”, its recommended to use the “Cron” option.

Configuring the cron is not difficult, but should be done under the default webserver user.  (ownCloud’s cron doc)

  1. sudo -u www-data crontab -e
  2. Add to the bottom:  */15 * * * * php -f /var/www/owncloud/cron.php
  3. save and exit

Beyond the cron configuration, you can also check “Enforce HTTPS”.  While the webserver should be doing this task, a little backup probably won’t hurt.

App Thoughts

External storage support:  Probably one of the most important available apps.  This lets you connect to Dropbox, Google Drive or other accounts.  It also lets you define local storage directories, such as NFS mounts.

ownCloud Dependencies Info:  I do not believe this one is needed normally, but is a good tool out there to make check ensure you have the appropriate dependencies.

Unfortunately I had to disable the Pictures app at this time since it is not working properly for me. I hope it’ll be resolved in the future.

 

And with that… For now… Until next time… The End

Various References:

Volume 2: lighttpd: An Easy Fling

(This is part of My ownCloud Adventure)

While my initial foray into ownCloud was successful… Even if I did not see it all the way through…  I felt I needed to investigate a solution that would bet better suited for the limited hardware of my Raspberry Pi.

The path chosen was a brief dalliance with lighttpd.

Taking advantage of Win32 Disk Imager, I was able to write an image to the SD card with all the completed prep work that covered in the Preface.  This did save a good bit of time.

  1. sudo apt-get update
  2. sudo apt-get install lighttpd php5-cgi curl libcurl3 php5-curl php5-common php5-gd php-sml-serializer php5-mysql
  3. cd /etc/php5/cgi
  4. sudo nano php.ini
    • uncomment:  “cgi.fix_pathinfo = 1”
    • Not actually sure this is required, as a re-read of the description says that “1” is now the default value
  5. cd /etc/lighttpd
  6. sudo lighty-enable-mod fastcgi-php
  7. cd conf-available
  8. sudo cp 10-expire.conf 10-expire-myHost.conf
  9. sudo nano 10-expire-myHost.conf
    • Append
      • $HTTP[“url”] =~ “(css|js|png|jpg|ico|gif)$” {
        expire.url = ( “” => “access 7 days” )
        }
      • etag.use-inode = “enable”
      • etag.use-mtime = “enable”
      • etag.use-size = “enable”
      • static-file.etags = “enable”
  10. sudo service lighttpd restart

And with that the ownCloud first-run webpage should be accessible at https://server.ip.or.fqdn/owncloud.  Which leaves things in basically the same spot as the end of Volume 1.

After describing everything needed to get lighttpd up and running with ownCloud though, I’m hoping a detail was not left out… This does appear to live up to the “Easy Fling” description though.

Its possible this would have been the end of my adventure, except for one detail.  In the Preface I mentioned security… And while I have no particular knowledge or specific security concern to doubt lighttpd… I was a little put-off by the last update being over 9 months ago in November 2012.

And similarly, while I cannot speak to nginx’s security posture being better that lighttpd, it appears to be more actively maintained… Not to mention its quickly growing popularity.

Which leads us to… Volume 3:  nginx:  A Successful Foundation

Various References:

Volume 1: Apache2: A Heavy Duty Companion

(This is part of My ownCloud Adventure)

My adventure with ownCloud started out well, focusing on the goal of using Apache for my webserver, but it appears that some of my records were lost during my adventure… With the actual commands I used to install Apache now unavailable (i.e. never recorded to begin with).

So I’ll be providing what believe to be the best reconstruction (i.e. guess) that I am able to provide.

  1. sudo apt-get update
  2. sudo apt-get install apache2 php5-gd php5-curl  php5-cgi libapache2-mod-php5 php5-mysql libcurl3 php5-common php-xml-serializer
  3. cd /etc/apache2/sites-available
  4. sudo cp default mySite
  5. sudo cp default-ssl mySite-ssl
  6. sudo nano mySite-ssl
    1. edit:  SSLCertificateFile /etc/ssl/localcerts/mySite.fqdn.pem
    2. edit:  SSLCertificateKeyFile /etc/ssl/localcerts/mySite.fqdn.key
    3. save and exit
  7. sudo service apache2 stop
  8. sudo a2dissite default
  9. sudo a2ensite mySite
  10. sudo a2ensite mySite-ssl
  11. sudo service apache2 start
  12. Test:  https://server.ip/ownCloud
    1. If the certificates are working, you’ll have to tell your browser that you accept the risk of accepting a self-signed cert
  13. Assuming it worked…
    1. cd /etc/apache2/sites-available
    2. sudo nano mySite
      1. After “DocumentRoot” line, add…
        1. Redirect permanent / https://site.ip/
        2. or:  Redirect permanent / https://fqdn/
      2. save and exit
    3. sudo service apache2 reload

These instructions make a few assumptions that should be mentioned before progressing further.

  • The Preface has been followed
  • apache’s default root directory is “/var/www”
  • an owncloud directory (or symlink) exists at “/var/www/owncloud”

At this point, going to “https://site.ip.or.fqdn/owncloud” should bring one to the initial configuration page for ownCloud.  On a Raspberry Pi, with its limited hardware, It may take more than a few seconds to appear.

One last parting thought… Apache2 is a good webserver.  It has served me well over the years, but as the years have passed its put on some weight.  During this initial ownCloud endeavor… And it hit me when loading ownCloud for the first time…  I learned that there are other, less weighty (i.e. light) webserver options.

So in an effort to not repeat myself, its at this point that Volume 1 will wrap up, as I plan to go into more post-installation details at the end of Volume 3.

Until next time…  Volume 2:  lighttpd:  An Easy Fling

Various References:

 

Raspbian using SD card & USB thumb drive

Sub-Topic: Creating a backup image of your Raspbian SD card

Decided to try moving my actual linux partition from the standard SD card location to a USB memory stick.

I did this without fully understanding the benefits (or cons).  🙂

I knew people had done this previously with USB hard drives.  Its possible this will reduce the likelihood of the SD card becoming corrupted.  I’m not sure if it provides any performance (read/write) improvements.

So in summary… I just did it… To do it.

Notes:

  • My primary resource for getting this done was: Raspbian on Raspberry Pi using SD card + USB memory stick
  • I primarily use a Win7 laptop, so I’ll be differing from the above link in the details, but the overall concepts remain the same.
  • When working with any images I used the Win32 Disk Imager program (v0.7).
  • I did all this after already having Raspbian working and configured with an SD card

Process:

  1. Determine the device name of the USB memory stick
    1. This can be accomplished via “dmesg” as seen at the above link.
    2. An alternative method is to “sudo tail -f /var/log/messages” prior to putting the memory stick in.  When you put the memory stick in log messages will appear similar to the “dmesg” format.
    3. My memory stick was at “/dev/sda”
    4. Remove the USB memory stick once done
  2. Create a backup image of your SD card
    1. This accomplishes a couple of things.
      1. Creates a nice backup of a working Raspbian image
      2. Makes it so that when you’re successful, the Raspbian image running off your USB stick is already configured and working immediately.  Yes… This was as awesome as it sounds.
    2. With Win32 Disk Imager
      1. Select the SD card drive letter
      2. Type in the name and full path for the backup image (e.g. c:\users\john doe\desktop\rasp_backup.img).  I had to type it in, bringing up the file window only allows selecting an existing img file
      3. Click Read
      4. And wait…
  3. Write the SD card backup image to the thumb drive
    1. Again, using Win32 Disk Imager
      1. Select the thumb drive’s drive letter
      2. Select the backup img file you just created.  You can use the file dialog box this time
      3. Double check that you did selectd the thumb drive’s drive letter
      4. Click Write
      5. And wait…
  4. Prepare the boot SD card
    1. I had a smaller 256MB SD card lying around, so I used it for this purpose
    2. I used Window’s format capability to format the boot SD card
      1. File system:  FAT32 (this is not the default)
      2. Allocation unit size: 1024 (not sure if this is needed, but its what I did… Default was 2048, which probably would have worked)
  5. Copy boot files from USB memory stick to boot SD
    1. Open the USB memory stick via Windows Explorer
    2. Open the boot SD via Windows Explorer (in a separate window)
    3. Copy all displayed files from the USB memory stick to the boot SD
  6. Modify the boot files to point to the USB memory stick
    1. On the boot SD, open “cmdline.txt”  (notepad worked for me)
    2. There is only a single line in the file
    3. Change “root=/dev/mmcblk0p2” to “root=/dev/sda2”
      1. This tells Raspbian to look at the 2nd partition on the USB memory stick instead of the 2nd partition on the SD card
      2. Save.  There should be no issues saving with notepad since you’re editting the middle of the line, so no carriage return issues that could occur… Possibly… I really don’t know in this case.  🙂
      3. Its possible you SD card and USB memory sticks have different device names, but the above is how it looked for me
  7. Put the boot SD and USB thumb drive into your Pi and plug in the power

After I did the above, everything worked for me the first time and with the configuration I had previously working with just an SD card.  Which means I did not have to move my headless Pi to reconnect it to a TV and keyboard and mouse to verify and configure.

Raspbian – NFS w/Synology

Synology stuff first…

  • Enabled NFS file sharing on my Synology
  • For each share on my Synology NAS, had to go into NFS Permissions and create a rule
    • Disabled “Asynchronous”

Then followed these instructions…

First, install the necessary packages. I use aptitude, but you can use apt-get instead if you prefer; just put apt-get where you see aptitude:

sudo aptitude install nfs-common portmap

(nfs-common may already be installed, but this will ensure that it installs if it isn’t already)

On the current version of Raspbian, rpcbind (part of the portmap package) does not start by default. This is presumably done to control memory consumption on our small systems. However, it isn’t very big and we need it to make an NFS mount. To enable it manually, so we can mount our directory immediately:

sudo service rpcbind start

To make rpcbind start automatically at boot:

sudo update-rc.d rpcbind enable

Now, let’s mount our share:

Make a directory for your mount. I want mine at /public, so:

mkdir /public

Mount manually to test:

sudo mount -t nfs 192.168.222.34:/public /public

  • (my server share path) (where I want it mounted locally)

Now, to make it permanent, you need to edit /etc/fstab (as sudo) to make the directory mount at boot. I added a line to the end of /etc/fstab:

192.168.222.34:/public /public nfs rsize=8192,wsize=8192,timeo=14,intr 0 0

The rsize and wsize entries are not strictly necessary but I find they give me some extra speed.

 

Notes:

  • Everything basically needs to be done via sudo
  • With multiple shares, each needs to be mounted independently.  Such as…
    • /public/dir1
    • /public/dir2

 

Source: http://www.raspbian.org/RaspbianFAQ

Raspbian – VNC

Installing VNC on the Pi

We’re going to use Tight VNC here (server on the Raspberry Pi and Viewer on Windows).

There’s an excellent tutorial over at Penguin Tutor if you need more information.

First of all install the Tight VNC Server from the command prompt:

sudo apt-get install tightvncserver

Let it finish installing (if you’re asked to confirm anything, just hit ‘y’ on the keyboard). When complete start the server:

vncserver

You’ll be asked to create a password, enter one and confirm. I used raspberry for ease of use, but probably not the most secure!

When asked to create a view only password, say No.

Every time you start VNC you’ll see something like:

New 'X' desktop is raspberrypi:1

Note the :1. This is the desktop session created. You can add more by running VNC again.

Head over to TightVNC on your windows box and install the viewer.

 

Source: http://www.neil-black.co.uk/raspberry-pi-beginners-guide#.UTk0TDC9t8F

Raspbian – Misc To-Done

Misc things I’ve done to configure my Pi for my personal usage.

Most have to be done via “sudo”

  • Create a new user, separate from “pi”
    • Command:  ‘adduser’
    • Appears to be a Debian specific command, different than the usual Linux ‘useradd’
  • Make new user’s primary group be “users”
    • Since I’m connecting to my Synology NAS over NFS, this allows any files I create as the new user to be part of a common group between the Pi and NAS
    • Command: ‘usermod -g users <newuser>’
  • As “pi” user, give new user ‘sudo’ access
    • Command: ‘visudo’
  • Create RSA key for authentication
    • Command: ‘ssh-keygen’
    • Be sure to keep your key safe and retrievable so that access is not lost… Don’t lose your key!
  • Add pub key to “~/.ssh/authorized_keys” file for new user
  • After achieving access via key authentication, disable SSH password authentication
    • Edit /etc/ssh/sshd_config
    • “PasswordAuthentication no”
  • Optional, specify SSH access for accounts
    • Edit /etc/ssh/sshd_config
    • At bottom of the file, add:
      • AllowUsers newUser1 newUser2
    • Good way to leave default “pi” user “active”, but not directly accessible via SSH
  • Changed hostname
    • nano /etc/hosts
    • nano /etc/hostname
    • reboot
  • Install rsync
    • aptitude install rsync
  • rsync backup script caused an error
    • Error: Too many open files
    • Testing solution: edit /etc/security/limits.conf
      • @users     hard     nofile     32768
  • Configure NTP to sync with NAS
    • Edit /etc/ntp.conf
    • Comment out existing lines starting with “server” that look like “server 0.debian.pool.ntp.org”
    • Add line like “server <nas IP>”
    • Save
    • service ntp restart

To be continued…

Raspbian – SSH Keys

Very important note: once you get access to your Pi, do regenerate the SSH keys.
Since Raspbian (and basically all the other distributions) are distributed as prepared images to copy onto the SD card, it is not safe to keep the default SSH keys.
To regenerate the keys proceed as follows:

# sudo rm /etc/ssh/ssh_host_*
# sudo dpkg-reconfigure openssh-server

Source: http://www.slblabs.com/2012/08/16/rpi-ssh-ip/

Synology Configuration Items

Tested on DS412+ and DS411 from www.synology.com

  • Followed many of the items in this tutorial: http://www.synology.com/tutorials/how_to_protect_your_Synology.php?lang=us
    • Created new admin account and then disabled default admin account
    • Enabled auto-IP block
  • Used no-ip.com free DDNS service
  • Enabled local SSH
  • Configured with static LAN IPs
  • Enabled CloudStation
    • Limited number of folders able to be sync’d  🙁
    • Created 1 sync shared folder, placed picture and video folders in here