I ordered my Dell XPS M1530 with the “extended”, 9-cell battery in the hopes that I could run on battery power for at least three hours.  After using my laptop for a few days I realized that I had got my wish:  It ran for about 4 hours with the screen dimmed to ~75%, the ondemand CPU governor enabled, and running a 3D-accelerated (Compiz) desktop.  This was with Ubuntu 7.10 (Gutsy Gibbon) and KDE 3.

Recently (well, months ago =) after migrating to KDE 4.1 in Ubuntu 8.10 I’ve had to plug my laptop in after about 2 hours.  Even if I dimmed the screen significantly and shut down non-essential services it still wouldn’t last very long.  More importantly, as time progressed I knew the problem would just get worse so I decided to investigate.  This investigation turned up some surprising tweaks that save a lot of power…

(more…)

Cron is not a particularly intelligent utility.  It will run a command whenever it is set to run–regardless of whether or not the last invocation of said command completed.  So if you have a command that puts a high load on your system and it’s time for cron to execute that same command again you’re going to be in a heap of trouble.

The solution to this problem is as old as cron itself but for some reason it seems to have gone missing in the minds of the general cron-using public.  Here it is:

* * * * * [ -n "`ps -ef | grep -v grep | grep myprocess`" ] && <execute myprocess>

That will only execute “myprocess” if it isn’t already running.  Here’s another way:

* * * * * [ ! -f /tmp/myprocess ] && touch /tmp/myprocess && <execute myprocess> && rm -f /tmp/myprocess.pid

Of course, it would be even better if ‘myprocess’ actually wrote a PID file itself so you wouldn’t have to manage it from within cron.  If ‘myprocess’ is a shell script here’s how you do that:

#!/bin/bash
[ ! -f /tmp/myprocess.pid ] && echo $$ > /tmp/myprocess.pid
<your code goes here>
rm -f /tmp/myprocess.pid

Of course, if your script is going that far you might as well go all the way:

#!/bin/bash
if [ -f /tmp/myprocess.pid ]; then
    echo "Not running since /tmp/myprocess.pid exists"
    exit 1
fi
echo $$ > /tmp/myprocess.pid
<your code goes here>
rm -f /tmp/myprocess.pid

It took me forever to figure this out because I could find ZERO examples after like 20 minutes of googling and at least 10 minutes of reading the docs (I’m sorry but, “see the MySQL documentation for more details” is *FAR* too ambiguous).  Anyway, so no one has to go through what I did here’s a real example of how to use SSL with the MySQLdb Python module:

#!/usr/bin/env python

ssl_settings = {'ca': '/etc/mysql/mysql_ca.pem',
    'cert': '/etc/mysql/mysql_cert.pem',
    'key': '/etc/mysql/mysql_key.pem'
}

db=MySQLdb.connect(host="mysqlserver",
    user="myuser",
    passwd="mypassword",
    db="mydatabase",
    ssl=ssl_settings
)

server_status = db.stat() # This was another thing that was non-obvious (to me anyway)
print server_status

# Perform a standard query
c = db.cursor()
c.execute("SELECT * from some_table")
row = c.fetchone()
print row

For reference, I was only able to get the SSL connection to work if I supplied at a minimum the ‘cert’ and ‘key’ parameters.  The ‘ca’ parameter isn’t necessary but it adds an extra layer of security (at trivial cost) so you might as well use it.

The really annoying thing about SSL in the MySQLdb module is that it doesn’t report whether or not it is actually using SSL (you could set ‘ssl=”blah”‘ and it would still continue on its merry way).  If you get the ssl settings parameter wrong it will still try to connect without using SSL–sending your queries in plaintext over the network.  To prevent this from happening I highly recommend you add the REQUIRE SSL parameter to the MySQL user you’re going to be using for connections…

mysql> GRANT ALL PRIVILEGES ON mydatabase.* to username@somehost
	      -> IDENTIFIED BY "secretpass" REQUIRE SSL;

Here’s a list of all the available keywords you can use in the ssl connection parameters (taken from here):

Hardware detection

I love how fast the hardware detection is.  In Windows when you plug in some new piece of hardware you have to wait for that “ba-doop” sound (and the driver to load).  It can take an especially annoying length of time when booting up with new hardware attached (especially a mouse).  In Linux hardware detection is nearly instantaneous.

I just plugged in a new mouse and it was recognized and working properly before I could even put my hand on it.  Also, no annoying sound.

Desktop customization

I love how I can customize everything.  If I don’t like the boot screen graphic I can change it.  If I don’t like my login screen, desktop, window decoration, or even what happens when I move the mouse over a window, I can change it in almost any way imaginable.  I can make it look and operate like Windows or a Mac or I could make it completely unique; *my* desktop.

Not only can anything and everything be customized but most of these changes don’t even require administrative privileges.  Linux puts a lot of power in the hands of users without sacrificing security.

Available software

I love how I have easy access to tens of thousands of applications for free.  Most poeple don’t know this but there’s far, far more software for Linux than there is for any other platform.  If you combined all the available software for Windows and Macs it wouldn’t even come close to what’s available for Linux.  Best of all, you don’t have to pay a cent.  Just about all of it is completely free.

Solutions are just a Google away

I have a saying, “To find a solution with Linux you merely search the Internet. To find a solution with Windows you have to search your IT budget.”  If I want to do something new with my Linux desktop all I have to do is perform a quick search and I’ll likely find a swath of easy-to-follow HOWTO articles.  In Windows when you search the Internet for solutions, nine times out of ten the only way to do what you want is to pay for some proprietary software package.

If the (Windows) product you just purchased doesn’t do everything you want you’ll likely have to purchase more software to fill the gap.  In Linux, because of the nature of open source software, adding new functionality is usually just a matter of mashing up your existing free software with some new free software.

Linux distributions are the perfect example of “mashing up” disparate free software packages to create a system that has comprehensive functionality.  Best of all, there’s hundreds of them to choose from for all sorts of generalized or specialized purposes.  You can try a few and pick the one that best meets your needs and desires.

I’m posting this because I know someone out there will find it useful (or at the very least, a time saver).

What is FoxyProxy?

FoxyProxy is a great add-on to Firefox that lets you define multiple rule-based proxy servers.  It lets you do things like define a rule that loads all URLs through a certain proxy server except those that match a given pattern.  Rules can be wildcards (*whatever.com*) or regular expressions (https?://.*.whatever.com.*).

The problem (need an IP address regex)

I had a problem with FoxyProxy where IP addresses (e.g. 127.0.0.1, 10.0.0.1, etc) were being loaded through my work’s proxy server when they shouldn’t be using a proxy at all.  This is because I had a proxy setup with a “Match all URLs” rule along with a blacklist rule for local URLs (*.myworkintranet.com*).  What I needed was a blacklist rule that would tell FoxyProxy to load all IP addresses directly.  Specifically, I needed a regular expression that would match any IP address.

The solution (regular expression matching any IP address)

https?://[1-9][0-9]?[0-9]?.[0-9][0-9]?[0-9]?.[0-9][0-9]?[0-9]?.[0-9][0-9]?[0-9]?.*

There you have it.  I know this will also match invalid IP addresses (e.g. 999.999.999.999) but it shouldn’t matter since there’s no number-only top-level domains (i.e. .999 as opposed to say, .com).

Also, in case you were wondering FoxyProxy uses the Javascript regular expression format.

Other regular expressions you might find useful

Same thing but for FTP URLs:

ftp://[1-9][0-9]?[0-9]?.[0-9][0-9]?[0-9]?.[0-9][0-9]?[0-9]?.[0-9][0-9]?[0-9]?.*

Match reserved (non-Internet) IP addresses (i.e. 127.X.X.X, 10.X.X.X, 192.168.X.X, and 172.16-31.X.X):

https?://(127|10|172|192)\.(1[6-9]|2[0-9]|3[01])\.[0-9][0-9]?[0-9]?\.[0-9][0-9]?[0-9]?.*

Oil hit $100/barrel today. Why? Oil inventories are plummeting. Could this be the beginning of the hydrocarbapocalypse (Note: I invented that word)? Probably not, but it could be our first taste of it (beating my original July estimate by ~6 months). I’m going to explain why but first here’s a graph to better illustrate my points:

There’s two things that are scary about this graph and the price of oil reflects it pretty accurately: First, the “norm” of oil inventories rising briefly in November never happened this year. Second, the weatherman is predicting one heck of a cold winter for much of the U.S. and we’re already burning oil more rapidly than normal (we typically have a slow decline in oil inventories between December and March).

So here’s my prediction for the next few weeks: If the inventories continue to fall at the rate in this graph, the price of oil will likely hit $120/barrel in two weeks. If after two more weeks inventories continue to decline investors are going to freak and we’ll start seeing $200/barrel by the end of January. However, at some point during this crisis (depending on the intelligence of the President) the U.S. will likely try to counter the problem by releasing oil from the Strategic Petroleum Reserve. This will cause inventories to rise back to their historic norm which will be immediately followed by OPEC announcing slightly increased production at the beginning of February. The resulting “normalcy” of things in March will bring the price per barrel back down to the $100 range.

During this time frame it is likely that the U.S. Congress will do something meaningless that SOUNDS like it might help—such as passing legislation that allows drilling in the Arctic National Wildlife Reserve (ANWR). Any increase in oil production from such a law being passed would take decades to bear fruit and the media will be nearly silent of this fact.

I still hold that the real hydrocarbapocalypse will kick off on the weekend of July 4th this year.

I’ve been running Gutsy for a few weeks now (including pre-release) and I just recently figured out all my java problems. I googled all over the place and couldn’t find these fixes ANYWHERE so I did what any Linux geek would do: I debugged and fixed them myself. So if you’re having problems with Java on Gutsy here’s some fixes…

The proxy server problem with java 7 (icedtea)

My first problem was that java applets were not connecting through the proxy server (which is the only way for me to connect where I am). For whatever reason the default for the icedtea-java7 package(s) is to NOT get the system default proxy settings. The fix is to edit /etc/java-7-icedtea/net.properties and change

java.net.useSystemProxies=false

to be:

java.net.useSystemProxies=true

Easy enough!

The java.net.SocketPermission problem

My second problem was that no applet would load because the default policy in the icedtea-java7 package(s) is defaults to DENY for java.net.SocketPermission for everything but the “listen” attribute. to fix this I had to add some permissions under the “grant {” section in the /etc/java-7-icedtea/security/java.policy file:

// allows anyone to listen on un-privileged ports
permission java.net.SocketPermission "localhost:1024-", "listen";
permission java.net.SocketPermission "*", "resolve";
permission java.net.SocketPermission "*", "connect";
permission java.net.SocketPermission "*", "accept";

The first two lines should already be there. Just add the resolve, connect, and accept lines then restart Firefox. Java should now be working properly. Test it here

I finally fixed the last thing: Formatting. If you’re curious, I use the Textile 2 markup language with my wordpress posts. You can see what it is like here. I find that it is much easier to work with than the WYSIWIG editor that comes with WordPress.

The plugin I was using before broke with Apache 2.0 (which is freaky weird) so I searched and searched and finally found one that worked

Thank you Joel ‘Jaykul’ Bennett!

Update: Oops, I didn’t realize that permalinks weren’t working (which meant people couldn’t access full articles or comments). I just fixed it (.htaccess was broken).

I just upgraded my server to from apache 2.0 to apache 2.2 and it broke some things. Most notably my image gallery, my random quotes, and the excellent TextControl plugin that makes my posts pretty =(

I’m going to be working on this as much as I can over the next few days but my son is in the hospital so all you readers will have to just deal with the ugly formatting for a while =)

Update: I fixed everything but the gallery and the TextControl plugin. Still working on it.

Update 2: I fixed the gallery.

I recently wrote a custom script that works in conjunction with psad (Port Scan Attack Detector) to pop up a transient message on my screen when my machine is attacked. It looks like this:

So when some machine out on the network does a port scan or attacks/probes my laptop it alerts me in an unobtrusive manner with the pertinent details. The script also uses the espeak text-to-speech engine to say, “We’re under attack!” when such an attack occurs. It is pretty fun, actually.

Click the title to see the HOWTO.

< !-more->

Prerequisites:

• psad must be installed. On Ubuntu, “sudo apt-get install psad” should do (Here’s my config if you want).
• iptables logging must be turned on (see this).
• You must be running KDE (or at least have the dcop daemon running).
• sudo must be configured so that you can run the commands in my script as root without a password.
• You need my script

• Optional: Install espeak for a silly voice announcing that you’re under attack. On Ubuntu, “sudo apt-get install espeak” should do.
  

  Edit my script

  My script will probably run just fine without any modification. However, if your psad log directory is configured to something other than ”/var/log/psad” then you’ll need to edit my script and change the PSAD_LOG_PATH variable to match your environment.

  Configure psad

  psad has a straightforward configuration file that is typically located at /etc/psad/psad.conf. I edited my psad.conf so that it only alerts on “danger level 3” or higher and told it not to bother actually emailing out alerts (though, it still generates the email_alert files). However, the important part is near the end of the file: You must set the following options (telling it to run my script):

  ENABLE_EXT_SCRIPT_EXEC Y;
EXTERNAL_SCRIPT /home/riskable/bin/psad.sh SRCIP;

  Important: Make sure that EXTERNAL_SCRIPT includes the actual path to psad.sh.

  Next you need to setup your syslog daemon to log kern.info messages to the psadfifo file. If you’re using ksyslogd (i.e. Ubuntu) you can type the following:

  echo "kern.info |/var/lib/psad/psadfifo" >> /etc/syslog.conf

  Now restart psad (sudo /etc/init.d/psad restart).

  Configure sudo

  Make sure that you can run grep and sed as root using sudo without having to enter your password. If you don’t know how to do this, add the following line to the bottom of /etc/sudoers:

  
your_user ALL=(ALL) NOPASSWD: /bin/grep, /bin/sed


  Just make sure you replace “your_user” with your actual username and you should be all set.

  Testing

  A quick way to test psad is to nmap yourself from another host (I think it ignores localhost by default). If your machine’s IP was 192.168.0.2, from another machine run, “nmap 192.168.0.2” and you should get an alert within a few seconds. If not, something is wrong (obviously). Here’s how to troubleshoot:

  If psad is working properly, you should see a folder representing the IP address you were attacked from in /var/log/psad (i.e. ”/var/log/psad/192.168.0.1/”). Within this folder should be a file (or two) that end in _email_alert. These are the files that my script uses to gather information. If they don’t exist you probably have one of two problems:

  1. psad isn’t configured properly. Check the logs and your config file.

1. iptables logging isn’t enabled (did you run these two commands as root?)

   If you “cat whateverIP_email_alert” and see that it contains a legitimate alert then you probably have psad configured properly but double-check that the path to psad.sh is correct and that it is executable (i.e. “chmod 775 psad.sh”). If your iptables are setup properly you should see the following if you run the command, “sudo iptables -L”:

   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   LOG        0    --  anywhere             anywhere            LOG level warning
   
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   LOG        0    --  anywhere             anywhere            LOG level warning
   
   

   You can test the psad.sh directly by running it as root and passing it the IP address of one of the folders in /var/log/psad. For example:

   /path/to/psad.sh 192.168.0.1

   That should generate an alert. If it doesn’t, either dcop isn’t working properly or the _email_alert file isn’t interesting enough for my script to bother reporting (single port probes are ignored unless they match a signature). Time for some good old fashioned debugging at this point (hint: try running the script like so: “sh -x psad.sh 192.168.0.1”).

   Please leave a comment or trackback if you’re using this script. Enjoy!