The result: several hours of fighting with a dozen different applications before I actually had photos displayed on my TV. And this post.

I don’t understand why what seems like a fairly simple task is so complicated.

This is what I found to be the easiest recipe on a stock Ubuntu 11.10 installation. Fair warning: this is quick & dirty, you don’t get special effects, you don’t get music, etc.

1. Required software (load through the software center, or via apt-get): imagination, devede, brasero.
2. Open Imagination. Click the import photos icon (it is a terrible choice of icon — there’s no clue that you should want to click on the black square to import photos) and choose your photos.
3. Export video. Choose DVD for output; to keep it organized, drop the video file in the Videos directory in your home directory. This can take a while if you have a slow computer and/or a lot of photos.
4. Open DeVeDe. Configure the title. Import the video you just generated.
5. Generate the DVD ISO image; again save the image to your Videos folder.
6. Insert a DVD in the drive. Open your Videos folder. Right click on the ISO image and choose Write to Disc.

Some notes, in no particular order:

• If you want to tweak the slideshow, imagination will let you play around with transitions, slide duration, etc.
• If you want to import video clips, use Openshot instead of Imagination. It’s harder to use (and overkill) compared to Imagination if all you want to do is produce a static photo slideshow. But if you want to do any video editing, it’s a good combination of power and ease of use.
• If you want music, Openshot might also be your best bet. I didn’t look at adding music via Imagination or DeVeDe.
• Don’t try to use the Brasero application directly. I experienced crashes/lockups while using it, but it worked well when all I did was right click the ISO and choose Write to Disc. (It’s also an ugly, hard to use piece of junk.)

Things I tried and rejected:

• K3b: After Brasero failed miserably twice, I tried K3b. Rejected it in favor of not pulling in a bunch of KDE infrastructure that I wasn’t using anyway, and also in favor of the simplicity of just directly burning the file without having to explicitly open a separate app.
• dvd-slideshow: This command line app does appeal to my inner geek, but I can’t recommend it for users who want a GUI. (Even the inner geek appeal isn’t enough to make me want to use it when the combination outlined above works well.)
• Mistelix: As good as Imagination, and I would have selected it if I had quickly found a way to rotate a photo from within Mistelix. Photos that showed up auto-rotated in other apps showed up sideways in Mistelix and I didn’t see an obvious rotate button. Imagination did the right thing.
• Bombono: Junk. Don’t bother with it. I opened it, saw that the tabs were overlapping the menus, couldn’t figure out how to import any photos, and purged it from my system.
• Videoporama: Development is dead. It wasn’t immediately obvious that it was going to be easy to use for the simple task of creating a DVD from a set of photos.

The software stack above 10x better if Imagination implemented a feature to export a DVD ISO. It would be 100x better if it had a “Burn DVD” button that spit out a shiny disc that I could drop into a DVD player.

(To be fair, the whole video situation is 1000x easier than it was 5 or 6 years ago when I tried to do something similar, realized how much work it was going to be, and walked away in frustration. The tools have come a long way.)

Dec  8 03:19:33 localhost sshd[4718]: User root from 10.1.2.3 not allowed [...]
Dec  8 03:19:35 localhost sshd[4721]: Invalid user db2inst1 from 10.1.2.3
Dec  8 03:19:38 localhost sshd[4723]: User root from 10.1.2.3 not allowed [...]

fail2ban is configured to (temporarily) block these after a certain number of attempts, but they keep coming back. One particular IP address was hitting ssh constantly (except for the ban periods) for several days, so I added a rule to drop everything from that address — but this strategy isn’t scalable.

The simple, obvious solution is to only allow access from known hosts. It would be very rare that I need to access this server from anywhere except a small number of addresses. I started with a ufw (Ubuntu’s “uncomplicated firewall”) ruleset like this:

% sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
Anywhere                   DENY        10.1.2.3
Anywhere                   DENY        172.16.99.88
22                         ALLOW       Anywhere

To avoid getting locked out, I added (temporarily) a crontab entry for root:

*/15 * * * * /usr/sbin/ufw allow ssh

This will allow access to ssh from any un-banned IP address (the current policy) every 15 minutes. Then I inserted a rule that allows access to ssh from my home ISPs netblock. (You can figure out the netblock by doing a whois lookup on your external IP address; you may need to add multiple netblocks if your ISP has several allocated. Be careful: it’s no fun to get locked out!) This action is safe because I have not yet removed global ssh access. Note that I’m using “insert 3″ to add this rule at a specific position in the list.

sudo ufw insert 3 allow proto tcp from 10.9.8.0/18 to any port 22

And I added a rule to permit access from another server with a fixed IP I have access to (for the rare case where I need to access this server when I’m not at home):

sudo ufw insert 3 allow proto tcp from 172.17.101.102 to any port 22

Now my ruleset looks like:

Status: active

To                         Action      From
--                         ------      ----
Anywhere                   DENY        10.1.2.3
Anywhere                   DENY        172.16.99.88
22/tcp                     ALLOW       172.17.101.102
22/tcp                     ALLOW       10.9.8.0/18
22                         ALLOW       Anywhere

So far, so good, but ssh access is still permitted from anywhere — because of that last rule. This is the dangerous part… you could get locked out if you haven’t set the rules correctly. (You set up that crontab entry, right?)

sudo ufw delete allow ssh

Wait for the prompt… hooray, I’m still connected! After checking that I can access ssh from home and the other server, I know it’s safe to remove the crontab job. (If the cron job has already fired, you’ll need to rerun the ufw delete allow ssh command.)

At this point I can delete the first two rules that ban specific IPs, since they’re outside my netblock and won’t be allowed anyway.

Now I can enjoy quieter logs without all those access attempts from China and Croatia!

SSH makes it trivial to use that VPS as a SOCKS5 proxy. Just do:

ssh -D 8080 myvps.example.com

Then set your browser’s SOCKS proxy to localhost:8080. In Firefox on Linux, this is Edit > Preferences > Advanced > Network tab > (Connection) Settings > Manual Proxy Configuration. Leave all fields blank except for SOCKS Host and Port — localhost and 8080, respectively. Choose SOCKS5. Then browse to about:config and change change network.proxy.socks_remote_dns to true. This tells Firefox to ask the proxy to resolve names instead of trying to resolve them using your ISP. Chrome worked for me without hassle.

Go to test-ipv6.com to test that it works. If your results from test-ipv6.com indicate that IPv6 name lookups are failing, make sure you’ve got that about:config setting mentioned above changed.

“AnyConnect cannot confirm it is connected to your secure gateway. The local network may not be trustworthy. Please try another network.”

There may be several reasons for this error, which you’ll find on other pages that hit for a search on this string.

The reason that I encountered seems to be unique. What I found by digging into a wireshark capture is that AnyConnect sends a TLS alert to the server, disconnecting the session. The alert message says “Unknown CA”.

It could have something to do with installing the firefox plugin “Certificate Patrol” recently. AnyConnect apparently uses firefox’s certificate store. Perhaps Certificate Patrol does something to the store that makes it so that AnyConnect can no longer use it?

In case it matters, I’m on Ubuntu 10.04.

Whatever the cause, you can fix it by doing the following:

1. Figure out the CA that signs your VPN server’s certificate. (Hat tip to Didier Stevens for the easy way to do this.)
   1. Fill in your server, I’m going to use www.google.com.
   2. openssl s_client -connect www.google.com:443 >! /tmp/google
   3. Hit ctrl-C.
   4. You saw “Thawte Consulting (Pty) Ltd.”.
2. Now search for “thawte root certificate”. (Obviously this will vary depending on who signs your server’s certificate.)
3. Go to the page where they list certificates. Download them all. (I tried downloading the one that looked like it matched the signature on my server’s certificate, but I think you need everything down to the root in order to fully verify it. It’s easier to just download everything than try to figure out exactly which ones are needed.)
4. Convert to PEM format. (Hat tip to Mozekoze for this recipe.)
   1. openssl x509 -in input.crt -out input.der -outform DER ## (if the certs are in .crt format)
   2. openssl x509 -in input.der -inform DER -out output.pem -outform PEM
5. Copy all the PEM files to /opt/.cisco/certificates/ca. (Or to ~/.cisco/certificates/ca.)

Alternatively, you could copy the certs out of the keystore on your machine, convert to PEM, and then copy the PEMs into the directory mentioned above. (On ubuntu, you can see the certificates in the package ca-certificates. You could copy just the thawte certs by doing something like “cp $(dpkg -L ca-certificates | grep -i thawte) /tmp/certificate-conversion/”.)

Three cheers for wireshark, strace, openssl, and google for help figuring out what was going on. Cisco could make things a little bit easier to figure out — a decent diagnostic message would have been great — just tell the user “Unknown CA”, it’s already buried in the wireshark trace.

1. Install wine. (sudo aptitude install wine)
2. Install python into the wine environment. (Download an msi from python.org and run msiexec /i python-x.x.x.msi.)
3. Install whatever prerequisite packages you need (e.g. wxPython) using wine or msiexec.
4. When you’ve got everything ready to build, just do wine c:/Python27/python.exe setup.py bdist_wininst and look in ./dist/ for your exe!

/* Read previous pid file. */
if ((i = open (path_dhcpd_pid, O_RDONLY)) >= 0) {
    status = read (i, pbuf, (sizeof pbuf) - 1);
    close (i);
    if (status > 0) {
        pbuf [status] = 0;
        pid = atoi (pbuf);

        /* If the previous server process is not still running,
           write a new pid file immediately. */
        if (pid && (pid == getpid() || kill (pid, 0) < 0)) {
            unlink (path_dhcpd_pid);
            if ((i = open (path_dhcpd_pid,
                           O_WRONLY | O_CREAT, 0644)) >= 0) {
                sprintf (pbuf, "%d\n", (int)getpid ());
                write (i, pbuf, strlen (pbuf));
                close (i);
                pidfilewritten = 1;
            }
        } else
            log_fatal ("There's already a DHCP server running.");
    }
}

The problem with this strategy is that, if the box dies, there’s a stale pid file left in /var/run/dhcpd.pid. This wouldn’t be so bad — the code above checks [using kill(pid, 0)] to see if there’s a process running with that pid. But when the box is restarting, there will be a bunch of processes all starting in similar sequence each time. So on one boot, you might see dhcpd with a pid of 1001 and ntpd with a pid of 1002. If the box dies violently (e.g. power cut), the dhcpd pid file will contain 1001. On the second boot, assume ntpd starts first and gets a pid of 1001 and dhcpd is 1002. Now, the kill(pid, 0) will succeed, making it appear that dhcpd is already running, and dhcpd will exit.

How to fix this?

1. Explicitly put the pid file under /tmp. Getting this right is fussy — make sure you avoid the race conditions associated with creating temp files. Use dhcpd’s “-pf” flag to tell it where to use the pid file. This avoids spurious “already running” messages, because dhcpd will never read a pid from an existing pid file. [You could also just remove the /var/run/dhcpd.pid file, but I'd rather explicitly provide the path in my startup script in case some dim bulb decides to change the compiled-in default.]
2. Be careful in your restart code to kill any existing dhcpd (assuming you really want a new dhcpd), or avoid trying to start a new one (assuming you want to use an already running dhcpd). pgrep(1) and pkill(1) will be useful here.

In researching this, I saw this bit of wisdom from Henning Brauer: “pid files are useless.”.

I heartily agree…