Postgres: createuser failing

A collegue had an issue with createuser not working as expected. ie.

postgres:~$ createuser --createdb --no-createrole -pwprompt openuser
Shall the new role be a superuser? (y/n) y
createuser: could not connect to database postgres: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.0"?

As they say.. The devil is in the details.. the cause why this was failing was due the the single dash before the pwprompt, which made the command interpret is as the '-p' option. That option expects a decimal number to specify the port number, unfortunately it doesn't complain that the string to number conversion fails, which makes it end up using 0 as the port number.

A nasty time sink bug!

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 ]--------

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.

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

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/

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

Fedora 12 policy

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