Saturday, 6 December 2014

Up and Away - Setting up a LAMPi

Acknowledgements:
For guidance I found a great article by Etel Sverdlov on Digital Ocean.  Written for Ubuntu 12.04 - but none the less still valid
https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu


Installing a LAMP (server) on your Raspberry Pi

This is something that I have done a number of times now, but I've always dashed in and just done it in whatever order worked.  Having looked at this in a bit more of a planned manner, I read Etel Sverdlov's article first, and that made a lot of sense.  What I'm attempting to present here is based upon that, but with a few updates to call out some important points.

Step 1 - Latest repositories

First of all, need to update the repositories for aptitude (I prefer aptitude to apt-get - use apt-get if you wish)

sudo aptitude update



Step 2 - Install Apache2

Apache2 is a nice web server.  Get used to it and it can be really friendly to use and administer.  To install:

sudo aptitude install apache2

It's pretty straight forward.  You'll be asked to confirm the installation of new files - just answer 'y'.  Once that is done, then it is time to test your Apache2 installation using your browser.  If you are running the Pi GUI on your RasPi, point your browser at 127.0.0.1.  If like me, you are setting up your RasPi to be a headless server, with only the command line interface, you'll have to point another machine on your network at the RasPi's address.  You should see a web page like this:






IMPORTANT!
During the Apache2 installation, there was one message - "Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName".  This possibly happened on your install too.  Depending on what you want to do with your RasPi, this may need to be addressed later on.  For now, I'm letting it slide.  Let's call it a Priority 2 TODO

Now you may have read my previous post, where I setup multiple IP addresses on the RasPi NIC at eth0 through aliases.  So when I point my browser at the root address of the alias, I still get Apache's default index page.  So, the web server is running, on both aliases.  This is a bit more urgent - let's say a Priority 1 TODO.

I'll come back to these points in future posts.  Moving on for now.


Step 3 - Install MySQL


MySQL is quite a nice bit of kit.  Haven't used it enough.  And full credit to Etel, I've followed her instructions quite closely this time.  In the past I was quite nervous about attempting an install without the test DB, and without other features, but as Etel rightly point's out, these aren't necessary, and fixing them now will lead to a tighter installation, better for security.  Keeping in mind that this RasPi is due to be effectively a production level machine, that's what we need.

Installing MySQL is a bit more involved, with a few choices to be made.  To kick off the process:

sudo aptitude install mysql-server libapache2-mod-auth-mysql php5-mysql

From this command, your system may detect some conflicts in the packages, particularly apache2-mpm-prefork vs apache2-mpm-worker. Where we go from here depends upon what you want to do with your box.

For mine, I'm going to accept removing apache2-mpm-worker module. The apache2-mpm-worker is a more memory efficient module for handling multiple calls using thread processing.  However it constrains then that you should only use thread safe calls, and this module is known to have issues with PHP.  If we were building a dedicated MySQL box, without the Apache and PHP components, for a large, highly scalable commercial system, I would probably recommend differently.  But for a low volume server, where system performance is non-critical, where some code used may not be thread-safe, I am choosing apache2-mpm-prefork.

Set the MySQL Root password when prompted.  Just get it done and dusted.  You can do it later, but doing it now will help avoid forgetting later.

Next, set-up and configure the database with the following commands:

sudo mysql_install_db

sudo /usr/bin/mysql_secure_installation


The system should prompt you for the MySQL Root password:

Enter current password for root (enter for none):


OK, successfully used password, moving on...


Now come the important security choices in the MySQL installation.  The first will be the choice to remove anonymous users.  For me, this is a no-brainer.  Unless you want to setup a publicly accessible free-to-play database server, there is no reason.  To support a web server, your install should only have known users with roughly three levels of access; root for admin, developer accounts for developing (or deploying/troubleshooting), and web app/service accounts for the applications that are going to consume the database.  So, that's a yes to removing anonymous users.

Remove anonymous users? [Y/n] y                                           
 ... Success!


Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y

... Success!



HOLD THE FORT!  Don't let root login remotely?  How will we administer this?  Don't stress, before putting the RasPi to it's final config, we will create the other user accounts.  If however, you are already running your RasPi through SSH, you may wish to choose 'n' for this option for now. (Just note down for later that you need to change it)

Removing the default test database is another no-brainer.  For this to be a production level box, we should not have any test artifacts.  If this was for a development server, or a classroom education server, I'd say keep it, but for this one, it's going.

Remove test database and access to it? [Y/n] y

 - Dropping test database...

 ... Success!

 - Removing privileges on test database...

 ... Success!


Reloading the privilege tables will ensure that all changes made so far will take effect immediately.

Reload privilege tables now? [Y/n] y

 ... Success!


Step 4 - Install PHP

Installing PHP is pretty straight forward, but there will be some more choices to be made along the way.  Let's start with:

sudo aptitude install php5 libapache2-mod-php5 php5-mcrypt

Then as the chosen packages are identified, we have another choice to make, a conflict between libapache2-mod-php5filter and libapache2-mod-php5.  "What's the difference?" you ask - well here goes:

  • libapache2-mod-php5filter is not thread safe, so if you opted for apache2-mpm-worker in MySQL (see above), do not use libapache2-mod-php5filter
  • libapache2-mod-php5filter does not pass PUT and OPTIONS calls to the PHP processor - sends them straight to Apache and can break WebDAV - possibly not good for collaboration platforms

So, with this reasoning together, my selection was easy - libapache2-mod-php5 stays.

Next we want to make sure that if we have a PHP coded index page for a site, that it will get recognised as the index page.  This may, or may not have been put into the dir.conf file during installation.  Double check by using sudo to open dir.conf in your preferred editor.


sudo nano /etc/apache2/mods-enabled/dir.conf

If necessary add index.php to the beginning of index files. The page should now look like this:

<IfModule mod_dir.c>

          DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm

</IfModule>


Check!

Next, you may want to add some extra modules to extend the PHP functionality.  This does not need to be done right now, but if you want to, check which modules are available in the repositories first:

apt-cache search php5-

Choose your modules and install.  Finally test the PHP install.  Use your preferred text editor to create the following file: /var/www/info.php

<?php
phpinfo():
?>


Then restart Apache

sudo service apache2 restart

Now test the page in your browser:  127.0.0.1/info.php
If you see a page like the one below, all has been successful.


Thursday, 4 December 2014

Change Brings Challenges

For some time now I've been running a #RasPi off our router, providing the private cloud based options for file-sharing, collaboration, and getting to those important documents we forgot to bring.  So far I'm very happy with ownCloud.  I'm also happy with Apache as my base web server, though I have not done enough with it.  A basic home page is all really.

Plus, that image has been up and running now for some time.  It's image base is old (2013??) and it probably needs a spruce-up of its firm-ware.  I want to put an email server on it.  So far I'm considering Citadel as my front runner there.

The other problem is that I fear it may have been hacked.  Either that, or with my increasing age, and the extended periods of time since I last accessed that box, I have forgotten the passwords.  Ooopps!  Can't have a box that has been rooted.  The kid in me smells a counter hack in the making. The old bloke recognises that there was nothing on the box of any grand importance. A #rebuild with a new SD card and properly implemented security would probably avoid the potential of reclaiming a box with unknown backdoors.

Beyond this, what I'd also like is to setup the opportunity for some web services that can interface with some home-made mobile apps.

What I am uncomfortable with is our router.  Yes, you can set it up to forward connections for different services and applications.  It will forward incoming common protocols to the correct port on a specified IP address.  I am not certain however, if you have more than one website, differentiated by port, that the router's port forwarding works that well.  The interface for setting up the port forwarding is not user friendly.  So, I am considering using multiple IP addresses on eth0 (#aliases), to ease the pain.

To set up for using multiple IP addresses, there are two methods.  One is to a running change that is non-persistent  An example of this can be found at Penguin Tutor.  The method I am going to use will persist the changes when the RasPi is rebooted:

pi@exampleberry ~ $ sudo vi /etc/network/interfaces
  
Edit the interfaces file with vi to add the eth0:0 alias

iface eth0 inet static
    address 192.168.72.88
    netmask 255.255.255.0
    gateway 192.168.72.254
    auto eth0

iface eth0:0 inet static
    address 192.168.72.89
    netmask 255.255.255.0
    auto eth0:0

...

iface eth0:9 inet static
    address 192.168.72.98
    netmask 255.255.255.0
    gateway 192.168.72.254

Repeat as necessary for aliases eth0:1.. to eth0:x, depending upon how many aliases your box requires. Save the changes to your interfaces file and restart your network services.

pi@exampleberry ~ $ sudo /etc/init.d/networking restart

Check the results by running ifconfig.

Of course, a potential headache that I will create by doing this is that I will simply increase the exposure of my RasPi box to further intrusions.  So before I go any further, its time to research how to harden my RasPi and monitor for intrusion.

Acknowledgments:
Narad Shrestha's article on Tecmint (http://www.tecmint.com/create-multiple-ip-addresses-to-one-single-network-interface/), "Create Multiple IP Addresses to One Single Network Interface"

Friday, 20 June 2014

Moving Beyond the QNAP Concepts

It's been some time since I drooled over a friend's set up of Plex on a QNAP NAS, and wondered how I could efficiently manifest something similar on a RasPi.  Further analysis of the circumstances have reshaped my thoughts on that matter.  But as for any of the technical challenges I seem to take on around our home, the journey is rarely straight forward, and the direction constantly changes.  And for this project, so has the prospect of a budget.

Previously I had identified that running the Plex services of the RasPi was not an option.  And the reason I wanted to use Plex was that it would work natively with our lounge room TV.  Further research and trials has since blown that concept out of the water - LG does not have the smart TV apps for our model that work with Plex.  This does not mean our ideas for using Plex are dead - far from it.  Allow me to elaborate.

The media centre solution that I need to apply now needs to facilitate the following:
Access from our lounge room TV (LG) - Wirelessly connected to our internal network
Access from our bedroom TV with smart Blu-ray (Samsung) - Wirelessly connected to our internal network
Limited access from our son's playroom TV (Medion) - not currently connected to our networks
RasPi does not run Plex, but can run XBMC
I have canabalised an old 2nd hand machine, and setup an Ubuntu server with Plex, CouchPotato, Sickbeard and other apps.  It's in our DMZ.  This means that the Samsung smart Blu-ray can access it, but our LG TV cannot as its network features do not seem to allow it to discover appliances outside its subnet.

So, the Plex server in the DMZ, works. Samsung has a Plex app. Works on the bedroom blu-ray. Lounge TV can't use Plex, and can't connect to the DMZ. But the Plex server is capturing content, and I don't want to put it in the internal subnet.  The Plex server has a fair but of content on it already, but I want to be able to control the access our son has to that via his playroom TV.  And at the same time, whilst I'd like to be as power conservative as possible, our current situation dictates that conserving money is the more important criteria.

Limiting the connectivity of the playroom TV would also be advisable - helps with regulating the young boy's Internet access.  Plus, it would be beneficial family suitable content could also be made available on our portable DVD-player when we travel.  It accepts USB connections, as does the playroom TV.  So, my thoughts are that the easiest solution there, is a portable USB drive.  I can refresh the content every once in a while to provide variety, but otherwise it is low-cost, simplistic, restricts access, and is portable.

That means that there is only the lounge room TV to satisfy.  My current thinking is that my RasPi with XBMC, could serve movies to it directly through HDMI, and the content for the RasPi could be migrated from the Plex server either by some kind of scheduled task, or by establishing some code that will detect when new movies and TV shows have arrived on the Plex server, and will cause an update to the RasPi.

Friday, 11 April 2014

Survey of IT Training Needs - Canberra/Yass Valley Region

I am seeking expressions of interest in non-registered IT training courses, for the Canberra/Yass Valley region.  If you live or work in this area, could you please complete the following survey.  It should take no more than 3 to 5 minutes of your time.  Thank you for your time and consideration.

Expression of Interest in Non-Registered IT Training Courses

Tuesday, 31 December 2013

My ideas have been QNAP'd

It has been some considerable time since my last post.  Whilst my fingers may not have been typing as much, this does not mean that productive work has ceased.  Far from it.  I have in recent months encountered a number of options and ideas that will change the scope of my work with the Raspberry Pi.

Within my own home environment, I have been seeking to utilise the RasPi as a solution for a number of different needs; home automation, media centre, games console, personal cloud server, web server, print server, etc.  Up front the RasPi has three core strengths from my humble opinion; ease of use, low-cost and energy efficiency at 36W.  However, it has some drawbacks as well.

With respect to it's use as a media server, the software solution that I had heard a lot about and had been wanting to use (because it was the one that would work with our main TV) was Plex.  However, Plex is not available on the RasPi.  With any server that is storing large amounts of data, that is constantly running, having some kind of redundancy in the storage.  Let's face it, the time taken to rip several hundred DVD's and CDs to a media server, and the bandwidth required to download others is not insignificant, and if you've done it once, you really don't want to go through it again.  Unfortunately, with only USB connections for mass storage options, the RasPi is limited in this aspect, and the more hard drives that you have plug in through a powered hub, or with their own power supply, the less green the RasPi becomes as an option.

Over the last month I have had good fortune to spend some time with fellow geeks who have sorted their home media centres and are using Plex.  I've been lucky to receive demonstrations of their systems, and more importantly one of them revealed that he is running his system from a QNAP server.  I asked about power consumption and he told me that since replacing an old PC with the QNAP server, their power bills had decreased about $100 (AUD) a year.  Given that the QNAP servers have multiple drive bays, mounting multiple hard drives and configuring a RAID array will provide redundancy.  They have multiple Gigabit Ethernet ports, half-a dozen USB ports and other features too.  What's more, they only draw 40W when in operation (less for sleep mode) and their processors are far more powerful than that of the RasPi.

Awesome!

So, does this mean the end of the Rastaberrian Project?  Hell, no! It just simply means that I can refine the scope of my ideas of what to do with the RasPi, and remove the concept of using it as a media, print or personal cloud server.  My current thoughts are to place any such server in DMZ, so that it can be accessible externally as well.  In considering the RasPi for home automation, my current thoughts are that this should be secured within the home green zone, and if external access is required - facilitated by web services via a secure web page hosted from the DMZ.  Use of the RasPi as a games console, or to make an ordinary TV into a Smart TV, I think still holds merit.

Friday, 20 September 2013

RasPi and a 13 Port Hub: What Would You Do?

My recent acquisition of a 13 port hub to work with my Raspberry Pi got me to thinking, what could be done with it?

Sure, I'm intending to work with it to develop some energy and cost efficient #media_centre options, but my mind has been ticking over what other options it could be used for - with the two devices combined, that provides a total of 14 USB ports.  With the combination of an #Arduino kit or two, it could be rigged up with motion sensors, then when activity is detected by the Arduino sensor nodes, it could wake up a number of web cams to record the activity.  Possibly useful as security for a small office or apartment.  You could have an array of 4 +Arduino sensor suites, and 7 web cams attached.  The remaining two ports (remember the Pi is drawing its power from one port) could be used for an external HDD to save the footage to, and a wireless Broadband modem - so that when activity is detected it can contact you and provide footage on demand.

So, I am looking for some inventive ideas please.

I'll kick off the party with my own idea - this one is less serious and more fun.

1. The Venus Pi Trap
Requires;
3 x Arduino controlled sensor arrays - each array has motion and distance sensors
1 x Raspberry Pi
1 x 13 port hub
10 x USB missile launchers

Write a customised app for controlling the sensor arrays and the missile launchers.  The app interprets the motion and distance data from the sensors to triangulate on the motion, and in turn aim the USB missile launchers, then fire.  Surprise your family and friends! Slaughter your siblings in a hail of rubber missiles! Teach the cat that the corner of the room is not its litter tray!  If you think a battery of 10 missile launchers is overkill, just replace one or two of the launchers with web cams - capture the carnage forever.  Shock and Awe!.

Thursday, 19 September 2013

Play Room Media Centre: Green Hub Option 2

Given that it's not possible to get the PiHub in Australia yet, I've been looking out for other options.  Particularly option that would draw the same or less than the PiHub, yet still offer the same functional advantages.

I Was Bad
Yes I found an option to the PiHub, and I bought it.  Thank you Dick Smith for the XH1237 powered USB hub.  This beauty draws 108W through it's power pack.  That's about the same as three of my +Raspberry Pi machines.  But it did cost $60 AUD.  That is a fair bit more than the PiHub.  Ooops!

But Wait There's More...
The real beauty of this device though is that the output of its power pack is 5VDC at 4A.  That means that whilst the power pack draws the power of 3 RPi, it puts out enough to power 4 RPi.  And it could power 4 RPi and have ports remaining for peripherals.  Yes, you heard correct.  This baby has 13 USB 2.0 ports!

13 Ports?  Really?
Yep.  Now you might well be thinking that this is a bad case of over-kill.  It could be.  But, lets think in terms of a Media Centre that has the capacity to play games.  Now of course you are going to want the hub to power the RPi.  You are also going to want to plug in a substantial  size HDD and a WiFi dongle.  That's 3 ports gone.  Wireless keyboard/mouse dongle.  That's 4 ports gone, with still room to spare.  So let's assume you want a second HDD in there - the first was for your movie collection, then second is for your games.  Sweet.  Now lets throw in some neat gadgets for your gaming experience.  Say a steering wheel, pedals and feedback chair.  We've allocated 8 ports now.  There's 5 ports spare on the hub, plus one other on the RPi itself.

What More Can We Plug In?
Now depending upon what games you have and how big your screen is, it could be feasible to have up to 4 controllers plugged in.  We could also plug in a web cam.  Bam!  That's our 13 ports filled, but look at what we've achieved - neat!