What has zimbra done to the whole system?

[Zig]

After installation of Zimbra, it says that zimbra has done modifications to the whole system. I think it might mean changing some files outside of /opt/zimbra. Then what actually was done?

[phoenix]

After installation of Zimbra, it says that zimbra has done modifications to the whole system. I think it might mean changing some files outside of /opt/zimbra. Then what actually was done?

What, exactly, are you talking about? As far as I know it doesn't say it's made "modifications to the whole system".

A little bit more of an explanation about where you're seeing this message might help.

[Zig]

Well, I might make a mistake. But I cannot find the exact string for I do not want to install it again.

Then let me describe what I am concerning -- will Zimbra modify files outside of the /opt/zimbra directory? For example when I installed zimbra in CentOS 5, the "sudo" will not work because of a version conflict in openssl. I just wonder will Zimbra's installer make some other changes in the system I did not track? I think this is important for a production server. Are there any documents about this?

[phoenix]

Well, I might make a mistake. But I cannot find the exact string for I do not want to install it again.

Then let me describe what I am concerning -- will Zimbra modify files outside of the /opt/zimbra directory? For example when I installed zimbra in CentOS 5, the "sudo" will not work because of a version conflict in openssl. I just wonder will Zimbra's installer make some other changes in the system I did not track? I think this is important for a production server. Are there any documents about this?

Zimbra will run fine on CentOS5, I'm using it on that. You just need to make a minor change to the sudoers file.

You can rest assured that Zimbra is not making any changes to your system that would have a negative impact on it. There are some extremely large organisations around the world using Zimbra, I don't think they'd be too happy if we modified their operating systems.

You need to read the documentation and make sure that you have any required files/libraries installed, ther are a few minor additions like startup scripts, cron jobs and that's about it - everything else we require goes in the /opt/zimbra directory.

[Zig]

Yes, I agree to you that Zimbra will not make negative changes. But anyway, I would like to know if there are other changes in the system for I am a system administrator. Not every service on my server are tested against Zimbra, I do not know if they will co-exist normally with Zimbra.

Maybe I should change the question to "Are there any documents like Zimbra Hack or Zimbra Inside", since I want to make some configuration changes to Zimbra to fit our need.

[phoenix]

Maybe I should change the question to "Are there any documents like Zimbra Hack or Zimbra Inside", since I want to make some configuration changes to Zimbra to fit our need.

If you're using a supported operating system then you can be sure that Zimbra will run with the installed default services. Zimbra is supposed to be installed on a dedicated server, if you want to run it with any other services then it's you're responsibility to test it. If you want to see what it runs with then read the documentation, search the forums or the wiki and post any specific questions you may have in the appropriate forums.

[dijichi2]

Zig, in answer to the question you asked 3 times, there are a few files that are modified outside of /opt/zimbra. Here are a couple I can think of off the top of my head - there may be others:

/etc/passwd, /etc/group, /etc/shadow, /etc/gshadow - zimbra adds zimbra and postfix users, and zimbra, postfix and postdrop groups. (i think, may not be full list)

/etc/sudoers - zimbra adds several entries for sudo

/var/spool/cron/crontabs/zimbra - zimbra adds its own crontab

/etc/ld.so.conf - zimbra adds entries so the system picks up its libs. this can and has caused problems with programs external to zimbra

/etc/syslog.conf - zimbra modifies syslog. this can and has caused problems with programs/log analysis tools external to zimbra.

[Zig]

Yep, that is exactly what I asked for.
The modification of ld.so.conf is what I am concerning most.
Do you know any means of keeping Zimbra using his libraries while the other applications using the original version of libraries? For a single application, I can make a wrapper, but for the whole Zimbra, I do not have good ideas.

[dijichi2]

Unfortunately not for zimbra, there are far too many dynamically linked binaries and libraries to take care of, so you have to 'wrap' all the other apps on the server that conflict. There aren't too many - generally the only libs that tend to get in the way are SASL, LDAP and MySQL. They can cause issues with other apps that are linked in with competing system libs, such as Apache etc. If you do get any issues, I tend to prefix the binary call in the init script with LD_LIBRARY_PATH. This is a pain in the ass but usually easier to do than mess with ld.so.conf.

Ideally, as zimbra largely self-contains itself in /opt/zimbra, it should either statically link or compile with runtime path hinting and not touch ld.so.conf. I seem to remember adding a comment to a bug report concerning this recently. Certainly on the upcoming unofficial Solaris port all the dynamic linking is hinted and no manipulation of the system dynamic loader is necessary.