Wednesday, August 29, 2012

Google Music Manger for Linux Finally Plays Nice with Two Factor Authentication

For some time now the Linux version of Google Music Manager has been a pain to use with two factor authentication enabled.  Until now there was no way to enter the two factor verification code, so the only way to log in with two factor enabled was to use an  impossible-to-remember application specific password.   But the problem with that was that there was no way to have Music Manager save the password for the subsequent log-ins... so every time I started it I would have to look up the password to log in.

Today that has all changed after updating to google-musicmanager-beta-1.0.43.6722-0. When Music Manger asked me to log in I took a chance and tried using my "normal" Google password.  To my surprise a window appeared asking me for my verification code.  After entering the code I was in... no more looking up that application specific password to log in!  I also tried stopping and restarting it and it logged back in without asking me for my password again... it finally remembers me!

Thanks Google for showing a little bit of love to us Linux nerds!


Saturday, August 4, 2012

Some of My Girls

Took some pictures of a few of my girls last week.  Here are a few of them:




Back to Blogger

For the past few years I have been hosting this using Wordpress on a Godaddy hosting account that I was using for other purposes.  I no longer need the hosting account so I have moved back to Blogger.

Wednesday, February 13, 2008

Google Apps and External Jabber/XMPP Servers

Background: I have a couple of domains that I am using with Google Apps. Google Apps includes Google Talk, which is Google's Jabber/XMPP based Instant Messaging. I also have a normal GMail account that also includes Google Talk. While experimenting with an IM interface to Twitter I found that although Google Talk in my normal GMail account could talk to other Jabber systems, Google Talk in my Google Apps account could not.

I found the answer in Kavinda Munasinghe's Blog, and in two Google documents (here) and (here).

As I understand it Jabber/XMPP uses DNS entries to find the servers needed to talk to another domain. For example, if you want to talk to joe@example.com, your Jabber server will use DNS to look up service (SRV) records for the jabber/xmpp service in the example.com domain. Here is an excerpt from the ejabberd documentation regarding the SRV records:

There are 3 SRV records that can be created for a Jabberd installation:

     _jabber._tcp.   ->    .:5269
_xmpp-server._tcp. -> .:5269
_xmpp-client._tcp. -> .:5222

The first and second of these specify the host and the port for server-to-server (s2s) communications. There are two listings for this because the new XMPP protocol, regarding SRV records, is replacing the older Jabber standards. The third listing above specifies host and port for unencrypted client communications (c2s).

Putting it all togehter, the records needed for a Google Apps domain (example.com) are:
_xmpp-server._tcp.example.com. IN SRV 5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp.example.com. IN SRV 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server._tcp.example.com. IN SRV 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server._tcp.example.com. IN SRV 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server._tcp.example.com. IN SRV 20 0 5269 xmpp-server4.l.google.com.
_jabber._tcp.example.com. IN SRV 5 0 5269 xmpp-server.l.google.com.
_jabber._tcp.example.com. IN SRV 20 0 5269 xmpp-server1.l.google.com.
_jabber._tcp.example.com. IN SRV 20 0 5269 xmpp-server2.l.google.com.
_jabber._tcp.example.com. IN SRV 20 0 5269 xmpp-server3.l.google.com.
_jabber._tcp.example.com. IN SRV 20 0 5269 xmpp-server4.l.google.com.
_xmpp-client._tcp.example.com IN SRV 5 0 5222 talk.l.google.com
_xmpp-client._tcp.example.com IN SRV 20 0 5222 talk1.l.google.com
_xmpp-client._tcp.example.com IN SRV 20 0 5222 talk2.l.google.com
_xmpp-client._tcp.example.com IN SRV 20 0 5222 talk3.l.google.com
_xmpp-client._tcp.example.com IN SRV 20 0 5222 talk4.l.google.com


Monday, February 11, 2008

Friday, January 25, 2008

Shrinking a Linux LVM Partition

This is a work-in-progress as I am figuring this out as I do it.

I have a notebook computer that has linux on it (Fedora 8). At one time I had it set up to dual-boot linux and XP, but when I purchased a larger drive for it I figured I would use the old drive for XP and the new drive for linux and just swap them around when I want to change OS. That was stupid. It is way too much of a hassle to swap the drives around so now I almost never use XP. The problem is that once in a while there is an application I would like to use that only runs in windows and dows not work well in Wine.

So now I want to move things around on the drive to make room for a Windows partition. Here is what I currently have:

Laptop Hard Drive: 160GB: 19457 cylinders of 16065 * 512 bytes.

DeviceStartEndUsage
/dev/sda1125Linux xt3 /boot
/dev/sda22616000Linux LVM
--1600119457Unallocated


I also have a 250GB USB Hard Drive: 30401 cylinders of 16065 * 512 bytes.

DeviceStartEndUsage
/dev/sdb115009NTFS (Copy of XP partition from my original drive)
/dev/sdb251005112Linux ext3 /boot (from old drive)
/dev/sdb3511312161Linux lvm (from old drive)
--1216230401Unallocated



The layout of the LVM Physical Volume is as follows:

LogVolRoot0 - 625 extents (Fedora 7 root)
(unused) - 625 extents
LVFedora8 - 625 extents (Fedora 8 root)
LogVolSwap - 62 extents
LVHome - 1948 extents
(unused) - 878 extents



I decided to try using the Logical Volume Management GUI tool to try to move things around. First I created an LVM partition on the unallocated portion of the USB hard drive (/dev/sdb4). I did this by going to the "Uninitialized Entries" section of the tool, expanding the /dev/sdb entry, selecting "Partition 4" and then selecting "Initalize Entry".

Next I selected the physical view of my volume group, than on the diagram I selected the extents of one of the Logical Volumes that I wish to move around (LVHome), and then selected "Migrate Selected Extents from Volume". This gave me a windows that allowed me to choose where to put the extents... I chose the LVM partition on /dev/sdb4. This took quite a while to complete. It is kind of amazing that it even worked while the volume was active and the file system mounted and in-use.

Next... the same thing for LVFedora8. This is a little scary since this is the root volume that I am currently running on. This took a while too... and the system is still running.

Next, I am going to move the LVFedroa8 volume back, and hope it puts it at the open space towards the front of the partition (right after LogVolRoot0). Ok... well that did not quite work =(. It put it right back where it was. Next I will try moving it to the USB drive, and then moving it back with the "contiguous" option selected. Fingers crossed... Nope! Once again it put it back where it was originally. I may have something to do with the allocation policy that is configured on the Volume group... but I think I found a different way to do this...

While the move was going on I opened up a shell windows and did a ps. I saw that it was using the "pvmove" command to move the data:

/usr/sbin/pvmove --alloc contiguous /dev/sdb4:1948-2572 /dev/sda1

Looking at the man page for pvmove revealed that I can specify which tracks I want to use in both the source and destination. I am going to try to use the pvmove command to do this instead of using the gui.

At first, I tried using the same disk as the source and destination... just moving to a different location. This did not work. Here is what did work:


  1. /usr/sbin/pvmove --interval 30 --name LogVolSwap /dev/sda2:1875-1936 /dev/sdb4
  2. /usr/sbin/pvmove --interval 30 --name LogVolSwap /dev/sdb4:1948-2009 /dev/sda2:624-686
  3. /usr/sbin/pvmove --name LVFedora8 --interval 30 /dev/sda2:1937-2561 /dev/sdb4
  4. /usr/sbin/pvmove --name LVFedora8 --interval 30 /dev/sdb4:1948-2572 /dev/sda2:686-1311
  5. pvresize --setphysicalvolumesize 100G /dev/sda2
  6. fdisk /dev/sda (delete and recreate partition 2 as a smaller size, create 3rd partition for XP)
  7. pvresize /dev/sda2
  8. /usr/sbin/pvmove --name LogVolHome --interval 30 /dev/sdb4:0-1947 /dev/sda2
A few general notes on pvmove: The --interval 30 tells is to display a status on the terminal every 30 seconds, --name LogVolSwap tells it to only move tracks that are within the specified source that are also part of the LogVolSwap logical volume.

Line 1: This is moving the swap LV from the interal drive (sda1) to the USB drive (sda2).
Line 2: Move the swap back to the internal drive, but put it in the first unused portion of the partition (tracks 686-1311).
Line 3: Move the Fedora 8 LV from the internal drive to the USB drive.
Line 4: Move Fedora 8 back to the internal drive, but starting at the first free track.
Line 5: Resize the LVM physical volume to a size smaller than we are going to make the partition (for now)
Line 6: Resize the partition with fdisk.
Line 7: Resize the LVM physical volume up to the partition size (don't specify a size and pvresize will make it fit in the partition).
Line 8: Move the Home LV from the USB drive to the internal drive.

Now I dd the XP partition from the USB drive to /dev/sda3, edit by grub.conf to chainload, reboot and ... it doesn't work. :(

Possible problems...
- The XP partition is too far into the drive to be bootable (I have heard rumors of a limit around 130GB)
- XP doesn't like the fact that it is on a different partition
- I messed up copying XP

Thats as far as I got before I ran out of time. I'll keep this out here as a starting point in case I come back to this later.

Thursday, September 13, 2007

Picture