fak3r

This is a big deal for me, I played with Skype back in the day, but never really used it much since it required a second client, and I have always used Gaim (which is now Pidgin) to consolidate all of my accounts into one client and didn’t want to break out of that mold, but now I don’t have to.  Using the Skype API, Eion Robb has created a Pidgin plugin called Skype API plugin for Pidgin/libpurple/Adium.  Now I just add my user to the Pidgin accounts tab and I can now chat via Skype in Pidgin just like I chat with all my other contacts.  Note that you can’t do the video of Skype on Pidgin.  Mac users note that you can use this on Adium (my fav OS X chat client), which uses libpurple, which is the backend for Pidgin, on Mac.  So now I’m using Skype again, which is a propreitary app, thanks to them providing an API for the Open Source community to latch on to.  Ah, the circle of life…

If you’re like me you’re already running one of the Firefox 3 betas and loving the new features and stability lacking in the earlier series. The only issue now is that it’s taking extension writers time to update their extension to be compatible with the new Betas. Some of these extensions can almost hold me back to the 2.x series since they’re so useful, but 3 is just so much better in many ways. So, to install an old (2.x) extension into a new (3.x) Firefox just takes a little tweak to the install file. By default the extensions are hardcoded to something like 2.0.12 or the like, and *generally* nothing else needs to change to make it work with the 3.x series. (please re-read the *generally* part…done? ok). To do this, just right click on the extension (I’ll use the Gspace one for this example) and choose ‘Save as…’ Once you have it, open up the commandline (or force WinZip to open it, unsure of how to do that) with unzip (the extensions end with .xpi, but are really a kind zipfile):

unzip gspace-0.5.92-fx+fl.xpi

After it unpacks things, you’ll have an install.rdf file in your current directory, it’s just an XML structure file so you can open it in vi:

vi install.rdf

Search for the following block for targetApplication and find the variable for maxVersion:

2.0.0.*

Then simply modify the maxVersion variable to something like:

3.*

Then save that file. Next rebuild the xpi file with all the same files it had before, but this time with the modified install.rdf (NOTE: I renamed the file from .xpi to -edited.xpi so I could tell it apart)

zip -r -D gspace-0.5.92-fx+fl-edited.xpi chrome defaults license.txt install.rdf gpl.txt chrome_jar.manifest chrome.manifest

And lastly open the newly created xpi with Firefox - it should now install no problem. If there’s an issue bail out by manually deleting the .jar (and any other chrome or default files you saw when you unpacked). Worse case you’ll need to build a new profile, but that’s hardly a price to pay for the thrill of the adventure! (blah, that sounds pretty geeky, eh?)

Anyone building a server with a LAMP stack today has tons of options, mine have evolved to using Varnish -> Lighttpd -> Xcache -> PHP5 -> MySQL. Once I had Lighttpd (aka Lighty) installed and running PHP pages I looked to optimize the configuration and push it as hard as possible for more speed. Of course lately I’ve been getting unexplained slowdowns, with many instances of php5-cgi appearing to be taking up almost all of my available CPU on `top`. Reading up on things it appears that I had max_procs, along with PHP_FCGI_CHILDREN, set far too high for the load I’m getting. When you start lighty it gives you the number of processes you’ve define, and then those in turn spawn the number of children you’ve specified. While my settings were too high, they were really overshooting things when you take into account that I’m using Xcache (which provides PHP pre-caching) and Varnish (for HTTP acceleration). So even though one of my dynamic sites that I’m working on to ‘monetize’ things is getting 700-800 hits each day, my caching strategy is taking the load away from the ever available Lighty. Because of this, lighty has much less to do, so giving it a ton of processes to just sit there and eat memory until they’re zombified is a waste. After reading the lighty FAQ and other posts specific to this, I’ve settled on the this for my fastcgi config block within my lighttpd.conf file. (more…)

With all the tweaking to get my Dell Vostro 1500 working with Ubuntu, it’s still been an annoyance to get sound working evertime after hibernation. It goes to sleep fine, it wakes up fine, it obeys all of the power preferences I defined within Gnome fine too, it’s just that when it comes out of hibernation, the sound is usually off. It’s not muted, it’s off. Trying to restart alsa (the sound server) is a lession in frustration, so until now I’ve been ignoring it since it was rare that I would need it, but still…come on. This week I came across a solution in the Debian Forums that creates a new task for Linux to do before it shuts down and before it starts up.: “Create the file /etc/pm/sleep.d/49sound…

mkdir /etc/pm
vi /etc/pm/sleep.d49sound

with the following contents:

function kill_sound_apps() {
pidsnd=$(lsof | grep /dev/snd | awk '{ print $2 }')
pidmixer=$(lsof | grep /dev/mixer | awk '{ print $2 }')
piddsp=$(lsof | grep /dev/dsp | awk '{ print $2 }')
kill $pidsnd $pidmixer $piddsp
}

case "$1" in
hibernate|suspend)
kill_sound_apps
modprobe -r snd_hda_intel
;;
thaw|resume)
modprobe snd_hda_intel
;;
*)
;;
esac

exit $?

Then just make it executable:

# chmod +x /etc/pm/sleep.d/49sound

So before shutting down, Linux properly shuts down the sound, and when it comes back it, it properly starts the sound. As always, this *should* work, but the fact that it hasn’t been updated in Ubuntu Gusty is one of the reasons I’m shifting to Debian Lenny on this ‘top.

NOTE: yes, I am thinking of making Ignignokt my official HOWTO mascot. “Using a key to gouge expletives on another’s vehicle is a sign of trust and friendship“

These are some basic tweaks to speed up Firefox that have been tried and true for some time now.  I haven’t seen these collected in one place recently, so if you have Firefox and want to improve its performance, try these steps.  If you have a broadband connection (who doesn’t?), you can speed up your page loads considerably using these steps.   Basically you’re allowing Firefox to load multiple things on a page instead of one at a time. By default, it’s optimized for dialup connections (lowest common denominator) so here’s what you need to do to fix that.

1. Type “about:config” into the address bar and hit return. Type “network.http” in the filter field, and change the following settings (double-click on them to change them):
2. Set “network.http.pipelining” to “true”
3. Set “network.http.proxy.pipelining” to “true”
4. Set “network.http.pipelining.maxrequests” to 8 (recommended by Firefox devs)
5. Right-click anywhere and select New-> Integer.  Name it “nglayout.initialpaint.delay” and set its value to “0″. This value is the amount of time the browser waits before it acts on information it receives.  With it set to zero the page just pops up, it’s a dramatic change.

So give those a go, and don’t stop there, there’s plenty of Firefox add-ons to download and explore with; whatever you want to do online, there’s likely an add-on that’ll make it easier/better/faster.

Thanks to a post from Steve over at debian-administration.org, I finally got around to setting up monit, the little monitoring app we use at work to keep things sane.  I was getting around to installing it at home, but it became more urgent when Varnish went down last week; without it running there’s nothing to handle requests on :80, so as a webserver it’s dead. So here’s my monitrc for the webserver Lighttpd fronted by Varnish, acting in the reverse proxy/http accel role. Varn is listening on 80, then, if things aren’t cached, it forwards things on to Lighttpd listening on 82. Lighty also listens on the standard 443 for HTTPS requests, so we check that as well.

check process varnish with pidfile /var/run/varnishd.pid
start program = "/etc/init.d/varnish start"
stop program = "/etc/init.d/varnish stop"
if cpu > 60% for 2 cycles then alert
if cpu > 80% for 5 cycles then restart
if totalmem > 200.0 MB for 5 cycles then restart
if children > 250 then restart
if loadavg(5min) greater than 10 for 8 cycles then stop
if failed host 127.0.0.1 port 80 protocol http
then restart
if 3 restarts within 5 cycles then timeout

check process lighttpd with pidfile /var/run/lighttpd.pid
start program = "/etc/init.d/lighttpd start"
stop program = "/etc/init.d/lighttpd stop"
if cpu > 60% for 2 cycles then alert
if cpu > 80% for 5 cycles then restart
if totalmem > 200.0 MB for 5 cycles then restart
if children > 250 then restart
if loadavg(5min) greater than 10 for 8 cycles then stop
if failed host 127.0.0.1 port 82 protocol http
then restart
if failed host 127.0.0.1 port 443 type tcpssl protocol http
with timeout 15 seconds
then restart
if 3 restarts within 5 cycles then timeout

So now we have monit watching Lighttpd, Varnish, Postifx, MySQL and OpenSSH - restarting things if they fail, and emailing me the status when they do.  Next on to some long term trending with Cacti providing some rrd graphing and then we’ll really have an idea of what this box is doing and be able to tune it accordingly.

When you run a webserver behind a reverse proxy or HTTP accelerator like Squid or Varnish, the webserver access logs will display the IP of the proxy (generally 127.0.0.1) instead of the end user’s IP.  This not only breaks any kind of tracking or reporting you want to run against your webserver logs, but it also takes away a datapoint I’ve had use for in general server admin tasks. This server runs Varnish in front of Lighttpd, and it reveals the end user’s IP in the header as X-Forwarded-For, so it’s just a matter of making Lighttpd (lighty) use that variable in its access logs instead of the default variable defining the referring IP. Once we know that, the configuration is simple; in lighttpd.conf, enter this:

accesslog.format = "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b /
\"%{Referer}i\" \"%{User-Agent}i\""

For the definition of these variables, and plenty more, hit Lighty’s wiki. Props to the poster on the Varnish mailing list for bringing this up and reminding me to fix it! I’ve sent this link to the list so now it’s out there.

On the monit mailing list today someone asked how they could monitor a process that didn’t have a pidfile associated with it.  Without thinking I jotted this down, there’s likely a better way, but this should work and may be all I need for some init.d scripts for a couple of apps on ramon (the home server).  In the the beginning of the startup script, define the PIDFILE with the path and the cmd followed by the pid suffix and then just dump the PID number from the ps output into it:

export PIDFILE=/var/run/${1}.pid
ps -fe | grep ${1} | head -n1 | cut -d" " -f 6 > ${PIDFILE}

Once this is done, monit can monitor it just like it monitors any other process with a PID.  Later, for a shutdown hook, nuke the PIDFILE on the way out.

if [ -f ${PIDFILE} ]; then
rm ${PIDFILE}
fi
### rest of shutdown ###
exit 0

I think that should do it, anyone see a problem with that / a better way?

Looking over the Debian own harden-doc guide online, (which is a monster of a resource) as well as Debian Help’s security page gave me some excellent new ideas on how to secure Debian and Linux in general.   Also today i found a netstat command with some nice switches to help you figure out what is listening on each port in an easy to read layout, -plunt:

netstat -plunt

Plus it’s fun to say, ‘plunt’. Lastly there’s a good overview of deborphan (which assists you in keeping your system clear of unneeded packages) with coverage on how to use it at Debian Adminstrator.org. But in the comments a thread talks about how it’s better to use aptitude, as this does it automatically.

UPDATE: thanks to a comment below from Ted, we now have a solution to have this option persist across kernel updates.  In grub, “…at the end of this new menu item add it as an argument to the line:

defoptions=quiet splash irqpoll

I knew there had to be a way, thanks for the post Ted!

There’s a known bug in Ubuntu 7.04 (Feisty) with some ata detection routine that causes the system to take over 2 minutes to boot. Since this has happened to me more than once I’m documenting it here for me, and for other desperate souls that may find their way here. If your system is very slow to boot, and you see error messages in your dmesg (`dmesg | grep ata`) such as this:

[ 34.122465] ata1.00: qc timeout (cmd 0xef)
[ 34.122519] ata1.00: failed to set xfermode (err_mask=0×4)
[ 34.122565] ata1: failed to recover some devices, retrying in 5 secs
[ 46.260055] ata1: port is slow to respond, please be patient (Status 0×90)
[ 69.218482] ata1: port failed to respond (30 secs, Status 0×90)

You just need to ad `irqpoll` to your grub line. So in so in /boot/grub/menu.lst I added irqpoll to the kernel line:

kernel /boot/vmlinuz-2.6.20-15-generic root=UUID=48c5a348-eb39-4171-8531-671a49fdb75b ro quiet splash irqpoll

and it fixes the issue. Probably a work around, but since this resets every time you install a new kernel you’ll realize when it’s broken and when it’s fixed. Oh, and my system boots in 21 seconds now…is it geeky that I know that, and I tweaked the system to make it boot faster than the 27 seconds it was booting in? I guess we’ll never know!