Log in

Living a life of small adventures
... punctuated by moments of unpredictable chaos and grand exploits
Recent Entries 
13th-Jun-2011 10:33 pm(no subject)
My friend posted this earlier in a different forum and I felt the need to preserve the question and my reply (re-posted here with permission):
sex doesn't have to equate to sleaze, I promise...
by dirtybunny on Monday, June 13, 2011 at 12:15pm

one thing i always forget about, but am reminded with startling clarity every time i am exposed to working with the fetish community, is how often fetish or sex in general is associated with trashiness or sleaze... why in north america are we so repressed that even when we're expressing ourselves sexually, too often what is expressed is filtered through this lens of trash and sleaze, why can't sex or fetish be classy, cathartic in a healthy, empowering way? even when visiting the head shops in western europe seeing naked chicks on water bongs, even in these places the images are all slightly different than here, the sexual impulses not nearly so dirty and trashy as they are portrayed over here, and the cumulative effect of all these countless tiny differences add up to a huge difference in how sex is dealt with...

hell, a visit to the red light district in amsterdam [even the one in frankfurt where it's technically illegal as compared to amsterdam where it's not is so different in so many tiny ways] and talking to the prostitutes over there, which i highly recommend, makes is so clear how different things are... just watch how people approach those working in the red light district and soon you'll be able to tell who's north american and who isn't just by how they approach and speak to the women, it's truly fascinating and one of my favourite things about amsterdam, something i make time to do every time i'm there...

makes me also wonder if, in areas of the world where they aren't so set on equating sex with sleaze, if people betray each other sexually in the same painfully trashy ways at the same rates as we do here, because in other areas, socially speaking, the differences can be huge, so i do wonder... you don't have to be betrayed sexually in a truly sleazy way to find it quite frustrating at times, but i bet it helps ;)

it really is amazing, when in western europe, and especially amsterdam, there are so many minute, subtle differences they really do all add up to a huge overall change in portrayal and everyday sexual behaviour... and the past couple years... it's made me really think about how it may be affecting how people act in regards to fidelity/cheating in north america, as well as in regards to socialization in the area of gender roles [esp. mainstream masculine ones] because i've found that even the most progressive and open-minded people can still carry a lot of this dirty/sleazy approach to sex over here and then you factor in the gender role factor and it can be pretty discouraging to see how people i'd otherwise respect quite a lot, act in regards to sex... bah
Two things immediately come to mind: the "culture of entitlement" and a very interesting comment I read that I thought was profoundly insightful: that the US (and, by extension, "American culture" as imported by others) has become a kleptocracy. While it may have started out with conflicted Puritanical values, it has evolved into something much more sinister and troublesome. When you combine those two cultural threads it's all about "why don't I have all the sex I think I'm supposed to have" and "how am I going to get my sex" (keeping in mind the "kleptocracratic" culture)... it's about owners and the owned... the powerful and the service providers (and I'm not just talking prostitution)... the rulers and the servants. In a race to the bottom, sleaze is an easy and energy efficient way of communicating the expected social dynamic... of enforcing the power relationship and minimizing the guilt that would have to be felt when stealing from another "person". The difference in attitudes is simply that: whether one is dealing with a person that has the right to remain a person during sex (no matter how, shall we say, vigorous that sexual behaviour might be... "classy, cathartic in a healthy, empowering way"), versus something that must be taken and owned to be enjoyed ("filtered through this lens of trash and sleaze" to dehumanize and therefore allow the act to be committed without the burden of shame on the part of any of the participants).

P.S. Before anyone jumps on me ... when I say "American culture", I'm not saying "Americans"... most Americans I know are heavily conflicted by the culture they find themselves in (even if they don't realize it or understand the nature of their discomfort... although they, again from personal experience, recognize and value the converse of the trash/sleaze culture when they experience it (and it's not just sex I'm talking about), but don't know where to turn to find it because it's, by definition, a sub-sub-culture that is overshadowed in every aspect of life by the sub-cultural manifestations of the macro-culture). ,,,,, <— I figured I needed a few more commas but couldn't figure out how to fit them in that already overburdened sentence.
Haven't done much in the way of computer stuff this past week (perhaps you are all relieved to not have to scroll past that much techno-verbiage, heh). I have decided that 64-bit Linux is not quite ready for prime-time on the desktop though, and have re-installed my development workstation at Carleton with Scientific Linux 6.0 32-bit (I had the 64-bit version installed initially since it is a lovely 64-bit multi-core powerhouse). Specifically, to do my daily work, I need access to certain programs and plugins that are sometimes only available as 32-bit binaries. Sigh... The good news is that I don't have to down-rev my new server's OS at home (from Slackware64 to the 32-bit Slackware version) because I am using it primarily as a server and not a desktop, so I should be good. The one thing I did install for desktop use on it is Adobe's beta 64-bit version of Flash Player 10 for Linux (codenamed "Square"... also available for 64-bit Windoze and Mac OSs). So far, so good, but I'm having issues with the sound support on my box (probably just ALSA configuration, but not a high priority, I need to get LDAP working first), so it might be a while before I can report back on how it does (it plays YouTube videos at least, so... the basics at least work).

And because I am keeping track of what I do to my system for posterity's sake (and in case anyone else can benefit from it), here's how I installed the 64-bit Flash on Slackware64: downloaded the distribution "tar.gz" archive file [using the "Download plug-in for 64-bit Linux (TAR.GZ, 4.1 MB)" link], untar'ed the archive [tar -zxvf flashplayer10_2_p3_64bit_linux_111710.tar.gz], moved (as root) the sole file in the archive to the Firefox plugins directory [mv libflashplayer.so /usr/lib64/mozilla/plugins], fixed the permissions [cd /usr/lib64/mozilla/plugins; chown root.root libflashplayer.so; chmod 755 libflashplayer.so]. Just had to re-launch Firefox and all was well.
In my last technical post, I had finally achieved a perfectly functioning Slackware64 13.37 system installed and booting (from RAID Level 1 disks!) and ready for configuration. I had not yet configured the data space (using the Logical Volume Manager, LVM), and was still debating about whether or not to bite the bullet and learn how to installed LDAP for user authentication and other system information (trying not to have to run NIS anymore).

I had originally planned to do one Physical Volume/Volume Group for the data, but then I thought about doing two volume groups: one for business stuff, and one for home stuff. After a little more consideration, I decided against that approach as well and settled on an odd sort of functionality (given the recent issues with identity theft and various other data security concerns) and decided to create an 80GiB partition that I could encrypt if I ended up storing people's registration information for some of the business ideas I have. That way, even if the computer was physically stolen, there would be no easy way to get to that information. I can use it for a regular partition until then ;). It did mean though that I had to repartition the hard drive again (I didn't need to touch the first 3 partitions that were already nicely set up, thank you very much). However, since the PC hard drive scheme can only handle 4 primary partitions (and 3 were already accounted for), I changed the 4th one from being a primary partition to an "extended" partition (it's an option that's part of the "fdisk" command) and then creating two partitions in that partition (which were /dev/sd{a|b}5 and /dev/sd{a|b}6)). I made both of them RAID (type fd) partitions as well (Note: before I repartitioned, I made sure the system status was clean because I had done a pvcreate on the partition while the 4th one was a primary partition [pvremove /dev/md2; mdadm --stop /dev/md2]). The new partition table looks like this:
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400   fd  Linux raid autodetect
/dev/sda2          206848     8595455     4194304   82  Linux swap
/dev/sda3         8595456   176367615    83886080   fd  Linux raid autodetect
/dev/sda4       176367616  1953525167   888578776    5  Extended
/dev/sda5       176369664   344141823    83886080   fd  Linux raid autodetect
/dev/sda6       344143872  1953525167   804690648   fd  Linux raid autodetect
I then ran "partprobe" to force the kernel to reload the disk's partition tables without having to reboot the system (try that with Windoze, eh?). I created two new RAID devices [mdadm --create /dev/md{2|3} --level=1 --raid-devices=2 /dev/sda{5|6} /dev/sdb{5|6}]. I waited for the devices to finish their RAID synchronization (just "cat /proc/mdstat" until it showed the sync'ing was complete) and created an EXT4 filesystem on /dev/md2 [mkfs.ext4 /dev/md2] and added it to the /etc/fstab file after the entry for /dev/md0 (see below). Then it was time to set up the final RAID partition with the LVM. First, a Physical Volume needed to be created [pvcreate /dev/md3], then the Volume Group needed to be set up on that Physical Volume [vgcreate vgexp00 /dev/md3] (where "vgexp00" is just a name/label that I chose myself in case I add more volume groups in the future, it's an arbitrary name that should mean something to the one using it... in this case it's my "export volume group 00"). I then created all the Logical Volumes (LVs) I wanted to have on the system. The key with these is to group "like" data together so it's easier to back up and manage access to. For instance, in my case, I have LVs for media (music and video), web sites, home directories, software development, one each for downloaded programs and information for Windoze and Linux, etc. (see the fstab below) [e.g. lvcreate --name lvhtdocs --size 40G vgexp00]. Each one had different size needs, so I created them all by hand. I then created EXT4 filesystems and mountpoints for them all with a quick loop [e.g. mkdir /exp; for i in htdocs media dbase homes devel windoz linux shared; do mkfs.ext4 /dev/vgexp00/lv$i; mkdir /exp/$i; done]. I then edited the /etc/fstab file by hand to add the necessary entries:
/dev/sda2        swap             swap        defaults         0   0
/dev/sdb2        swap             swap        defaults         0   0
/dev/md1         /                ext4        defaults         1   1
/dev/md0         /boot            ext4        defaults         1   2
/dev/vgexp00/lvdbase  /var/lib/mysql   ext4   defaults         1   2
/dev/vgexp00/lvhtdocs /exp/htdocs ext4        defaults         1   2
/dev/vgexp00/lvmedia  /exp/media  ext4        defaults         1   2
/dev/vgexp00/lvhomes  /exp/homes  ext4        defaults         1   2
/dev/vgexp00/lvdevel  /exp/devel  ext4        defaults         1   2
/dev/vgexp00/lvwindoz /exp/windoz ext4        defaults         1   2
/dev/vgexp00/lvlinux  /exp/linux  ext4        defaults         1   2
/dev/vgexp00/lvshared /exp/shared ext4        defaults         1   2
/dev/md2         /exp/stuff       ext4        defaults         1   2
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro  0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0
Note: the first number (0 or 1) is whether the filesystem should be checked ever at mount/boot (there are rules for how/when), and the second number is the order they should be checked in. Per the man page for fstab, it should be the root filesystem at 1 and everything else at 2... larger numbers could be added, but this allows for maximum parallelism in doing the checks, which have long I/O waits, in the case where a system is being brought back after a power failure or crash... even if they're all on the same disk, the LVM can place information across the disk and making access requests for a bunch of filesystems at once allows the disk to sequence the accesses in such a way that it maximizes performance (i.e. moves the relatively slow mechanical disk arm as little as possible at a time to fulfill the most requests as possible as quickly as possible).

Lastly, one of the "features" I decided to implement is putting the MySQL (or Drizzle hopefully soonish) database files into a logical volume. I guess I should mention that the reason for using the LVM is that the LVs can be created with a smallish size (what I think I'll be using in the next year, let's say), but if the data I'm storing on it grows past the limits of the LV, I can dynamically increase the size of the LV and then the EXT4 filesystem on it by growing the LV into the remainder of the VG (volume group) which is not fully allocated (in my case, when I was done, I had assigned roughly 420G of about 850G to LVs, so i have 430G left to allocate as needed). Filesystems and LVs can also be shrunk if it turns out I overestimated and need the space for some other LV. Anyway, to do that, I mounted the database LV on a temporary mount point [mount /dev/vgexp00/lvdbase /mnt/tmp], copied all the files from the database directory to the mounted filesystem [cp -r /var/lib/mysql/* /mnt/tmp], set their permissions to the right value [cd /mnt/tmp; chown mysql.mysql *; chgrp root *.err; chmod 660 *], removed the old files from where they were (Note: mysql was not running at this point because I had not configured it yet) [rm -rf /var/lib/mysql/*], edited the /etc/fstab file to make sure that this filesystem was mounted on /var/lib/mysql immediately after the /boot filesystem was mounted (see above), tested by mounting it [mount /dev/vgexp00/lvdbase /var/lib/mysql], and then setting the permissions correctly [chown mysql.mysql /var/lib/mysql; chmod 750 /var/lib/mysql].

Once it was all done, I rebooted to make sure everything went where it was supposed to and everything looked good. It was... including the changes I had made to ownership and permissions on the database directory. Woot! The filesystem was finally set up and I could begin the configuration proper. I created a user account for myself (so I didn't have to do everything as root), fired up KDE (the graphical user interface that, fyi, I've been using for two days and am typing this from using Firefox), and plugged in the network (I assigned a static IP for now local to my network and it works like a charm).

The last thing was to decide: NIS or LDAP. I chose LDAP... it's about time I say (even though I know I'm going to regret it). Regret #1? Apparently Slackware deliberately does not ship with the OpenLDAP server. Kind of wtf? But Patrick apparently had some justification for it. There's a lovely page though, "OpenLDAP in Slackware-13.0", that explains how to add it in. The nice thing is the Slackware installation DVD comes with all the source packages and build scripts, so it just needs to be copied over to the hard drive, one file edited, and a new version of OpenLDAP (containing the server and whatnot) built and installed. Worked like a charm but took a long time (building it includes running an extensive set of automated regression tests on the resulting programs). Basic instructions: copy the source directory from the DVD (/dev/sr0 on my system) to the local disk (I used a subdirectory off my home directory) [mount /dev/sr0 /mnt/dvd; cp -r /mnt/dvd/source/n/openldap-client .], edit the build script [cd openldap-client; cp openldap-client.SlackBuild openldap.SlackBuild; chmod a+x openldap.SlackBuild; <use your favourite editor>], save the modified script, run it after setting the correct architecture (in my case 64-bit) [export ARCH="x86_64; ./openldap.SlackBuild], and wait. Note: if using a sed or vi editor, the substitutions are:
s/\ (clients\/libraries only\!)//g
This apparently fixes a bug that crept in because the server code was not being built and enabled the server code to be compiled. When the build and automated tests are done, you will have a file in /tmp which is the Slackware package for the program ready to install. In my case, I copied it to a local directory I was using to store such things for later use or archiving [cp /tmp/openldap-2.4.23-x86_64-1.txz ~/packages]. Then it just needed to be installed with [cd packages; upgradepkg /var/log/packages/openldap-client-2.4.23-x86_64-1%openldap-2.4.23-x86_64-1.txz] (and yes, the % is required). Now, we're caught up and thus begins my laborious process of learning and configuring LDAP. More to come...
4th-Jun-2011 03:59 pm - In neat little boxes...
Going from stable hardware to a functional Internet server is not an instant process. For instance, deciding how to install the operating system and getting it to boot and how to partition the drive for data takes a lot of work — especially when "state of the art" is a moving target. When I last installed a system, the idea of trying to boot off a RAID 1 partition (mirrored disks... in case one disk dies, the exact same data is on the second one as well) was not possible. In my first post on the topic, I had been planning to have one non-mirrored partition on each of the two drives (for redundancy) that I would have had to manage manually so I could boot off either disk if the other failed. On my current server, I have a separate (non-mirrored) boot disk (it also had the operating system on it) and then a pair of disks in a RAID 1 configuration for my data. I learned, however, that LILO (the LInux LOader) could now boot a RAID 1 partition! Well, that was going to save me a lot of manual configuration and provide better data safety, so that sounded like a great idea. Right? I mean, right?

Well, I had already partitioned my hard disk as follows (sda and sdb were identically partitioned... and note in case you didn't know or are used to other Unices, Linux blocks are indicated as 1K, not 512 bytes):
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400   83  Linux
/dev/sda2          206848     8595455     4194304   82  Linux swap
/dev/sda3         8595456   176367615    83886080   fd  Linux raid autodetect
/dev/sda4       176367616  1953525167   888578776   fd  Linux raid autodetect
Where sda1/sdb1 [100MiB] was going to be where I stored the operating system image to boot off of (manually placing copies on each filesystem and installing the LILO bootloader individually on each disk's Master Boot Record (MBR)) and mounted as /boot once the system was running, sda2/sdb2 [4GiB] would be non-mirrored swap partitions (both used simultaneously to give 8G of swap), sda3/sdb3 [80GiB] was going to be the RAID 1 (mirrored) / (root) partition, and sda4/sdb4 [some crazyass number of GiB, like 850 or something] was going to be the RAID 1 (mirrored) with a Logical Volume Manager (LVM) volume group (VG) on top of it (more on that later...). A quick note on the swap partitions: the fact that I did not use a swap file on a RAID partition does mean that if the system is heavily loaded down and swap space is being used and a disk fails, that stuff could crash (programs and possibly even the operating system). However, if swap space is needed, the performance hit of putting it on top of a software RAID implementation would be unforgivable. The system could crash, but if it's brought back up, there's enough swap on one disk to run the system fine on the one functioning swap partition). A compromise that I feel is acceptable to take.

I went ahead and created the mirrored partitions /dev/md0 and /dev/md1 with /dev/sda3:/dev/sdb3 and /dev/sda4:/dev/sdb4 respectively [mdadm --create /dev/md{0|1} --level=1 --raid-devices=2 /dev/sda{3|4} /dev/sdb{3|4}] and created EXT4 filesystems on /dev/sda1, /dev/sdb1, and /dev/md0 (the mirrored disks from the previous step) [mkfs.ext4 /dev/{sda1|sda2|md0}]. I mentioned earlier that LILO can now boot off RAID 1 partitions, but I did not know that at the point that I had done all of this... I installed the Slackware64 13.37 distribution and then started investigating how to do the LILO boot thing properly with my particular configuration. It was then that I learned about the new capability and realized that it would be best if I rolled things back a little and mirrored sda1 and sda2. I copied the files out of that filesystem into a temporary directory I created, rebooted the system so I could change the partitions from type 83 "Linux" to type fd "Linux raid autodetect" and mirror the partitions. Sadly... the temporary directory I had created was on the RAMdisk that is used by the installation load and when I rebooted, all the files were gone. It was a laughing (at myself) head-desk moment... doh! Well, not such a bad thing (I just needed to re-install the OS, so not a problem at that stage, heh). It also gave me the chance to redo things with the new configuration. I would make /dev/md0 the /dev/sda1:/dev/sdb1 mirrored partition and go from there.

And here's where things took a turn for the argh... I knew I had to re-number the other mirrored partitions so that the /dev/hda4:/dev/hdb4 partition went from /dev/md1 to /dev/md2, and the /dev/hda3:/dev/hdb3 partition went from /dev/md0 to /dev/md0 so I could make the boot one /dev/md0. How to do this? Well, after much research (this is all new functionality, so it's not very well documented anywhere), you stop the mirrored partition (say /dev/mdX for the mirrored partitions /dev/sdaN and /dev/sdbN), re-assign it a new "superblock minor number" (let's say Y), and start it back up again [mdadm --stop /dev/mdX; mdadm --assemble /dev/mdY --super-minor=X --update=super-minor; mdadm --assemble /dev/mdY /dev/sdaN /dev/sdbN] (boy, did it take a long time to figure out how to do that!). Did /dev/md2, then /dev/md1, then created /dev/md0 and everything looked good. Did a "cat /proc/mdstat" and everything was happily mirrored and chugging away. Created an EXT4 filesystem on /dev/md0 and everything looked good. I wiped the filesystem on /dev/md1 to make sure I had a clean installation, did a fresh installation, and rebooted the computer just for good measure and... all the RAID device numbering was messed up! I thought it was hard to figure out how to do the stuff I just did... it had nothing on figuring out how to fix this new problem! The clue came when I looked at the information associated with the RAID devices [mdadm --detail /dev/mdX] and saw that there was a line like "Name : slackware:1" where the number after the "slackware:" seemed to match the "mdX" number assigned... and also corresponded to the number I used to create the RAID partition (which the --update=super-minor command didn't seem to change). I was wondering if this was something that was autogenerated at boot time or whether it was actually in the RAID configuration information stored on the disk... I used the program "hexdump" to look at the contents of the first few kilobytes of data stored in the RAID device block on the disk [hexdump -C -n /dev/mdX] and sure enough, the string "slackware:X" was there. I then had to start the search for how to change the "Name" of a RAID array as apparently this was very new and never used functionality. The built-in help indicated it could be done, but the syntax didn't make sense. Ultimately, I figured it out and changed the name (and re-changed the minor number in the superblock as well just to be sure) [mdadm --stop /dev/mdX; mdadm --assemble /dev/mdY --update=name --name=slackware:Y /dev/sdaN /dev/sdbN; mdadm --assemble /dev/mdY --update=super-minor /dev/sdaN /dev/sdbN; mdadm --assemble /dev/mdY /dev/sdaN /dev/sdbN] and this technique proved reliable and worked like a charm every time (rebooted the system to make sure everything stuck, and it did, yay!). I understand that this is Slackware functionality to guarantee what mdX number gets assigned to a RAID array (where other operating systems can, and do, randomly make assignments), so it's ultimately a Good Thing™, but it's not well documented.

So, it was time to finish up the installation by installing the bootloader. The configuration (in /etc/lilo.conf on the /etc directory for the operating system installed on the disk, e.g. /mnt/etc/lilo.conf if that's where the disk partition with the OS is mounted) was pretty much this (it was having problems with my video card, so I left out the fancy graphical console modes):
lba32 # Allow booting past 1024th cylinder with a recent BIOS
boot = /dev/sda
# Append any additional kernel parameters:
append=" vt.default_utf8=0"
timeout = 50  # In 1/10ths of a second
vga = normal
# Linux bootable partition config begins
image = /boot/vmlinuz
root = /dev/md1
label = Linux
read-only # Partitions should be mounted read-only for checking
Fairly simple stuff, the "boot" line specified the "whole disk" so the bootloader would be installed in the Master Boot Record (MBR) of the drive, it would load the Linux image, and use /dev/md1 as the root filesystem. Simple, except it didn't work!!! LILO, when run [mount /dev/md1 /mnt; mount /dev/md0 /mnt/boot; chroot /mnt lilo -v -v -v], would generate the message "Inconsistent Raid Version information on /dev/md0". Sigh... now what? Well, it turns out that sometime over the past year, the "metadata format" version of the "mdadm" package had changed from 0.9 to 1.2... and LILO did not know how to read the 1.2 version metadata and so assumed the superblock of the RAID array was corrupted (there's a bug report here). It could, according to what I read, understand the 0.9 metadata format, so... copied the files off the /dev/md0 partition (this time onto the actual hard drive, heh) and re-initialized the partition to use the old metadata format (again, it took a huge amount of time to track down the poorly documented command) [umount /mnt/boot; mdadm --stop /dev/md0; mdadm --create /dev/md0 --name=slackware:0 --metadata=0.90 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1; mkfs.ext4 /dev/md0; mount /dev/md0 /mnt/boot]. Once that was done, the boot files could be copied back and lilo run again. When I first tried it, I only installed on /dev/sda and when I tried to boot, it just hung (never even made it to LILO). This confused me, so I checked the boot order of the disks in the BIOS settings. The "1st disk" was set to boot first and then then "3rd disk" if it couldn't. It took me a while, but I eventually tried (out of desperation) to switch the boot order of the disks and ... voila... the LILO boot prompt! Turns out that the disk that Linux thinks is "a", the BIOS thinks is the "3rd" disk, and "b" was the "1st" disk. Live and learn, eh? The trick was it still needed to be installed on both hard disks (each has a separate MBR), so "lilo" had to be run and then the "boot" parameter had to be changed to /dev/hdb in lilo.conf and lilo had to be run again [just "chroot /mnt lilo -v -v -v" once the filesystems were already mounted]. Once I installed on both /dev/sda and /dev/sdb it didn't matter which one I set first, so that was then working the way it should.

Great... right? Sigh... the kernel would load and then panic because it could not figure out how to use the root filesystem (it would give the message: "VFS: Unable to mount root fs on unknown-block(9,1)". I remembered from my digging that the RAID disk devices had the major device number "9", and the root minor device (from above) was "1", so it knew it was trying to load that device, but couldn't. To me, that said that the RAID drivers were not in the kernel and that I would need to build a RAMdisk with the proper kernel modules and libraries for it to properly mount the RAID device as root. I'd had enough and went to bed at that point and took it up the next day. Again, what a pain to find documentation (one of the reasons why I'm writing this all out for posterity's sake... maybe I should write a magazine article, heh)! The trick was to use the "mkinitrd" script that comes with Slackware, and to do that you need to have installed OS available because the command doesn't seem to be installed on the DVD's filesystem. Once the operating system is mounted [mount /dev/md1 /mnt; mount /dev/md0 /mnt/boot], create a copy of the /proc/partitions file on the disk version of the OS [cat /proc/partitions > /mnt/proc/partitions] (it will be the only file in that proc directory). Edit the /mnt/etc/lilo.conf file to include the line "initrd = /boot/initrd.gz" right below the "image = /boot/vmlinuz" line (and make sure the boot line is "boot = /dev/sda"). Then run the mkinitrd command to create the RAMdisk image and lilo to install it [chroot /mnt mkinitrd -R -m ext4 -f ext4 -r /dev/md1; chroot /mnt lilo -v -v -v]. Change the /mnt/etc/lilo.conf file to "boot = /dev/sdb" and run lilo again [chroot /mnt lilo -v -v -v] to install LILO's configuration on both disks. At this point, you need to delete the "partitions" file on the mounted OS image (it should be an empty directory for the virtual /proc filesystem when it runs) [rm /mnt/proc/partitions].

And that, my friends, is how I spent my summer vacation ;). The system booted (I tried switching boot order via BIOS and it worked fine), mounted its root filesystem, and loaded my shiny new Slackware64 13.37 installation in all its glory. Finally!!! But my journey is far from over... I now have to configure the system and integrate it with the framework I already have running so it could eventually take over from my current server (my plan was to move the pair of 200G disks from the current server to the new one and use them as part of a system backup strategy). I had to install the LVM partition for my data and decide how to carve up the space into Logical Volumes (LVs). I have to decide whether I want to stick with NIS or move to LDAP for authentication (I've been meaning to for a while, but know it's going to be a colossal nightmare), I have to configure Samba (for file and print sharing with Windoze machines), I have to move my web sites to the new box (including migrating the MySQL databases for the Wordpress installations), and then migrate the data from my old server to the new data partitions. Sigh... it's a huge job with so many different technologies (each of which requires a great deal of expertise to use)... all the while I'm working full time, designing the scientific payload for a satellite in my spare time, taking care of my kids, and preparing for a two week television show shoot in less than a month with violetnun as we renovate her house in front of the cameras (P.S. please send Canadian Tire money!!! We're using it as a major method of raising the funds we need for supplies, heh... also any thing or service you can give us to help with the renovations itself or to use as barter for things or services would really help out as well!). It's restoring a heritage (1865) house in St. Isodore that was falling into the ground when she got it, and if/when it sells, violetnun will donate 20% of the "free and clear" proceeds after the sale to an organization in Ottawa that helps kids at risk. I'll be posting more soon :).
3rd-Jun-2011 11:13 pm - Memories of stability...
When we last "spoke" about technology, I was getting ready to work on that server. What a couple of weeks this has been. Perhaps I knew instinctively that it wouldn't go smoothly and that's what kept me from tackling it for as long as I put it off. In the back of my mind, I remembered that I'd been told that the system was "flaky". That's a Bad Thing™.

Needing to press ahead and find out what I was up against, I realized that this was a real 64-bit system and so fired up Slackware64 13.37 to install. I was still leery of the warning that there might be a problem but it ran for a few days without flaking out. I was thinking that perhaps the reported issues were due to having been running Windoze on the system. Still, this was going to be my server and I was going to be trusting my data and my network to it (possibly business and events as well) and I did not want to take any chances. Luckily, Slackware (and a number of other Linuxes) come with a utility called memtest86+ that can be run off the installation DVD. The system seemed stable, but I figured "what the heck, just to be sure"... I started it running before going to bed, and when I got up the next morning, there were memory errors... :( Not many, and only on one of the many tests it ran, but it was enough to raise all my concerns again. The fact that it was only a few errors out of trillions of memory accesses would certain account for what would be perceived at "flaky" behaviour. I seemingly had found my culprit. In looking at the information pages for memtest86+ and a bunch of the overclocker forums (I wasn't overclocking, but it was one of the only places I could seem to find information at all on the subject), it became clear that it was a real issue with the memory and not just some peculiarity of the test. It was, indeed, the culprit. The clincher was the following statement (on the overclocker forum pointed to above):
There have been numerous reports of errors with only tests 5 and 8 on Athlon systems. Often the memory works in a different system or the vendor insists that it is good. In these cases the memory is not necessarily bad but is not able to operate reliably at Athlon speeds. Sometimes more conservative memory timings on the motherboard will correct these errors. In other cases the only option is to replace the memory with better quality, higher speed memory. Don't buy cheap memory and expect it to work with an Athlon! On occasion test 5/8 errors will occur even with name brand memory and a quality motherboard. These errors are legitimate and should be corrected.
I read that while I was upstairs, late at night, and I went downstairs just to verify and, sure enough, it's an AMD64 Athlon X2 based system.

Thus began a week long search for an answer about whether or not this system could be used after all. First things first: check the brand and specifications for the memory. Kingston KVR400X64C3AK2/1G... "1GB 400MHz DDR Non-ECC CL3 (3-3-3) DIMM (Kit of 2)" in all 4 slots for 2GB total. Very similar models were listed in the ASUS A8N-SLI Premium motherboard manual: KVR400X64C3A/512 and KVR400X64C3A/1G... both of which had the same specifications as the stuff I was using (the main difference between the KVR400X64C3AK2/1G and the KVR400X64C3A/512 is that the "K2" memory came as a "timing matched" pair of 512M modules to make 1G of RAM... presumably giving a better guarantee of performance). I went searching the 'tubes for information on whether anyone else was having issues with this motherboard and it became obvious that there was some sort of ... memory timing issue ... perhaps (the information seemed utterly unreliable, but there were enough anecdotes that I could be confident something was going on). Most of the posts focused on running the board with 4 DIMMs installed (memory errors when trying to expand the memory beyond the 2 DIMMs that they supposedly had when they purchased the system). It took days of hunting for bits of data, but it ultimately became clear what was going on. In the meantime, I decided to test the memory sticks themselves, one at a time, then two at a time (I had two matched pairs), then all four. Classic troubleshooting. Leaving the motherboard memory setting to "Auto" (the DIMMs store meta information about themselves that is readable by the BIOS at boot and is used to set the timing parameters if the Auto setting is used), I put in each DIMM, ran memtest86+ for at least 8 hours, and recorded any errors. That last part was really easy because there were zero errors. Ditto for the pairs of DIMMs. No errors. Put in all four and ... errors. This seemed to agree with what I had read online with people having problems. I also noticed something interesting (that was ultimately backed up with online anecdotal evidence as well): the BIOS would set the memory timing to full DDR400 timing (400MHz ... huge bandwidth!) when one or two DIMMs were installed, but shifted down to DDR333 timing when four were installed. The explanation given was that the processor and/or northbridge chip (the accounts were not consistent) did not have the bandwidth to support two simultaneous independent memory channels (which is what happened when you added the second bank of two DIMMs, it's pretty high performance stuff) and so had to scale back the speed of the overall memory system so it could keep up.

I played with manual timing and went right back to the datasheets for the memory chips (Samsung) used on the Kingston memory modules and, according to everything I read, I was operating everything within specification (if clocks were accurate enough on the motherboard), but no matter what I did, I still got errors. I read every account of others' experiences I could find and nothing provided a clue on how to solve the timing issues (they actually just muddied the waters because most of the accounts were of the "wave a dead chicken" variety). Eventually it came down to making a decision: live with 1G of memory at DDR400, buy new memory and hope it worked better (there were accounts of certain combinations working at DDR333 perfectly), or solving the timing issue. I eventually, manually, rolled back the timing to DDR266 and adjusted the memory timing parameters to match (again, based off the actual Samsung memory chip datasheets, fyi K4H560838H-UCCC) and ran the memory test one more time. And... no errors. Left it sit another 16 hours. No errors. Solid as a rock. So the decision then became run 1G at DDR400 (until I could afford to buy a pair of 1G DIMMs that I could replace them with to get 2G) or 2G (four 512M DIMMs) at DDR266. But at least I had a stable system either way :). In the end, I chose more memory versus faster memory because it's been my experience that the extra gibibyte is what's going to have the biggest overall impact on system performance if the system gets loaded down... and DDR266 is not pokey to say the least. For posterity's sake, the memory timing parameters were [memory clock] TCK = 266MHz (7.5ns), [CAS* latency] TCL = 2.0 TCK, [minimum RAS* active] TRAS = 45ns (6 TCK), [RAS* to CAS* delay] TRCD = 20ns (3 TCK), [row precharge] TRP = 20ns (3 TCK), [row refresh cycle] TRFC = 75ns (10 TCK), [write recovery] TWR = 15ns (2 TCK), and [row cycle] TRC = 65ns (9 TCK). I read in various places that leaving "1T/2T memory timing" set to 2T was the safer option (and 1T wasn't enough of a performance boost to justify the risk on the chipset I had), so that's what I did. I also didn't touch the default setting of [read-to-write delay] TRWT = 3 TCK since I guessed it was a chipset thing because I could not find it on the datasheet anywhere.

So... I finally seemed to have stable hardware, I had a general plan for how I was going to format the disks and install, and I was ready to rock and roll... or was I?
24th-May-2011 01:51 am - Next server decision...
Well, I finally got around to investigating whether the system I had been given in April of 2010 actually worked... yes, it's been that shitty of a year for me that it took me that long to even try. Well, first thing is, of course, to clean out the computer... clean the fans, clean the dust off the boards, clean out the heatsinks, etc. on both the motherboard and plug-in cards (e.g. the video card). To clean the CPU heat sink required that I remove it from the system to wash it out (those thinly spaced fins make it hard to get dirt out). Also, I had been told that the system was behaving in a flaky manner and that there might be something wrong with it. Flaky to me usually means CPU or GPU overheating. So I decided, as part of my cleaning process to replace the thermal compound between the CPU and GPU and their respective heatsinks (it was dry and probably not as effective as it once was when I inspected it). Once that was all done, I installed my pair of terabyte hard drives (that I will be using in a RAID configuration for data availability), found the other parts needed to complete the system and turned it on (expecting smoke or ... nothing). Well, after sorting out a few things I hooked up wrong, it so far it seems to be working fine! It's an AMD 64 3800+ dual-core 2GHz processor, 2GB of RAM (expandable to 4GB), and all manner of other goodies (it's an Asus A8N-SLI Premium motherboard if that means anything to you). Certainly a lot more powerful than any of my other computers and it would make a fine server, I'm sure! I haven't installed the OS yet (Slackware version 13.37, acronym lol), but it booted the installation DVD (i.e. it booted Linux) and I was able to put empty partition tables on the two drives.

Once I got to that stage, I needed to work out a proper disk utilization strategy. The motherboard says it has two hardware RAID controllers: an NVIDIA nForce 4 SLI quad Serial ATA II controller, and a Silicon Image 3114R quad Serial ATA RAID controller. I needed to decide what sort of support Linux had for these controllers versus doing basic software RAID with the OS. I eventually found the right page: Serial ATA (SATA) chipsets — Linux support status. The main piece of information is that both devices are what are referred to as "fake RAID". It took some looking, but this basically means that they are also forms of hardware assisted software RAID, but have a proprietary data storage strategy. In short, just about every article I read suggested that using standard Linux software RAID was likely going to be faster, more reliable, and more robust than trying to use the manufacturer's often proprietary drivers or imperfect open source support. It took a fair amount of research on that one question, but it was what I needed to make my decision to use software RAID (which is what I have been using on my current server, and it works like a charm).

So, I finally have my disk partitioning for both terabyte disks figured out (they will be the same partitions and filesystems on both). Partition 1 will be 100MiB and will be used for the /boot filesystem (my current server uses 18MiB of space), and will have an ext3 filesystem. Each disk will have a separate, non-mirrored, /boot filesystem that I will have to initialize for each to allow either disk to be bootable [type 0x83]. Partition 2 will be 4GiB for non-mirrored Linux swap (there will be one on each, for a total possible of 8GiB) [type 0x82]. Partition 3 will be mirrored 80GiB for the Linux OS (my current server is using about 10GiB) and will have an ext3 or maybe ext4 filesystem [type 0xFD]. Partition 4 will be the remainder of the disk (roughly 888GiB!!!) will be mirrored and will be formatted for use with the Logical Volume Manager infrastructure (which allows the space to be partitioned into logical volumes that can be resized, etc. later) [type 0xFD]. The logical volumes will be formatted with ext3 or ext4 filesystems (yes, that's the next major decision I have to make!). Funkadelic!

Before I go any further, I unfortunately probably have to download the Slackware64 ISOs to use to install (I'd downloaded the "regular", 32-bit version) because this system has a proper 64-bit multi-core CPU. Sigh... it's hard to get it right!
28th-Mar-2011 02:02 am - Free music!
Since I have a relatively decent Intertubes connection finally, and I wanted to share one of these with a friend, I have posted the MP3s for an EP I released on CD back in 2008 as “Tin Ape” (with a bonus track from 2010). Free music. Naughty album cover. Hope you enjoy!

Tin Ape: Impudent Simian EP
30th-Jan-2011 03:39 pm(no subject)
Two quick notes...

1. I am seriously curtailing my Facebook activity. It was a time leech that didn't really leave much to show for my efforts (although I was at least apparently relatively entertaining from what I've been told, heh). I'm going cold turkey until March (I have sooooo much work at school to do, and so much is going on in my actual life, that this is a necessity — I just needed more hours in my week). I do plan to start a Facebook page for my radio show and maintain a music blog there (this was a noticeable component of what I did on my personal Facebook page), but I'm going to ease out of the fetishisation of the trivial that was the ongoing Twitter-like use that I was putting Facebook to previously.

2. That means I plan to post here more often instead... less frequently than I was posting to Facebook, but certainly more frequently than I've been posting here recently (mostly because I didn't really want to have to sit down and write out all the shit that was going down in my life, not because I didn't have anything to say). At best, I posted the fluffy bunny stuff to my Facebook account... nothing to particularly engage or challenge. Nothing to really tilt the emotional meter. I like to say that, at best, Facebook got 3-5% of what I could say. LJ has always (when I said anything) had much closer to 10-15% of my reality on display for others. [I probably should keep a personal journal for the rest; however, I'm just not that motivated!].

Anyway, I'm leaving this post public and if you want to read what's going on, then you're welcome to friend me (if you haven't already). I talk about my life (which has been described by a friend as "living a life of small adventures" and to which I added "punctuated by the occasional terrifying huge ones at unexpected intervals"); my music (both created by me, the work I do as a radio show host on CKCU, and my latest musical finds); my thoughts (sometimes even essays) on politics, feminism, the challenges faced by indigenous peoples, and all manner of issues faced by society; my experiences flying (I'm a pilot trying to get my commercial license on a Kraft Dinner budget); my fun times with friends; and my kids (although they're teens now — awesome ones at that — so there's not quite as much to say anymore as there was). Unfortunately, almost all of my posts are "friends only" because of a small number of extremely toxic individuals that, because of associations with my children that are out of my control, seem to read anything I post publicly and interpret through the lens of their hate-distorted view of the world. I don't keep secrets, but I also have no desire to open myself up for unnecessary abuse simply because I want to share some of my thoughts and feelings with others. It's a venue that, even with the above-mentioned risks has allowed me to form amazing friendships with people from all over. In some cases, I've even gone on to meet them in real life, and in some cases fate (well, mostly budget, heh) has conspired otherwise. I read everything that people on my friends' list write, although I haven't had the time to reply as much as I would have liked the past year and a half, I hope to be a little better with that going forward now that I've nixed the dreaded time leech described above.
9th-Oct-2010 12:21 am - Thanks for butterflies...
If there are any Canadians (or wannabe Canadians) looking for a place to roost this coming Thanksgiving weekend, you are cordially invited to my place for a traditional meal of Thanksgiving sushi on Sunday evening. There will be both the fish kind and the veggie kind in the offing. I believe I will also be inventing a "Thanksgiving Sushi" using roasted turkey for the non-veg and probably based off some sort of squash for the veg version. There will also be a black forest cake that Happy will be making from scratch (she tried one last week, and although it was delish, it had a few issues that we are going to address with the "practice makes perfect" approach of making another). Potatoes of various constitutions (haven't figured out what I'm going to do there yet). Probably squash and bok choy and goodness knows what else ;). I promise there will be no tofurkey!!!

P.S. We will also be going to see the flutterbys (butterflies) in the greenhouses at Carleton University around noon if you want to come along.

Just drop me a message if you think you will be able to come so I have an idea of how many to expect!
This page was loaded Feb 25th 2017, 8:22 pm GMT.