First of all, I decided for duplicity as tool to perform this backup encrypted automatically. I decided to do it encrypted, because there is sensible data in the wiki, a reason why my whole home directory is encrypted using ecryptfs. The scripts below need some small changes in case your home directory is not encrypted (and the cronjob thus runs even when you are not logged in).

To use the backup routine described below, you need a gpg key and an ssh key. The gpg key is required to encrypt the data transferred to the remote server, while the ssh key is required to do a passwordless transfer.

Basically, I use the following two lines to do the automatic backup and rotate full backups periodically:

duplicity  incremental --full-if-older-than 2W --encrypt-key $ENCRYPTKEY  $LOCAL_DIRECTORY scp://$USER@$HOST//$REMOTE_DIRECTORY >>  $HOME/logs/wikibackup.log
duplicity remove-all-but-n-full 2 --force scp://$USER@$HOST//$REMOTE_DIRECTORY >> /$HOME/logs/wikibackup.log

The first line does an incremental backup of the local directory (e.g. /home/user/desktopwiki) to a remote host with given directory. For encryption the gpg key ID is given as parameter and output logged. Every two weeks it performs a full backup and between normal incremental backups. This is just to not grow the remote directory file list permanently. The seond line deletes the full backups except the current and the one before (that is in fact not necessary, the paramter could also be 1).

When you have your ssh key in your gnome keyring and run those commands with the respective variables set in a terminal while logged in, the backup is performed.

Apparently I don’t trust myself in not forgetting to run this from time to time. So a cronjob is required.

When setting this up, the problem comes up, that the ssh key needs to be opened with a password, because cron does not know your gnome keyring. One solution is to create a separate keyring for your cronjob, but in the given case, a backup is only necessary when I am logged in, because there are no changes otherwise. Beside this, a backup is only possible when I am logged in, because the encrypted home directory is not open otherwise and data not accessible.

So, I decided to just propagate the information where the keyring can be used (the SSH_AUTH_SOCKET environment variable) to the backup-script called by cron via a simple text file. When cron calls the script, the variable is apparently unknown.

Thus I modified wikistart.sh by simply adding the following line at the end:

echo $SSH_AUTH_SOCK > ~/desktopwiki/wikibackup_sshauthsock

My backup script then simply exports the content to the SSH_AUTH_SOCK variable for duplicity and the gnome keyring is used then.

The full backup script /home/user/desktopwiki/wikibackup.sh:

#!/bin/bash

HOST=remote.host.name
USER=username
LOCAL_DIRECTORY=/home/user/desktopwiki
REMOTE_DIRECTORY=/home/user/desktopwiki
ENCRYPTKEY=yourkeyid
export SSH_AUTH_SOCK=`cat /home/user/desktopwiki/wikibackup_sshauthsock`

if [ ! -e $SSH_AUTH_SOCK ]; then
	exit;
fi

ssh $HOST "ls" &> /dev/null

if [ $? == 0 ]; then
	duplicity incremental --full-if-older-than 2W --encrypt-key $ENCRYPTKEY $LOCAL_DIRECTORY scp://$USER@$HOST//$REMOTE_DIRECTORY >> /home/user/logs/wikibackup.log
	duplicity remove-all-but-n-full 2 --force scp://$USER@$HOST//$REMOTE_DIRECTORY >> /home/user/logs/wikibackup.log
fi

Finally, I set a simple cronjob to run the backup in the background:

0 * * * * /home/wallento/desktopwiki/wikibackup.sh

But recently I came to the conclusion, I need a more powerful wiki engine and I also wanted to get rid of those different places where documents are stored, namely my IMAP inbox, home directory, several SVNs etc..

Instead my new way of doing this is to store group documents in SVN and have a local working copy. Group information and general documents are stored in an intranet wiki. And my personal documents and information I will store on a local wiki.

My choice is MoinMoin as locally running wiki. It is quite simple, pure python and file based. Just call a simple script and it runs as a service. I want to start the server when I log in to Gnome, it can’t even be started before, because my home folder is encrypted using ecryptfs.

Here are the steps to take:

1. Download the latest version of MoinMoin and extract it to some local folder, such as /home/user/desptopwiki/moin-1.9.3
2. Start the server by starting it in a terminal python ~/moin-1.9.3/wikiserver.py
3. Test if it is running correctly by checking htp://localhost:8080 in a browser
4. I modified some settings of the server for example by activating the front page in ~/desktopwiki/moin-1.9.3/wikiconfig.py
5. To manage the server I created two scripts:
   • wikistart.sh
     

     #!/bin/bash
     
     if [ -e ~/desktopwiki/wiki.pid ]; then
         ~/desktopwiki/wikistop.sh
     fi
     
     ~/desktopwiki/moin-1.9.3/wikiserver.py &> /dev/null &
     echo $! > ~/desktopwiki/wiki.pid
     

   • wikistop.sh
     

     #!/bin/bash
     
     if [ ! -e ~/desktopwiki/wiki.pid ]; then
          exit 0
     fi
     
     PID=`cat ~/desktopwiki/wiki.pid`
     
     TMP=`ps -p $PID -o args= | grep wikiserver.py`
     
     if [ -n "$TMP" ]; then
          kill $PID
     fi
     
     rm ~/desktopwiki/wiki.pid
     

   I know this can be done much better and nicer, but this way it works fine. Don’t forget to make them executable!

6. Finally I added ~/desktopwiki/wikistart.sh to the programs started at gnome login via System->Preferences->Startup Applications

I did some minor changes to the Wiki configuration, but MoinMoin can be (locally!) used without nearly any changes to the configuration.

A last thing I did was to use prism to display the wiki and created a starter in the panel for this, because it looks nicer without all the browser stuff..

For a project we need a Redhat Enterprise Linux 4, so that I opted for an evaluation of the ES. For project partners, we needed NoMachine’s NX. Due to the user limitation, the open source variant freenx came to focus. First issue was a missing usermod, what I solved quite dirty. Finally, the keyboard mapping did not work. AltGr was kind of page down and key up was screenshot, others with even no effect.

Doing the google thing, it took me two hours to come to the solution mentioned here:

Open the /usr/bin/nxnode script for editing and go for some line around
cat < "$USER_FAKE_HOME/.nx/C-$sess_id/options"
In the following line, I added
${client:+client=$client,}
after
[..]${kbload:+kbload=$kbload,}${keymap:+keymap=$keymap,}
and it works fine now!

@@ -337,5 +337,5 @@
# Launch SDK
#############################################################################

-$SDK_HOME/eclipse $USER_WORKSPACE -vm $JAVA_VM -startup $SDK_HOME/startup.jar $SDK_ARGS
+GDK_NATIVE_WINDOWS=1 $SDK_HOME/eclipse $USER_WORKSPACE -vm $JAVA_VM -startup $SDK_HOME/startup.jar $SDK_ARGS


When running the Tivoli Storage Manager, the backup stores the encrypted directory structure. But instead I wanted to store the stuff “unencrypted” to enable easier restore.

To use TSM in that way, just add to your dsm.sys

VIRTUALMOUNTPOINT /home/username

My solution to use my local svn backend and use the git master branch in the normal way, is to branch the svn and work with rebasing and cherry-picks, to not confuse the world with my internal svn stuff. This is a quite simple solution, but maybe helps you to solve the same issue.

First you need to branch from your current master HEAD.

git branch svn
git checkout svn

Initialize SVN from git

Initially we want to push our current stuff to the subversion repository. This is not absolutely straight forward, but easily done as described here.

git svn init http://url/to/svn
git svn fetch
echo `git log --pretty=oneline master | tail -n1 | awk '{print $1}'` `git show-ref git-svn | awk '{print $1}'` >> .git/info/grafts

Now we can commit the current git to the subversion server

git svn dcommit

Push stuff to SVN

Pushing stuff to svn is pretty straight-forward as a series of commands, that can e.g., be put in an alias:

git stash
git checkout svn
git rebase master
git svn rebase
git svn dcommit
git checkout master
git stash apply

Get stuff from SVN

This part is kinda ugly, because we need to rewrite IDs. The best efficient way I found so far is manual, but I hope I can elaborate an automated way for it.

First get the current revision from SVN.

git checkout svn
git svn rebase

Now some comparison work is required, because you will need to get the revisions one per one and rewrite the commit messages. First check the log in the svn branch

git log

You will see the new revision. Now we will pick this one also for our git master branch, so that we first switch there:

git checkout master

and now pick the commit by the id in svn branch

git cherry-pick commit-id

Now we still need to rewrite the comment, that can be done by amending the last commit

git commit --amend

will open the editor and let you remove the git-svn-id line.

This may not be the best way to do it, but I hope it helps you with such a layout.