Dump a database table from MySQL:
$ mysqldump -u <db-username> -<db-password> --opt --quote-names --allow-keywords --complete-insert <db-name> <db-table> > <output-file>

Slurp a database table back into MySQL:
$ mysql -u <db-username> --password=<db-password> -D <db-name> < <input-file>

Copy over a MySQL table dump or any other file
$ scp -P <optional-port> <username>@<IP>:/some/path/to/remote/file <local-file>

Copy over a complete directory with rsync, with additional ssh parameters:
$ rsync -av --progress --stats --copy-links -e 'ssh -p <ssh-port>' <username>@<IP>:/path/to/dir/with/trailing/slash/ /path/to/target/dir
 

Following some of the guidance on the Codex' Login Trouble page brought now resolution, some even felt simple-minded, like deactivating plugins or chaning file permissions - the latter being stupid as this was clearly an application layer problem and nothing with permission on the fs level...

The solution came via this post:

This post mentioned what I had done: renaming the database tables from the default wp_<whatever> to wp_<some-id>_<whatever>. I did this to accommodate multiple WP installs in one database.
Of course, I had properly changed the prefix in the wp-config.php file, from $table_prefix  = 'wp_pf_'; to $table_prefix = 'wp_<some-id>_';

The problem was that WP pulls user permissions from the wp_usermeta and the wp_options tables and uses (why! why! why!?) the prefix supplied in the wp-config.php file to build some essential keys, like <prefix>_capabilities in these dbs!

So I could resolve the insufficient permission error by doing this:
You have to update the key/value pairs in the following database-tables:

In the <prefix>_usermeta table, there are several keys that need to be renamed:

<prefix>_capabilities
<prefix>_dashboard_quick_press_last_post_id
<prefix>_prefix_user-settings
<prefix>_user-settings-time

and in the <prefix>_options table:

<prefix>_user_roles

After that, login worked again.

The defaults for fcgi have changed from Lenny (was 1GB) to Squeeze (is now 128KB)

Solution is:
Go to /etc/apache2/mods-available/fcgid.conf
and add (here for 2GB):

<IfModule mod_fcgid.c>
...
...
# 2GB
FcgidMaxRequestLen 2147483648
</IfModule>

via

Simple byte calculator

• http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/
• http://forceping.com/2010/03/18/mod_gnutls-sorgt-fur-namebased-ssl-virtualhosts/
• http://www.outoforder.cc/projects/apache/mod_gnutls/docs/#example

then install
$ apt-get install libapache2-mod-gnutls

then run
$ a2enmod gnutls

check if anything is configured in these files that would prevent apache2 from working with gnutls:
nano /etc/apache2/httpd.conf
nano /etc/apache2/apache.conf

configure your virtual hosts, refer to the manual mentioned above on how to do that
nano /etc/apache2/sites-enabled/000-default

Possibly your will need to add the GnuTlsPriorities directive to common config examples, see:
http://www.outoforder.cc/projects/apache/mod_gnutls/docs/

tar outputs to stdout ("-", the minus), 7-zip, here 7zr, reads from stdin ("-si") and outputs a 7zip file - all connected by the pipe.

• So you've freshly installed exim or got a fresh install with Debian Squeeze?
• You did not tinker with the config files manually but used dpkg-reconfigure exim4-config so that you were guided through the basic config?
• You are not running greylistd, although all the other posts you've found related to "temporarily rejected RCPT" are related to that? (Note that exim4 has greylisting not built in or installed with it by default! So the error here is not coming from there.)
• No mail is getting into your server, you are not receiving mail in your inbox.

My solution:
Check your FQDN (fully qualified domain name), the value the wizard filled in for you on the first reconfgure question seems to be wrong!
Use hostname --fqdn to get the real FQDN of your machine. After that answer all the questions as before and after exim has restarted mail should work.

(In a debug session [see below: Coda point 2 for that] I found out that exim reported "451 Temporary local problem - please try later" to calling SMTP servers, so my local config seemed to be the problem, and as the errors also mentioned something with local host name as the root of the problem, I figured it had to do with my FQDN setting.)

Coda
Some posts say that this is related to DNS - it is not, not really. I had no hints of failed DNS lookups in the logs.

Watch what exim is doing, the easy way with:
$ tail /var/log/exim4/mainlog -f

This post here was useful:
use exim -d -bh [a-senders-ip-address] with an IP from the logs where you've found the error with exim in a debug session.
Manually enter a MAIL FROM: foo@example.com and exim will tell you how it handles it.
Then manually enter a receiver address with RCPT TO: my-email@example.com, where in my case exim began to point me into the right direction.

Editing a section out from the middle of a video:
$ ffmpeg -i <input> -ss hh:mm:ss.000 -t hh:mm:ss.000 -sameq <output>
(-ss seek to position, -t duration of relevant segment, -sameq maintain quality of input)
You might also use -vcodec copy -acodec copy to 1:1 edit out data from the input, but I've found that most videos don't have keyframes where you expect them, for example with one mov I've edited, the result was all black as the video didn't render. So on editing video, you seem to have to re-encode with most video to get what you expect, loosing a generation in the process.
 

ffmpeg -i <input_video> -f image2 <output_name>%03d.jpg

a more verbose variant:

ffmpeg -i <input>.avi -r 1 -s WxH -f image2 <output>-%03d.jpeg

To create a video from a sequence of images (the other way round):

ffmpeg -f image2 -i foo-%03d.jpeg -r 12 -s WxH foo.avi

A look into /etc/fstab brought up nothing helpful: UUID=xyz none  swap    sw 0 0 seemed okay. So as it seems there was an error with the volume that was listed as swap.

Then, listing partitions with fdisk -l showed that there was no swap.

swapon -a -v gave me:

swapon on /dev/sda5
swapon: /dev/sda5: found swap signature: version 1, page-size 4, same byte order
swapon: /dev/sda5: pagesize=4096, swapsize=3016753152, devsize=3007315968
swapon: /dev/sda5: last_page 0xb3d00000 is larger than actual size of swapspace
swapon: /dev/sda5: swapon failed: Invalid argument

Looks like something corrupted my swap. Or the swap might not be formatted. Thus, I created/formatted it anew with:

mkswap /dev/sda5

which gave the device a new UUID. After adding the new UUID to /etc/fstab the swapon command worked and swap was there. Looking at the boot sequence is a todo.
All this might have resulted from a strange hiccup before I possibly never will find out about.