Friday, February 6, 2009

Once upon a time, there was a driver

For reasons known and unknown, I downgraded from Vista back to Windows XP Pro. In the meantime, I looked for audio drivers for my ASUS P5N32-E SLI board, sporting the Soundmax SupremeFX ADI 1988B chipset. However, the drivers on Asus's site still don't support 5.1 output; who'da thunk it? What happens is, in the sound test, only the front left, front right, and sub channels work. The surround speakers and center speaker don't. Only some savvy research and our friends at techreport.com saved us. At the following link:

http://techreport.com/articles.x/11212/4

We are given the hint at the middle of the second paragraph:

"However, a set of AD1988B codec drivers on the driver CD for Asus's M2N32-SLI Deluxe motherboard worked flawlessly on the P5N32-SLI Premium"

So I went to the M2N32-SLI Deluxe driver site. And it worked. And it was good.

For future reference (just in case ASUS decides to reenter the hell it oh-so-assuredly deserves), the driver can also be found here, as long as I can hope to keep it there.

Hopefully this helps someone out there from banging their head against the wall trying to figure this out.

Wednesday, January 21, 2009

Encrypting a file system on Centos 5.2

While these instructions show you how to make a file into a file system by using a mapping from /dev/object to file (like /dev/loop0), you can forgo the mapping for just creating an encrypted file system on a /dev/device directly (like /dev/sdb), or also on a /dev/partition, if you so choose (like /dev/sdb1).

A NOTE BEFORE YOU BEGIN!

To create a valid keyfile for Centos 5.2 cryptsetup for use in crypttab (like how I’m keyword fishing here?), you must not have an explicit newline at the end of the keyfile. VIM AUTOMAGICALLY APPENDS A NEWLINE TO THE END OF ALL YOUR FILES. Imagine that. Instead you should do the following:

echo -n “password” > keyfile.key

This makes a one line fine with your password in there without an explicit newline at the end. This I figured out by searching, in this order:

cryptsetup keyfile
hashalot
hashalot cryptsetup

which finally let to an answer in an obscure mailing list archive. FFS, irc channel help really is just a great way of getting pissed off first thing in the morning. Which is to say that they’re one or two steps above useless. At least this is what I have found so far.

On to the meat of the post.


Linux Encrypted Filesystem with dm-crypt

An encrypted filesystem will protect against bare-metal attacks against a hard drive. Anyone getting their hands on the drive would have to use brute force to guess the encryption key, a substantial hindrance to getting at your data.

Windows and Mac OS X each provide its own standard cryptofs tools while Linux, of course, provides many tools to accomplish the task. The tool of choice these days, it seems, is dm-crypt. Invoked with the userspace cryptsetup utility, dm-crypt provides a fairly clean and easy-to-use cryptofs tool for Linux.

Additionally, CentOS 5 includes an improved version of dm-crypt that supports LUKS. LUKS is an upcoming standard for an on-disk representation of information about encrypted volumes. Meta-data about encrypted data is stored in the partition header, and allows for compatiblity between different systems and support for multiple user passwords. Besides that, GNOME and HAL have support for handling LUKS volumes, and can automatically prompt for a password if a removable medium with a LUKS volume is attached. If you do not require compatiblity with older CentOS versions or systems that do not support LUKS, it is advised to use the LUKS scheme. The commands for setting up encrypted LUKS volumes are also described in the examples in this article.

Here are Scripts to automate creation, un-mounting, and remounting of LUKS encrypted filesystems following the method described below.

Required Packages

Before getting started, make sure all the requisite packages are installed:

* cryptsetup (cryptsetup-luks for CentOS-5)
* device-mapper
* util-linux

It's likely, however, that they're already present on your system, unless you performed a very minimal installation.

Initial FS Creation

I typically encrypt files, not whole partitions, so I combine dm-crypt with the losetup loopback device maintenance tool. In the bare language of the Unix shell, here are the steps to create and mount an encrypted filesystem.

# Create an empty file sized to suit your needs. The one created
# in this example will be a sparse file of 8GB, meaning that no
# real blocks are written. Since we will force block allocation
# lateron, it would not make much sense to do this now, since
# the blocks will be rewritten anyway.
dd of=/path/to/secretfs bs=1G count=0 seek=8
# Lock down normal access to the file
chmod 600 /path/to/secretfs
# Associate a loopback device with the file
losetup /dev/loop0 /path/to/secretfs
# Encrypt storage in the device. cryptsetup will use the Linux
# device mapper to create, in this case, /dev/mapper/secretfs.
# The -y option specifies that you'll be prompted to type the
# passphrase twice (once for verification).
cryptsetup -y create secretfs /dev/loop0
# Or, if you want to use LUKS, you should use the following two
# commands (optionally with additional) parameters. The first
# command initializes the volume, and sets an initial key. The
# second command opens the partition, and creates a mapping
# (in this case /dev/mapper/secretfs).
cryptsetup -y luksFormat /dev/loop0
cryptsetup luksOpen /dev/loop0 secretfs
# Check its status (optional)
cryptsetup status secretfs
# Now, we will write zeros to the new encrypted device. This
# will force the allocation of data blocks. And since the zeros
# are encrypted, this will look like random data to the outside
# world, making it nearly impossible to track down encrypted
# data blocks if someone gains access to the file that holds
# the encrypted filesystem.
dd if=/dev/zero of=/dev/mapper/secretfs
# Create a filesystem and verify its status
mke2fs -j -O dir_index /dev/mapper/secretfs
tune2fs -l /dev/mapper/secretfs
# Mount the new filesystem in a convenient location
mkdir /mnt/cryptofs/secretfs
mount /dev/mapper/secretfs /mnt/cryptofs/secretfs

Unmount and Secure Filesystem

To unmount and secure the encrypted filesystem manually, you essentially do the last part of the set instructions in reverse.

# Unmount the filesystem
umount /mnt/cryptofs/secretfs
# Remove device mapping
cryptsetup remove secretfs
# Or, for a LUKS volume
cryptsetup luksClose secretfs
# Disassociate file from loopback device
losetup -d /dev/loop0

Remount Encrypted Filesystem

Once you've created an encrypted filesystem, remounting it is a relatively short process:

# Associate a loopback device with the file
losetup /dev/loop0 /path/to/secretfs
# Encrypt mapped device; you'll be prompted for the password
cryptsetup create secretfs /dev/loop0
# Or, for a LUKS volume
cryptsetup luksOpen /dev/loop0 secretfs
# Mount the filesystem
mount /dev/mapper/secretfs /mnt/cryptofs/secretfs

Note that cryptsetup will not provide a useful error message if you mistype the passphrase. All you'll get is a somewhat unhelpful message from mount:

*

mount: you must specify the filesystem type

If that happens, then recycle cryptsetup and try mounting the filesystem again:

cryptsetup remove secretfs
cryptsetup create secretfs /dev/loop0
mount /dev/mapper/secretfs /mnt/cryptofs/secretfs

This does not apply to LUKS volumes, where cryptsetup will provide a useful error message during the luksOpen step.

Adding additional keys to a LUKS volume

As mentioned earlier, the LUKS format allows for the use of multiple keys. This means that you can add more than one key that can be used to open the encrypted device. Adding a key can simply be done with:

cryptsetup luksAddKey <device>

For instance, if you use the /dev/loop0 loopback device, you could execute:

cryptsetup luksAddKey /dev/loop0

cryptsetup will ask you to enter one of the existing passphrases twice. After that you will be asked to enter the additional key twice. When this step is also succesfully completed, you can use the existing key(s), and the new key to open the volume.

Setting up encrypted volumes during system boot

Sometimes you may want to set up encrypted volumes during the system boot, for instance, to set up an encrypted home partition for a laptop. This can be done easily on CentOS 5 through /etc/crypttab. /etc/crypttab describes encrypted volumes and partitions for which a mapping should be set up during the system boot. Entries are separated by a newline, and contain the following fields:

mappingname devicename password_file_path options

Though, normally you don't need all four fields:

*

Most of the possible options for the options field are ignored for LUKS volumes, because LUKS volumes have all the necessary information about the cipher, key size, and hash in the volume header. Second,
*

Normally, you don't want to store a password file in plain text on the root partition. It's certainly possible to store it somewhere else, but at this boot stage in rc.sysinit only the root partition is normally mounted read-only. If the password field is not present, or has the value none, the system will prompt for the password during the system boot.

So, if you are using a LUKS volume and would like to prompt the system for a password, only the first two fields are required. Let's look at a short example:

cryptedHome /dev/sdc5

This creates a mapping named cryptedHome for an encrypted volume that was previously created on /dev/sdc5 with crypsetup luksFormat /dev/sdc5. If you have also created a filesystem on the encrypted volume, you can also add an /etc/fstab entry to mount the filesystem during the system boot:

/dev/mapper/cryptedHome /home ext3 defaults 1 2

There are two options that are not ignored for LUKS partitions:

*

swap: the volume will be formatted as a swap partition after a mapping is set up.
*

tmp: the volume will be formatted as an ext2 filesystem, with permissions set up correctly to be used as a filesystem for temporary files.

Both options require that there are entries for using the mapping in /etc/fstab, and both options are destructive. An entry for an encrypted swap partition could look like this:

cryptedSwap /dev/sda2 none swap

Or if you do not want to type a password for the swap partition during every boot:

cryptedSwap /dev/sda2 /dev/urandom swap

Note that this will not work if /dev/sda2 already is a LUKS partition, because LUKS partitions require a non-random key.

From:
http://wiki.centos.org/HowTos/EncryptedFilesystem?action=show&redirect=TipsAndTricks%2FEncryptedFilesystem

PDF:
http://csua.berkeley.edu/~vaheder/blogpdf/vahederBlogspotCom/encryptcentos52.pdf

Friday, January 16, 2009

How to disable selinux in Centos 5.2 and enable mysql server on startup

Quick ones.

10 MySQL (5.0)

To install MySQL, we do this:

yum install mysql mysql-devel mysql-server

Then we create the system startup links for MySQL (so that MySQL starts automatically whenever the system boots) and start the MySQL server:

chkconfig --levels 235 mysqld on
/etc/init.d/mysqld start

Now check that networking is enabled. Run

netstat -tap | grep mysql

And

How to disable SElinux in CentOS 5
[Tuesday, January 22, 2008 | 1 comments ]

How to disable SElinux in CentOS 5

What is SElinux ?

SELinux introduces Mandatory access control (MAC) in Linux. Using MAC, system administrator can create a mandatory policy that limits what access a particular process may be granted to an object.

You are running CentOS and you aren't sure if you have SElinux enabled or disabled. Here is how you can check if you have SElinux disabled in CentOS 5
Steps to check SElinux in CentOS 5

[root@centos5 ~]# grep SELINUX /etc/selinux/config

# SELINUX= can take one of these three values:

SELINUX=disabled

There is file called config in /etc/selinux which is used to enable/disable SElinux in CentOS:

[root@CentOS 5 ~]# cat /etc/selinux/config

[root@centos5#cat /etc/selinux/config

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

# enforcing - SELinux security policy is enforced.

# permissive - SELinux prints warnings instead of enforcing.

# disabled - SELinux is fully disabled.

SELINUX=disabled

# SELINUXTYPE= type of policy in use. Possible values are:

# targeted - Only targeted network daemons are protected.

# strict - Full SELinux protection.

SELINUXTYPE=targeted

# SETLOCALDEFS= Check local definition changes

SETLOCALDEFS=0

While installing CentOS 5 linux if you haven't paid much attention then chances are you probably have missed window where installation program ask to enable/disable SElinux.

SElinux can run as enforcing or in permissive mode. If in /etc/selinux/config file selinux is set as permissive or enforcing then change it to disabled. You would need to reboot your CentOS server to disable selinux. This change wouldn't work without rebooting your linux box.

--


From:
http://www.howtoforge.com/centos-5.1-server-lamp-email-dns-ftp-ispconfig-p4
http://sysdigg.blogspot.com/2008/01/how-to-disable-selinux-in-centos-5.html

PDFs:
http://csua.berkeley.edu/~vaheder/blogpdf/vahederBlogspotCom/mysqlselinux1.pdf
http://csua.berkeley.edu/~vaheder/blogpdf/vahederBlogspotCom/mysqlselinux2.pdf

How to use, add, and remove svn:ignore

This was pulled from http://www.imarichardson.com/2007/05/26/adding-and-removing-subversion-directories-using-svnignore/

26 May, 2007
Adding and removing subversion directories using svn:ignore

Posted by: imarichardson In: Programming & Development

So I inadvertently added a directory to ignore in subversion only to find out after I deployed (capistrano) that I should not have. So I wrestled around for about 20 minutes when it dawned on me: why not just check the svn help on my box. Nonetheless, here’s what it is:

To add to subversion, use one of the following:

1. imarichardson $ svn propset svn:ignore filename.txt directory/
2. imarichardson $ svn propset svn:ignore "*" directory/

To add in a specific file from a directory, or match a wildcard, respectively. In the second line I’m just using all the contents from the directory.

To remove a directory,

1. imarichardson $ svn propdel svn:ignore directory/

… to delete the svn:ignore reference from the directory.


--

Wasn’t that useful?

Also useful links (hopefully that don’t disappear).
http://stackoverflow.com/questions/414879/how-to-remove-a-file-folder-from-a-svn-repository-and-add-to-ignore-list
http://sdesmedt.wordpress.com/2006/12/10/how-to-make-subversion-ignore-files-and-folders/

As a test (of my dedication), PDFs of the pages in question.

http://csua.berkeley.edu/~vaheder/blogpdf/vahederBlogspotCom/svnignore1.pdf
http://csua.berkeley.edu/~vaheder/blogpdf/vahederBlogspotCom/svnignore2.pdf
http://csua.berkeley.edu/~vaheder/blogpdf/vahederBlogspotCom/svnignore3.pdf

Change of plans

Since I have no time, I’m switching over to use this blog (how green of me) as a resource for little things I come upon that I need for future reference. Hopefully this will help those out there looking for the same information. As a first example: how to use svn:ignore.

By the by, you can find my other ruminations at http://blog.vaheder.com.

Monday, July 21, 2008

Link not, for gone, it will be

I don’t believe in linking certain things, such as instructions, tutorials, or files for tutorials, as things have a tendency of disappearing from the internet. Despite the inherent efficiency in having a single file somewhere “out there” and multiple people linking to it, people inevitably run out of money to host their files, and they fall off the edge of the internet. I have the luck to have a hosting solution that will probably persist until the end of the internet (or until the end of the University of California at Berkeley, whichever comes first), so, besides occasional blackouts, hopefully the files hosted here will persist. If not, I was wrong. Let me know somehow that I was, by email or something. Deal?

One step at a time

In the interest of developing a DS reader equivalent in polish, if not features (pdf rendering might not be something the DS is capable of) to the PSP’s bookr application, I am starting this blog with two goals: to make things easier for others following in the development path (which, especially in regards to setting up the PSP toolchain, is quite difficult), and to provide a web site from which to document and distribute the program (which does not yet have a cute, yet DS-laden title).

Step one. Set up your environment.