Accessing shared music from Fedora on iTunes

At work, I have my music collection on my Fedora desktop. At times I’ve wanted to access this library on my Mac Book Air but have been unable to do so given they are on two separate subnets (and DAAP is a broadcast protocol). The solution was Network Beacon.

In short:

  1. Ensure your DAAP server is accessible. For Rythmbox, enable/configure the DAAP Music Sharing plugin (be sure to click the ‘Share my music’ checkbox for the plugin).
  2. Make sure port 3689 is open on your Linux firewall if necessary.
  3. On the Mac, download and install Network Beacon and configure a new beacon thusly:
    1. Beacon Enabled: Yes
    2. Service Name: [string of your choice]
    3. Service Type: _daap._tcp
    4. Port Number: 3689
    5. Enable Host Proxy: Yes
    6. Host Name: [full hostname]
    7. IP Address: [duh]
  4. Now you should be able to open iTunes and see the DAAP share appear in the SHARED section. Note that Network Beacon must remain running for iTunes to see the remote share.

Note that if the machines were on the same subnet you should be able to skip Network Beacon entirely and just enable the DAAP Music Sharing and punch the hole through the Linux firewall.

cygwin does not like UNC paths in %PATH%

For the past few days I’ve been troubleshooting agonizingly slow SSH login performance into cygwinized Windows Server 2008r2 clients. And when I say slow, I mean 1+ minutes to bring up a prompt.

I finally narrowed the problem down to the machines having UNC paths in the system’s %PATH% environment variable (and thus inherited by the cygwin environment). Despite the UNCs being valid and accessible, cygwin was not happy about having them present. Removing them from the system %PATH% and bouncing the CYGWIN sshd service reduce the login times down to a more modest 3-4 seconds.

I’m unsure if this is isolated to the version of cygwin being used, Windows Server 2008r2’s interaction with UNC paths, or some combination thereof but the solution was simple once I figured it out.

gridengine qmon font problems

Even after you get gridengine installed, you’ll have some lovely font problems when using qmon. After trying a few things, the easiest is just to follow the advice at this web page and set the fonts to fixed. Note that copying $SGE_ROOT/qmon/Qmon to $HOME is an important part — updating the file directly won’t work. This should be done on the system with the qmon binary (should be obvious, but you never know).

If you decide to try and fix the fonts themselves, remember that the fonts need to exist on the Xserver rendering the qmon dialog, not necessarily the one on the system where qmon is being run from. In other words, if you’re doing X11 forwarding from a remote host to your desktop, it’s your desktop’s X11 server that needs the fonts, not the fonts on the remote host. Thanks to this post clarifying that pesky detail.

And finally, if you decide to poke around and get non-fixed fonts working, you’ll probably need these RHEL packages (via):

  • xorg-x11-font-utils
  • xorg-x11-fonts-100dpi
  • xorg-x11-fonts-75dpi
  • xorg-x11-fonts-misc

and possibly futzing with xfs and fc-cache. I tried this approach and fixed the initial error messages from the X server (yay!) but resulted in boxes instead of glyphs (boo) and failed back to fixed fonts.

gridengine RPM for RHEL5 (and CentOS 5) is broken…

…and here’s how you fix it.

After installing gridengine, before running install_sge (or install_qmaster / install_execd):

  1. edit /usr/share/gridengine/util/install_modules/install_common.sh
  2. find the CreateGSEStartUpScripts() function and nuke the entire contents of the “if [ $create = true]; then” up until (but not including) the “if [ $euid = 0 …]” line.
  3. save and exit the file
  4. edit /usr/share/gridengine/util/install_modules/install_qmaster.sh
  5. find the StartQmaster() function and change the ‘$SGE_STARTUP_FILE -qmaster’ line to read ‘/etc/init.d/sgemaster’ and remove the remaining contents of the function up until (but not including) the ‘$INFOTEXT …’ line
  6. save and exit the file

Now you can run the appropriate installation program.

The problem is that the RHEL5 packaging tries to remove the gridengine startup scripts and replaces them with its own startup scripts. Sadly the job wasn’t well done (and obviously wasn’t tested). I’ve notified the package maintainers but this will get you going until the package has been fixed (given that the package has existed in this form since 2008, I’m guessing it isn’t that popular of a package as-is).

Introducing Seregil, my new MacBook Pro

Yesterday I received my new 15″ MacBook Pro from FedEx and I’m sure I’ll be spending the next several evenings getting it all set up. I’ve christened it Seregil from the character of Lynn Flewelling’s Nightrunner series. (I always name my computers from characters in books — usually those I’m reading or have read recently.) It is spec’d out thusly:

  • MacBook Pro
  • 15″ high-density anti-glare screen
  • i5 2.4GHz CPU
  • 8GB RAM
  • 128GB SSD

For the past 4 years I’ve used Linux systems exclusively and when it came to purchase a new computer I decided to jump to Mac. Moving to Linux from Windows was the most productivity-enhancing change I’ve ever made and I’m hoping the swap to Mac doesn’t set me back. What appeals to me so much about Macs is that they have the classic unix underpinnings with an elegant GUI.

Currently I have a Windows VM which I use solely to put music on my iPhone. That’s going straight to /dev/null. Instead I’ll be creating a Fedora 13 (14?) VM as a backup for those things that just need a Linux touch to them. For instance, I’m going to give Apple Mail a chance, but if it just doesn’t pan out, I’ll run Evolution on the VM using VMware Fusion with Unity. I’m interested to see if The Gimp, Inkscape, and other X-Windows dependent apps behave better running in the VM rather than directly on the OS X X-server. While they function well, they just aren’t really integrated into the OS X UI.

I already have Adium, Unison, Moneydance, LibreOffice (aka: OpenOffice), and Chrome installed and configured. My iPhone library is moved over and correctly synching with my phone thanks to a bit of work getting the Library IDs sync’d between the two. Now to get VMware Fusion installed and that Linux VM created.

Fedora 13: taking the plunge on the laptop

Fedora 13 was released yesterday and I’ve decided to take the plunge on the laptop and upgrade it from Fedora 12. After I kick the tires for a bit I’ll upgrade my desktop.

The last time I did this I was frustrated that I had to download all of the packages twice, once for each system. This time around I decided to fix that. I discovered this page that talks about various methods of caching the download after the first time. My initial thought was to use the “rsync /var/cache/yum and keepcache=1” approach as it’s by far the easiest to implement. The problem is that the IBM script that wraps around preupgrade to make sure that all the IBM pieces get upgraded/added properly has a nasty habit of ‘yum clean all’ing at inconvenient times if you need to restart preupgrade which would clear the cache (yes that’s a defect, they don’t seem interested in fixing it).

So instead I thought I’d go with just the ‘Squid with cache’ route. That doesn’t work nearly as well as one would hope due to all the various mirrors that could be used. The raw Squid cache might work well for a large organization but doesn’t hack it for what I want.

I ended up with the ‘Squid with IntelligentMirror‘ approach which seems to be working well so far. The RPMs are still being downloaded onto the laptop but I’ve validated they’re correctly being stored on the desktop so when I get ready to upgrade it, the process should be significantly faster.

As a reminder to myself: use the intelligentmirror-0.5 package and not the intelligentmirror-1.0.1 package, despite what this file says. The 1.0.1 package just serves up the pre-cached files but doesn’t actually do the caching.

Making your monitor easier on the eyes

As someone who sits in front of his computer at least 8 hours every day, I’m pretty picky about my monitors. Three years ago I forked out my own money for two 1600×1200 LCDs from Dell and love them. Oddly I’ve never poked around with the monitor’s color temperatures.

Yesterday I stumbled, via slashdot, over Redshift. This little jewel adjusts the color temperature of your monitor to match the level of the sun throughout the day at your particular location on the earth. In other words, the color temperature of the monitor subtly changes throughout the day: warmer in the mornings, cooler during the day, warmer in the nights. (The “cool” and “warm” labels make intuitive sense if you see the colors — the warmer colors have a red cast to them and the cooler colors have a blue cast to them —  although they are opposite of the actual color temperature measured in Kelvin and the actual temperatures outside at that time of the day.)

The first time I used it the change was very abrupt. By default my monitors have a very cool, almost icy blue, color. Redshift adjusted that up to a warmer color. Determined to give it some time I used my computer throughout the rest of the day and in all honesty forgot about it. The color setting was retained from the overnight hibernation and I decided that I liked the change enough to change my system such that it starts Redshift when my X-windows session starts. Doing so required stopping it, which adjusted the colors back to the defaults, and starting it back up again. Wow – the difference (excuse the pun) is night and day. The default icy blue color was noticeably harsher on my eyes.

I’m probably going to adjust the coolest color to be a bit blue-er but overall I think I’ve had less eye-strain yesterday and today.