As said in a recent comment, I use logwatch to look at the logs on my server. Every night logwatch send me a mail with a report of what has happen.

One thing lacking was logs analysis for ikiwiki: ikiwiki don't produce log per-se. Access are logged and reported because they are done by the http server, but modification are only seen in the git repository, and comment waiting moderation are only in the ikiwiki directory.

So I needed a way for logwatch to report specific ikiwiki activity.

• First we need to have a file logging activity in the ikiwiki's git repository. So in cron.daily, before logwatch is run, I put:

  git --git-dir $IKIWIKI_MAIN_DIR/.git log --after="6 month ago" --format="%cd (%h) %an: %s" --date=iso > /var/log/ikiwiki.log
  

  of course a better way to do it would be to create a git hook that generate the logs when modification are done, and not once everyday just before the logs are generated.

• Then we need to tell logwatch to look at this file, so in /etc/logwatch/conf/logfiles/ikiwiki.conf I put

  ########################################################
  # Define log file group for ikiwiki
  ########################################################
  
  
  # What actual file? Defaults to LogPath if not absolute path....
  
  
  LogFile = ikiwiki.log
  
  
  *ApplyEuroDate
  

  The ApplyEuroDate make ikiwiki read the date in iso format, so it will only report commit done today. I've found no way to tell logwatch to look at the output of a program instead of looking at a file.

• We then must tell logwatch that it must generate the report for a new service, so in /etc/logwatch/conf/services/ikiwiki.conf

  ########################################################
  # Configuration file for ikiwiki filter
  ########################################################
  
  
  Title = "Ikiwiki"
  
  
  # Which logfile group...
  
  
  LogFile = ikiwiki
  

• Finally, we have to taught to generate the report, in /etc/logwatch/scripts/services/ikiwiki

  #!/bin/bash
  
  
  # First look at pending comment
  
  
  find $IKIWIKI_MAIN_DIR/ -name "*_pending" -exec echo "Pending comment:" \; -quit
  ( 
      cd $IKIWIKI_MAIN_DIR/
      find . -name "*_pending" -exec echo "    {}" \;
  )
  
  
  # we then look at new commit
  
  
  fst=true
  while read d t tz j; do
      if [ $fst == true ]; then
          echo "New commit:"
          fst=false
      fi
      echo -n "  "
      echo $j
  done
  

Every day I receive email from my server resuming what have been logged for the day. From time to time (but really rarely) there is no attempt at break in on my web server. The eternal question is :

• Is it that this day, no vile cracker, no young script kiddie, no spammer have found my blog server
• Is it that one of them succeed, and afterward clean any trace of breaking attempt.

Thanks to Bruce Schneier security blog, I come across an interesting article about liability and software. The problem is well known

• if you impose liability on any software producer, then it's a dead sentence for free software
• but the current situation enable software dealer to sell faulty software with I can't audit, with liability for them if their software fail on a large scale.

Of course for better security, the solution could be to not use proprietary software, still a law as proposed on ACM could be useful to protect madam Michu.

Debugging reportbug.

I've been hit by #610348 for some time now. I didn't comment on the bug report because I failed to find useful information to add there.

I've tried several things:

• using strace, one can find that reportbug freeze waiting for a returning futex.
• using ltrace, the freeze happen while calling sem_wait. It also happen sooner: the gui is not opened yet.
• using gdb I can sees that the sem_wait call have been made from PyThread_acquire_lock, but this seem only logical.

All this together give me no useful information. Further testing show that:

• the freeze don't always happen at the same time, and using python2.5 seem to make it happen latter.
• Trying to run it in another environment (say gnome) or with another user do not solve this for me.
• The problem don't exist in a brand new chroot, prooving it's a configuration problem. But which one?
• using meld I've tried to find significant difference between the two /etc, but found nothing that explain the problem.

I have no idea on what to do next to find where is the problem...

For some time, I was looking for a way to change grub default entry for only one boot. I want to tell it that next time it should boot the entry 0, and the time after that, use the usual default (the entry 1).

Founding documention for this is not as easy at it should, and the information on the debian wiki wasn't clear enough for me to understand.

So I edit the wiki page to make clear that grub-reboot also available for those using grub2, and that it will only configure the boot, but not reboot the computer itself. As each time I wrote some text in English, I'm not sure my version correctly transmit my meaning.

By the way, I'm changing my blog. The old one contain a post on my search of a solution for this. Thanks to stbuehler and Jochen for the indication leading to the correct solution for this.

Thanks also to Vadim Solomin for a patch to make pm-hibernate notice the configured method for shutting-down the computer.