Archive for November, 2011
As anybody who has used Canonical’s wildly popular Linux distribution, Ubuntu, you know that you automatically get 5GB of complementary cloud space on Ubuntu One, Canonical’s cloud service. If you want more than that, you obviously have to pay, but 5GB of cloud data can be very useful, especially now that the Windows Ubuntu One client is out. Perhaps I’ve just got used to using Google’s Chrome so much with it’s marvellous bookmark sync that I’ve been seeing the benefits of having a little data everywhere. Love it or hate it, having a Windows client makes Ubuntu One even more useful. There’s even an Android client available.
So, a dash of data in cloud. Nice. However, I’m still not trusting enough to keep important information in the cloud without a little encryption. Ironic I know, since I have a Google account and GMail tied to my Android phone and all that. But I’ve got Gmail backed up to my server and so, while I now feel I own my Google data (or at least have it backed up safely), there’s really not much you can to to protect yourself from Google itself :-)
Anyway, I digress. As I said, Ubuntu One is pretty useful now it’s multi-platform but if I’m going to store things on there, it’s nice to throw in a little encryption just to be safe. This is different to using something like LUKS encryption, because this works on a partition level, much lower than just dealing with files that you want to transfer. Even a useful encryption tool like TrueCrypt works by preparing a volume container for files, which while very good with a bunch of nice features, is not very handy for storing files on Ubuntu One.
Luckily, Ubuntu (and every other Linux out there) has a portable, standardised method for file encryption, OpenSSL. Here’s how to use it to encrypt your files before launching them off to Ubuntu One.
openssl aes-256-cbc -a -salt -in [UNENCRYPTED_INPUT_FILE_NAME] -out [ENCRYPTED_OUTPUT_FILE_NAME]
This will provide you with a standard AES 256-bit encryption scheme for your file. OpenSSL will prompt you for a pass-phrase, so be as creative as you are paranoid :-) The “aes-256-cbc” parameter specifies the use of 256-bit AES as the cipher and the “-salt” parameter adds a salt to the encryption setup for added security which helps foil dictionary attacks.
As long as somebody knows the pass-phrase (hopefully just you!), they can decrypt the file by using:-
openssl aes-256-cbc -d -a -in [ENCRYPTED_INPUT_FILE_NAME] -out [DECRYPTED_OUTPUT_FILE_NAME]
If you want to do this on the Windows side of things, you can use the Windows OpenSSL software as well. There you go – encryption for everybody :-)
If you want to encrypt a large number of files at once, you can always tar or zip then up first with (under Linux at least):-
tar -cf [TAR_FILE_NAME].tar [DIRECTORY_WITH_FILES_TO_TAR]
…and then use gzip to make the files a bit smaller before encrypting them. I don’t encrypt everything of course but it’s nice to have the option.
UPDATE 05/01/2012: There is now also an iOS Ubuntu One client available for Apple fans. I think Ubuntu One now has a client for pretty much every platform. Good going Canonical :D
If you have many Fedora (or any Red Hat based) systems, updating them all via yum separately means that you’re going to be downloading an awful lot of duplicated updates. Also, in some organisations, they will have a local yum repository for officially sanctioned updates so that it doesn’t break bespoke software that relies on specific versions of software packages. Here I’ll show you how to create your own local yum repository on your network via the Apache web server which you can then use for all the machines on your network – the point being that the updates are downloaded from a master server only once, thus saving you time and bandwidth.
First off, you’ll need to make you you have the Apache web server installed and running on the server you want to use as a yum repository. If it is, you can skip to the next part. If not or you’re not sure, install it with: -
yum install httpd
Set the httpd daemon to run with:-
service httpd start
This assumes that you now have your HTML document root at “/var/www/html”, which is the default. Also, if you have a firewall like iptables running you’ll need to open port 80 to allow HTTP traffic through.
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
You can verify the port is open with:-
which should show you something like:-
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http
The next thing to do is to create the directory structure required by yum to hold the packages. Create the following directories with:-
You’ll also need your Fedora installation CD for this next part. We’re going to copy the all the installation packages over. You can either use an installation CD/DVD or you can simply mount the ISO file you no doubt downloaded from the Fedora website. If you want to mount the ISO file, you can use:-
mount -o loop -t iso9660 /path/to/your/iso/file /mnt/iso
This will mount your ISO image at the /mnt/iso mount point directory – although the iso sub-directory must exist first, obviously. If not, create it.
The packages you want will be under “Packages” on the CD/DVD or mount point, so copy them to the “/var/www/html/yum/base” sub-directory you created earlier. Assuming you’re using a mount point of “/mnt/iso”, you’d use:-
cp /mnt/iso/Packages/* /var/www/html/yum/base
Next you need to create the base repository headers. For this, you’ll need a small utility called “createrepo”. It’s usually installed by default under Fedora, but if you’re using another Red Hat based distribution or it isn’t installed, install it with:-
yum install createrepo
After that, run:-
This may take some time, depending on your system hardware specifications, but eventually you should end up with a sub-directory from there called “repodata”. If you do an “ls” on that directory, you should see files that look something like the following:-
These are your repository header files. Okay, now you need to select an external mirror site for all the Fedora update packages. We’re going to use rsync (which I’ve covered before to sync backups across servers) to sync our local repository to an externally maintained Fedora repository. You can find a list of public mirror sites for your country and Fedora version here. Make sure the mirror site you choose supports rsync and not just HTTP or FTP else the following won’t work and you’ll have to use something like the “wget” command to copy over all the updated packages. Clearly “rsync” is better in this situation. For the sake of this post, I’m going to assume you’re in the United Kingdom and are using Fedora 15 on 64-bit systems. To sync your repository with the example one based on the above requirements, I’d use the command:-
rsync -av rsync://mirror.bytemark.co.uk/fedora/linux/updates/15/x86_64/ -exclude=debug/ /var/www/html/yum/updates
This example is using rsync to sync our local yum update directory with a Fedora mirror site maintained by Bytemark in the UK for 64-bit Fedora systems. Now would be a good time to create a daily cron job to keep your local repository in sync with the external one, so enter your crontab with:-
and add the following line (or whatever you want, assuming you’re familiar with using cron jobs):-
0 0 * * * rsync -av --delete rsync://mirror.bytemark.co.uk/fedora/linux/updates/15/x86_64/ -exclude=debug/ /var/www/html/yum/upates
Save this by typing “:wq” This will update your repository every night at midnight. I’ve also added the delete flag in order to save space so that source and destination match. Use “man rsync” if you want more information on this.
Lastly you’ll need to configure yum on your servers that you want to be updated via yum to point to your new yum update repository. While you can add this to “/etc/yum.conf”, it’s recommended that you add a separate .repo file under “/etc/yum.repos.d”. So create a new .repo file with:-
and add the following information:-
name=Fedora Released Updates
name=Fedora - Base
If you want to use environment variables to get the Fedora version and architecture, see here. Replace the “192.168.1.3″ IP address with the IP address of your repository server. That’s it – add this file to each Fedora server you want to update locally and you’re good to go :-)