As Debian/Ubuntu user, I am spoiled when it comes to update management: apt-get updates most of my software, and apticron notifies me when updates are available. For WordPress however, the packaged versions of Debian/Ubuntu are really old and less adjustable which unfortunately makes a manual installation inevitable. While there are several automated WordPress update mechanisms out there, I couldn’t find a simple notify-on-update tool.

This post introduces the WordPress Update Notifier (WP-UN), a simple script that frequently compares the installed WordPress version with the latest available one. If a new version is available, it sends an e-mail to a given address.

Requirements

WP-UN needs a local mail server such as Sendmail or Postfix to deliver the notification e-mail.

Download & Installation

Download the script, save it to your preferred location and make it executable:

$ wget -O /usr/local/bin/wp-un \
          http://blog.philippheckel.com/uploads/2010/01/wp-un
$ chmod +x /usr/local/bin/wp-un

That’s it for the installation. The script can now be called by simply running wp-un.

Download: WP-UN 0.1, January 2010

Usage

Now you can call the script with the following arguments:

• –test: to test if the notification works, use the –test parameter (optional).
• INSTALL-DIR: the path to your local WordPress installation, for example /var/www/myblog.
• NOTIFY-EMAIL: the e-mail address of the person to notify if a new WordPress version is available.

By default, the script is completely silent so that adding a cronjob doesn’t require output redirections. If, however, the –test option is given, it is more verbose and sends the notification e-mail in any case.

If a new WordPress version is available, the output looks something like this:

$ wp-un --test /var/www/myblog admin@example.com
Checking installed version... WordPress 2.5.1
Checking latest version... WordPress 2.9.1
Update required; Sending notification to admin@example.com... done.

If WordPress is up-to-date, WP-UN would normally not send any notification. If, however, the –test option is enabled, it sends the e-mail no matter what. In this case, the output will look like this:

$ wp-un --test /var/www/myblog admin@example.com
Checking installed version... WordPress 2.9.1
Checking latest version... WordPress 2.9.1
Update not necessary; WordPress is up-to-date.
TEST-flag enabled: sending notfication to admin@example.com... done.

The notification you receive will look like this:

 The WordPress installation on host example.com needs an update:
 
   Installed Version: WordPress 2.5.1
                  at: /var/www/myblog
 
      Latest Version: WordPress 2.9.1
            Download: http://www.wordpress.org/latest.tar.gz

As cronjob

If you want to be notified as soon as a new version comes out, installing a cronjob is a good idea. Simply run crontab -e and add the following line to the file:

0 6 * * * /usr/local/bin/wp-un /var/www/myblog admin@example.com

WP-UN will now run every morning at 6am and notify you if a new WordPress version is out there!

Conclusion

WP-UN is just one of many solutions and it’s only the work of one afternoon. However, it doesn’t need any additional software and keeps it simple. It serves its purpose and keeps my WordPress installation always up-to-date. If you have any suggestions or questions, feel free to comment below.

I have always wondered why most ESPs don’t offer greylisting for their mailboxes, but only rely on less effective and resource-hungry post-retrieval filter methods. Unfortunately, my e-mail provider is one of them so that I get at least a couple of spam mails a day …

Luckily, it is very easy to set up your own mail relay with greylisting support, i.e. a mail server that simply forwards the mail to your real provider once it passes the greylist-filter.

This little tutorial describes how to set up Postfix and SQLgrey as mail relay.

1. What you need

• A dedicated or virtual private server with SSH root access.
• Access to the DNS entries of your domain for adjusting the MX record; in this post called example.com

2. How it works

If you have outsourced all e-mail services to a service provider like I have, the MX record of your domain usually points to your provider’s mail server. That is, your mails go directly to the mail server of your provider, e.g. Google’s mail server → your provider’s mail server. That is, your DNS configuration looks something like this:

$ dig example.com mx
...
example.com.		IN	MX	50 mx0.example.com.
mx0.example.com.	IN	A	(your provider's mail server IP)
...

In order to pre-process mails with greylisting and blacklisting, your server will handle mails as intermediary, i.e., mails will always traverse your server first; in the above case something like Google’s mail server → your mail server → your provider’s mail server. Consequently, the MX record has to be changed to the IP address of your server:

$ dig example.com mx
...
example.com.		IN	MX	50 mx0.example.com.
mx0.example.com.	IN	A	(your server IP)
...

But, first things first: we need to configure our server before we change the DNS records!

3. Installation & Configuration

If you have a Debian based system, install Postfix, SQLgrey and MySQL using apt-get:

$ apt-get install postfix sqlgrey mysql-server

This will install:

• Postfix: a fully functioning MTA which will be configured as mail relay, i.e., instead of storing arriving mails on the system, it will just greylist them and then forward them to their real destination (your provider’s mail server).
• SQLgrey: a SQL-based greylisting add-on for Postfix. Before accepting mails blindly, Postfix will ask the SQLgrey daemon whether to accept the mail or not. SQLgrey keeps track of mail delivery attempts and only replies with success if the foreign MTA tried delivering the mail at least twice.
• MySQL: a RDBMS which will be used as back-end for storing Postfix’s routing tables and SQLgrey’s caching tables. Both Postfix and SQLgrey also support other back-ends such as PostgreSQL.

3.1. Configuring SQLgrey

SQLgrey’s config files reside in /etc/sqlgrey/, the main configuration happens in /etc/sqlgrey/sqlgrey.conf. The file is well documented and offers many possibilities.

The most important options are:

• inet: IP address and port to bind the daemon to, default is 127.0.0.1:2501
• db_*: database connection details, i.e., database, user and password
• greymethod: defines which IP class to use for greylisting. Especially important for big e-mail service providers since the same mail might be delivered from two different IP addresses (Class C greylisting recommended!).
• optmethod: defines if greylisting is enabled by default (optout), or has to be enabled specifically for each address or domain (optin).

3.1.1. Config file /etc/sqlgrey/sqlgrey.conf

My configuration looks like this:

inet = 10101 # bind to localhost:10101
reconnect_delay = 5 # no reconnect before 5 minutes
max_connect_age = 24 # no reconnect after 24 hours
 
# database settings
db_type = mysql
db_name = sqlgrey
db_host = localhost
db_user = sqlgrey
db_pass = sqlgreypassword
db_cleandelay = 1800 
clean_method = sync # 'async' is said to be buggy
 
# greylist by class C network. eg: 2.3.4.6 connection
# accepted if 2.3.4.145 did connect earlier
greymethod = classc
 
# one must optin to have its (incoming) messages being greylisted
optmethod = optin

3.1.2. Database

SQLgrey has a fixed database structure which is set up automatically when the script is started. All that needs to be done is to create a new database sqlgrey with a corresponding user. You can do this manually, or with a tool like phpMyAdmin:

CREATE USER 'sqlgrey'@'localhost' IDENTIFIED BY 'sqlgreypassword';
CREATE DATABASE IF NOT EXISTS `sqlgrey` ;
GRANT ALL PRIVILEGES ON `sqlgrey` . * TO 'sqlgrey'@'localhost';
FLUSH PRIVILEGES;

3.1.3. Populating the database

SQLgrey automatically creates the required tables when it starts for the first time. So start the daemon using the provided init.d-script:

$ /etc/init.d/sqlgrey start

This creates a couple of tables in the sqlgrey-database. For our purpose and configuration, the tables optin_email and optin_domain are most interesting because only domains and e-mail addresses in these tables will be greylisted.

For our example, we will enable greylisting for the whole domain example.com:

INSERT INTO `sqlgrey`.`optin_domain` (`domain`) VALUES ('example.com');

That’s it for SQLgrey. Once we connect it to Postfix, it’ll provide us with the greylisting service we want.

3.2. Configuring Postfix

Postfix is a very flexible and powerful mail transfer agent (MTA) and can be used as final destination, or mail forwarder (mail relay). For this scenario, Postfix will be a mail relay which only forwards an e-mail if

• its recipient is listed in the database
• and it passes the greylisting-filter

The configuration files of Postfix reside in /etc/postfix/. The most interesting file for our purpose is /etc/postfix/main.cf.

In order to not be confused by all the more or less useful config parameters, the file shown here is minimal, i.e., you cannot remove any parameter without major consequences. Details to each of them can be found in the Postfix configuration man-page.

The most important parameters for the configuration as mail relay are:

• myhostname: this defines your hostname, i.e., in this case relay.example.com. Regarding the hostname, two things must be considered very thoroughly:
  1. The hostname must resolve to the IP address of your server, i.e., make sure you don’t state a fake host here. Postfix uses this value as HELO/EHLO identification, and some mail servers might reject your mails if this value doesn’t resolve to your server’s IP address.
  2. If you use your top level domain here, e.g. example.com, some mail servers might additionally perform a MX lookup and match your server’s IP address with the one of the MX record. In case the MX record points to a different IP address than the A record of the TLD, foreign servers might also reject all your mails. In my case, this resulted in log entries like this:

     postfix/smtp: to=<john.doe@example.com>, 
       relay=mx.my-esp.tld:25,  status=bounced 
       (host mx.somedomain.com[1.2.3.4] refused to talk to me: 
       550 Forged HELO: you are not example.com)

     As you can see, the foreign hosts suspected me of forging the HELO name, and denied relaying my mails.

• relay_domains: this option links to the database table relay_domains and defines the domains managed by this mail server. If a recipient-domain is not in this table, Postfix will reject the mail. For this example, the domain example.com must be added to this DB table.
• relay_recipient_maps: this option links to the database table relay_recipients and defines the e-mail addresses managed by this mail server. If a recipient address is not in this table, Postfix will reject the mail. This option is closely linked to relay_domains and will not work without it!

  In this case, only one address will be added to this table: john.doe@example.com.

• transport_maps: this option links to the database table transport and defines to which mail server incoming mails will be forwarded. Routing can happen address- or domain-based.

  In this case, mails for example.com shall be forwarded to our provider’s mail server, i.e., this table must have an entry of the form example.com → smtp:[mx.my-esp.tld].

  For details on the value format, read the transport man page.

• smtpd_recipient_restrictions: this is where the actual magic happens. This option checks the RCPT TO field of each incoming mail, i.e., the recipient, and then queries the greylisting service. Its options closely relate to the relay_*-tables from above:
  • permit_mynetworks allows local applications to send e-mails. If you have web sites running on localhost that may use e-mail, do not remove this option.
  • reject_unauth_destination queries the relay_domains SQL table, i.e., it checks whether a the incoming recipient domain is relayed by our server.
  • reject_unlisted_recipient queries the relay_recipients SQL table to find out if the exact address is relayed.
  • check_policy_service queries the SQLgrey daemon which in turn either allows or rejects the mail.

3.2.1 Config file /etc/postfix/main.cf

Here’s the minimal main.cf config file to make Postfix a mail relay with greylisting support:

# This is a minimal main.cf config file. Make sure to read the above 
# comments so you understand what each option means.
 
# server name; must resolve to your server's IP address
myhostname = relay.example.com
 
# avoid warning message 'dict_nis_init: NIS ...'
alias_maps = 
 
relay_domains = mysql:/etc/postfix/mysql_relay_domains.cf
relay_recipient_maps = mysql:/etc/postfix/mysql_relay_recipient_maps.cf
transport_maps = mysql:/etc/postfix/mysql_transport_maps.cf
 
smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        reject_unlisted_recipient,
        check_policy_service inet:127.0.0.1:10101

3.2.2. Database

Postfix is very flexible when it comes to address and route handling. In fact, its configuration doesn’t need a database back-end at all. However, using a SQL database makes everything much easier. I decided to use a very straight forward database structure which directly relates to Postfix’ configuration options.

First, create a database postfix and a corresponding read-only user:

CREATE USER 'postfix'@'127.0.0.1' IDENTIFIED BY 'postfixpassword';
CREATE DATABASE IF NOT EXISTS `postfix` ;
GRANT SELECT ON `postfix` . * TO 'postfix'@'127.0.0.1';
FLUSH PRIVILEGES;

Note: It is important that you use 127.0.0.1 as host, and not localhost, because Postfix runs in a chroot-environment and wouldn’t be able to access localhost.

After setting up the database, add the following three tables:

CREATE TABLE `relay_domains` (
  `domain` varchar(255) NOT NULL,
  `active` enum('y','n') NOT NULL DEFAULT 'y',
  PRIMARY KEY  (`domain`)
);
 
CREATE TABLE `relay_recipients` (
  `email` varchar(255) NOT NULL,
  `active` enum('y','n') NOT NULL DEFAULT 'y',
  PRIMARY KEY  (`email`)
);
 
CREATE TABLE `transport` (
  `pattern` varchar(255) NOT NULL,
  `relay` varchar(255) NOT NULL,
  `active` enum('y','n') NOT NULL DEFAULT 'y',
  PRIMARY KEY  (`pattern`)
);

In order to connect Postfix with the database, we need to create the three config files specified above: /etc/postfix/mysql_*.cf:

# /etc/postfix/mysql_relay_domains.cf
hosts = 127.0.0.1
user = postfix-read
password = postfixpassword
dbname = postfix
query = SELECT domain FROM relay_domains WHERE domain='%s' AND active='y'

# /etc/postfix/mysql_relay_recipient_maps.cf
hosts = 127.0.0.1
user = postfix-read
password = postfixpassword
dbname = postfix
query = SELECT email FROM relay_recipients WHERE email='%s' AND active='y'

# /etc/postfix/mysql_transport_maps.cf
hosts = 127.0.0.1
user = postfix-read
password = postfixpassword
dbname = postfix
query = SELECT relay FROM transport WHERE pattern='%s' AND active='y'

Before we can now start testing our server, we need to compile these config files to Postfix compatible lookup tables. Do that by running the following command:

$ postmap /etc/postfix/mysql_*.cf

3.2.3. Populate the database

Now we have to fill Postfix’ database with the domains and addresses we’d like to relay. In particular, that means we have to add example.com to relay_domains and transport, and the full addresses to relay_recipients:

INSERT INTO `postfix`.`relay_domains` (`domain` ,`active`)
   VALUES ('example.com', 'y');
 
INSERT INTO `postfix`.`relay_recipients` (`email` ,`active`)
   VALUES ('john.doe@example.com', 'y');
 
INSERT INTO `postfix`.`transport` (`pattern` ,`relay` ,`active`)
   VALUES ('example.com', 'smtp:[mx.my-e-mail-service-provider.tld]', 'y');

The entry structure for each table is different. Please refer to the Postfix manual for details (cp. transport, relay_domains, and relay_recipient_maps).

Note: the database structure above is not optimal since it requires redundant entries in three different tables. Even though the structure is not perfect, I have chosen this layout to make it easily understandable!

4. Test your server

After this short configuration period it’s now time to finally start the Postfix server:

$ /etc/init.d/postfix start

To make sure you didn’t make any mistakes in the configuration, you should now check the log files. Postfix and SQLgrey both use syslog so that you should be able to determine the system’s status like this:

$ tail -n 20 -f /var/log/syslog

If the log doesn’t show any errors, we can now try if everything works as expected. To do so, simply connect to the server from your home computer via telnet:

$ telnet relay.example.com 25
Connected to relay.example.com.
Escape character is '^]'.
220 relay.example.com ESMTP Postfix
HELO somebody
250 relay.example.com
MAIL FROM: some@address.tld
250 2.1.0 Ok
RCPT TO: john.doe@example.com
450 4.7.1 <john.doe@example.com>: 
   Recipient address rejected: Greylisted for 5 minutes

If Postfix replies with a 450 error code, i.e., relay temporarily denied, everything works just fine. On the server side, the log should output something like this:

postfix/smtpd: connect from 1-2-3-4.your-isp.tld[4.3.2.1]
 
sqlgrey: grey: new: 4.3.2(4.3.2.1), some@address.tld->john.doe@example.com 
postfix/smtpd: NOQUEUE: reject: RCPT from 1-2-3-4.your-isp.tld[4.3.2.1]: 
    450 4.7.1 <john.doe@example.com>: 
    Recipient address rejected: Greylisted for 5 minutes; 
    from=<some@address.tld> to=<john.doe@example.com> ....
 
postfix/smtpd: disconnect from 1-2-3-4.your-isp.tld[4.3.2.1]

Wait 5 minutes and try connecting again via telnet. This time, SQLgrey will detect that this is your second delivery attempt and add the sender e-mail and its IP address to the automatic white list (AWL). Postfix will accept your mail and forward it to your provider’s mail server (according to the transport-table):

postfix/smtpd: connect from 1-2-3-4.your-isp.tld[4.3.2.1]
 
sqlgrey: grey: reconnect ok: 4.3.2(4.3.2.1), 
    some@address.tld -> john.doe@example.com (00:22:42) 
sqlgrey: grey: from awl: 4.3.2, some@address.tld added 
 
postfix/smtpd: client=1-2-3-4.your-isp.tld[4.3.2.1]
postfix/cleanup: message-id=<201001...@relay.example.com>
postfix/qmgr: from=<some@address.tld>, size=422, ...
postfix/smtp: to=<john.doe@example.com>, 
    relay=mx.my-esp.tld[12.34.56.78]:25, status=sent, ...
postfix/qmgr: removed
 
postfix/smtpd: disconnect from 1-2-3-4.your-isp.tld[4.3.2.1]

5. Go live: change the DNS record

Play around a little and make sure that everything works as expected. If it does, change the DNS record like described above, i.e., set the MX record of the domains to be relayed to your server’s IP address.

Note: For the first few mails, you should definitely watch the logs. If anything goes wrong, you can always change back the MX record. But be aware that DNS changes might take up to 48h!

If you have any questions, please comment below. I am open for suggestions!

On my journey through the Web I looked into the details of various business notebooks. I stumbled across the Dell Latitude E6400, which looks nice and has everything I wanted. Unfortunately, it also seems to have problems with Ubuntu. In particular, the fan seems to run all the time (and not too slow, but very loud) – as many forum posts and user reviews prove [1,2,3,4].

Since I couldn’t find a solution, I decided to ask the Dell support via their support chat.

Update Nov/09: It appears that a BIOS update addresses the heat problem. Please refer to the community forum post (thanks to chato) for details.

Here’s what I found out. Note: This is a chat with the German Dell support from September 21, 2009, translated into English.

Me:
The Latitude E6400 has (like many forum posts say) a big problem with Ubuntu. In particular, the fan is always on and makes a lot of noise.

Agent:
Welcome to the Dell Chat.

Me:
Hallo. I’d like to know if there already is a solution for this problem. I was thinking about buying a E6400, but I couldn’t find any solutions for the fan/noise problem in Ubuntu.

Agent:
Since we do not support Ubuntu on this device, Dell does not work on a solution. Ubuntu is currently only supported on netbooks. There is no solution.

Me:
Okay. Do you think there will be a solution in the future? Is Dell planning to support Ubuntu on the E6400? Or never?!

Agent:
As I said, we don’t sell the device with Ubuntu.

Me:
Okay. Thank you for the honest answer. I’m gonna have to buy a Thinkpad then … Have a nice day.

Agent:
I’m sorry. But we don’t support Linux.

Me:
It’s not your fault. Thanks anyway. Good bye.

Agent:
I’m so sorry.

So the outcome is: The Dell Latitude E6400 doesn’t support Ubuntu and is NOT planning to solve the fan/noise problem.. That means, I’m gonna have to buy one of those ugly Thinkpads. But what other solutions are there?! None!

Even though this is a good idea for some situations, most of the times, it’s just annoying: Collecting ideas for seminar papers or a thesis, for instance, is almost impossible without being able to Copy & Paste certain paragraphs from the PDF.

Fortunately, Linux can solve this problem with a simple tool called pdf to text. This command line tool simply strips all text from the PDF file and saves it to a given text-file.

Installation

The tool is part of the package poppler-utils and can be installed via your favorite package manager, e.g. apt-get:

$ apt-get install poppler-utils

Extract text from PDF files

This is also pretty simple and the man-page gives the instructions: pdftotext [options] <PDF> [<text-file>].

$ pdftotext PDF-file-with-copy-and-paste-restriction.pdf

In case you’d like to perform this for every PDF-file in a folder (recursive search), simple do that:

$ find -name '*.pdf' -exec pdftotext "{}" \;

After executing the command, there will be a *.txt-file for each PDF file in the folder, – containing the plain-text of the corresponding PDF file.

This is where a password manager comes in handy: Open the password vault by typing in the master password, put in all you secrets and crucial information, save it and be happy. As if!

Almost every password manager I found on the Web was crowded out by details so that it took minutes to add a single account. What I wanted was something like a text-file with password — and that’s what I made: A simple command-line password safe.

How it works

Simsafe is nothing else but a simple Perl script wrapped around the symmetric encryption functions of GPG. Every box with GPG and Perl installed can hence use the script (= every linux box!). And even if the simsafe-script is not installed on the system, a simple gpg –decrypt FILE shows the plain text contents. That is, Simsafe files are nothing more but text-files with password!

Usage

It’s simple and really easy to use.
Syntax:

$ simsafe FILE

Create a new password safe file

$ simsafe mySafe
simsafe: Creating a new password safe 'mySafe'
simsafe: Please enter the new password: (type in your password)
simsafe: Please confirm the password: (confirm your password)
simsafe: Executing editor vi ...
  // VI or your favourite editor opens
  // and you can edit the plain text file
simsafe: Encrypting with GPG ...

Adding/Removing entries to the password vault

$ simsafe mySafe
simsafe: Please enter the safe password: (type in your password)
simsafe: Decrypting with GPG ...
simsafe: Executing editor vi ...
  // VI or your favourite editor opens
  // and you can edit the plain text file
simsafe: Safe unchanged.

Get it!

It’s a reeeaallly small script and this post is possible longer than the perl-file itself, but here it is. Simply download it, make it executable and put it somewhere in your PATH.

Download: Simsafe v0.1, Apr. 2009

The Kademlia Protocol

Kademlia is based on four simple remote procedure calls (RPCs) and guarantees a very fast and lightweight exchange of information by using the connection-less UDP instead of TCP. Every node as well as every entry of the DHT is tagged with an identifier, called node ID or key. By XORing identifiers, one can calculate the distance between them and is hence able to walk through the network knowing whether one is near or far to a specific node. This so called XOR metric makes it possible to group the entries of the DHT around the K closest nodes to the entry’s key. An entry with the key 10, for instance, will be stored at the nodes with a node ID close to 10.

Kademlia + PKI = KadS: The Secure Extension

In my Bachelor thesis, I am going to extend Kademlia from a simple peer-to-peer protocol to a trusted and secure network. The proposed KadS network is almost identical to the Kademlia network, i.e. it consists of the described RPCs and implements the same XOR metric. The major extension to the protocol is that every node is equipped with a public/private key-pair signed by a trusted CA. This extends the normal Kademlia network to a public key infrastructure (PKI) in which every communication is encrypted, every node can be trusted and only verified nodes can participate in the network.

Every connection is synchronously encrypted with a session key which is created and exchanged in a handshake procedure when two nodes first meet. That is, a node has a different session key for the connection with each node it knows in the network. The handshake is similar to the one used in other software except for the fact that both clients exchange their public key and need to verify each others identity. After a successful handshake, two nodes are able to exchange lightweight encrypted messages using the session key and the basic protocol applies

An application: The distributed URL blacklisting service

As an application to the proposed KadS network, I chose a distributed URL blacklisting service. Please read more in my Bachelor thesis exposé, or simply download the whole thesis:

Blacklisting Malicious Web Sites using a Secure Version of the DHT Protocol Kademlia.

In my case, my external disk has four partitions. Every time I plug in the disk, Nautilus opens four windows. Each of them is blinking in the panel, — really annoying!

How to disable it?

Open Nautilus –> Edit –> Preferences –> Media
Now disable Browse media when inserted. That’s it.

I know, it’s pretty easy but it took me a while to figure it out. So I thought I save you guys the effort of searching the Web.

Since Unison can also be used to sychronise more than two hosts, it’s perfect for big amounts of data that has to be shared in a team.

A scenario like this is possible and works for me: UserA <-> Server <-> UserB.
But of course, also other users could sync with the server. Unison rocks!

Today, after reinstalling his OS, my friend got the following error message:

Warning: inconsistent state.  
The archive file is missing on some hosts.
For safety, the remaining copies should be deleted.
  Archive are96968da50882488164ef52510703a8e on 
     host <UserAs-local-hostname> is MISSING
  Archive ar664775fc717afcf6cc46edbc47d25641 on ...

The easy solution

Unison keeps archive-files for each pair it synchronises with. One on each host, i.e. one on your local PC (UserA) and one on the server, both stored in a folder called ~/.unison and looking like the files above.

The easiest solution would be to just delete all archive-files on the server as unison suggests. But that would result in a situation where all the other users that sync their files with the server would have to do a slow sync which is extremely slow and sometimes takes more than 20 minutes for large folders (e.g. > 10 GB).

The best solution …

… is to just delete the required archive-files on the server. Pretty easy, that’s how it works:

Log on to the server (assuming that it’s a Linux machine, but it certainly works similar for any other system) and find the relevant archive files:

$ ssh mysyncuser@mysyncserver.com
$ cd ~/.unison
$ fgrep '//UserAs-local-hostname/' ar*

You should get something like this:

Binary file ar664775fc717afcf6cc46edbc47d25641 matches

Delete the listed files and it should work like a charm.

Unfortunately, the installation on Ubuntu/Kubuntu and any other Linux distribution is still not the most comfortable. For this reason, I sat down some hours and packed the tool into a deb-package and additionally added a nice command line tool to simplify some of the basics.

For those who can’t wait, here’s the package: gcaldaemon_1.0beta16~ubuntu0_all.deb

Update Nov/08: Ubuntu Intrepid: I just re-installed my Ubuntu and successfully tested the provided version for the new system. Works like a charm for Hardy and for Intrepid.
~ 150 downloads so far, no complains/malfunctions!

Update Feb/09: Launchpad: I just uploaded the code that creates the deb-package on Launchpad. Maybe somebody of the Ubuntu team will pick it up and integrate it into the distribution. There is also a bug report for this issue, – feel free to contribute.

For all of you interested how to create your own package from my sources, follow these steps:

$ bzr branch lp:~binwiederhier/+junk/gcaldaemon
$ cd gcaldaemon
$ wget http://downloads.sourceforge.net/gcaldaemon/gcaldaemon-linux-1.0-beta16.zip
$ sudo ./create-package.sh gcaldaemon-linux-1.0-beta16.zip 'gcaldaemon_1.0beta16~ubuntu0_all.deb'
$ sudo dpkg -i gcaldaemon_1.0beta16~ubuntu0_all.deb

Update Apr/09: Ubuntu 9.04, Jaunty Jackalope: As Jens just wrote in the comments-section, the deb-package seems to work for Jaunty as well without complications. Yeyy!

Download and install

Alternatively to creating the package from my source, you can just download and install it from my deb-file:

$ wget http://blog.philippheckel.com/uploads/2008/09/gcaldaemon_1.0beta16~ubuntu0_all.deb
$ sudo dpkg -i gcaldaemon_1.0beta16~ubuntu0_all.deb

The following tools will be available:

• gcaldaemon
  Start/stop/restart the daemon.
• gcaldaemon-sync-now
  For immediate synchronization.
• gcaldaemon-config
  Open the graphical config editor.
  Also available via the menu „Utilities -> Configure GCALDaemon”.
• gcaldaemon-password-encoder
  Encode passwords for the config file.

Configuration

Each user of the system can have his or her own instance of the daemon running.
The config file is located at ~/.gcaldaemon/conf/gcal-daemon.cfg.

To edit the config file, you can either use your favorite editor, e.g. vi or use the GCALDaemon config editor GUI:

$ gcaldaemon-config

You can also open the config editor via the menu: „Utilities -> Configure GCALDaemon”.

To create passwords for the config file use the gcaldaemon-password-encoder-script. For details about the config options, please read the GCALDaemon documentation.

Running GCALDaemon

I have simplified the way how to start/stop the daemon with a small script. Simply type “gcaldaemon” to see what it can do.

To start, restart, stop and check the status (just like in an init-script), type:

$ gcaldaemon start
Starting GCALDaemon ... ok
 
$ gcaldaemon status
GCALDaemon is running as PID 30543.
 
$ gcaldaemon restart
Stopping GCALDaemon ... ok
Starting GCALDaemon ... ok
 
$ gcaldaemon stop
Stopping GCALDaemon ... ok

Enable autostart for GCALDaemon

To enable the autostart-option for GNOME or KDE, type:

$ gcaldaemon enable kde
$ gcaldaemon enable kde4
$ gcaldaemon enable gnome

As a GNOME user, it’s also possible to enable/disable the daemon autostart via the menu „System -> Settings -> Sessions”

Finally …

I know that the package is far from perfect, but it’s a lot easier to install/configure than the original package. Feedback is always welcome.

1^st step: Copy the flash video files (capture the FLV-files)

Ubuntu (and I guess nearly every Linux distribution) makes it really easy to download the flash videos which can be streamed on platforms like Youtube and all the others. Bad luck for Windows users.

• Just open your browser (Opera in my case, Firefox does it too)
• Go to the website with the video you want to stream
• Hit “Play”, wait a few seconds and push “Pause” so that the video starts to buffer
• Now open the /tmp-folder in a file manager like Nautilus or Konquerer
• You will find a file with a name like “Flashzad23″, in any case something starting with “Flash”
• Rename this file to “my-youtube-video.flv”. This also works when the buffering process has not been finished yet

That’s it.

If you just want to watch the video, it’s possible to just open it with your favourite player such as VLC, Totem, MPlayer, etc. This also works while it is still buffering! But since you want to copy it to the iPod Video, you need to resize/re-encode it to a m4v- or mov-file.

2^nd step: Resize/Re-encode the flv-file for the iPod Video

Unfortunately, I didn’t find a perfect and fast solution to re-encode flv-videos for the iPod. I will demonstrate two ways, the fast one for movies and series you only want to watch once. And the perfect one for videos you want to keep on the iPod for a longer time.

Install “ffmpeg” from the Medibuntu repository

For both ways it is at least necessary to install the packages ffmpeg and libavcodec0 from the Medibuntu Repository instead of the regular Ubuntu reps.

You can find out how to do this on the Ubuntu help pages.

The fast way

The fast way a one big disadvantage: The iPod isn’t able to estimate the length of the video. That means it’s not possible to use the nice diamond control to jump within the video. Regular rewind and fast-forward is still possible anyway.

Luckily, you only need one tool: ffmpeg. Just install it via apt-get:

$ apt-get install ffmpeg

Basically, just use this command to convert a flv-file to a mov-file (readable/playable by the iPod Video):

$ ffmpeg -i "my-youtube-video.flv" -f mp4 -vcodec mpeg4 -maxrate 1000k \
   -b 700k -qmin 3 -qmax 5 -bufsize 4096 -g 300 -acodec aac -ab 192k \
   -s 320x240 -aspect 4:3 "my-youtube-video.mov"

To simplify the mass-conversion, I wrote a tiny script which can be copied to your own “.bin”-directory (cp. this article):

#!/bin/bash
 
for file in $@; do
        ffmpeg -i $file -f mp4 -vcodec mpeg4 -maxrate 1000k -b 700k -qmin 3 -qmax 5 \
           -bufsize 4096 -g 300 -acodec aac -ab 192k -s 320x240 -aspect 4:3 $file.mov
done

The perfect (and slow) way

Well, this way might be the better one since the disadvantage from above doesn’t occur. Unfortunately, it does take a lot longer. A LOT! But just try it out by yourself.

I found an flv-to-iPod (m4v) encoding script on ubuntu.com written by John Dong. Find instructions and installation hints to the script on the Ubuntu Wiki

3^rd and last step: Transfer the video to the iPod

Use gtkpod or your favorite iPod managing software to transfer the video to your iPod.
I hope this helped a little. Please let me know if you have difficulties or found a better (easier) way to do the conversion!