Fixing up Raspberry Pi with apt-get update woes.

Greetings, weary tech[no] traveler!

Lately, I've been having some trouble updating the software on my Raspberry Pi (running Raspbian) via 'apt-get update'.  Every time I would run:

sudo apt-get update

I would get the following output:

Hit http://archive.raspberrypi.org wheezy Release.gpg
Hit http://mirrordirector.raspbian.org wheezy Release.gpg
Hit http://archive.raspberrypi.org wheezy Release
Hit http://mirrordirector.raspbian.org wheezy Release
Hit http://archive.raspberrypi.org wheezy/main armhf Packages        
Ign http://archive.raspberrypi.org wheezy/main Translation-en       
Hit http://raspberrypi.collabora.com wheezy Release.gpg             
Hit http://raspberrypi.collabora.com wheezy Release
Hit http://raspberrypi.collabora.com wheezy/rpi armhf Packages
Ign http://raspberrypi.collabora.com wheezy/rpi Translation-en
Get:1 http://mirrordirector.raspbian.org wheezy/main armhf Packages [6891 kB]
Hit http://mirrordirector.raspbian.org wheezy/contrib armhf Packages               
Hit http://mirrordirector.raspbian.org wheezy/non-free armhf Packages                                                                                                                                     
Hit http://mirrordirector.raspbian.org wheezy/rpi armhf Packages                                                                                                                                          
Ign http://mirrordirector.raspbian.org wheezy/contrib Translation-en                                                                                                                                      
Ign http://mirrordirector.raspbian.org wheezy/main Translation-en                                                                                                                                         
Ign http://mirrordirector.raspbian.org wheezy/non-free Translation-en                                                                                                                                     
Ign http://mirrordirector.raspbian.org wheezy/rpi Translation-en                                                                                                                                          
100% [1 Packages xz 0 B]

And it would just hang there.  Until the SSH connection would time out.

It is important for me to successfully run updates on my Raspberry Pi.  If you're running something like Apache or a MySQL server you've got to be able to patch them.  Also, I have a healthy case of paranoia when it comes to software updates and information security.  Anyway...

It turned out I was running an older version of the Raspberry Pi firmware, which was impeding my ability to successfully run apt-get update && apt-get upgrade.

I'm sure I'm not the only one who had this problem.  Now that I've fixed this problem for myself, I thought I'd show you how to fix it yourself.

1. First, make sure your Raspberry Pi has a solid connection to the internet. 
2. Log in.
3. Update the Raspberry Pi firmware:
   
   sudo rpi-update
   
   If rpi-update terminates with the following (or similar) error:
    *** Relaunching after update
    *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
    *** We're running for the first time
    *** Backing up files (this will take a few minutes)
    *** Backing up firmware
    *** Backing up modules 3.12.20+
   cp: cannot stat `//lib/modules/3.12.20+': No such file or directory
   
   Then create a directory called in 3.12.20+ in the directory /lib/modules/:
   
   sudo mkdir /lib/modules/3.12.20+and then run sudo rpi-update again.
4. This will take about 10 minutes, so go for a walk, grab a beer, etc.
5. If no errors appeared, your firmware was successfully updated.  Reboot your Raspberry Pi to activate the new firmware:
   
   sudo reboot
6. Once the Raspberry Pi has rebooted, log in, and run your updates:
   
   sudo apt-get update && sudo apt-get upgrade

Ubuntu 14 and Apache and MoinMoin! Oh my! (Part 2)

Greetings, weary tech[no] traveler!

Welcome to Part 2 of  Ubuntu 14 and Apache and MoinMoin! Oh my!

Suppose your wiki contains sensitive data and utilizes the user authentication features MoinMoin.  It would be a good idea to secure it from eavesdropping creeps using man-in-the-middle attacks, wouldn't it?  We should configure our wiki's apache config file to use https, along with SSL certificates, to encrypt all of the traffic to and from our wiki site.  That way, anyone who's packet sniffing on your network (or the network your site is hosted from) won't be able to make any sense of what they are recording.

Once you have generated your SSL certificate and private key move your SSL certificate to /etc/ssl/certs/ and your private key to /etc/ssl/private/:

sudo mv humboldtwiki_example_com_cert.cer  /etc/ssl/certs
sudo mv myprivateSSLkey.key   /etc/ssl/private

NOTE:  NEVER give your private SSL key to anyone.  If you give a private key to someone, that someone now has the key to your castle, rendering any encryption useless.

After you have moved your certificate and private key, enable Apache's SSL module:


sudo a2enmod ssl

Next, make sure the directory  /etc/ssl/private has the following permissions:

drwx--x--- 2 root ssl-cert  4096  private/

And the contents have permissions and group settings like this:

-rw-r----- 1 root ssl-cert 1704  myprivateSSLkey.key
-rw-r----- 1 root ssl-cert 1704  ssl-cert-snakeoil.key

If the new private key has different permissions, change them to match the ones above like this:

sudo chgrp ssl-cert myprivateSSLkey
sudo chmod 640 myprivateSSLkey.key

As a matter of fact, all of the private keys in this directory should have the same permissions described above.

Modify, the Apache config file (in our case, humboldtwiki.conf) to your wiki site like this:

# create some wsgi daemons - use these parameters for a simple setup
WSGIDaemonProcess moin user=www-data group=www-data processes=5 threads=10 maximum-requests=1000 umask=0007 display-name=wsgi-moin

# use the daemons we defined above to process requests!
WSGIProcessGroup moin

<VirtualHost humboldtwiki.example.com:80>
  ServerName humboldtwiki.example.com
  ServerAdmin webmaster@example.com
  Redirect 301 / https://humboldtwiki.example.com
  CustomLog /var/log/apache2/humboldtwiki-80-access.log combined
  ErrorLog /var/log/apache2/humboldtwiki-80-error.log
</VirtualHost>

<VirtualHost humboldtwiki.example.com:443>
  ServerName humboldtwiki.example.com
  ServerAdmin webmaster@example.com

  WSGIPassAuthorization On
 
  SSLEngine on
  SSLCertificateFile    /etc/ssl/certs/humboldtwiki_example_com_cert.cer
  SSLCertificateKeyFile /etc/ssl/private/myprivateSSLkey.key

  DocumentRoot  /usr/share/moin/humboldtwiki
 
  WSGIScriptAlias / /usr/share/moin/humboldtwiki/moin.wsgi

  <Directory />
    Options FollowSymLinks
    AllowOverride all
    Allow from All
    Require all denied
  </Directory>

  <Directory /usr/share/moin/humboldtwiki>
    AllowOverride All
    Allow From All
    Require all granted
  </Directory>

  ErrorLog /var/log/apache2/humboldtwiki-error.log

  LogLevel warn

  CustomLog /var/log/apache2/humboldtwiki-access.log combined
</VirtualHost>

What this Apache config does, is that it forces all users to connect to the wiki site using https.  Anytime a user navigates to the url, http://humboldtwiki.example.com, their web browser will be redirected to https://humboldtwiki.example.com.

Now, let's restart Apache so that our changes will take effect:

sudo service apache2 restart

There you have it!  You've now protected your wiki site, and your users, from the classic man-in-the-middle attack.

Ubuntu 14 and Apache and MoinMoin! Oh my! (Part 1)

Greetings, weary tech[no] traveler!

Sure has been a while since the last post, hasn't it?   I could go on about why I haven't posted in a while, but why?  You're here to find out how to serve up a wiki, right? 

Recently I had to set up and configure and a wiki site, complete with https and SSL certificates.  For this task, I decided to use what I called the MUA (MoinMoin, Ubuntu, Apache) stack.  We're all familiar with the greatness of Ubuntu and Apache, but out of all the wiki solutions that are available why did I choose MoinMoin?  MoinMoin is a free and open source wiki solution, that is easy to install, configure, and use.  Plus, it's written in python.  As a python fanatic, I have a bias for anything python related.

So, let's get down to it!  Log into your shinny new Ubuntu 14.04 server and install Apache, as well as MoinMoin and the mod_wsgi apache module:

sudo apt-get install apache2 python-moinmoin libapache2-mod-wsgi -y

Once Apache, mod_wsgi, and MoinMoin are finished downloading and installing, enable mod_wsgi by running the following command:

sudo a2enmod wsgi

Next, let's configure MoinMoin.  You can name your wiki site anything you want, but for the sake of example let's call the wiki in this example, humboldt.  In the interest of modularity, let's configure MoinMoin so that we can serve more than one wiki later on down the road.  At the command line, create a directory for our wiki site, and copy our wiki config and wsgi config files:

sudo mkdir /usr/share/moin/humboldt
sudo cp /usr/share/moin/config/wikiconfig.py  /usr/share/moin/humboldt
sudo cp  /usr/share/moin/server/moin.wsgi   /usr/share/moin/humboldt

Next, we'll configure our wsgi file for humboldt.  Open /usr/share/moin/humboldt/moin.wsgi in a text editor of your choice.  Once opened change the following line:

sys.path.insert(0, '/etc/moin')

to:

sys.path.insert(0, '/usr/share/moin/humboldt')

Now, let's configure our wiki config file, wikiconfig.py.  This is the file that you will edit to make configurations that are specific to humboldt only.  For now, let's change the site name and interwiki name for humboldt.

Using vim, I made the following changes to wikiconfig.py:

sitename = u'Humboldt Wiki'
interwikiname = u'HumboldtWiki'

There are lots of ways to configure MoinMoin.  However, the details of wikiconfig.py is not within the scope of this post since I'm only going to cover how to install MoinMoin as well as serve it with Apache, using mod_wsgi.  I'll talk more about that in a future post.

We need to add our configuration of humboldt to MoinMoin.  First, we must create a config file specifically for humboldt.  To do that:

cd /etc/moin
sudo cp mywiki.py humboldtwiki.py

Then edit humboldtwiki.py.  Change it so that the class Config looks something like this:

class Config(FarmConfig):

    # basic options (you normally need to change these)
    sitename = u'HumboldtWiki'
    interwikiname = u'HumboldtWiki'

    # name of entry page / front page [Unicode], choose one of those:

    # a) if most wiki content is in a single language
    #page_front_page = u"MyStartingPage"

    # b) if wiki content is maintained in many languages
    page_front_page = u"FrontPage"

    data_dir = '/usr/share/moin/humboldt/data'

    data_underlay_dir = '/usr/share/moin/humboldt/underlay'

Save and close the humboldtwiki.py.  Then within the same directory, open and edit the wikis variable, in file the farmconfig.py, to look like this:

wikis = [
    ("humboldtwiki", r"^http://humboldtwiki\.example\.com/.*$"),
]

Adding our wiki to the wikis variable in this fashion will allow us to add another wiki instance in the future (if we so choose), with little effort.  It never hurts to plan ahead!

Save and close the farmconfig.py file.

Now that we've done the initial setup and configuration of our MoinMoin wiki site, let's move onto creating and configuring our apache config file for it.  At the command line:

cd /etc/apache2/sites-available
sudo vim humboldtwiki.conf

Again, you don't have to use vim.  Just use whatever text editor you like.

In your new, blank, apache config file add the following:

# create some wsgi daemons - use these parameters for a simple setup
WSGIDaemonProcess moin user=www-data group=www-data processes=5 threads=10 maximum-requests=1000 umask=0007 display-name=wsgi-moin

# use the daemons we defined above to process requests!
WSGIProcessGroup moin

<VirtualHost humboldtwiki.example.com:80>
  ServerName humboldtwiki.example.com
  ServerAdmin webmaster@example.com

  WSGIPassAuthorization On

  DocumentRoot  /usr/share/moin/humboldtwiki

  WSGIScriptAlias / /usr/share/moin/humboldtwiki/moin.wsgi

  <Directory />
    Options FollowSymLinks
    AllowOverride all
    Allow from All
    Require all denied
  </Directory>

  <Directory /usr/share/moin/humboldtwiki>
    AllowOverride All
    Allow From All
    Require all granted
  </Directory>

  ErrorLog /var/log/apache2/humboldtwiki-error.log

  LogLevel warn

  CustomLog /var/log/apache2/humboldtwiki-access.log combined
</VirtualHost>

We're almost done.  Now we need to create a symlink in Apache's "sites-enabled" directory, to the config file we just created.  After that, we'll need to restart Apache.  At the shell prompt, enter the following commands:

cd /etc/apache2/sites-enabled
sudo ln -s ../sites-available/humboldtwiki.conf .
sudo service apache2 restart

Voilà!  Now you're serving up a MoinMoin wiki site, using Apache and mod_wsgi!

However, if you plan on keeping data sensitive wiki pages, you'll want to force https on the users.  If you're interested in using https with MoinMoin, check out Part 2 of Ubuntu 14 and Apache and MoinMoin! Oh my!

Fixing NIS Client/AutoFS Login Permission Error

Greetings, weary tech[no] traveler!

So...you've decided to make that shinny, new Ubuntu 12.04 server of yours into an NIS client.  You've gone through all the necessary steps to install and set up NIS, AutoFS, and NFS.  Yet for some reason (which will be made obvious soon), neither you nor anyone else with NIS credentials can:

1. Edit, delete, create, or copy any files they owned before NIS was set up.
2. Get their home directory (for example: /home/username) auto-mounted.

All they get is this error message (seen below) at the command line:

Could not chdir to home directory /home/username: Permission denied
-bash: /home/username/.bash_profile: Permission denied

Permission denied?!  What gives, brah?

Let's check the permissions of all the home directories.  At the command line, run the following command:

ls -l /home

You will get output that will look similar to this:

drwx--S--- 15 username username 4096 Dec 31 15:04 username/
                             :
                             :
                             :

Apparently, the permissions on the home directory are restrictive such that there are no read, write, or execute bits for group (g+rwx).  Since username (in your case might be something different) is most likely not a valid NIS group (depending on how you set up your NIS groups), there's no way you'll be able to access your home directory; let alone auto-mount it.

Let's check and compare one other thing; the User IDs (UID) of username on the NIS server we are trying to authenticate with and on our troublesome NIS client.   Alternatively, if you do not have access to the NIS server, you can check the UID of username on another NIS client that does work.  At the command line of both machines, run the following command:

getent passwd username

The output from our troublesome NIS client will look similar to this:

username:x:1000:1000:username,,,:/home/username:/bin/bash

The output from the same command, ran on our NIS server (or working NIS client), will look similar to this:

username:x:34528:1000:username,,,:/home/username:/bin/bash

Notice how the UIDs are different.  The UID, of username, on the NIS server is (in this case) 34528.  Whereas on our NIS client, the UID is 1000.  The UIDs of username do not match and they must be changed so that they do. Plus, the group called username, which is local to our troublesome NIS client must be deleted as well.  Otherwise, the local group (username) will be used instead of the appropriate group that is provided by our NIS server.

Before we start making changes to important files, let's back them up first.  Just in case!

sudo cp /etc/passwd /etc/passwd_BACKUP
sudo cp /etc/group /etc/group_BACKUP

Now, let's fix this problem. 

1. sudo vim /etc/passwd [Personally, I like to use vim.  However, you can user whatever text editor your like.]
2. Locate the line for the username in question.  In this case, it's username.
3. Edit the UID of username so that it matches the UID of username from our NIS server.  In this case, the UID of 1000 should be changed to 34528.
4. Save and exit your text editor. 
5. Back at the command line, edit /etc/group:  sudo vim /etc/group
6. Locate the line for the username group.  It should look like this:  username:x:1000:
7. Delete this line.
8. Save and exit your text editor.
9. Reboot your NIS client:   sudo shutdown -r now

Once you have rebooted your NIS client, log into it.  To verify that our changes fixed the problem, check if you're currently in your home directory by running pwd at the command line.  Next, run ls -l.  Your files in your home directory should no longer be apart of the old username group.