Autotitles in screen.

This comes in really handy in ~/.screenrc:

shelltitle '$ |bash'

Then add this in ~/.bashrc:

export PROMPT_COMMAND='[ "$TERM" == "screen" ] && echo -n -e "\033k\033\\"'

Restart screen in a fresh bash session and enjoy.

UPDATE: I stupidly screwed up the screenrc line because I did it from memory instead of copypasta. No cookie for me!

UPDATE #2: Aha, found that something in the innards of my blog software was removing an extra backslash that was needed in the export command above. Sorry for the mess.

Fedora and RHEL network configuration files.

It’s not as well known as it should be, but there’s a great source of documentation for the ifcfg-<interface> files that provide network settings in some configurations. NetworkManager has the ability to interpret these settings as well.

If you look in the online documentation for the initscripts package, you’ll find a file called sysconfig.txt that has a listing of all the parameters in ifcfg files that are parsed by your system’s startup (init) scripts. This can be really helpful when you have to write a network configuration file from scratch, or you want to know what the legal values are for a specific variable. For instance, on my Fedora 15 system, this file is found at: /usr/share/doc/initscripts-9.30/sysconfig.txt

Hopefully this information is helpful to some readers, since it came up today in a conversation with someone at Ohio Linux Fest whom I consider to be highly skilled and educated sysadmin.

New Logitech H555 details.

In reference to my earlier post, I picked up my replacement H555 headset this weekend and wanted to share the changes I noticed from the earlier model I previously owned. Some changes are good, some are not.

Pros: The headset band is now a little thicker — this might make the newer one just a little less prone to breakage if you dropped it from a great height or if someone who didn’t weigh a lot sat on it. All the previous adjustments are still available. Also, although the microphone stalk is about the same size, the mic housing itself at the end of the stalk is a little bulkier. This probably contributes to a little better noise reduction, which I’ve noticed in casual use thus far.

Same: The general mic sound quality is the same. It’s quite good for VoIP and casual use in screencasts, but of course not as good as a quality microphone.

Cons: The hard case that used to come with this unit was not included in the retail package that I purchased. The new headset fits just fine in my existing case, so this is wasn’t a deal breaker for me. Unfortunately people purchasing this for the first time will only get a carrying bag which doesn’t protect the unit as well. Also the detachable dongle that used to convert the unit from dual TRS 1/8″ plugs to USB has been changed into a non-detachable, USB only plug. If you were hoping to use the headphones with other standard audio jacks, you’re out of luck.

I’m still happy with the quality of the headset, and overall I think it’s a good purchase. The new USB hookup is now recognized by my Fedora 15 box as a “Logitech H555 headset,” so I expect the audio hardware inside is updated slightly. It seems to work perfectly just as the old one did. Just be aware of the above changes if you intend to buy one.

Logitech H555 headset.

UPDATE Aug. 15, 2011: There have been a few changes to the new model, which you can read in this additional post.

Continuing with another “gear I like” post… Yesterday my Logitech H555 headset finally gave up the ghost. I’ve had this USB headset for about three and a half years, which may be a record for me. I’m very tough on wired things where I have a propensity for yanking on the cord. I’ll routinely do clumsy things like try and walk away with it still attached to both my laptop and my head, or drop the headset on the floor, or get it tangled up with other things on my desk. So it’s a wonder it survived this long, and a testament to how good the product is.

I greatly prefer using a headset to relying on a laptop’s internal mic and speakers. Those internal sound devices can make conference calls and even point-to-point contacts painful because the person on the other end can get a lot of echoes, typing clatter, and environmental noise. A headset may make you look like a Time/Life operator (“Can I take your order?”) but it really makes business dealings more professional and your personal chats more pleasant.

The sound is fantastic, and I find it to be very comfortable to wear for extended periods since it has dual adjustable earpieces with thick pads. It’s not as comfortable as a great set of over the ear studio monitor headphones, but those aren’t really as portable. This headset can fold up into a convenient carrying case (sized just right for a nice Fedora logo sticker!) which makes it highly portable and unlikely to be damaged in transit.

The connection from the headset is actually via two 1/8-inch TRS plugs — one for the stereo headphones, and one for the microphone. You could plug that into a large number of laptops that have separate headphone and mic connectors. Why TRS for the mic then? Ah, that’s where the magic comes in. There’s a USB dongle into which you can plug the leads and that allows the mic to become a noise canceling, low-powered condenser. The resulting sound from the mic is very clear, which makes my VoIP calls comprehensible to folks on the other end of the conversation. You can also use it for screencasts and podcasts, although of course the sound won’t be as good as a professional large condenser type microphone.

But how does it work with Linux? Spectacularly. It’s automatically recognized on every Fedora I’ve used it with, starting with Fedora 9, as a USB audio device. I can use PulseAudio to easily control the volume on the mic and headset — and if that’s inconvenient for some reason the headset cord has a mini control which allows me to vary the headset volume with a rotary dial, and mute the mic with a slider switch. The control is at a perfect location, not too close to my neck and not too far away to find when I’m in the middle of a conversation.

By the way, I don’t shill for Logitech or anyone else. This is just a gadget that has made my life easier. I use the H555 daily, usually for several hours, on voice-over-IP softphone calls. Now that Google+ has a neat Hangout feature for multi-party video conferencing, I sometimes use the headset with that app as well. Hopefully this post will help someone have an easier time choosing a device to suit their needs.

Fedora 15 rocks on ThinkPad.

On Friday my new Lenovo ThinkPad x220 arrived and of course in the evening after I finished work, I was jonesing to put Fedora 15 on it. The machine is a type 4286CTO (Smolt info here). I started by booting into the BIOS and checking the options as shipped by Lenovo. There wasn’t much to change here, other than to enable hardware virtualization so I could more easily run KVM on the laptop should I choose to do so later. I didn’t enable the extra direct IO option, VT-d, because I’ve seen it cause weird installation problems in a lot of cases.

While I was starting to work on my new laptop, I also took the time to refresh my backup of data on the laptop I’ve been using, a ThinkPad x201 graciously lent to me by Tim Burke when my Dell XPS M1330 started to go belly-up a couple months ago. I used rsync to sync everything to a large USB drive.

Then I grabbed a spare 64-bit Fedora 15 Live USB key with the standard Desktop image and booted from it, just to see what I might expect from an installed system. I was impressed (but not really surprised) to see that everything worked great out of the box (with one trivial exception I’ll cover below). Not only the standard stuff like video hardware acceleration, special keyboard buttons, Bluetooth, sound, and suspend/resume, but also stuff like the webcam (at full resolution) and wireless. So I tried an installation from the Live key, and everything went fine — and fast, due to the new 2nd-generation “Sandy Bridge” Core i7 processor on this notebook.

Booting that went flawlessly, so I decided to try a more full-featured install over the network. I copied the pxelinux images for the kernel (vmlinuz) and initial ramdisk (initrd.img) to the /boot folder, edited the /boot/grub/grub.conf file to add a boot stanza, set the new boot stanza to be the default, and then restarted. Spoiler: this installation also went flawlessly. When it came time to deal with the package configuration, I did two things:

1. Using the installer’s ability to edit repository configuration as part of the interactive installation, I pointed the installation at my home network, for speed purposes — having made sure my local mirror of content was updated with the latest content already.
2. I made sure the “Updates” repository was turned on (and also pointed at local content). This would save me having to do a separate update after installation.

In minutes I had a working system. Using some of the yum-fu from an earlier post, I added in missing packages that were on my previous system.

Now came time to restore my user data. However, I decided to forego using the USB drive for restoration, because here I was with two relatively speedy laptops, each equipped with a gigabit Ethernet network interface. Nowadays these interfaces don’t need special loopback or null cables; they can autosense direct connections and adjust accordingly. So I cabled the notebooks together and used the easy NetworkManager tool to set up the wired interfaces with manual addresses on the same IPv4 network.

A quick check with ping showed I was ready to go, so I ran rsync over SSH to pull all the user data (in /home) from one box to another. This step probably saved me about half the time that the USB copy would have cost thanks to greater bandwidth over gigabit Ethernet versus USB 2.0. (The new laptop has USB 3.0 but the backup drive I have is USB 2.0.)

One of these days I’ll get around to puppetizing my home network, but I just don’t have the time for it these days. So my last step was manually grabbing an assortment of configuration info from my old laptop:

• Stuff from /etc/NetworkManager/dispatcher.d/ and /etc/postfix/ to support my laptop email solution (start here if you want to learn more about it)
• Some web server configuration files from /etc/httpd/conf.d/ so I can run my local sandboxes of Drupal
• A little more info from /etc/NetworkManager/system-connections/ where I have some system-wide connection profiles

And with that, I was ready to go. Actual “me time” expended on all this was less than an hour, if you count both installations, post-configuration tasks, and miscellaneous piddling around in the middle. Of course I wandered off and did other things while the data copying was going on, so I’m not counting that time.

As I mentioned, everything worked perfectly on the installed system with one tiny exception. Even the fingerprint scanner was set up in a matter of seconds, using the handy GNOME 3 “My Account” tool. Interestingly, if you’re one of the poor unfortunate unwashed using Windows 7 (even the so-called “Ultimate” edition), both the webcam and the fingerprint scanner have to have extra drivers installed if you want to use them. But in Fedora? Nope. It all works 100% out of the box. What’s the exception then? The only thing that’s not functioning yet is the new “microphone mute” function button. The button does issue a key press signal, but it’s not captured by anything yet. This is also an “extra driver needed” for Windows users, but true to form, the new button is already on its way to working out of the box in Linux, thanks to the awesome work of community members. My bet is you’ll see this enabled in a kernel update in Fedora 15, or at worst in Fedora 16 which will be out in a few months.

Hopefully this will be helpful to anyone who’s considering one of these fine laptops. ThinkPads are kind of the Cadillac of laptops for IT worker bees, in my opinion. Or maybe I mean Toyota truck? Anyway, they’re tough, reliable, full-featured and in the case of the X series, highly portable. And they work absolutely great with Fedora and Linux in general. Happy hacking!

Help for the hapless.

I often make typos, and sometimes I hit a key combo when I don’t mean to. (That never happens to you right? Right?) One of my most common goof s is hitting several of the same key combination in a row, such as Ctrl+D to exit shells. I might find myself in a situation where I’m running a secure shell session in a terminal, and after I exit out of several subshells or a screen session with Ctrl+D, I inadvertently hit Ctrl+D one extra time, and exit the shell I wanted to keep.

Now ordinarily this wouldn’t be a problem — just run ssh to get back into the box, and Bob’s your uncle. But every once in a while it can be disastrous, for instance when you’re piddling around with the network on a remote box, or if the SSH session in question is providing a tunnel for some other applications in progress.

I do a couple things to avoid this problem. The first is to use the ControlMaster option with my SSH sessions (the shorthand option is -M). More than one instance can share the same connection. The first instance acts as a master, and you can configure where to store the socket it’s using. Additional sessions you start on the same host and port will share the connection.

This has a couple effects, and one of them is fast startups for the second and following connections — since the connection has already been made and you’ve authenticated, all that remains is to start up the session (such as a login shell). Another effect is that you can shut all the connections down (somewhat forcibly) by shutting down the master session!

Take my situation for example. I set this option in my personal configuration file (~/.ssh/config), because I often have multiple connections open from different applications to the same host. Sometimes those connections aren’t all obvious. For example, my music library is on a remote host that I access with Rhythmbox via SFTP (FTP over SSH). The SFTP connection will open automatically when I start up Rhythmbox — I get prompted for the passphrase, of course, because I don’t like to store that anywhere — and the volume is mounted via Nautilus, the GNOME file manager.

Now imagine later on, I open a secure shell to the same system for other work. If I unmount the share for some reason, having forgotten it was the first thing that started a SSH connection and thus inherited the title of “master,” boom! My other SSH session gets disconnected. Yikes. And the reverse sometimes happens too — I might stop the SSH session I started in the morning, and if it’s the master for the music library connection from Rhythmbox, my music might stop cold.

So obviously, I like the positive side effects of this setting, but not so much that last, negative one. Especially when I have a  habit of shutting down the master carelessly. Recently I’ve started using is the -N option to help solve this problem, which doesn’t execute anything on the remote side after authenticating. I think I saw this hint elsewhere, and found it intriguing.

You don’t get a shell or anything else after login, just an open socket. So at this point you can background the job (Ctrl+Z in the bash shell), and close the terminal it’s in. The SSH socket stays open peacefully and invisibly in the background like a Zen master, waiting to do your bidding. Now you can open up additional sessions on that system with ssh remote-host-name, and they pop up quickly. No matter what interactive shell session you close, things keep humming right along. (If you really need to close the entire connection and all shared sessions with it, you can just kill the master connection that’s still in the background.)

Since I use a variety of SSH tunnels for different stuff, the -N switch has made it much easier for me to keep my tunnels alive and working even if I have to logout of my GNOME session. If you’re more trusting with keeping your SSH passphrases in the GNOME Keyring, you could start up lots of these background connections with minimal keyboard interaction. If you wanted to be slightly more clever, you could even set up a notification that would inform you if one of the background sessions failed (that will still generate an error condition on your end, the client end).

This is not the only way to use SSH more effectively, but this method solved my problem and I hope you find it useful, and that it helps you complete your work a little more efficiently. I’ve started a category for hints like this on my blog, and I’ll continue to send useful tidbits here for your reading pleasure. If this information helped you, or if you want to make an additional suggestion, please feel free to use the comment form, or trackback from your own helpful blog entry.