dragffy.com

I have a first generation macbook coreduo.

The latest version of Ubuntu (Hardy Heron 8.04 LTS) works very well on it with minimal configuration. However, several issues remain. One of which is the poor sound quality. Initially, installing linux-backports-modules did the trick, however after several reboots it became clear that it didn’t always work. I came across this post, which I followed and the results were outstanding. I have completely copied it here, only to make sure there is another copy of this important document. Full credit for this one goes to the original author. Anyway, here’s what you need to do:

Edit the file /etc/modprobe.d/options
$ sudo vim /etc/modprobe.d/options

And add the following to the end of the file:
options snd-hda-intel model=[MODEL_BELOW] position_fix=2 probe_mask=1

Run the following command:
$ sudo update-initramfs -u

Then reboot.

You must select the Intel HDA model that corresponds to your computer:

These are the codes you can use in the above instructions:
intel-mac-v1 : Intel Mac Type 1
intel-mac-v2 : Intel Mac Type 2
intel-mac-v3 : Intel Mac Type 3
intel-mac-v4 : Intel Mac Type 4
intel-mac-v5 : Intel Mac Type 5
macmini : Intel Mac Mini (equivalent with type 3)
macbook : Intel Mac Book (eq. type 5)
macbook-pro-v1 : Intel Mac Book Pro 1st generation (eq. type 3)
macbook-pro : Intel Mac Book Pro 2nd generation (eq. type 3)
imac-intel : Intel iMac (eq. type 2)
imac-intel-20 : Intel iMac (newer version) (eq. type 3)

For example, I have a Macbook 1st generation, and the only setting that worked was
model=intel-mac-v1. All others just gave me no sound at all, including the apparently
obvious macbook and the documented-as-equivalent macmini ones.

If nothing works, you can revert this by deleting the line and performing the rest of the steps.

For BEST sound, if the above works, open a terminal and type:
$ alsamixer

And set the front and surround sliders to their maximum.
It might be necessary to unmute them with the ‘M’ key.
Press ESC twice to leave the program.

I recently set up a new file server. It contains three 1 terabyte drives configured in a RAID 5 array but with RAID 1 for the boot partitions so in the event of drive failure the system could still boot.

Essentially you need to go through a normal installation process and make sure you choose a couple of things during parition setup. I split each of the 3 drives in to two partitions, one 200MB, and the other partition the remaining disc space. This is what I had:
sda1 = 200MB
sda2 = 9800MB
and the same for the other drives.

Set all sda1 partition to be ext3 and bootable and mounted as /boot, set sdb1 and sdc1 partitions to be Linux Software Raid, bootable, but not mounted. Configure the RAID and create a new RAID device, tell it to use three devices and add to it sda2, sdb2, and sdc2.

When I returned to the partition menu I configured md0 as a partition for a logical volume group. I then configured LVM and created logical volumes for /root, swap, and /home. Returning to the partitioning menu I formatted these and selected their mount points and installed the system.

Following system installation I went about creating a RAID 1 array for sda1, sdb1, and sdc1. First thing was to create a new array using mdadm and the two paritions we haven’t yet assigned:
# mdadm --create /dev/md1 --level=1 --raid-disks=3 missing /dev/sdb1 /dev/sdc1

Make a filesystem on our new RAID device:
# mkfs.ext3 -m 0 /dev/md1

Save the new configuration in to mdadm’s config file:
# mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Edit mdadm.conf and remove the duplicate entry at the bottom:
# vim /etc/mdadm.conf

Mount the new RAID device so we can copy data to it:
# mkdir /media/md1
# mount /dev/md1 /media/md1

Copy over the boot partition to the RAID device:
# cd /boot
# cp -dpRx . /media/md1

Edit fstab and replace /dev/sda1 with /dev/md1:
# vim /etc/fstab

Edit mtab and do the same:
# vim /etc/mtab

Unmount /boot, change it’s system type and add it to the RAID array:
# umount /boot
# fdisk /dev/sda
Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): f
Changed system type of partition 1 to fd (Linux raid autodetect)
Command (m for help): w

# mdadm --add /dev/md1 /dev/sda1

Configure GRUB so that it can boot from any hard drive:
# grub
grub> device (hd0) /dev/sda
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/sdb
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/sdc
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

# update-initramfs -u

Change all occurance of (hd*) to (hd0) in the file /boot/grub/devices.map.

That should be all – good luck with the reboot!
# reboot

Installing Netatalk from the repositories means that when you connect using a Mac client you will be warned that you are going to send your password in the clear. Obviously this isn’t great for security, and being prompted every time you want to connect is annoying. This occurs because Netatalk in the Ubuntu repositories is compiled without SSL support (SSL is what handles the encryption).

The key to getting this to work is to get the Netatalk source code and compile it yourself. Don’t worry, it’s been done hundreds of times before and if you follow this tutorial closely you should be fine.

The commands written always start with a dollar sign ($), you should not type this, it just indicates the commands should be typed at a standard user prompt in the terminal.

First off it’s a good idea to switch to your home directory:
$ cd ~

Make a new directory to hold the hundreds of small Netatalk files:
$ mkdir netatalk

Ensure you have essential development libraries and tools installed:
$ sudo aptitude install libdb4.2-dev libslp-dev autotools-dev devscripts cracklib2-dev dpkg-dev libssl-dev

Change in to the newly created directory:
$ cd netatalk

Install the netatalk source code:
$ sudo apt-get source netatalk

Install all required dependencies for netatalk:
$ sudo apt-get build-dep netatalk

A new directory called netatalk-2.0.3 should have been created, change in to that directory:
$ cd netatalk-2.0.3

Compile Netatalk with the SSL option:
$ DEB_BUILD_OPTIONS=ssl sudo dpkg-buildpackage -us -uc

Install the finished product!:
$ sudo debi

Frustrated at having to create my own drop-down country lists in CI I created a helper for it. It can even work with the CI Validation class, so if the form is submitted and fails validation when it is redisplayed the same country is selected as the form was submitted with.

Download the file MY_form_helper.php and put it in the folder: /system/application/helpers/.

Download the file countries.php and place that in /system/application/config/.

You will now be able to create drop-down lists of countries in your views like this:
< ?=form_countries( 'country', $this->validation->country, array( 'style' => 'width: 250px' ) )?>

Ensure that you create a validation rule called “country” in your controller and that you are loading the form helper.

form_countries() takes three arguments. The first is the name you would like to give the select box, this is required. The second is the country to select by default – this could be something like ‘GB’, or $this->validation->country, otherwise you can leave it blank. The third argument is any additional properties to give the select box, you can leave this blank, or pass an array. In the example above we also set the width to 250x. The country chosen by the user will be returned to the script as a two-letter ISO country code, if you are validating this then you can set the min and max length values as 2, and accept alphabetical characters only. If using MySQL as your database you will get best performance by creating a column of the type char with a length of 2.

Initially I had set a mail account with a quota of 200000, or roughly 200MB. The user complained of a full mailbox, despite using Plesk to up the limit to 2GB, and then unlimited the account continued to bounce emails saying:
"Recipient's mailbox is full"

I found people complaining of a bug in version 7.5 of Plesk, but it seems this is also present in 8.3. The problem, I discovered after nosing around the config files of the server, was that any changes I made in Plesk weren’t saved. Ultimately I found the limit in the config file remained at 200MB, despite numerous changes. The quota config file is located at:
/var/qmail/mailnames/example.com/username/@mbox.quota

Manually edit that file so it has the quota you want. I like to use vim:
vim /var/qmail/mailnames/example.com/username/\@mbox.quota
(run this as root)

After editing, save the changes, and you won’t need to restart any services or the server. Changes should take effect.

Note, that this was performed on a CentOS 5 installation, so paths and instructions may vary slightly on other systems.

Bazaar has come on a long way over the last six months with the latest release being somewhere around the 1.4 mark. Today, with the upgrade to Hardy which brought with it version 1.3 I started noticing incompatibilities between my local version (1.3) and the server version (0.9). Further investigation revealed some major changes across those revisions, including a completely revised storage format for branches or repositories. So, once you get Bazaar up to the latest version, you need to go about upgrading the storage formats of you branches like so:

To find out what storage format you are currently using, just go the the branch’s folder and type in:
bzr info -v | grep 'repository'

That should give you an output similar to this (an example of an obsolete format):
repository: Knit repository format 1

If it’s anything other than “Packs containing knits” then you’re still using the old storage format. How to upgrade is documented in the bzr documentation, including preparation and upgrading, but the gist of it is:

Make sure you backup the whole directory first, then run:
bzr upgrade

(if you’re using shared repositories, make sure you specify where the root repository is with bzr upgrade root-repo-dir)

Once that’s done, you should reconcile:

bzr reconcile

If the operation doesn’t report any problems, run a quick bzr info to make sure the repository has been updated correctly and you should be able to delete the backup of the old storage format dir which is named .bzr.backup/. Only do that after you’re sure everything is OK!

Today I upgraded a server that was running Gutsy AMD64 arch. I wanted to note in this blog that the update went well, and the result is what seems to be a perfectly good Hardy Heron system. This is what I did from the command line:
sudo aptitude install update-manager-core

followed by:
sudo do-release-upgrade

Went through it all. Sometimes got prompted about config files – whether to keep my version or install package maintainers version. I chose to install the maintainers in case there were some important new config options (I had backups of my config files). These were mostly related to Apache and PHP. Having gone through the config files I can say that it is safe to choose to keep your config files (if upgrading from Gutsy). If you’re going from Dapper you probably should check.

Profiling an application is a great way to see how it is performing. CodeIgniter comes with a profiling class, which you can make calls to from your controllers. However, during development I find profiling so helpful that I want it on all my pages, without having to specifically call it each time. I also want to be able to deploy my development site to a production server – making calls to the profiler throughout the controllers means I would need to edit each and every controller to make sure the profiler wasn’t active on the live server.

After much searching I discovered a better solution. This allows you to add profiling to the bottom of every page (along with its debug info and SQL query info). When you copy the dev site live you just exclude 1 file, and profiling will be removed totally. All you need to do is create a file called MY_Output.php in system/application/libraries that extends the Output core class, with the following contents:

< ?php
# /system/application/libraries/MY_Output.php
if (!defined('BASEPATH')) exit('No direct script access allowed');
class MY_Output extends CI_Output {
function __construct() {
parent::__construct();
$this->enable_profiler( TRUE );
}
}
?>


This will enable profiling output on all your pages for development and debug purposes. When you copy your site to a production server just make sure you don’t copy MY_Output.php file. I normally use rsync for copying live and just add: --exclude="MY_Output.php" to the rsync command.

The condition to using the name MY_Output.php is that you left the variable $config['subclass_prefix'] in config.php as default. This defaults to $config['subclass_prefix'] = 'MY_';, so if you change it you will need to alter the filename of your new class.