Last Friday, I was greeted by the unfortunately behaviour that my mouse stopped working. I checked my yum logs, and the culprit looked to be some recent updates to Xorg.
Looks like I guessed correctly. Someone was nice enough to post details about the problem, and how to fix it.
Thank you twilightomni!
Monday, September 22, 2008
Friday, September 19, 2008
Changing the gnome-keyring-password on Fedora 9
Fedora 9 improved its integration with the Gnome Keyring Manager over Fedora 8, in that your login password is used to automatically unlock the login keyring.
Which works great... until you change your login password. Changing the keyring password is similar to what one would do on Ubuntu, but a bit different.
Which works great... until you change your login password. Changing the keyring password is similar to what one would do on Ubuntu, but a bit different.
- Install seamonkey
sudo yum -y install seamonkey - Run it
seamonkey - Edit->Preferences->Password Keyrings
- Select the 'login' keyring, and click 'Change Unlock Password'
Saturday, February 23, 2008
Living in a virtual world
I have been extremely happy running Fedroa 8 on my ThinkPad T61. Dual screen works when I'm docked; wireless works around the house; all Linux, all the time. There are, unfortunately, a couple of minor hiccups.
The IT department at work is very Windows centric. The wireless is WPA2, using MSCHAP/PEAP for authentication. This should work with F8, but I can't quite get the config right. Then there's the VPN - it's this Windows only CheckPoint client. I think this is standard IPSec/IKE, so I should be able to divine out the config necessary to setup OpenSWAN. But I've yet to be successful figuring it out.
I've kept the Windows partition around for those few apps that I use that are Windows only. When I need wifi at the office, or VPN on the road, I just boot into Windows and I get it. But there's all of this Linux-y goodness on my laptop that's inaccessible; potential waiting to be tapped. And since I used LVM, not even tools that allow reading ext3 partitions work.
So what's a guy to do? I finally decided to try booting my Linux partition within VMWare, with Windows as the host OS. Things worked out much better than I expected.
For those adventurous enough to try this themselves, let me cover a few of the highlights.
Take ample backups before you begin. It's entirely possible that you could trash your Windows partition, your Linux partition, or even both. A small USB/Firewire drive and an hour or two to run the backups are all you'll need for the peace of mind that you can recover from such a dangerous undertaking.
Be sure your system boots into Linux by default. Windows is the VMware host, and with this setup, you could boot the very same partition under the VMware guest. This would wreak untold havoc, and is best avoided. Even if you configure the bootloader to prompt forever asking you to make a choice, make sure that the default choice is not the VMWare host. Besides, you only run Windows when you have to; right :-)
Be prepared to tweak your X settings. X configuration is probably the last bit of voodoo/black magic/unholy art within the usual operation of a Linux server that I know almost nothing about. (Well, that and Sendmail. Oh, yeah, and Bind. Maybe I'm not as smart as I thought...) But, as soon as you boot into VMware, X will fail to startup and you'll be staring at X's debug messages, thinking that a world of 80x24 really couldn't be all that bad. I was able to get to a not-quite-miserable place, where I can get displays to work for both native and VMware boots, with only a single line change to a config file when needed. (And a special thanks to the Gentoo guys who already did this sort of thing).
Use a NAT network interface instead of a bridge. Normally, in VMware, you want your guest NIC to be bridged. However, on a laptop this is less than ideal. I'm not sure the virtual NIC will adjust as the real network adjusts. And I'm certain that it would not have access to the VPN, which is the main point of this exercise. So go with a NAT interface. You won't be able to access the virtual guest from anywhere but the VMware host, and you will have trouble with non-NAT friendly protocols. But I'm willing to bet that's less trouble than the alternative.
Disable snapshots. While the VMware snapshot facility sounds nice, it doesn't work so well when you boot directly into the virtual guest. Go ahead and turn it off in the virtual machine settings; you won't miss it.
Add a sound device. With this and fullscreen mode, you'll be asking yourself "Is it live, or is it VMware?"
I was surprise that I didn't have any more trouble than I did. I have the Windows partition mounted within Linux, but it recognized that it wasn't cleanly unmounted and refused to mount. The VMWare NIC shows up as eth1. I didn't even have to install VMware Tools for the mouse to auto-transition to and from the VMware console.
The IT department at work is very Windows centric. The wireless is WPA2, using MSCHAP/PEAP for authentication. This should work with F8, but I can't quite get the config right. Then there's the VPN - it's this Windows only CheckPoint client. I think this is standard IPSec/IKE, so I should be able to divine out the config necessary to setup OpenSWAN. But I've yet to be successful figuring it out.
I've kept the Windows partition around for those few apps that I use that are Windows only. When I need wifi at the office, or VPN on the road, I just boot into Windows and I get it. But there's all of this Linux-y goodness on my laptop that's inaccessible; potential waiting to be tapped. And since I used LVM, not even tools that allow reading ext3 partitions work.
So what's a guy to do? I finally decided to try booting my Linux partition within VMWare, with Windows as the host OS. Things worked out much better than I expected.
For those adventurous enough to try this themselves, let me cover a few of the highlights.
Take ample backups before you begin. It's entirely possible that you could trash your Windows partition, your Linux partition, or even both. A small USB/Firewire drive and an hour or two to run the backups are all you'll need for the peace of mind that you can recover from such a dangerous undertaking.
Be sure your system boots into Linux by default. Windows is the VMware host, and with this setup, you could boot the very same partition under the VMware guest. This would wreak untold havoc, and is best avoided. Even if you configure the bootloader to prompt forever asking you to make a choice, make sure that the default choice is not the VMWare host. Besides, you only run Windows when you have to; right :-)
Be prepared to tweak your X settings. X configuration is probably the last bit of voodoo/black magic/unholy art within the usual operation of a Linux server that I know almost nothing about. (Well, that and Sendmail. Oh, yeah, and Bind. Maybe I'm not as smart as I thought...) But, as soon as you boot into VMware, X will fail to startup and you'll be staring at X's debug messages, thinking that a world of 80x24 really couldn't be all that bad. I was able to get to a not-quite-miserable place, where I can get displays to work for both native and VMware boots, with only a single line change to a config file when needed. (And a special thanks to the Gentoo guys who already did this sort of thing).
- move /etc/X11/xorg.conf to xorg.conf.bak
- restart X (init 4; init 5)
- login; run system-config-display
- configure the display as you like it, this will generate a new xorg.conf
Use a NAT network interface instead of a bridge. Normally, in VMware, you want your guest NIC to be bridged. However, on a laptop this is less than ideal. I'm not sure the virtual NIC will adjust as the real network adjusts. And I'm certain that it would not have access to the VPN, which is the main point of this exercise. So go with a NAT interface. You won't be able to access the virtual guest from anywhere but the VMware host, and you will have trouble with non-NAT friendly protocols. But I'm willing to bet that's less trouble than the alternative.
Disable snapshots. While the VMware snapshot facility sounds nice, it doesn't work so well when you boot directly into the virtual guest. Go ahead and turn it off in the virtual machine settings; you won't miss it.
Add a sound device. With this and fullscreen mode, you'll be asking yourself "Is it live, or is it VMware?"
I was surprise that I didn't have any more trouble than I did. I have the Windows partition mounted within Linux, but it recognized that it wasn't cleanly unmounted and refused to mount. The VMWare NIC shows up as eth1. I didn't even have to install VMware Tools for the mouse to auto-transition to and from the VMware console.
Wednesday, February 6, 2008
Subversion+Kerberos, without the realm!
We're using Subversion with Kerberos authentication here at work. I love having one-password-to-rule-them-all, but having the @REALM show up in the Subversion log is a bit of a pain. Today I came up with a solution.
It's very simple. I use a post-commit script to change the author revprop. The change in post-commit is quite trivial:
It's very simple. I use a post-commit script to change the author revprop. The change in post-commit is quite trivial:
What's not so trivial is the change to pre-revprop-change. I wanted to ensure that only the change from user@REALM to just plain user was allowed.#
# strip Kerberos realm from svn:author
#
OLD_AUTHOR=$(svn pget svn:author file://$REPOS --revprop -r $REV)
NEW_AUTHOR=$(echo "$OLD_AUTHOR" | sed "s/$REALM//")
svn pset svn:author "$NEW_AUTHOR" file://$REPOS --revprop -r $REV
NEW_VALUE=$(cat)
# ...
#
# Stripping Kerberos realm is allowed
#
if test "$ACTION" = M -a "$PROPNAME" = svn:author; then
OLD_AUTHOR=$(svnlook pget "$REPOS" svn:author --revprop -r $REV)
echo "NEW: $NEW_VALUE"
echo "OLD: $OLD_AUTHOR"
ALLOWED_NEW_AUTHOR=$(echo "$OLD_AUTHOR" | sed "s/$REALM//")
if test "$NEW_VALUE" = "$ALLOWED_NEW_AUTHOR"; then
# allowed author change
exit 0
fi
echo "svn:author $OLD_AUTHOR may only be changed to $ALLOWED_NEW_AUTHOR" >&2
exit 1
fi
Friday, January 25, 2008
Making peace with NetworkManager
Being new to the Linux laptop scene, I've struggled with getting the network settings just right. I've always been more comfortable with text config files, but switching wireless networking settings is something that's best handled in a UI.
I've finally tweaked the network config and NetworkManager settings to behave properly.
I enabled the NetworkManager service: chkconfig NetworkManager on. Now whenever Gnome starts there's a little networking icon in the Notification Area. From there I can left-click to switch networks, config wireless, etc.
Next I took care of the delayed boot time when disconnected from the network (waiting for dhclient to time out). I disabled 'Activate device when computer starts' on both eth0 and wlan0. This can be done by system-config-network, or by editing /etc/sysconfig/networking/devices/ifcfg-{eth0,wlan0}. If I ever need network access from a non-GUI login, I simply ifup eth0.
The biggest difference that annoyed me was NetworkManager ignoring the Fedora init script's DHCP client config /etc/dhclient-eth0.conf. We have Win2k3 DNS/DHCP servers, so I need send fqdn.server-update and send host-name clauses in the dhclient config. The short story is, whenever NetworkManager started the interface, no one could resolve my laptop's name.
I finally discovered that NetworkManager uses /etc/dhclient.conf. I add the two magic lines to that file, point, click, I'm good to go.
Networking, finally, 'just works'.
I've finally tweaked the network config and NetworkManager settings to behave properly.
I enabled the NetworkManager service: chkconfig NetworkManager on. Now whenever Gnome starts there's a little networking icon in the Notification Area. From there I can left-click to switch networks, config wireless, etc.
Next I took care of the delayed boot time when disconnected from the network (waiting for dhclient to time out). I disabled 'Activate device when computer starts' on both eth0 and wlan0. This can be done by system-config-network, or by editing /etc/sysconfig/networking/devices/ifcfg-{eth0,wlan0}. If I ever need network access from a non-GUI login, I simply ifup eth0.
The biggest difference that annoyed me was NetworkManager ignoring the Fedora init script's DHCP client config /etc/dhclient-eth0.conf. We have Win2k3 DNS/DHCP servers, so I need send fqdn.server-update and send host-name clauses in the dhclient config. The short story is, whenever NetworkManager started the interface, no one could resolve my laptop's name.
I finally discovered that NetworkManager uses /etc/dhclient.conf. I add the two magic lines to that file, point, click, I'm good to go.
Networking, finally, 'just works'.
Thursday, January 24, 2008
Dual Head on ThinkPad T61
I've been running Fedora 8 on my ThinkPad T61 since November, and I've been reasonably happy with it.
The most irksome thing about the setup is that I had the hardest time getting both the DVI and VGA displays running as an extended desktop. Until now!
I still haven't worked out the vagaries of getting X configured, but once I'm at the desktop, it's a simple matter of
Update: In tweaking xorg.conf, I realized that it's necessary to add the clause Virtual 3200 1200 to Section "Screen", SubSection "Display". Without it, xrandr gives errors about max screen size.
The most irksome thing about the setup is that I had the hardest time getting both the DVI and VGA displays running as an extended desktop. Until now!
I still haven't worked out the vagaries of getting X configured, but once I'm at the desktop, it's a simple matter of
xrandr --output VGA --autoSpecial thanks to the folks at intellinuxgraphics.org who led me down the path of multi-monitor bliss!
xrandr --output VGA --right-of TMDS-1
Update: In tweaking xorg.conf, I realized that it's necessary to add the clause Virtual 3200 1200 to Section "Screen", SubSection "Display". Without it, xrandr gives errors about max screen size.
Welcome, fellow monkeys!
I've had a personal blog for quite some time now. Lately I've felt the need to write about technology related stuff, but it didn't seem quite appropriate for The Way. So, here's my new blog. This will focus pretty much on software and technology related items I come across during my day.
Your feedback is appreciated :-)
Your feedback is appreciated :-)
Subscribe to:
Posts (Atom)
