Changing default clock-format from 24-hour to 12-hour in Fedora 19

When setting up my latest Kickstart files for Fedora 19 I noticed that the default GNOME clock format of the clock displayed on the login screen and user's desktop and lock screens were all in 24-hour time format. I wanted to change this to a 12-hour clock format. I first came across a post that explained how to do this using dconf under the gdm user's account:

This works great and may be what some users want. However, this only changes the format of the clock on the login screen and its lock screen -- Once you log-in as a user or create a new account on the system, the user ends up with a 24-hour clock.

I then stumbled across glib-compile-schemas which provided me with a way to override the defaults provided by the settings schema. To use glib-compile-schemas I must first create a schema override file in /usr/share/glib-2.0/schemas. Because I will be overriding the clock-format value in schema id /org/gnome/desktop/interface/ I will name my file org.gnome.desktop.interface.gschema.override. It is important that the file's name ends with .gschema.override as this is required by the glib-compile-schemas utility.

Once I have defined all my overrides I can execute the glib-compile-schemas utility on the /usr/share/glib-2.0/schemas directory:

There may be some warnings displayed as there are deprecation notices for some of the keys defined by other applications. Once that was done I restarted and can see that my override has resulted in the default time format for all users, gdm included, being set to 12-hour.

Hope this helps someone else who manages systems for multiple users and likes things as automated as possible.

Monitors, keyboards, and mice oh my!

I finally did it! I installed Synergy so that I could use my multiple computers, monitors, keyboards, and mice with only one keyboard and one mouse. In other words, alleviating the need for the multiple keyboards and mice I had laying around my desk.

You are probably thinking "You could have just used a KVM switch you idiot!" You would probably be right! However, I considered this a few times in the past but the problem I ran into is that:

1. I have multiple monitors
2. I use multiple computers at the same time
3. I sometimes like to see one set of applications or widgets while working in another resource intensive application

So, in the end, it seemed that a standard KVM wasn't suited to the task. I did a bit of research a while back, looking for the perfect KVM, but never came to any conclusion as I also did not want to spend a whole lot of money on a solution that would only partially work.

In the end, I owe this all to the good folks over at the Linux Action Show as Synergy was the universal app pick on their Mysterious Blue Systems | LAS | s21e05 episode.

I installed the app today on all the systems on my desk and it has been working beautifully! The only issue that I have run into so far is trying to get used to using a single keyboard and mouse!

Going from GnuCash 2.2.9 to 2.4.5

Going from one version of an application to another is no big deal. It normally does not require one to give much thought to their existing data or configuration as it is a common expectation that the application upgrade process will take care of upgrading any required configuration or data changes that are being introduced by the new version of the application. Thus, the process is quite simple and painless.

That being said, it is always important not to take things for granted, lower your expectations, and never assume. So, be sure to make a backup of all important data and configuration before proceeding with any update or upgrade that may alter the features of the application or data the application reads and writes. I have known too many people that took this for granted and had something go wrong with an upgrade. Only to find themselves wishing they had their original data. Keep in mind that if the data is modified by the updated application, it normally will not work in the prior version of the application either. This can be true even if you didn't actually modify the data yourself. In some cases, an updated application will make changes to file formats, data structures, and data formats.

For GnuCash, backing up the application data and configuration is pretty simple when on a UNIX based platform. I can not say the same for Windows as I am not a Windows user but I have heard the process is similar.

To backup my data, all I need to do is locate my GnuCash file(s) that I want to save from a potential disaster. I am actually already doing this via automated system backups as everyone is probably already doing, but then again, there goes that assumption thing. The location of your GnuCash file will depend on where you saved it. You can identify the file name by simply looking at the window's title bar in GnuCash or using the options provided in the GnuCash File menu. Unfortunately, I do not have GnuCash 2.2.9 installed so I do not know for sure how this can be done. But, in most applications, I normally achieve this by using the File -> Save As... option -- which will normally open a dialog at the location of my existing file along with the existing file name in the File Name or Save As text field. All I should need to do is make a note of the directory and file name so that I can later retrieve it from the file system. In my case, I already know where my file is located and named so there is no need for me to dig around to find it. So first, I will create a folder to store my backup in.

1. Navigate to my Documents folder (or wherever you want to store the backup)
2. Create a new folder named GnuCash-2.2.9-Backup (or whatever you want to name it)

Now that I have a place to store the backup, I need to copy my GnuCash data file there.

1. Navigate to the folder that contains my GnuCash data file -- Documents/Finance/Household Accounts
2. Right-click on the file and select Copy -- In my case, the file is named Household.gnucash
   • Be sure to select Copy! You do not want to move it (Cut) or drag-n-drop it as this defeats the purpose of making a backup copy
3. Navigate to the backup folder GnuCash-2.2.9-Backup created previously
4. Right-click on an empty place in the folder and select Paste or select Edit -> Paste from the folder's menu

You should now have a copy of your GnuCash data file stored in your backup folder. We can now move on to configuration. The primary reason for backing up the configuration is so that if anything goes wrong with the update or we find that the upgraded version of GnuCash won't run for us, we can revert back to the older version without having to start all over. This part can become tricky as the process will vary from operating system to operating system. So, I apologize if this gives you difficulty.

1. Navigate to your home folder
2. Enable Show Hidden Files if not already
   • This is important because the GnuCash configuration directories are normally hidden
   • In Nautilus, this can be done by pressing CTRL+H or from the View -> Show Hidden Files menu
3. Right-click on the folder named .gnucash and select Copy
   • Pay special attention to the period (.) in front of gnucash
   • Be sure to select Copy! You do not want to move it (Cut) or drag-n-drop it as this defeats the purpose of making a backup copy
4. Navigate to the backup folder GnuCash-2.2.9-Backup created previously
5. Right-click on an empty place in the folder and select Paste or select Edit -> Paste from the folder's menu

We have now made a backup of our GnuCash data file (the file which contains all of the important account data) and our GnuCash configuration data which also includes any custom reports we created and information about books if using that feature of GnuCash. This is probably enough for most of us, however, depending on what features you use from GnuCash, there may be other folders that we should backup just in case. For example, if you are using or ever used the online banking feature of GnuCash, AqBanking would have been in use and contains its own configuration.

1. Navigate to your home folder
2. Enable Show Hidden Files if not already
   • This is important because the GnuCash configuration directories are normally hidden
   • In Nautilus, this can be done by pressing CTRL+H or from the View -> Show Hidden Files menu
3. Right-click on the folder named .aqbanking and select Copy
   • Pay special attention to the period (.) in front of aqbanking
   • Be sure to select Copy! You do not want to move it (Cut) or drag-n-drop it as this defeats the purpose of making a backup copy.
4. Navigate to the backup folder GnuCash-2.2.9-Backup created previously
5. Right-click on an empty place in the folder and select Paste or select Edit -> Paste from the folder's menu

There may be other configuration files or elements that I have not identified, so if you want to be really safe, backup/mirror your entire hard drive so that you can simply revert to the backup/mirror in the event that something goes wrong with the upgrade. Also, feel free to comment with other folder and file names that I have excluded so that others who should care about them can.

We are now ready to install the new version of GnuCash. Because I am using a Red Hat based Linux operating system, the upgrade is as simple as going to Add/Remove Software and telling it what I want to install and it does the rest.

1. Navigate to and select System -> Administration -> Add/Remove Software
2. In the Search field, select Search by name
3. In the Search field, enter gnucash
4. Select the Find button
5. Place a check next to the Finance management application - gnucash package -- in my case gnucash-2.4.5-1
6. Click the Apply button
7. If additional software dependencies are required, click the Continue button
8. Authenticate as the administrative user
   • If you are the only administrative user, enter your password
   • If there are more then one administrative users, select your user name in the drop-down list and enter your password
   • If there are no administrative users, you will need to enter the root user's password

Once all packages have been downloaded and installed, you are ready to fire up GnuCash.

Strangely enough, when I launched the new version of GnuCash, it told me that my saved reports have been upgraded to the new format. It then treated me as a new user of GnuCash, which I find a bit unsettling. Primarily because it knows that I have saved reports but doesn't seem to know that I have an existing data file that I have been using. No problem though, I simply opened my Household Accounts file by going to File -> Open... and navigating to the folder in which my file is stored and selecting it and clicking Open. Once my file had been opened I could see that all seems to be intact. However, I really won't know until I reconcile some accounts over the next few weeks. Because I am not 100% certain that all went as planned, I will keep my backup in a safe place for the next couple of months.

How to generate encrypted shadow password

I recently had a need to generate some encrypted passwords to store in a Kickstart file. This seemed like it should be a fairly straight forward task but it stumped me for a bit. Basically, I needed to take a plain text password and encrypt it as part of the rootpw or user option in the Kickstart file. My initial search of how to do this lead me to many quick solutions. However, upon closer look, the quick solutions only seemed to point to how to generate an MD5 hashed password. I really wanted a SHA512 hash. So, I continued my search -- And found nothing useful. Do not get me wrong. I found many ways of using PHP, database utilities, optional packages, and even some strange shell scripts that would essentially become utilities of their own. I finally gave up on my search and decided to figure it out. The search wasn't completely a waste of time because the information I gained during my search allowed me to come up with a solution. The solution was based on combining information I read within the crypt() method along with information I found on how to generate MD5 hashes.
Two simple methods, choose one that best fits your need:

python -c 'import crypt; print crypt.crypt("Red Hat", "$6$somesalt$")'

perl -e 'print crypt("Red Hat", "\$6\$somesalt\$") . "\n"'

In both methods, the first parameter value of Red Hat is my plain text password that I want to generate a hash for. The second parameter is the salt needed by the crypt() function. The salt is what is very important here. It must start out with $6$ followed by a salt value, followed by a $. The $6 tells the crypt function to use SHA512 and the second $ serves as a delimiter between the hash method and the actual salt. The last $ is needed because it is what appears in the shadow password as a delimiter between the salt and the actual hash. So, if we looked at a shadow password:

$6$somesalt$rkDq7Az4Efjo.0vtRe7E/8UXZNB6.88eMNIaqLdpmULIFkw3gDNPFnjAX4Y9fiGFzVlOyaDr1X.YYUsczCeMH.

The 6 defines the hash algorithm that was used. In this case, SHA512. The somesalt defines the actual salt that is used to generate the hash. The dollar-sign ($) is not used as part of the salt. Finally, the remaining string after the third dollar-sign ($) is the actual hash.
When invoking the crypt() method, essentially the same format applies. Within the salt parameter value, you can define the salt along with the hash algorithm to use. In the case of the perl command, the dollar-signs ($) had to be escaped.

Unmounting --rbind mounts in Linux

My latest confusion with using mount and its handy --bind and --rbind options is with unmounting such mounts. It should have been as simple as:

umount /my/mount/point

But when executing such a command I end up with:

umount: /my/mount/point: device is busy.
       (In some cases useful info about processes that use
        the device is found by lsof(8) or fuser(1))

So the error had me baffled as the mount shouldn't have been in use. I initially thought some process was grabbing a hold of it and causing me some headache. So I used lsof and fuser command to identify who was tying my mount up. It turned out that there were lots of processes tying it up. Here is a more specific example that I was working with:

mount --rbind /home /export/home

I used --rbind because /home contains a couple of mount points that I also wanted to export as part of binding /home to /export/home. Seemed simple enough. Well, after using the umount command and getting the aforementioned error I used lsof and fuser to see that just about every process from /home showed up as using both /home and /export/home.

So, I did a bit more research and found this RFE (although old): https://bugzilla.redhat.com/show_bug.cgi?id=194342

Basically it was talking about recursive binds not being able to be unmounted due to mounts inside the mount having to be unmounted first. So I immediately ran:

umount /export/home/share1
umount /export/home/share2

Yes! No error! So, now:

umount /export/home

No! The error is still there. I couldn't figure this out. I banged my head against the keyboard a few times and then decided to analyse the workaround command provided in the RFE's comments:

mount | awk '{print $3}' | grep ^/dev | sed -e s,/dev,/tmp/dev, | xargs umount
umount /tmp/dev

I plugged /home in for /dev and /export/home for /tmp/dev and executed without the xargs command on the end (I wanted to see what it was going to output):

/export/home
/export/home/share1
/export/home/share2
/export/home/user01/.gvfs

Well wouldn't you know it! I forgot about gvfs. Anyway, that prompted me to throw a quick script together. It is very raw and might not be 100% correct but it gets the job done for me and makes it so I don't have to go back and figure out where all my child-mounts are.

#!/bin/sh

MOUNTS=`mount`
OFS=$IFS

IFS=$'\n'
if [ -d "$1" ]; then
  OLDWD="`pwd`"
  cd "$1"
  rootMount="`pwd`"
  cd "$OLDWD"
else
  rootMount="${1%/}"
fi

for mount in $MOUNTS; do
  umountTgt=`echo $mount | awk '{print $3}'`
  if [ "$umountTgt" = "$rootMount" ]; then
     mountSrc=`echo $mount | awk '{print $1}'`
     umountList=$umountList`mount | awk '{print $3}' | grep ^$mountSrc | sed -e s,$mountSrc,$rootMount, `$'\n'
     for umount in $umountList; do
        if [ "$umount" != "$rootMount" ]; then
        echo "Unmounting $umount..."
        /bin/umount "$umount"
        fi
     done
  fi
done

IFS=$OFS

echo "Unmounting $rootMount..."
/bin/umount "$rootMount"

Wrong disk being used when booting from a USB stick with an encrypted root partition

I had decided to play around with installing a full blown Fedora 9 distribution to a 16GB USB flash drive. The installation went well but after the installation was done and the system restarted I found that it would not boot due to a strange issue with the root file system not being found.

It turned out that this was because I enable encryption on theroot file system. The boot loader was not able to mount the encrypted file system for some reason. After further investigation (by removing quiet from the boot command) I found that cryptsetup was attempting to open the encrypted partition on the wrong drive. In my case cryptsetup was attempting to open the encrypted file system from /dev/sdc2 which actually made sense seeing that this partition was /dev/sdc2 at install time but as this is now the boot device it is sda and my encrypted partition is at /dev/sda2.

I began to look through the configuration files in /etc to find the hard coded references to /dev/sdc2 but didn't seem to find anything that would result in this behavior. I then stopped and thought about it for a moment and quickly realized that it couldn't be anything on the root file system causing the conflict as the root file system was not being mounted at boot time. So, I then started picking a part the boot partition to see if I could find this hard coded /dev/sdc2 reference. I did find some references but they did not seem to be the cause of the problem. So, I was back to square one. There had to be something causing this problem but what was it? Out of desperation I decided that the problem may be inside one of the boot images. This thought required me to figure out how to get inside the image and see its content. This didn't take me long
because there seems to be some good references out there about unpacking or mounting a boot image. I started with initrd-<version>.img and quickly saw the actual problem. Inside the initrd image there is a script named init that gets run. It is this script that is the cause of my headaches and lead me tothe process of fixing it.

Here is what I did:

Using the Resuce CD (or another install) mount the boot and encrypted partition on the USB stick. In my case this was /dev/sdc1 (boot) and /dev/sdc2 (LUKS LVM). I used the resuce CD so my encrypted partition was mounted for me (it appeared that I had to enable networking for it to load the LUKS stuff) but the boot partition was not automatically mounted. So for me to mount it I did:

mount /dev/sdc1 /mnt/sysimage/boot 

This mounted the boot partition of my USB stick at /boot of the root file system of my encrypted partion on the USB stick. In other words, the encrypted partition (sdc2) had been mounted by the Rescue CD at /mnt/sysimage.

Changes to the boot partition:

Once mounted I made the simplest change first. I had to modify /mnt/sysimage/boot/grub/device.map and make sure hd0 was set to /dev/sda. Prior to my edit it was set to /dev/sdc which wouldn't be right if the USB stick was the actual boot media.

Changes to the root partition:

Next I fixed the /mnt/sysimage/etc/crypttab file to look for the LUKS partition at /dev/sda2 instead of /dev/sdc2.

Next I fixed the /mnt/sysimage/etc/sysconfig/grub file to look for the boot property at /dev/sda instead of /dev/sdc.

Changes to the initrd image:

Now came the hard part. The reason for the boot failure is because the initrd image (that controls boot up) has been left in charge of mounting the encrypted file system. A startup script that runs prior to any configuration from the actual root file system has a hard-coded setting for the location of the LUKS file system. To fix this you have to modify the initrd image itself.

First you need to extract the initrd image so that you can modify its contents:

mkdir /tmp/initrd-usb
cp /mnt/sysimage/boot/initrd-*.img /tmp/initrd-usb
cd /tmp/initrd-usb
gunzip < initrd-*.img | cpio -id 

You should now have the entire contents of the initrd image extracted in /tmp/initrd-usb. We now need to modify the /tmp/initrd-usb/init file and fix the hard coded /dev/sdc2 reference for the encrypted file system. In my case I found three references to sdc3. One of them was the echo statement that printed "Setting up disk encryption: /dev/sdc2" at boot time.

echo Setting up disk encryption: /dev/sdc2 

I changed this one to /dev/sda2 because I wanted the output at boot time to be accurate. The other two references were to the cryptsetup command right below the echo statement:

cryptsetup luksOpen /dev/sdc2 luks-sdc2 

I changed the /dev/sdc2 to /dev/sda2 and luks-sdc2 to luks-sda2. The luks-sda2 will be used as the name of the encrypted device in the device mapper and the /dev/sda2 is the actual partition that contains the encrypted file system.

Once I made the three changes to the init file I had to repackage the initrd image. Before repackaging though I moved the original initrd image file out of /tmp/initrd-usb so that it didn't get included in the new initrd image.

mv /tmp/initrd-usb/initrd-*.img /tmp 

Then I repackaged the initrd image:

cd /tmp/initrd-usb
find ./ | cpio -H newc -o | gzip -9 > /mnt/sysimage/boot/initrd-<kernel version>.img 

In my case <kernel version> was 2.6.25-14.fc9.i686 so my command was:

find ./ | cpio -H newc -o | gzip -9  > /mnt/sysimage/boot/initrd-2.6.25-14.fc9.i686.img 

Done!

Once that was done I exited the shell and waited for my machine to reboot. I then booted from the USB stick and sure enough all went as planned and I was up and running.

References:

http://musialek.org/?p=3

This is where I got the specific commands for repackaging the initrd image. Seemed this information wasn't as easy to find as extracting the initrd image contents.

USB Tether AT&T Tilt (WM6) to Linux Laptop (Fedora 8)

I spent sometime over the weekend trying to get my Windows Mobile 6 phone tethered to my laptop so that I could use my phone's Internet access from my laptop. This, in most cases, is a simple process but for some reason it seems a bit more difficult with WM6 on my AT&T Tilt (HTC 8925).

I had done some searching for instructions on how to do this but for the most part, came up empty handed. I should probably mention that I am attempting to tether to a laptop running Fedora 8 (Linux Kernel 2.6.23).

I will say that I found some interesting information that got me pointed in the right direction on the SuSE forums, so I must give credit where credit is due and tell you that http://suseforums.net/index.php?showtopic=41219 is where I found the actual process on how to get the tether to work. I will say that the only relevant thing here is the information on creating the network interface configuration file (ifcfg-rndis0). In my case, this file went in /etc/sysconfig/network-scripts as I am using Fedora. I did not have to get the usb-rndis-lite kernel patches from SVN like the posting indicated I needed to do but this might just be due to the fact that I have the functionality from somewhere/something else. So, if you aren't able to get it to recognize your phone as a network device when you plug in the USB cable, you might want to look at patching the kernel with the usb-rndis-lite package.

Now, here is where I stumbled for some time. In the forum posting referenced above, you are instructed to enable Internet Sharing via USB on the phone. Well, in my case (and from searching, many other cases) the utility that provides Internet Sharing functionality has been replaced by the Wireless Modem utility. From the looks and sounds of it, the Wireless Modem utility does not work. I will admit that I didn't spend too much time trying to get it to work either. I just know that my initial effort proved to go nowhere so I quickly started looking for a way to get the Internet Sharing utility installed and working.

So, I jumped back on the web and starting searching for the utility. What I ran across was many references to installing a CAB from xda-developers that would add the Internet Sharing utility. Although I hate to install applications on my phone (especially when posted on a forum) I decided that I would at least download it and pull it apart to see what it did. Well, that is when I found out that I would have to register for a forum account on xds-developers to continue with a download. Well, this isn't fun and really not fair. So, my next task was to do a search for the CAB file name itself. My thought was that someone would have to had reposted it in some other forum or blog that would not require me to sign-up for an account in order to download it. Well, no luck!

I did not give up though. I remembered that when I first got my phone a few months ago I had stumbled across some Internet or sharing utility of some kind on my phone. I just could not remember what or where I stumbled across it at. So, I began to browse my phone from WM6 File Explorer. After sometime of browsing I came up empty handed. I took a break for an hour or so and then started browsing again. My second browse turned success.

It turns out that Internet Sharing is already installed on my AT&T Tilt (and probably other WM6 devices that are in the same situation). The utility just isn't accessible from the Start menu or Programs/Settings. But this is an easy fix! No need to install or run some custom CAB from some forum posting. Instead, just add the shortcut that already exists on your phone to the Start menu or to Programs. It is that simple!

The shortcut for Internet Sharing is named, wait for it... Internet Sharing. And it is located in the Windows directory. If for some reason you do not have the Internet Sharing shortcut already created on your device in the Windows directory, maybe you can use the IntShrUI shortcut. And if that shortcut doesn't exist, maybe just create your own shortcut referencing the program file name IntShrUI (also located in the Windows directory).

In my case, I simply copied /Windows/Internet Sharing to /Windows/Start Menu/Programs/Tools. Then I was done. I could then start Internet Sharing by going to my Start menu and selecting Programs and then Tools and then Internet Sharing.

Now that I had Internet Sharing up and running on my phone, I could enable it as instructed in the forum posting. Once I did this and created my network interface configuration file (ifcfg- rndis0) I plugged my phone into my laptop via USB and sure enough, I had a new network interface named rndis0 that now had an IP address of 192.168.0.102. Not only did my WM6 phone give my laptop and IP address, it also took care of DNS by giving my laptop a DNS address of 192.168.0.1 (which also happens to be the gateway address).

My next goal is to get this working via Bluetooth. I just like the idea of having my phone on my hip and checking my e-mail from my laptop without the need of pulling on the USB cable or hooking anything up. Of course, if I do get it working via Bluetooth, I would only use such a connection for limited or short sessions. USB is a much better solution as it is a bit more secure and my phone can charge while I am using its Internet access.