Zimbra Debian Support

[marcmac]

NPTL is found by running:
/usr/bin/getconf GNU_LIBPTHREAD_VERSION | grep NPTL

If we find it, we're happy. If we don't, you're probably running a 2.4 kernel? That's no good.

[marcmac]

We don't check for perl.

I'm not sure why you wouldn't have it installed, tho - but I'll add a check for it.

[marcmac]

Ah, the Getopt::Std module is missing:
as root:
perl -MCPAN -e 'install Getopt::Std' will add this - or add all the perl packages.

[marcmac]

And yes, you need a 2.6 kernel. (Which you really should already be running...)

[FarrisGoldstein]

Originally Posted by marcmac

I know absolutely nothing about ubuntu.

How does it relate to debian as far as packaging goes?

Packaging is much the same, and on my box even more so than usual. I have a mixed network of debian and ubuntu boxes, and I frequently build packages for one and use them on both.

What version of dpkg does it have?

1.13.10

It sounds like either the package install isn't setting the ownership/permissions correctly (if dpkg does that - don't really remember) and the fixperms.sh script is failing.

I'm trying to narrow this down. I don't think it's because of dpkg, but I can't be sure. Where is this fixperms.sh script? Is it generated on the fly?

Is the zimbra user getting created?

Yes.

[marcmac]

/opt/zimbra/bin/zmfixperms.sh - run it as root

[FarrisGoldstein]

Originally Posted by marcmac

/opt/zimbra/bin/zmfixperms.sh - run it as root

I cleaned everything up, started a fresh install, then paused just before I was getting the errors and manually changed ownership of the files and ran zmfixperms.sh. It got further and did not complain, but the services still do not seem to start up. There must be some other pieces I'm not seeing.

My guess is that it probably has to do with some of the install packages still not setting up things to work quite in "the debian way." I tested this by trying the install on a relatively clean Debian 3.1 (sarge) box. I'm seeing the same results there. So my guess is that it isn't ubuntu's fault, but more something to do with the way I administer and configure my servers. Unfortunately, I have no way to track this down, and I'm not in a position right now to install a 100% clean 3.1 env to try on. Perhaps sometime next week I will try it in a VM.

Until then, does anyone have any thoughts on what could be causing the problems? I realize that's a tall order, what with having no conclusive errors or decent logs.

[marcmac]

The way to figure this out is to run through the post install stuff by hand (the hard way).

Track down the commands run by zmsetup.pl (all from the applyconfig function) and figure out which ones are failing.

I'd start with trying to get the ldap service up and running - does zmldapinit succeed or fail?

[FarrisGoldstein]

Originally Posted by marcmac

I'd start with trying to get the ldap service up and running - does zmldapinit succeed or fail?

It doesn't. Indeed, this showed me that there's probably quite a bit in the install not succeeding:

root@bauer:/opt/zimbra/libexec# ./zmldapinit
./zmldapinit: line 56: /opt/zimbra/openldap/sbin/slappasswd: No such file or directory
./zmldapinit: line 57: /opt/zimbra/openldap/sbin/slappasswd: No such file or directory
sed: can't read /opt/zimbra/openldap/etc/openldap/slapd.conf: No such file or directory
sed: can't read /opt/zimbra/openldap/etc/openldap/zimbra.ldif: No such file or directory
sudo: /opt/zimbra/openldap/libexec/slapd: command not found
ERROR - failed to start slapd

[marcmac]

that's pretty bad - the package installations are failing, somewhere.

I imagine that zimbra-core won't install because it's looking for missing prereqs, and everything else is failing because zimbra-core isn't installed.