Tag Archives: slackware

Encrypting a Linux home partition with Truecrypt

Scope:

This post will be short (and sweet). We will secure the majority of our personal data by encrypting our home partition. This is important for users with personal or sensitive data on their laptops, as well as other mobile devices such as the Google Nexus 7 when it runs Ubuntu Linux.

General Information:

The steps to encrypt a partition with Truecrypt are probably the easiest ones compared to alternatives such as LUKS and other Linux Kernel built in tools. This involves installing Truecrypt, creating an encrypted partition, copying all the sensitive data into it, deleting the sensitive data from the unencrypted partition it was previously on, and configuring mounting and umounting of the Truecrypt volume during startup/shutdown. You will need to perform this as the root user, and you will need an empty partition which you can encrypt. The steps are generic: they assume you are encrypting a brand new home partition (and not something else), after storing your user data under the /home folder on the root partition. They have been tested on Slackware64 but will work on all Linux distributions. Please adjust the partitions, runlevel scripts and installation procedure for your Linux distribution (as an example, for Ubuntu, Truecrypt might be available via Aptitude repositories vs. a binary installation package, and the runlevels will not be in traditional BSD style).

Procedure:

  1. Install Truecrypt after downloading from here:
    # tar vxf ./truecrypt-7.1a-linux-x64.tar.gz
    # ./truecrypt-7.1a-setup-x64
  2. Create an encrypted Truecrypt partition. You will be asked about the partition, passwords and keyfiles to use:
    # truecrypt --text --create
  3. Mount the new encrypted volume in a temporary location and copy all sensitive data to it. This should be done as root from singleuser runlevel if operating on the /home folder:
    # telinit 1
    # mkdir /tmp/encrypted
    # /usr/bin/truecrypt --text --mount --protect-hidden=no --volume-type=normal --keyfiles= /dev/sda6 /tmp/encrypted
    # cp -aR --preserve=all /home/* /tmp/encrypted/
    # rm -rf /home/*
  4. Configure mounting/unmounting on startup/shutdown:
    Edit /etc/rc.d/rc.S and add the following line after “/sbin/mount -a …”:

    /usr/bin/truecrypt --text --mount --protect-hidden=no --volume-type=normal --keyfiles= /dev/sda6 /home

    Edit /etc/rc.d/rc.6 and add the following line before “/sbin/umount -a …”:

    /usr/bin/truecrypt --text --dismount /dev/sda6
  5. Test with a reboot!

1 Comment

Filed under #!, Slackware

Slackware 13.37 and the ASUS PCE-N13 Wireless Adapter

ASUS PCE-N13

The ASUS PCE-N13 is not especially pretty, but its cheap, fast, and officially supported!

If you are on the market for a wireless adapter for your Linux desktop, the best bang for the buck today seems to be the ASUS PCE-N13. Not only will ~30$ get you a/b/g/n support, 300Mbps transfer rates, 2 antennas and a PCIe bus, but it also says “Linux Support” right on the box, and not in some fine print in an obscure corner. The only card in my local shop to read that, although all of them work just fine. So this is a *moral* choice as well 😉

The card is indeed supported by the rt2860sta module. Unfortunately, with Both Slackware 13.37 and Ubuntu 10.10, the kernel module fails to bind to the card because the various rt2800 and rt2x00 modules conflict with rt2860sta. The module loads, but all attempts to initialize the card result in error messages. To remedy this, simply blacklist the other modules from loading by adding those modules to /etc/modprobe.d/blacklist.conf like this:

# Blacklist rt2800 and rt2x00 modules
# This will allow the rt2860sta module to bind to the ASUS PCE-N13 card:
blacklist rt2800lib
blacklist rt2800pci
blacklist rt2x00lib
blacklist rt2x00pci

2 Comments

Filed under Slackware

A Linux Tablet PC – Slackware 13 on the HP Pavilion tx2500

This post is a brief summary of how to get your Linux running on a tablet PC. We’ll be using the HP Pavilion tx2500 and Slackware13. These steps can be adapted for other tablets. They should be easier on distribution such as OpenSUSE or Ubuntu, where a lot of the system configuration is done automatically behind the scenes. Overall, you may find they all worked for you with minimal tweaking, or, that you could use one or 2 bits to help you where you got stuck.

This document will cover the ‘few’ bits that do not work out of the box with a pure GNU/Linux, mostly due to them being propriety hardware: Graphics (FGLRX), WiFi (Broadcom), Touch/Stylus (Wacom), Touchpad (Synaptics) and Sound (Intel HD). This how-to should leave you with a fully working tablet, minus a fingerprint reader.

1. ATi’s FGLRX:

ATi’s Radeon 3200 is a propriety chip-set, but the ATi drivers outweigh their open-source brother when it comes to 3D performance. Download the latest FGLRX driver from ATi, make the binary executable, and run it with the ‘–buildpkg Slackware/All’ flag. This will create a .txz package you can install with pkgtool. Run ‘aticonfig –initial’ and ‘ldconfig’ as root, and reboot. If FGLRX is not loaded, ‘modprobe fglrx’.

2. Broadcom’s WL:

Well, what can we say, Broadcom’s 4328 R3 wireless chip-set is also propriety hardware. To get your WiFi working, download the latest Linux STA 802.11 driver from Broadcom, unpack and compile with ‘make’. You must unload the ‘ssb’ module (if loaded), and you must load ‘lib80211_crypt_tkip’, before you may load the newly built wl.ko module with ‘insmod /path/to/wl.ko’.

3. Stylus/Touch and Touchpad

This part is not much different in practice, but very different in essence – we’ll be using opensource drivers from the Linux Wacom project. Download the latest LinuxWacom version from the Linux Wacom Project, and build with X.org support. Then place the HAL and UDEV rules along with the xorg driver at their designated locations:

$ ./configure --enable-wacom
$ ./make
# ./make install
# cp src/xdrv/wacom_drv.so  /usr/lib64/Xorg/modules/drivers/wacom_drv.so
# cp src/util/10-linuxwacom.fdi /etc/hal/fdi/policy/10-linuxwacom.fdi
# cp src/util/60-wacom.rules /etc/udev/rules.d/60-wacom.rules
# cp src/2.6.27/wacom.ko /opt/

Load the new module you made:

# insmod /opt/wacom.ko

Now, we have to modify /etc/X11/xorg.conf to let it know about those new inputs by adding new ‘InputDevice’ sections and adding them to ‘ServerLayout’. This involves identifying the correct /dev/input/event# for the touch, stylus and eraser. You can do it by watching the dump from each event file while (read: at the same time as) you  send input events by dragging the pen across the screen:

# cat /dev/input/event8

If you are running into difficulties with your xorg.conf, you can use this file for refrence: HP_Pavilion_tx2500.xorg.conf

Calibrate your tablet with ‘xwacomcpl’. Download and compile CellWriter for handwriting recognition.

Screen Rotation script:

Since this is a tablet, screen rotation is pretty handy. Because we’re using Wacom modules, we will also need to change the oriantation of the wacom devices. Basicaly, xrandr can be used in conjunction with xsetwacom to rotate the tablet and the screen together. Here’s how it works – the following lines will rotate everything “right”:

# xrandr -o right
# xsetwacom set WacomTouch rotate 1
# xsetwacom set WacomStylus rotate 1
# xsetwacom set WacomEraser rotate 1

You have to match the device name to the device identifier in xorg.conf, and use the right path for xsetwacom. Instead of “right” for xrandr you may use “left” “inverted” or “normal”, and instead of “rotate 1” for xsetwacom you may use 0 for normal, 2 for left and 3 for inverted. Most people script this together into something, like the example I made here: wacom_rotate.sh

4. Sound

This was the easiest bit to get working. All it took, is running alsaconf, and selecting the ‘snd-hda-intel’ option.

5. Automate

The easiest way is usually to put all the stuff that is not scripted on its own into ‘/etc/rc.d/rc.local’, or for some distribution ‘/etc/rc.local’ (That would probably include loading ‘wl.ko’ and ‘wacom.ko’).

I hope you found this helpful. Leave comments, or ask for help if you crashed your Linux following these instructions 😉

7 Comments

Filed under #!, Slackware

RAID for Everyone – Faster Linux with mdadm and XFS

I crashed my Linux. It took a lot of skill and root access, but I’ve accidentally hosed my desktop and backtracking will be more time consuming than running through a quick Slackware install. If you find yourself in this situation, and have more than one drive on your machine, it makes sense to RAID the drives. RAID will either greatly increase performance for the drives, which are the bottleneck of any desktop, or mirror the drives for disk failure protection. To read more about RAID, which becomes more and more popular, try The Linux Software RAID How To.

This quick how-to will try to cover the basics, but all the basics, needed to install any Linux Desktop distribution on any machine with 2 or more drives. It begins with installing a Linux system on a RAID1 partition, and continues with adding a RAID0 home partition after the install. For the home partition, XFS will be used as a file-system, and tweaked to illustrate some of its strengths with RAID. Finally, It’ll cover replacing a failed drive in an array. Any bits of it will try to be relevant to other scenarios. Mostly, it will attempt to demonstrate how simple it is to administer RAID arrays with mdadm.

Why software RAID (mdadm)? Chances are, your motherboard already comes with an on-board RAID controller. Those are present on motherboards as cheap as 60$. I won’t be using mine, however, and this tutorial will not cover that part. I had the most miserable experience with my ATI on-board RAID, which is a propriety chipset, working out of the box only with SuSE, and failing drives left, right and center. Even if your lucky to have a decent Linux supported controller, you will still have a hard time finding a decent interface for the firmware, the options will be lacking at best, and you will not find RAID 5 and 6 options on motherboards or low end cards. You will also have no cheap way to recover data from failed controllers, spare buying the same hardware again. Propriety software cards are not even worth mentioning. Since the CPU penalty for software RAID is fairly low on modern chips, and all Linux distributions supports mdadm out of the box, that’s what I recommend.

Why Slackware? I’ll be using Slackware 13 because that’s what I like, and because Slackware install CD gives the most partitioning freedom (read: a console with all the console-tools) before the install. But this will work on anything Linux. Here it goes:

1.  What you need:

Get a Slackware CD/DVD ready, or any Linux installation CD from which you can access a console before the installation starts. Live CDs are great! Backup your data. No, really, do it now. And we assume you have at least 2 drives installed. The size does not have to be identical, but the partition layout will be limited to that possible on the smallest of the drives.

2. BIOS:

Reboot with the Linux installation CD in the drive. In your BIOS, make sure the RAID controller is off (and that you can boot from CD/DVD).

3. Partition Drives:

Boot the CD/DVD and get to a console. Slackware just takes you to one on its own, from a Debian DVD one can access an alternative console with Alt+F2, etc, and in a LiveCD there’s probably a terminal program. Pull one up. Log in as root, or do everything with $ sudo. Here goes the destructive part. Identify the drives you’ll use with

# fdisk -l

This examples uses /dev/sda and /dev/sdb. We also assume you have no active RAID arrays on the drives you manipulate. If you do, stop them:

# mdadm --manage --stop /dev/md0

Create parition tables on drives:

# cfdisk /dev/sda

delete all partitions. Create a Swap type partition (one of two) and a Linux Raid Autodetect type partition. Write and exit. repeat on other drive(s) with the same sizes for both partitions. Note that you do not have to use the entire space right away. In this case, we will setup a root file system on a mirrored partition, for redundancy and ease with bootloaders as most recommend. Only later we’ll attach a striped (for size and speed) home partition.

4. RAID the drives:

mdadm is our weapon of choice. It’s mighty but simple. Here’s a RAID1 (mirrored) device /dev/md0, using /dev/sda2 and /dev/sdb2 (assuming /dev/sda1 and sdb1 were used for swap):

# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2

Now, RAID1 drives will take some time to rebuild (sync the mirror), depending on your partition size. I’ve seen 20GB partitions rebuilt in 15 minutes and 500GB partitions go for almost 2 hours over 2 7,200 RPM SATA drives. You can tell what the status is by glancing at /proc/mdstat:

# cat /proc/mdstat

Wait for the array to rebuild before proceeding. Many corners of the internet, including this one in the past, suggested you had to wait for an mdadm array to rebuild before using it. However logical this sounds, in reality, “the reconstruction process is transparent, so you can actually use the device even though the mirror is currently under reconstruction”, and we can move right along regardless of the type of RAID we chose:

5. Start Linux install and choose /dev/md0 as your root partition. Install the OS.

6. Setting up a RAID home partition, or any other partition, is not much more complicated. We’ll use RAID 0 for home, because of the volume it provides, as well as the speed performance. We’ll be using /dev/sda3 and /dev/sdb3 for a mirrored RAID. So head over to the terminal:

# cfdisk /dev/sda3

partition as you wish, type Linux RAID Autodetect, and repeat with /dev/sdb3. Make sure the partition sizes match.

7. Set up RAID:

This is a simple striped setup across 2 partitions

# mdadm --create /dev/md1 --level=0 --chunk=256 --raid-devices=2 /dev/sda3 /dev/sdb3

here, we had to specify the RAID 0 chunk, which is the stripe size, in addition to the options we used with RAID 1. The optimal chunk size depends entirely on your primary usage.

8. Setup a file-system:

You can use anything and just skip this section, but XFS has special tweaking for RAID, and its worth taking advantage of them for performance. XFS allows specifying the partition RAID dimensions to the file-system, and takes them into consideration with file reads/writes, to match the operations. 2 parametrs are used with XFS upon creation and mounting: sunit, which is the size of each chunk in 512byte blocks, and swidth, which is sunit * amount-of-drives (…for RAID 0 and 1; that minus 1 for RAID 5; or that minus 2 for RAID 6). More about RAID and XFS can be found here. To create a matching XFS file-system:

# mkfs.xfs -d sunit=512, swidth=1024 /dev/md1

9. Move home to its new home.

To quickly move the contents of the old /home directory to the new RAID partition, simply rename the old home, create a new home, mount, and copy stuff over. We’ll put an entry in fstab to mount the file-system properly, and with no access time logging, to get the performance boost. All of this must to be done as root with all other users logged out. (If home was on a separate partition already, you must unmount it and remount it as something else rather than moving it):

# mv /home /home.old
# mkdir /home
# echo "/dev/md0     /home     xfs     noatime,sunit=512,swidth=1024    0    2" >> /etc/fstab
# mount /home
# cp -aR --preserve=all /home.old/* /home
# rm -rf /home.old

10. Thats it for the setup. Now, lets give our new RAID array a real test drive.

We can check the status of all our arrays with:

# cat /proc/mdstat

We can monitor RAID1 arrays (but not RAID0) with:

# mdadm --monitor --oneshot /dev/md0

But the most rewarding bit will be performing some speed tests with hdparm. Lets check on a speed performance of a single drive:

# hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads:  366 MB in  3.01 seconds = 121.45 MB/sec

Compare this to the speed of our RAID 0 array:

# hdparm -t /dev/md1
/dev/md1:
 Timing buffered disk reads:  622 MB in  3.01 seconds = 206.71 MB/sec

Yup, that’s right folks — the speed on a 2 drive RAID 0 array is twice as high. That being expected, it is by no means less satisfying 😉

Bonus: Recovering a failed drive from a RAID1 array. This will be handy for your root partition. Needless to say, you will not be able to recover anything from your RAID0, because it has 0 redundancy. With RAID1, however, the machine just keeps humming along after a drive gave up. How will you know you have a failed drive then? If the drive failed partially (repeatedly failing on some seeks but not on all), you will notice your performance degrade. You can test for performance degradation even before it becomes severe, with hdparm as explained above. If the drive failed totally, you might not notice.  It’s good to occasionally peak at /proc/mdstat to see that the array is up. In this case, the fix is easy – just pop in a new drive when the system is off. However, if you have a partially failed drive in a RAID1 array and you do not wish to wait for a reboot (very reasonable on a server that keeps working, if you could just avoid the horrible seek delays for the failing drive), you could drop it yourself in 2 commands.

My /dev/md0 is a RAID1 array which is made of /dev/sda2 and /dev/sdb2.  In my case, it was easy to see the drive  access light throwing fits, and the desktop freezing occasionally, indicating a problem with the drives. A quick run of hdparm revealed that /dev/sdb was the failing drive, as it displayed much slower reads. It caused the file-system on /dev/sdb2 to be barley accessible, which slowed my RAID1 array during writes (reads were still fast because they could be completed from the good drive alone, but writes needed to happen on both drives). So as soon as I got my desktop back from an occasional freeze, I fired up a terminal, marked the drive in the array as failed, and removed it from the array:

# mdadm --manage /dev/md0 --fail /dev/sdb2
# mdadm --manage /dev/md0 --remove /dev/sdb2

Past that point, its just a matter of powering off and replacing the drive at your earliest convenience. Once you got a new drive, pop it in, boot the system up, clone the partition table, and add the new partition to the array:

# sfdisk -d /dev/sda | sfdisk /dev/sdb
# mdadm --manage /dev/md0 --add /dev/sdb2

… watch the array rebuild itself by looking at /proc/mdstat , and you’re done. Phew. 🙂

I hope the minimal amount of code and steps will demonstrate how easy it is for any person with 2 hard drives to enjoy the benefits of RAID, which will make your Linux Desktop even faster/safer, without investing any significant amount of time or money.

7 Comments

Filed under #!