Quote:
Originally Posted by holunde  Firstly, is this installation method likely to cause major problems, when upgrading zimbra some day? |
Yes it is. The dpkg db may reflect a version that a future installer may not recognize, and attempt a clean install rather than an upgrade. I have not tested, and this is only an assumption.
At this point, you are operating on an "unsupported" system. The forums are yours, and we will help you, but we cannot tell you whether or not it will cause you problems.
Quote:
Originally Posted by holunde Secondly, it looks as if there are three files in /opt/zimbra with wrong usernames. They are created during installation.
Is this a bug? Changing ownership to zimbra manually seems to be ok.
-rw-r--r-- 1 zimbra zimbra 20 2007-06-13 23:57 .bash_history
-r--r--r-- 1 503 503 232 2007-05-04 02:45 .bash_profile
-r--r--r-- 1 503 503 1009 2007-05-04 02:45 .bashrc
-r--r--r-- 1 503 503 62 2007-05-04 02:45 .exrc |
Zimbra doesn't access any of those files, so it won't hurt anything.
Quote:
Originally Posted by holunde Thirdly, in the log, the amavis-process only loads some things, se below.
Is this important, or should something be done about it?
Jun 14 01:12:05 zimbra amavis[20018]: Amavis::Cache code loaded
Jun 14 01:12:05 zimbra amavis[20018]: SQL base code NOT loaded
Jun 14 01:12:05 zimbra amavis[20018]: SQL::Log code NOT loaded
Jun 14 01:12:05 zimbra amavis[20018]: SQL::Quarantine NOT loaded
Jun 14 01:12:05 zimbra amavis[20018]: Lookup::SQL code NOT loaded
Jun 14 01:12:05 zimbra amavis[20018]: Lookup::LDAP code loaded
Jun 14 01:12:05 zimbra amavis[20018]: AM.PDP-in proto code loaded
Jun 14 01:12:05 zimbra amavis[20018]: SMTP-in proto code loaded
Jun 14 01:12:05 zimbra amavis[20018]: Courier proto code NOT loaded
Jun 14 01:12:05 zimbra amavis[20018]: SMTP-out proto code loaded
Jun 14 01:12:05 zimbra amavis[20018]: Pipe-out proto code NOT loaded
Jun 14 01:12:05 zimbra amavis[20018]: BSMTP-out proto code NOT loaded
Jun 14 01:12:05 zimbra amavis[20018]: Local-out proto code loaded
Jun 14 01:12:05 zimbra amavis[20018]: OS_Fingerprint code NOT loaded
Jun 14 01:12:05 zimbra amavis[20018]: ANTI-VIRUS code loaded
Jun 14 01:12:05 zimbra amavis[20018]: ANTI-SPAM code loaded
Jun 14 01:12:05 zimbra amavis[20018]: ANTI-SPAM-SA code loaded
Jun 14 01:12:05 zimbra amavis[20018]: Unpackers code loaded
Jun 14 01:12:05 zimbra amavis[20018]: Found $file at /usr/bin/file
Jun 14 01:12:05 zimbra amavis[20018]: No $dspam, not using it
The last entry for dspam can be changed to load it by uncommenting line 104 in /opt/zimbra/conf/amavisd.conf.in :
#$dspam = '/opt/zimbra/dspam/bin/dspam';
Why is this commented out by default? |
DSPAM can cause delivery problems. We used it for a while until we realized that users weren't getting their messages. So, we turned it off.
See bug:
Bug 13962 - DSPAM Blocks devliery when enabled for more information. Yes, this can cause you severe problems, which is why it's off by default.
Quote:
Originally Posted by holunde Fourthly, I guess that the following server-start log-stuff is just normal, as everything seems completely stable, once the server is running. Spam-checks seem to work etc.
Jun 14 01:12:05 zimbra zimbramon[19396]: 19396:info: Starting mta
Jun 14 01:12:05 zimbra amavis[20018]: SpamControl: initializing Mail::SpamAssassin
Jun 14 01:12:05 zimbra amavis[20018]: SpamControl: init_pre_fork done
Jun 14 01:12:05 zimbra postfix/postqueue[20056]: fatal: Queue report unavailable - mail system is down
Jun 14 01:12:07 zimbra postfix/postfix-script: warning: not owned by root: /opt/zimbra/postfix-2.2.9/conf/main.cf
Jun 14 01:12:07 zimbra postfix/postfix-script: starting the Postfix mail system |
Yes, normal.
Quote:
Originally Posted by holunde Finally, I must say, that I'm really impressed with this product.
We've been running qmail with different frontends for some years. The server part is great, but it has been impossible to find a modern web-interface that is satisfactory for modern use.
The Zimbra client is a little slow to load but otherwise FANTASTIC in every aspect.
If I'm sucessful with this, well definitely consider upgrading to one of the payment versions. |
Awesome!!
Just to be clear about a couple of things:
The plan is to move to etch for 5.0 the same bug that cause redo log file permission issues affects more of the product with our move to Jetty in 5.0
Moving to etch will get us on a more recent kernel which should address this issue.
No Problem there.
We have NO plans to stop supporting debian for Open Source. Any rumors to the contrary are false, AFAIK.
We have not provided a network edition because of the owned by root bug. We will only support OSes that are enterprise-class systems. Debian is a such OS, but that bug (which STILL exists) is causing problems.
Good luck,
john