CentOS release 5.3 (Final)
1.5 GB RAM
zcs-5.0.16_GA_2921.RHEL5.20090429052155
./install.sh --platform-override
Up and running.
Great job, Zimbra!
Printable View
CentOS release 5.3 (Final)
1.5 GB RAM
zcs-5.0.16_GA_2921.RHEL5.20090429052155
./install.sh --platform-override
Up and running.
Great job, Zimbra!
./install.sh --platform-override
Works also for me.
Thanks, Zimbra!
Hi Tripple,
Please elaborate a little more:
- Single server installation?
- how many users do you have?
- what version are you using?
We have 1500 users, a big server (HP DL380 G5) 4 GB Ram 2 Xeon Quad, 8 raid 5 (via LSI controller) 147 disks and JAVA is killing the server. Authentication is done Externally via AD. We are using the Open Source edition.
We are not even using the web interface, we have a separate Horde/Imp server accesing the Zimbra box via IMAP.
Any ideas?
Thanks,
Ed
I'm just having a very small office. Nothing like yours. About 20 mailboxes.
4 domains on the server and 2 domains on another server forwarding mails to my Zimbra Open Source Edition.
The server is a Dell PowerEdge 1950 and users are reading mail with their favorite mailclient (OSX Mail.app) or with the Web Interface. The biggest mailbox is about 4GB.
In addition to the comment about RAM in the post above, you really should not be using RAID5 it will kill your performance and you should be using RAID10. You should have a read of this article: Performance Tuning Guidelines for Large Deployments - Zimbra :: Wiki
Thanks guys for your replies, we are moving people away from the horde/imp web client in favor of the Zimbra web client. Load is decreasing, server is getting better over time.
If I add extra memory for a total of 8GB, I will have to use Ubuntu 64bit edition and the 64bit edition of zimbra, (right?), and correct me if I am wrong, but I will not be able to do a drag and drop (copy) of the /opt/zimbra directory. Or I will be able to do it and later run an upgrade form 32 bit to 64?
Since we use the OS Edition, I do not think we have HSM and backup on that version...
Thanks again,
Ed