You’re checking your autodiscover URL http://exchange.contoso.com/autodiscover/autodiscover.xml but all you’re seeing it this stupid error message that tells you nothing, except:

<?xml version="1.0" encoding="utf-8" ?>  
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response>
    <Error Time="09:28:57.8739220" Id="2715916636">
      <ErrorCode>600</ErrorCode>
      <Message>Invalid Request</Message>
      <DebugData />
    </Error>
  </Response>
</Autodiscover>

If this is what’s happening to you, stop doing it :P You’ll never be able to check the autodiscover.xml from a browser. The contents of the file depend on the user agent of the client that requests it. Only Outlook (or compatible clients) will receive ANY configuration.

So, before you start deleting your virtual Autodiscover directory and re-create it it, make sure you’re using the correct client to verify your results.

Generally it behaves kind of weird with language pack updates. What’s going on and how do I fix it?

The cause of the problem is broken ZIP support in TYPO3. At least that’s what my research concluded.

To fix this, you need to set the path to the unzip utility in the TYPO3 configuration (so it doesn’t use the internal ZIP support). To do so you need to set this configuration variable:

$TYPO3_CONF_VARS['BE']['unzip_path'] = '/usr/bin/unzip';

Set it to wherever your unzip utility is located.

So what if you’re on Windows and don’t have unzip? I have no idea. Would be glad if someone told me.

Due to the simple way in which I implemented my update checking (an MD5 sum over the script itself), changes to the script interpreter line (aka shebang) would cause the script to output that a new version was available.

In addition to that, if the user did perform the update, his modification to the interpreter line would be overwritten.

So here is the revised version, that respects the first line on the script itself:

#!/bin/bash

set -o nounset
set -o errexit

SELF=$(basename $0)

# The base location from where to retrieve new versions of this script
UPDATE_BASE=http://typo3scripts.googlecode.com/svn/trunk

# Update check
function updateCheck() {
  SUM_LATEST=$(curl $UPDATE_BASE/versions 2>&1 | grep $SELF | awk '{print $2}')
  SUM_SELF=$(tail --lines=+2 "$0" | md5sum | awk '{print $1}')
  if [[ "" == $SUM_LATEST ]]; then
    echo "No update information is available for '$SELF'" >&2
    echo "Please check the project home page http://code.google.com/p/typo3scripts/." >&2
    
  elif [[ "$SUM_LATEST" != "$SUM_SELF" ]]; then
    echo "NOTE: New version available!" >&2
  fi
}

# Self-update
function runSelfUpdate() {
  echo "Performing self-update..."
  
  _tempFileName="$0.tmp"
  _payloadName="$0.payload"
  
  # Download new version
  echo -n "Downloading latest version..."
  if ! wget --quiet --output-document="$_payloadName" $UPDATE_BASE/$SELF ; then
    echo "Failed: Error while trying to wget new version!"
    echo "File requested: $UPDATE_BASE/$SELF"
    exit 1
  fi
  echo "Done."
  
  # Restore shebang
  _interpreter=$(head --lines=1 "$0")
  echo $_interpreter > "$_tempFileName"
  tail --lines=+2 "$_payloadName" >> "$_tempFileName"
  rm "$_payloadName"
  
  # Copy over modes from old version
  OCTAL_MODE=$(stat -c '%a' $SELF)
  if ! chmod $OCTAL_MODE "$_tempFileName" ; then
    echo "Failed: Error while trying to set mode on $_tempFileName."
    exit 1
  fi
  
  # Spawn update script
  cat > updateScript.sh << EOF
#!/bin/bash
# Overwrite old file with new
if mv "$_tempFileName" "$0"; then
  echo "Done."
  echo "Update complete."
  rm -- \$0
else
  echo "Failed!"
fi
EOF
  
  echo -n "Inserting update process..."
  exec /bin/bash updateScript.sh
}

If you have ever read that warning in the TYPO3 extension manager, you know exactly how annoying it can be to find that difference.

You made some minor tweak or fix and forgot about it and now you don’t know what it was and if the updated extension contains the same fix.

Or even worse. You’re already up to the new extension manager interface where there are neither upload comments nor the warning about local modification. Oh boy, oh boy.

So what can you do? Here’s what.

To do this, we need 3 scripts from the typo3scripts script suite.

1. extUpdate.sh
2. extChangelog.sh
3. extExtract.php

How to install and configure these scripts is explained on their respective wiki pages on the project homepage, so I won’t repeat that here. Let’s get right to the interesting parts.

$ ./extUpdate.sh
Sourcing script configuration from typo3scripts.conf...Done.
Checking dependencies...Succeeded.
New version of 'direct_mail' available. Installed: 2.6.10 Latest: 2.7.0
New version of 'div2007' available. Installed: 0.7.2 Latest: 0.8.1
New version of 'kb_md5fepw' available. Installed: 0.4.0 Latest: 0.4.1
New version of 'realurl' available. Installed: 1.12.0 Latest: 1.12.1

First of all, let’s see the upload comments for those extensions:

./extUpdate.sh --changelog
Sourcing script configuration from typo3scripts.conf...Done.
Checking dependencies...Succeeded.
New version of 'direct_mail' available. Installed: 2.6.10 Latest: 2.7.0
2.7.0 (2012-01-30 00:44:37)
 - layout tweaking
 - create draft newsletter and auto sending (e.g. weekly) (thanks to Benni Mack)
 - bug fixes
 please refer to changelog for further info.
 please report any bug or feature or anything in Forge (forge.typo3.org)

New version of 'div2007' available. Installed: 0.7.2 Latest: 0.8.1
0.8.0 (2012-01-23 21:19:28)
 add new classes for email and error message generation
 ready for TYPO3 4.6
0.8.1 (2012-01-28 18:10:45)
 allow the usage of a pibase object instead of class.tx_div2007_alpha_language_base

New version of 'kb_md5fepw' available. Installed: 0.4.0 Latest: 0.4.1
0.4.1 (2010-10-27 21:04:19)
 DEPRECATED: Use "saltedpasswords" and "rsaauth" extensions instead!

New version of 'realurl' available. Installed: 1.12.0 Latest: 1.12.1
1.12.1 (2012-02-17 13:23:27)
 Bug fixes. This is a recommended update to everybody.

Great! Now we even know that kb_md5fepw is deprecated. The extension manager doesn’t list deprecated extensions in the update panel as it seems. Oh well, let’s have a look at those local modifications that keep us from updating our extension.

$ ./extExtract.php direct_mail
Sourcing script configuration from typo3scripts.conf...Done.
NOTE: New version available!
Retrieving original extension file for 'direct_mail' 2.6.10...Done.
Extracting file 'direct_mail_2.6.10.t3x'...Done.
$ diff --recursive direct_mail_2.6.10.t3x-extracted/ typo3/typo3conf/ext/direct_mail
diff --recursive direct_mail_2.6.10.t3x-extracted//ext_tables.php typo3/typo3conf/ext/direct_mail/ext_tables.php
100c100
<                       )
---
>                       ),
diff --recursive direct_mail_2.6.10.t3x-extracted//mod2/class.tx_directmail_dmail.php typo3/typo3conf/ext/direct_mail/mod2/class.tx_directmail_dmail.php
421c421
<                       if (t3lib_div::testInt($createMailFrom_UID))    {
---
>                       if (t3lib_div::testInt($createMailFrom_UID) && $createMailFrom_UID > 0) {
diff --recursive direct_mail_2.6.10.t3x-extracted//mod4/class.tx_directmail_statistics.php typo3/typo3conf/ext/direct_mail/mod4/class.tx_directmail_statistics.php
439c439
<                               ' AND type=0'.
---
>                               ' AND (type=0 OR type=1)'.
diff --recursive direct_mail_2.6.10.t3x-extracted//res/scripts/class.tx_directmail_checkjumpurl.php typo3/typo3conf/ext/direct_mail/res/scripts/class.tx_directmail_checkjumpurl.php
132c132
<                                                       $jumpurl = str_replace('###SYS_TABLE_NAME###', $theTable, $jumpurl);
---
>                                                       $jumpurl = str_replace('###SYS_TABLE_NAME###', substr($theTable, 0, 1), $jumpurl);

Well, I don’t know what those changes do (actually, I totally do), but I better make sure I put them back after the update.

When I usually like to do is to echo -n a description of the current task and then later echo either “Done.” or “Failed!” (or something similar).
Obviously, that somewhat conflicts with pv. So here is the solution:

# Create backup archive
_statusMessage="Compressing installation..."
echo -n $_statusMessage
if hash pv 2>&- && hash gzip 2>&- && hash du 2>&-; then
  echo
  _folderSize=`du --summarize --bytes $BASE | cut --fields 1`
  if ! tar --create --file - $BASE | pv --progress --rate --bytes --size $_folderSize | gzip --best > $FILE; then
    echo "Failed!"
    exit 1
  fi
  # Clear pv output and position cursor after status message
  tput cuu 2 && tput cuf ${#_statusMessage} && tput ed
else
  if ! tar --create --gzip --file $FILE $BASE; then
    echo "Failed!"
    exit 1
  fi
fi

echo "Done."

The snippet also shows how to conditionally use pv if it is available, which I really like.

Upon failing to find what I wanted online, I constructed this beauty:

find . \( -exec test -w {} \; -o \( -exec echo {} \; -quit \) \) | xargs -I {} bash -c "if [ -n "{}" ]; then echo {} is not writeable\!; exit 1; fi"

This will print the name of the item that is not writeable in addition to the non-zero return value needed when used in more complex scripts.

If you don’t want/need the output, you can go with the simpler version:

find . \( -exec test -w {} \; -o \( -exec echo {} \; -quit \) \) | xargs -I {} test -z "{}"


If there is a more simple solution, please let me know.

While working on the typo3scripts project, I wanted to implement a self-updating feature into each of the scripts as that seemed most convenient for where these scripts would be used. My initial approach was OK but left me wondering.

So, here is the revised approach for a bash script that has the ability to update itself:

#!/bin/bash

set -o nounset
set -o errexit

SELF=$(basename $0)

# The base location from where to retrieve new versions of this script
UPDATE_BASE=http://typo3scripts.googlecode.com/svn/trunk

# Self-update
runSelfUpdate() {
  echo "Performing self-update..."
  
  # Download new version
  echo -n "Downloading latest version..."
  if ! wget --quiet --output-document="$0.tmp" $UPDATE_BASE/$SELF ; then
    echo "Failed: Error while trying to wget new version!"
    echo "File requested: $UPDATE_BASE/$SELF"
    exit 1
  fi
  echo "Done."
  
  # Copy over modes from old version
  OCTAL_MODE=$(stat -c '%a' $SELF)
  if ! chmod $OCTAL_MODE "$0.tmp" ; then
    echo "Failed: Error while trying to set mode on $0.tmp."
    exit 1
  fi
  
  # Spawn update script
  cat > updateScript.sh << EOF
#!/bin/bash
# Overwrite old file with new
if mv "$0.tmp" "$0"; then
  echo "Done. Update complete."
  rm \$0
else
  echo "Failed!"
fi
EOF
  
  echo -n "Inserting update process..."
  exec /bin/bash updateScript.sh
}

# Update check
SUM_LATEST=$(curl $UPDATE_BASE/versions 2>&1 | grep $SELF | awk '{print $1}')
SUM_SELF=$(md5sum $0 | awk '{print $1}')
if [[ "$SUM_LATEST" != "$SUM_SELF" ]]; then
  echo "NOTE: New version available!"
fi

It also includes the update check which wasn’t discussed over at StackOverflow. In case I revise the approach yet again, you’ll find the latest version over at the typo3scripts project page.

Cannot load certificate file error:0906D06C:
PEM routines:PEM_read_bio:no start line: error:140AD009:
SSL routines:SSL_CTX_use_certificate_file:PEM lib

All research regarding the matter pointed to a broken certificate. But even after re-exporting it and comparing the contents, we could not find any problem. I had the client repeat several parts of the certificate over the phone to my while comparing them to the one I had on the server. Everything matched exactly.

So I had the client send me the certificate and after a while I found the problem. The certificate the client had was saved as UTF8. If it was the BOM or the encoding of some characters, I have no idea. But after saving it as ANSI/ASCII the problem went away and the client was able to connect.

tl;dr: UTF8 is bad for OpenVPN certificates.

So first thing we want to do is remove the vesa framebuffer module from the modprobe blacklist.

sudo editor /etc/modprobe.d/blacklist-framebuffer

Comment out or delete the following line:

blacklist vesafb

Now to enable the needed modules:

sudo editor /etc/initramfs-tools/modules

And add the following lines at the end:

fbcon
vesafb

Finally, update your initramfs images:

sudo update-initramfs -u

Now, we need to make Grub pass the required parameters to the kernel to enable the high-res console.
In case of Ubuntu 8.04 (and 8.10 I guess) or any pre-Grub2 version:

sudo editor /boot/grub/menu.lst

For Grub2 installations:

sudo editor /etc/default/grub

There will be a line like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

You’re gonna want to add the vga parameter to that:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=791"

Or as the original article suggests (and what I prefer as well):

GRUB_CMDLINE_LINUX_DEFAULT="verbose vga=791"

But that only changes the amount of information you get during boot time.
The number that is passed as an argument with vga signals the desired resolution and color depth. 791 is 1024×768 with 64K colors. A full list can be found here.
Now, for Grub2 installations you’ll want to update Grub:

sudo update-grub2

And then, reboot!

sudo reboot now

Well, I ignored those people and did it anyway. And what did I, shortly after, get in return? A failed RAID volume. Yay.

One day I simply shut off my computer for a little restructuring of my work area, and after I turned it on again, it told me it can’t boot, cause, well, yeah. In fact, it reported that one of the RAID disks was no longer a member of the array. So I rebooted multiple times, shut off the computer and power supply, booted back up. The volume remained failed.

So I booted into an Ubuntu Live CD and browsed the web for solutions. Cause I was certain no data could have actually been lost. The RAID controller was just stupid. The solutions I found were mostly along the lines of “re-create the volume and restore a backup”. Of course I had no backup.
So I thought I would just back up the drives contents now and try to simply re-create the volume and write the data back.

Using dd, I did exactly that:

dd if=/dev/sda of=/media/backup/sda.dd bs=2MB
dd if=/dev/sdb of=/media/backup/sdb.dd bs=2MB

This took the whole night of course. So, the next day I rebooted to re-create the RAID volume. But I was very surprised to find that the RAID controller reported the volume to be in perfect health. And surely enough, seconds later my Windows was up and running again.
I praised the gods, instantly made backups and went on with my life.

Until yesterday. When the same shit happened AGAIN. I was minding my own business, when suddenly my computer shut off (due to overheating I assume). When I started it back up again, it, again, reported the RAID volume as failed.
Again, multiple reboots didn’t do anything. And, again, I went into a Live CD to back up the RAID member disks.
And, AGAIN, today my volume comes up as healthy as ever.

I have no clue if there is any logic behind this or if this was just magic happening. I also have no idea if my actions actually had anything to do with this RAID recovery. But, sure as hell, when I come across a failed ICH9R RAID0 volume again, I’ll dd the disks and reboot the shit out of it.

And, also, I’ll be converting back to a non-RAID setup ASAP.