Thursday, December 3, 2009

Zimbra public folders

When migrating from that other closed source groupware product to Zimbra, you will probably have to setup the system with a Public Folders view, resembling the other product. While it is possible to do in Zimbra, it's a bit cumbersome. The way I did it, is to create a 'user' per public folder, then share it's Inbox with the users that need access (using a mailinglist as share destination is also possible).

The procedure is can be done from the command line:

First create a Folder per user to store the public folders in:

$ zmmailbox -z -m user@domain.be cf --view message /PublicFolders


Then for every public folder account, share it's inbox with that user:

$ zmmailbox -z -m pubfolder@domain.be mfg /Inbox account user@domain.be rwidx


Then mount the share for the user:

$ zmmailbox -z -m user@domain.be cm --view message /PublicFolders/Pubfolder pubfolder@domain.be /Inbox



You can ofcourse script it, with something like this... (will output a script you feed to 'zmmailbox -z')

-------------[ python code ]--------
allusers = ['user1@domain.be', 'user2@domain.be', 'user3@domain.be']
pubfolders = ['folder1@domain.be', 'folder2@domain.be']

def createPublicFolderMap(users):
'''
create a folder to act as a parent for all the public folder submaps
'''

for user in users:
print "selectMailbox " + user
print "createFolder --view message /PublicFolders"

def createAndSharePubFolder(folder, users):
'''
creates the share on the public folder's inbox to the users
and creates a share mountpoint in the users for that inbox
'''
folderName = folder[:folder.find('@')]
folderName = folderName[0].upper()+folderName[1:]

print "selectMailbox " + folder
for user in users:
print "modifyFolderGrant /Inbox account "+user+" rwidx"

for user in users:
print "selectMailbox " + user
print "createMountPoint --view message /PublicFolders/" \
+folderName+" "+folder+" /Inbox"


createPublicFolderMap(allusers)
for pubfolder in pubfolders:
createAndSharePubFolder(pubfolder, allusers)
-------------[ python code ]--------

Wednesday, December 2, 2009

Zimbra ZCS6.0.2 server statistics failing

Ran into a problem where the Server Statistics in the Monitoring tab of the admin view were giving an error. The view uses the information written to /var/log/zimbra-stats.log however that file wasn't rotating correctly at night causing the statistics view to fail.

There were 2 issues at work here. For one, the logrotate scripts were using the killall command, which wasn't present on the system (a Debian 5.0.3 with just the Standard tasksel). Reported as Bug 43079. The other issue was that the killall parameters used syslogd, whereas debian lenny uses rsyslogd, which killall won't rightfully touch, reported as Bug 43081.

Monday, November 30, 2009

Totem hangs on AVI playback

After the upgrade to Fedora12 for some files totem hangs at startup. This is a bug in the gstreamer framework related to subtitles. It happens when you have the 'Automatically load subtitle files when movie is loaded' selected and there is an SRT file in the directory of your movie.
Quick workaround is to disable the option and load the subtitle manually.

The fix is already included in the next gstreamer update for fedora (0.10.25.1-2), but if you can't wait you can download the packages gstream, gstream-tools and the gstreamer-plugins-base from the koji build server.

Ubuntu's Karmic Koala has the same issue, the launchpad entry is at https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/441396

Thursday, November 26, 2009

The incredible shrinking harddisk

A harddisk in my home server was giving S.M.A.R.T. warnings of imminent doom, so I ordered a new harddisk, a Seagate ST31000528AS Barracuda 1TB.

I had read about some issues with bad firmware in their prior models (7200.11), but figured that was a one off that could happen to any vendor.

Received the harddisk a few days ago, plugged it in, booted an iso with GParted and proceeded to copy the partitions of the old disk to the new disk.. everything was going smoothly.

... until ...

After the copy, disconnected the old disk and plugged the new one in the first SATA port. That's when the troubles started. The disk wouldn't boot, which after thinking about it, was to be expected as I forgot to put a bootloader on it, doh! So back to GParted, but when the kernel started spewing errors, something about sectors being out of range. That's when I noticed that the disk was now detected as a 33Mb, instead of the somewhat larger 1TB it should be.

Rebooting didn't help, changing the SATA port, booting a different kernel, nothing helped.

Now here's what happened... for some reason, the team that made the BIOS of the motherboard, figured it would be a good idea to reserve some space on the harddisk to dump their crap on.. but apparently math skills are optional when applying for that position and hence they messed up the code that reserves the area (probably thought we wouldn't be using 1Tb disks any time soon). So instead of setting aside a modest sized area, the code almost grabbed the entire disk.

The reservation is done by setting the Host Protected Area of the disk.

Luckily with a recent hdparm (like the one you can find on a live CD of Fedora12 or Ubuntu 9.10), you can view/set the HPA boundary. After correcting it, my disk was back to normal... I'm still not sure why the BIOS isn't 'fixing' the disk again after a restart.. so I'm a bit worried that I'll loose data if one of the days the BIOS decides to screw me over again. Probably best to look for a BIOS update before trusting my data on the disk.


For those that are wondering.. the motherboard is a Gigabyte 965P-S3 (and finding the correct BIOS file would be so much easier if Gigabyte didn't make more than 1 revision of the motherboard or if they would at least mention how you can discover the difference between rev 1 and rev 3.3). Anyway, if you don't remember which motherboard you have, you can use the dmidecode utility or lshw if you have it installed. (or if your kernel is recent enough, you can look in /sys/devices/virtual/dmi/id)

More details and what other issues that can cause your disk to shrink are explained in this nice blog post: http://blog.atola.com/restoring-factory-hard-drive-capacity/

Tuesday, November 24, 2009

Fedora 12 PreUpgrade

The issue I had with insufficient diskspace in /boot while using preupgrade is now caught by preupgrade, for more information see preupgrade update info at https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11536 and the fedora wiki at http://fedoraproject.org/wiki/PreUpgrade

Friday, November 20, 2009

Fedora 12 policy

Glad to see this will be reverted. Common sense does prevail!

Friday, November 13, 2009

HOWTO: Flooding wireless networks...

Recipe:

1 wireless network
1 part Fedora 12
1 part Pulseaudio gravy
1 foolish setting:


What do you get?! A nice flood towards your wireless network with empty 16-bit audio packets even when no application whatsoever is playing audio.

One thing I don't remember... if I ever activated that setting while playing with my VirtualGL / remote wine gaming setup.. or if it was an effect from the Fedora upgrade... either way, best to double check your own setting after upgrading, as the effect is a pretty dead wireless network at seemingly random times.

Thursday, November 12, 2009

Karmic Koala

Before upgrading ubuntu 9.04 with the br0ken network to 9.10, I grabbed and compiled the mainline 2.6.32-rc6 kernel to make sure I had at least a working kernel to fix issues if the Karmic kernel was broken too.
Since the mainline kernel worked fine, I continued to upgrade to Karmic Koala, which uses a 2.6.31 kernel. I was happy to find out that the ubuntu 9.10 kernel didn't have any issues with my VLAN setup.
I still wonder if the issue was caused by an ubuntu specific patch or if the mainline kernel had issues. Maybe I'll git bisect it to feed my curiosity.

Tuesday, November 10, 2009

Murphy...

Since I was already busy with upgrading my laptop, I figured I might aswell upgrade my home server which was running ubuntu 8.04. However after upgrading to 8.10 my network didn't work anymore. When booting an older kernel it worked fine. Figured it was an issue in the kernel, Ubuntu 8.10 was using and since the target was to get to 9.10, I thought I might aswell continue. So upgraded the 8.10 to 9.04, however the network issue remained. With 2.6.28 on 9.04, I was unable to ping my WRT54G which runs OpenWRT. With 2.6.24 on 9.04 it works 'fine'. My home setup uses a couple of VLANs and it seems that that was causing the problems, without the VLANs the new kernel was able to ping the router.

As it was already getting late, I booted the machine with 2.6.24 and decided to call it a day.

Today, when I tried to initiate an OpenVPN connection to my home server from a remote location, the connection failed. Even a secure shell to the server didn't work. Going via the OpenWRT's shell to the server did work for some bizarre reason.

After some tracing with tcpdump and wireshark, it showed that the port number of the connection was somehow changing... ie. make a connection to port 1000 and it arrived on the server at port 1040 according to the packet trace.

First thought it had to do with the VLAN tagging and that for some reason the ubuntu kernel was interpreting the packets wrong, as I already had issues with the VLAN... but when I did the packet trace on the OpenWRT on the incoming interface, it was correct.. on the outgoing interface however it was wrong... which showed the cause was not with the ubuntu server but with the OpenWRT device. After rebooting it, the connections worked fine again.

Goes to show that when stuff goes bad, it really goes bad.. as in 2 different things going banana's at the exact same time!


Anyway the OpenWRT issue seems to be a bug in the 7.07 Kamikaze release, which is fixed in 8.09

Kamikaze 8.09 Release notes states:

* fix port forwarding NAT issues in brcm-2.4


So it looks like I'll have to update yet another device.

Monday, November 9, 2009

F12 systray / panel spacing

After the upgrade, the spacing between the icons in the systray area was way too large. Apparently it's a 'feature'. *sigh*

Fix with:

$ gconftool-2 --type int --set /apps/panel/applets/systray/prefs/padding 0

Preupgrade to Fedora 12

Used preupgrade to upgrade my Fedora 11 to rawhide / Fedora 12. The upgrade went smoothly except for 1 issue. Apparently my /boot partition was too small (190Mb with 142Mb still free), so after preupgrade downloaded all the packages and reboot into anaconda, I was presented with a nice out of diskspace error. ouch.
I tried to remove some left over old kernels from the boot partition but it wasn't enough. Luckily I always have an external USB drive with me, so I copied the preupgrade image to that drive, tweaked grub to load it from there and that did the trick.

Friday, July 24, 2009

Use the power!

Picked up a pair of Devolo DLAN AV200 HomePlug adapters, since my wireless connection to my desktop which had an USB USRobotics wifi adapter was flakey at best.. and it's not because there's many wireless networks in my neighbourhood (only 3 and my laptop's Intel PRO/Wireless 3945 works fine).

The box mentioned linux compatibility, but I wasn't expecting to find source code to the configuration program for linux.. afterall these things can be run without any computer intervention, so I figured that's why they listed linux.

The copyright notice on the source files is a bit odd though:


/*
dlanconfig.c: dlanconfig software for HomePlug devices for linux

Copyrighted 2007 by devolo AG

Redistribution in source form, with or without modification,
are NOT permitted.
This program uses explicitly confidential information
about HomePlug standard.
*/


Anyway... first impression is positive... the speed is nice, stability also.. the 200mbps claim is a bit misleading since they just have a 100mbit ethernet port, but all of the homeplug devices use that marketing ploy.

Wednesday, July 22, 2009

Wine fun #4

As I mentioned before, I was fooling around with running a game via wine on a remote server. After fixing wine to run the game, it was time to look for improvements in the remote connection.

While it worked via vino / VNC, it wasn't really playable.

VirtualGL and TurboVNC seemed like they could provide a satisfactory experience. My first attempt using TurboVNC as the X11 target for VirtualGL didn't work. It always resulted in a busy loop inside the nvidia closed source OpenGL library.

VirtualGL using the VGL Transport to my fedora 11 laptop, does work however! It's actually quite playable over a Wifi connection. The nice thing about this setup, is that the server is doing all the hard work, hence you could even use an under powered netbook as a game station.

I wonder if there would be much to gain by implementing a more advanced video compression engine in virtualgl. Maybe if I find the time, I might try to hook it up with libavcodec or something along those lines.

Saturday, July 11, 2009

Wine fun #3

The icing on the cake has finally arrived!

After reversing large parts of the game code and spending a silly amount of time in a debugger, I was finally able to track down the code path that caused the game to crash on wine.
Once that was clear, it was just a matter of comparing the difference in return values when running the game directly on a windows box.

Since I just hacked up the wine source to return the value I needed, it isn't a proper fix.. but I'm hoping the wine devs can come up with a solution that is acceptable for everyone.

The bug details can be found in Bug 10832

Monday, June 15, 2009

Wine fun #2

Forgot to mention that the quick fix to solve the issue I was having, was to change the device mapping so that it doesn't have one pointing to the root of the filesystem anymore. On default wine makes a mapping for drive Z to the root of the filesystem, hence why it was able to find and open /dev/random. So the easy fix was to change the Z drive mapping in ~/.wine/dosdevices

Now I just have to find out why the game bombs out when pixel shaders are enabled...

Saturday, June 13, 2009

Wine fun

Don't ask me how I came to this situation, but I was trying to run a windows game on my home server over a VNC connection. Not exactly an ideal and speedy setup, but cool to see it's possible.

However, for some reason I could start the game with wine when I was at the console of the machine, but whenever I tried to start it over a VNC connection, it got stuck in the connection phase. It first looked like a network issue, but a wireshark trace didn't show anything. It was also hard to explain why it would work locally but not remote, first thought it was due to the network load of the VNC session or some timing issue. So it was time to have a closer look at it.

First up, strace of the process showed it was very slowly reading small amounts of bytes from a certain FD. A look into /proc/<pid>/fd/<num> showed it was trying to read from /dev/random. Now we're getting somewhere.

Interesting thing about /dev/random is that it needs a source for entropy. The available entropy can be viewed from /proc/sys/kernel/random/entropy_avail. Wrote a tiny bash script to continuously display that file, which clearly showed that once the connection stage of the game was reached, the pool drained at exactly the same time as the game froze.. and then whenever the pool refilled, it was quickly drained again. So the problem was, due to working remote on the machine, too little events were generated that contributed to the pool, which blocked the process reading from the random device.

Starting some heavy disk activity, showed that this was indeed the issue, because as soon as I did that, the game continued.

Next step was finding out why wine used /dev/random instead of /dev/urandom. However, a quick grep through the source didn't show any location where this would crop up in my situation. Weird.

Next idea was trying to see what the game was trying to open exactly. Luckily wine has some pretty nice debug infrastructure, so after playing with WINEDEBUG a bit. I found that the game was issuing a CreateFileA() with "/dev/random" as file name, which doesn't work on windows of course. A double check in the game executable shows that it does indeed just that:


.text:0042C150 sub_42C150 proc near
.text:0042C150
.text:0042C150 arg_0 = dword ptr 8
.text:0042C150 arg_4 = dword ptr 0Ch
.text:0042C150
.text:0042C150 push esi
.text:0042C151 push offset aRb ; "rb"
.text:0042C156 push offset aDevRandom ; "/dev/random"
.text:0042C15B call _fopen
.text:0042C160 mov esi, eax
.text:0042C162 add esp, 8
.text:0042C165 test esi, esi
.text:0042C167 jz short loc_42C185
.text:0042C169 push 0 ; size_t
.text:0042C16B push 4 ; int
.text:0042C16D push 0 ; char *
.text:0042C16F push esi ; FILE *
.text:0042C170 call _setvbuf
.text:0042C175 add esp, 10h
.text:0042C178 test eax, eax
.text:0042C17A jz short loc_42C189
.text:0042C17C push esi ; FILE *
.text:0042C17D call _fclose
.text:0042C182 add esp, 4
.text:0042C185
.text:0042C185 loc_42C185:
.text:0042C185 xor eax, eax
.text:0042C187 pop esi
.text:0042C188 retn
.text:0042C189 ; ---------------------------------------------------------------------------
.text:0042C189
.text:0042C189 loc_42C189:
.text:0042C189 mov eax, [esp+arg_4]
.text:0042C18D mov ecx, [esp+arg_0]
.text:0042C191 push edi
.text:0042C192 push esi ; int
.text:0042C193 push eax ; int
.text:0042C194 push 1 ; int
.text:0042C196 push ecx ; void *
.text:0042C197 call sub_436C04
.text:0042C19C push esi ; FILE *
.text:0042C19D mov edi, eax
.text:0042C19F call _fclose
.text:0042C1A4 add esp, 14h
.text:0042C1A7 mov eax, edi
.text:0042C1A9 pop edi
.text:0042C1AA pop esi
.text:0042C1AB retn
.text:0042C1AB sub_42C150 endp



It's still not clear why this is done in the game, might be a check for linux (although the game is only available on windows) or maybe it's some old left over code that they forgot to remove. Who knows.

Anyway seems that the fact that wine supports unix file names transparently has caused issues in other places too

Thursday, April 23, 2009

FUD Factory in Full Force

Looks like microsoft aficionados are at it again: Intel CPU cache poisoning: dangerously easy on Linux

While it's true it's fairly easy to manipulate the MTRR registers on Linux. You still need to write the actual SMM code to execute and I'm sure anyone able to do that, will be able to download an example windows device driver and add some MTRR manipulation instructions to it. Either way, both Linux and Windows are vulnerable to this.. since it's not an OS issue.

As for the comments on that post.. if the virtualization layer you're using allows a virtual machine to manipulate the MTRR registers, you have bigger things to worry about!

It's a pity sites like Heise online already picked up on this.

Tuesday, March 17, 2009

Speeding up SSH connections

If you make alot of connections to the same host, it's worth setting up connection sharing in OpenSSH. You can enable this by adding the following to you $HOME/.ssh/config file:


Host *
ControlMaster auto
ControlPath ~/.ssh/%r@%h:%p


Do keep in mind that the 'master' will linger on until all slave connections are gone.

Thursday, March 5, 2009

Boot failure

After the lastest kernel update on fedora, my box refused to boot since it was unable to mount the root filesystem. The old kernel still booted fine. My first thought was an issue with the initrd, so I first rebuild it to see if that resolved it. No change.
Therefor it was time to take a closer look.. after unpacking the initrd, I noticed the mkrootdev line was different.. and that's when I recalled that I had updated my /etc/fstab root entry and had added 'relatime' to the mount flags.
Apparently mkrootdev was failing on that flag. I'd figure it would be a simple thing to fix, so I checked out the repository and noticed it was fixed in version 6.0.76-1 (fedora 10 uses 6.0.71):



commit e993db4b1790d0328fcd76c0fd88ca2a82a931d5
Author: Jayson King
Date: Wed Feb 4 21:11:54 2009 +0100

Make nash mount support relatime (#296361)

Make nash mount support relatime (#296361).

Tuesday, March 3, 2009

Ubuntu: saslauthd internal error in k5support_verify_tgt

When trying to get LDAP simple bind to work against Kerberos5 with saslauthd, I kept running into the following error:


saslauthd[29808]: auth_krb5: k5support_verify_tgt
saslauthd[29808]: do_auth : auth failure: [user=kvo] [service=ldap] [realm=LOCALREALM] [mech=kerberos5] [reason=saslauthd internal error]


a search for the error only mentioned adding the host principle to the keytab file, which I had done, but I was still getting the error.

It seems saslauthd on ubuntu requires that KRB5_KTNAME is set... even though /etc/krb5.keytab is the default, it still needs the environment variable to be present. (explicitly setting the default keytab in /etc/krb5.conf didnt help either).

So the solution to the problem is to add:


export KRB5_KTNAME=/etc/krb5.conf


to the /etc/default/saslauthd file.

Monday, February 9, 2009

PulseAudio logspam

Does this look familiar to you?


Feb 9 09:49:50 laptop-i pulseaudio[3227]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers.


Then this might help: Bug 471941. It doesn't fix the root of the problem, but at least it gets rid of the logspam.

Wednesday, January 28, 2009

Mozilla Weave v0.2.99 for F10 x86_64

Version 0.2.99 compiled on F10 for x86_64 can be found here.

Sound issue on FC10

Today's fedora kernel update, kernel-2.6.27.12-170.2.5.fc10.x86_64, resolves the issues with the headphone output. There's no need for the hda-verb command anymore (at least on my Dell D830).

Thursday, January 15, 2009

Mozilla Weave on F10 x86_64

After installing my 64 bit fedora, I found out that the default weave download doesn't work on 64 bit as it needs a native 64 bit library to do the crypto stuff which isnt included in the distributed plugin.
Solution is to grab the weave source and compile it yourself, which has some pitfalls on fedora if you try to use the xulrunner rpm, due to difference in paths.

Therefor to help people looking for it, you can download a 64 bit compiled F10 weave 0.2.98 from here.

Note of warning: my laptop didn't import the bookmarks correctly, not sure if it's a weave issue or something else. So tred carefully.

Fedora F10 x86_64 on Dell latitude D830 sound woes

There's some weird stuff going on with the sound on my dell latitude D830 laptop. I recently got that laptop and put fedora F10 (64 bit version) on it, so I'm not sure if it's a fedora issue or a more general one, as I haven't used any other distro on this machine.

The biggest problem is that there are a few issues causing audio to fail.

Here's what you can try to do to resolve it:

  1. run 'paman' (the PulseAudio Manager)
    if you can't connect, then pulse isnt running for some reason.. issue start-pulseaudio-x11 from your user account to restart it.

  2. in paman, check if Devices->Sinks actually shows a hardware device and NOT the Null Output device. If you have the Null Output, it means pulse was unable to open your hardware device, this happens when something had the alsa device open when starting pulse (e.g. I had this due to a KVM virtual machine that had a sound device attached to it).

    To debug, from a shell start pulse in commandline mode:
    $ pulseaudio -nC -vvv


    then issue:
    >>> load-module module-hal-detect


    and watch the debug output, it might say it can't open /dev/snd/pcmXXXX
    to check what is keeping that device open, issue:

    # fuser -v /dev/snd* /dev/dsp*


    kill the apps, then restart pulse from your user shell (start-pulseaudio-x11) and recheck in paman if the Sink is now showing the alsa device.

  3. if all this is ok and the pulseaudio volume program even shows sound playing, but you still get no sound, then most likely alsa didn't setup the sound codec correctly.. this was the case on my D830 which has a SigmaTel STAC9205 (you can find this info in /proc/asound/card0/codec#0)

  4. first try adding an option to modprobe, e.g.

    $ cat /etc/modprobe.d/dell
    options snd-hda-intel model=dell-m42


    and restart your machine, make sure the above issues don't popup again. If you have a different codec, you might check the alsa doc for something that fits your machine.

  5. If that didn't help.. grab hda-verb then look for the speaker node in /proc/asound/card0/codec#0

    e.g. on my laptop:

    Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
    Pincap 0x0000003f: IN OUT HP Detect Trigger ImpSense
    Pin Default 0x90170310: [Fixed] Speaker at Int N/A
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
    Pin-ctls: 0x40: OUT
    Unsolicited: tag=00, enabled=0
    Connection: 1
    0x10


    If the Pin-Ctls doesnt have OUT, then you will get no output. You can fix this with the hda-verb command:

    # hda-verb /dev/snd/hwC0D0 0x0d SET_PIN_WIDGET_CONTROL 0x40


    This should enable the sound output on your speakers.

  6. Last issue, speakers might work but as soon as you plug in a headphone, your sound goes away. (ie. sound doesnt work from the headphone).
    Look in the codec file for a headphone node:


    Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
    Pincap 0x0000173f: IN OUT HP Detect Trigger ImpSense
    Vref caps: HIZ 50 GRD 80
    Pin Default 0x0321101f: [Jack] HP Out at Ext Left
    Conn = 1/8, Color = Black
    DefAssociation = 0x1, Sequence = 0xf
    Pin-ctls: 0x00: VREF_HIZ
    Unsolicited: tag=3a, enabled=1
    Connection: 2
    0x10* 0x11


    Then enable the OUT with the same hda-verb as shown above, but update the node id:

    # hda-verb /dev/snd/hwC0D0 0x0a SET_PIN_WIDGET_CONTROL 0x40

Hopefully you will have sound by now.