Category Archives: Tech Tips

Better Pagure email filters for Gmail

I get quite a bit of email notification from Pagure, the free (as in freedom!), Python-based git forge. I have and participate in several repos there. Pagure sends me email when there’s a new or updated issue, pull request, or commit to a repo I monitor.

Previously, all that email for me has gone into a “Pagure” folder. But Pagure offers a special header, X-pagure-project, which indicates the specific project that triggered the email. Unfortunately, Gmail’s filters notoriously lack the ability to parse arbitrary headers. This is actually a limitation of the Gmail API. Why there’s no getHeaders() call, I have no idea — but maybe it has something to do with worries about arbitrary content there.

Now, I could probably set up filters to look for mail From: and then look in the subject line for [Project-name]. But this means I have to make a new filter for every project manually. YUCK!

Enter Google Apps Script

So I wrote my very first Google Apps Script (this script is MIT licensed).

Here’s the link, which will stay up to date.

How to use the script

To use it, you first need to connect Google Apps Scripts to your Google Drive. (Use New –> More in Google Drive, if this isn’t already done.) Then save this as a new script in your Drive.

Adjust the parentlabel value if needed. Then set a timer trigger to run the processInbox function every 5 or 10 minutes.

Make sure to remove any existing filter for Pagure notification email, so that your script has a chance to run against notifications in your Inbox.

If you’ve never used Google Apps Scripts before, it’s easy to get started. I’m living proof, since I’m not much of a developer. Here’s a quick start from Google that will help.

MeetBot makes for better meetings.

One of the aspects of Fedora is holding public meetings on IRC. We use Meetbot (courtesy of Debian, thanks!) to help administer meetings. Common commands allow Meetbot to do all the hard work of recording proceedings. The automatic minutes make it possible for people who couldn’t attend to follow what happened in the meeting. These minutes are key for maintaining transparency and information flow around the project.

But the minutes still depend on the people who chair the meetings to use the command set to record important data.

  • #startmeeting – Sets the overall group for the meeting
  • #endmeeting – Cleans up when done, and gives you the URLs for the minutes
  • #topic <Topic name> – Sets a topic heading for the next portion of the meeting
  • #info – Record some information that’s useful for anyone reading the minutes
  • #action <nick> <thing to do> – Clarifies who’s got the ball to complete something before the next meeting; it’s usually a good idea to set a due date*
  • #agreed – Documents something the attendees agreed on, also important to make decisions transparent
  • #idea – Helps give visibility to something no one is doing yet, but could be useful (also see #help in the MeetBot page)
  • #chair <person>… – Add someone(s) to the list of people MeetBot will listen to for commands

* A good friend of mine pointed out that unless you set a due date for an action item, you’re not writing actions, you’re writing a wish list. It should not only be clear who’s got the ball, but when they’re expected to give it back.

Here’s an example of a meeting I ran recently where I used the MeetBot commands to record useful minutes. If you were to look at these minutes later you’d get a pretty good idea of what was covered. You’d also know who was supposed to do tasks before the next meeting. There are a couple action items without clear dates, which is sub-optimal. But overall the meeting minutes are pretty clear.

In some cases, I ended up repeating things people said, using the #info command at the front to tell MeetBot to record in the minutes. If you’re running a meeting you should be prepared to do this. I also like to add everyone in the meeting to the #chair list, to help increase information flow when needed. (It’s also not a bad idea to reduce the chance that a single chairperson will be knocked offline and unable to #endmeeting.)

Are you reading your minutes when done to see if they’re effective? If not, you should. Use what you find to make your meetings better and more transparent for the community. I thought about showing some recent examples of poor minutes usage, but I didn’t want to embarrass anyone.

If your minutes only serve to show a link or two, and an attendance roster, that’s pretty much useless for most community members. Sure, logs are useful, and good for transparency too. But it takes a long time to read logs and extract necessary points from the dialogue. That dialogue can also sometimes be confusing after the fact due to the way IRC works.

Use the facilities we have available to us in Fedora to provide more information and transparency on what you’re doing. The couple of extra minutes per meeting spent using MeetBot will save each reader many more in return!

Logitech M570 on Fedora.

I just bought a new Logitech M570 wireless trackball for use with my Fedora workstation. I favor a trackball over a moving mouse, because it’s easier on the joints, not to mention more practical on a crowded desk. My previous trackball device was a wired Logitech, and it developed a few problems recently. I’ve had it eight years, so I decided I got my money’s worth and could spring for a new one.

The Logitech M570 uses the Logitech Unifying Receiver USB wireless dongle, common to many Logitech devices. You can pair up to 6 of them to the current unifying device dongle that ships with the M570. Most Fedora users will want this device to be set with correct permissions for people who login on the console. It’s also helpful to be able to query or display battery status.

So here are the steps I recommend to install the Logitech M570 on Fedora. Do these steps before you plug in the receiver or turn on the trackball device. I’m using GNOME 3.12 on Fedora 20, so your mileage may vary:

  1. You may want to remove your existing pointing device first. Otherwise the new one may not work, at least until you do.
  2. Install solaar (upstream link), a monitoring and control gizmo for your Logitech Unifying Receiver and connected devices. Thank you to Eric Smith for packaging and maintaining this tool for Fedora!
  3. Plug in the receiver to an open USB slot. I recommend a rear slot since you likely won’t move this very often. (If you do, there’s a handy slot inside the trackball’s battery compartment where you can store the receiver without losing it!)
  4. Turn on the Logitech M570, and it should Just Work.
  5. You can launch solaar from the GNOME Shell, and a notification icon appears in the message tray. You can use this tool to see status and pair or unpair devices.
  6. (optional) If you want solaar to start every time you login, open the Terminal and enter these commands:
    $ cd ~/.config/autostart $ ln -s /usr/share/applications/solaar.desktop .


Restoring pretty Grub screen in Fedora 19.

If, like me, you were an early adopter of Fedora 19, you may have upgraded from Fedora 18. If so, you might be seeing a black text screen for the grub 2 boot loader. It’s actually quite easy to get the pretty themed screen back if you want it. Just run this command:

yum install grub2-starfield-theme

This will restore the theme and you’ll see it at the next reboot. There is a bug that addresses this issue, but if you’re an early upgrader, you may have to bring in the fix manually.

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.