Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
slapos
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Jean-Paul Smets
slapos
Commits
a5f1a9eb
Commit
a5f1a9eb
authored
Jul 03, 2013
by
Marco Mariani
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
zimbra: more README.txt
parent
56ece8fc
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
61 additions
and
2 deletions
+61
-2
software/zimbra/README.txt
software/zimbra/README.txt
+61
-2
No files found.
software/zimbra/README.txt
View file @
a5f1a9eb
...
@@ -56,7 +56,7 @@ Our fork contains unofficial bug fixes in both 'vanillabuild' and 'authbind' bra
...
@@ -56,7 +56,7 @@ Our fork contains unofficial bug fixes in both 'vanillabuild' and 'authbind' bra
This is basically a fixed version of the upstream build.
This is basically a fixed version of the upstream build.
The 'vanillabuild' branch is able to build on one of the supported platforms (tested mainly with Ubutnu 12.04)
The 'vanillabuild' branch is able to build on one of the supported platforms (tested mainly with Ubutnu 12.04)
in the default zimbra location - /opt/zimbra which should also be the $HOME of the user 'zimbra'.
in the default zimbra location - /opt/zimbra which should also be the $HOME of the user 'zimbra'.
The build process creates
*
.deb files that need to be installed and configured as root.
The build process creates .deb files that need to be installed and configured as root.
Most zimbra processes and third party components will then run as root and switch to the 'zimbra' user
Most zimbra processes and third party components will then run as root and switch to the 'zimbra' user
(or postfix, or postdrop, and so on).
(or postfix, or postdrop, and so on).
This build has been tested with both IPv4/IPv6, in different configurations (ldap only, mta only, store only,
This build has been tested with both IPv4/IPv6, in different configurations (ldap only, mta only, store only,
...
@@ -81,6 +81,7 @@ scripts and processes that make one or more of the following assumptions.
...
@@ -81,6 +81,7 @@ scripts and processes that make one or more of the following assumptions.
This order roughly reflects the level of difficulty encountered in the project,
This order roughly reflects the level of difficulty encountered in the project,
from the esiest to solve, to the hardest.
from the esiest to solve, to the hardest.
Assumption 1: the system can be prepared by a root user, with specific system-level
Assumption 1: the system can be prepared by a root user, with specific system-level
configuration, before running the build.
configuration, before running the build.
...
@@ -104,6 +105,7 @@ Assumption 2: many libraries can be provided by apt-get, rpm, zypper and so on.
...
@@ -104,6 +105,7 @@ Assumption 2: many libraries can be provided by apt-get, rpm, zypper and so on.
Wherever possible, changes have been made to use libraries and tools
Wherever possible, changes have been made to use libraries and tools
provided by the Zimbra build itself (better option), or by SlapOS components.
provided by the Zimbra build itself (better option), or by SlapOS components.
Both building and actually running the system can require these.
Both building and actually running the system can require these.
A couple of files are needed to setup environment variables,
A couple of files are needed to setup environment variables,
both while building (done automatically by buildout) and while running
both while building (done automatically by buildout) and while running
the Zimbra system or administration scripts.
the Zimbra system or administration scripts.
...
@@ -115,7 +117,64 @@ Assumption 2: many libraries can be provided by apt-get, rpm, zypper and so on.
...
@@ -115,7 +117,64 @@ Assumption 2: many libraries can be provided by apt-get, rpm, zypper and so on.
These need to be executed with the '.' (source) command before any activity.
These need to be executed with the '.' (source) command before any activity.
A few packages could not be provided by zimbra or slapos, or could not be detected
A few packages could not be provided by zimbra or slapos, or could not be detected
by the makefiles.
by the makefiles. They have to be provided by the linux distribution.
- libcloog-ppl0: CLooG is a software which generates loops for scanning Z-polyhedra.
This library is used by GCC and implements the "graphite optimization"
used to build libmemcached and opendkim. The optimization could probably be
disabled and the dependency removed.
- libncurses5-dev
Although it is usually easy to provide a custom ncurses to a makefile/configure,
this was not the case for heimdal, and would need changing the configure scripts.
- gcc-multilib
Needed to compile junixsocket without patches. It may be not needed if the skip32
flag is provided to ant (see build.xml)
As noted, such package dependencies can probably be removed with a little further research.
Assumption 3: scripts provided by the packaging system (preinst, postinst, /etc/init.d/*)
will be run, as root, when necessary
Many applications have build procedures that can also install packages in a "target" directory,
where it can be directly configured and run.
In the case of Zimbra, this would be a "developer build" which would not be
configured for production purposes.
The standard Zimbra build populates /opt/zimbra (in our case, zbuild/home) then it take parts
and pieces of that content and creates .deb or .rpm files. Some parts (i.e. mysql) will be split
or be part of multiple packages.
The buildout parts that deploy Zimbra (zimbra-deploy-ldap and so on) open the .deb packages
and extract the data.tar.gz contents, therefore 'faking' the presence of them into the system,
but there is no way to run the control scripts as a regular user.
Typical tasks performed by preinst and postinst scripts are:
- set up and update symlinks: /opt/zimbra/{bdb, mysql, jdk..}
- set up directories to hold data: log, redolog, store, index, backup..
- creating configuration files: postfix/conf/main.cf, etc.
- removing obsolete config files or databases: i.e. /opt/zimbra/sleepycat
- set up /etc/sudoers for the zimbra user: i.e. in zimbra-core.postinst
- set up /etc/pam.d and /etc/security
- set up /etc/ld.so.conf, run ldconfig
- set up /etc/rc*.d with the S## and K## files
- set up crontab
- java -client -Xshare:dump (what is this for?)
- set up a tmpfs in /etc/fstab and mount it under amavisd/tmp
- patch db/db.sql with the hostname of the system before initializing the database
All of these need to be examined, reverse engineered and replicated in the buildout.cfg
(the simplest case being the many mkdir and ln commands).
Other tasks which we don't need to replicate are:
- set up /etc/prelink.conf, run prelink
- create users and groups for zimbra, postfix, postdrop
- running zmfixperms
New releases of Zimbra, even minor ones, add more tasks to the control files, depending on
new components, data migrations and environment constraints.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment