Skip to content

slapos
slapos
Commit ab983a08 authored by Marco Mariani's avatar Marco Mariani
Browse files
Options

zimbra doc: reindent

parent 2fcedb3d
Hide whitespace changes
Inline Side-by-side
Showing with 214 additions and 214 deletions
software/zimbra/INSTALL.txt
View file @ ab983a08
......@@ -33,9 +33,9 @@ How to install Zimbra
*) Install Ubuntu 12.04.x 64 bit server with at least 2GB RAM / 15 GB HD
For instance, you can download it from
http://releases.ubuntu.com/precise/ubuntu-12.04.2-server-amd64.iso
and just 'dd' the image to an USB key, then boot with it.
For instance, you can download it from
http://releases.ubuntu.com/precise/ubuntu-12.04.2-server-amd64.iso
and just 'dd' the image to an USB key, then boot with it.
*) Install additional packages
......@@ -57,28 +57,28 @@ How to install Zimbra
#127.0.1.1 myserver
192.168.0.118 myserver.mydomain.com myserver
Note that we commented/removed the line with 127.0.1.1. This file is actually checked by the zmsetup.pl script
to retrieve the host and domain names.
Note that we commented/removed the line with 127.0.1.1. This file is actually checked by the zmsetup.pl script
to retrieve the host and domain names.
*) DNS must be set up according to Zimbra documentation (myhost.mydomain.com has both A and MX records)
*) The global limits for 'number of open files' must be increased from the default of 1024.
Many maintenance scripts call 'ulimit -n 32768' - therefore the following must be added
to /etc/security/limits.conf
Many maintenance scripts call 'ulimit -n 32768' - therefore the following must be added
to /etc/security/limits.conf
----- cut here --------------------------------
* hard nofile 32768
* soft nofile 32768
----- cut here --------------------------------
After this change, reboot the system to make it effective.
After this change, reboot the system to make it effective.
*) System logging must be configured in order to have server monitoring from the admin interface
The following must be uncommented in /etc/rsyslog.conf:
The following must be uncommented in /etc/rsyslog.conf:
----- cut here ----------------
# provides UDP syslog reception
......@@ -99,7 +99,7 @@ How to install Zimbra
$ sudo chown `id -u`.`id -g` /etc/authbind/byport/{80,110,143,443,\!993,\!995}
$ sudo chmod 755 /etc/authbind/byport/{80,110,143,443,\!993,\!995}
Note that `id -u` and `id -g` are the user and group that will run Zimbra.
Note that `id -u` and `id -g` are the user and group that will run Zimbra.
*) Create the directory to contain zimbra build and clone the slapos repository.
......@@ -107,9 +107,9 @@ How to install Zimbra
$ mkdir zbuild; cd zbuild
$ git clone http://git.erp5.org/repos/slapos.git -b zimbra slapos
You can use a different name for the directory 'zbuild'.
From this point, we will refer to it as '/home/user/zbuild'
NB: the user that runs the build MUST be the same that will run Zimbra.
You can use a different name for the directory 'zbuild'.
From this point, we will refer to it as '/home/user/zbuild'
NB: the user that runs the build MUST be the same that will run Zimbra.
*) Create buildout.cfg
......@@ -125,13 +125,13 @@ How to install Zimbra
*) Build SlapOS and Java components
Bootstrap and run buildout a first time without arguments:
Bootstrap and run buildout a first time without arguments:
$ wget https://raw.github.com/buildout/buildout/1/bootstrap/bootstrap.py
$ python bootstrap.py
$ ./bin/buildout
After some time, you should read:
After some time, you should read:
BUILD SUCCESSFUL
[...]
......@@ -140,7 +140,7 @@ How to install Zimbra
tar --extract --bzip2 --file /home/user/zbuild/parts/junixsocket/junixsocket-1.3-bin.tar.bz2 --wildcards '*.so' --strip-components=2'
Unused options for junixsocket-sources: 'update-command'.
You might see instead:
You might see instead:
BUILD FAILED
/home/user/zbuild/parts/junixsocket__compile__/junixsocket-1.3/build.xml:411: Test org.newsclub.net.unix.SoTimeoutTest failed
......@@ -152,28 +152,28 @@ How to install Zimbra
Installing junixsocket.
Error: System error
This happens sometimes, and is an unpredictable timing issue.
Running buildout again fixes the problem.
This happens sometimes, and is an unpredictable timing issue.
Running buildout again fixes the problem.
*) Build Zimbra components
This is provided as a separate step to allow building and deploying on different machines.
This is provided as a separate step to allow building and deploying on different machines.
$ source environment.sh
$ ./bin/buildout install zimbra-build
Some Java warnings are expected.
Some Java warnings are expected.
Third party libraries build with the messages:
Third party libraries build with the messages:
*** Building in openssl SUCCEEDED.
...
*** Building in zeromq SUCCEEDED.
If any of them shows FAILED, check the dependencies, then read the section "Partial third-party build"
If any of them shows FAILED, check the dependencies, then read the section "Partial third-party build"
When buildout has finished, you should find the following files:
When buildout has finished, you should find the following files:
$ ls parts/zimbra-sources/ZimbraBuild/amd64/*deb
zimbra-apache_8.0.4.GA.5682.UBUNTU12.64_amd64.deb
......@@ -187,50 +187,50 @@ How to install Zimbra
zimbra-spell_8.0.4.GA.5682.UBUNTU12.64_amd64.deb
zimbra-store_8.0.4.GA.5682.UBUNTU12.64_amd64.deb
You may backup the .deb files to be sure you don't lose them by mistake (i.e. if you run
this buildout step again, they will be deleted).
If you want to install zimbra on another or multiple servers, you can skip this step
by reusing the .deb files - but only if the username and path of the build directory are the same.
You may backup the .deb files to be sure you don't lose them by mistake (i.e. if you run
this buildout step again, they will be deleted).
If you want to install zimbra on another or multiple servers, you can skip this step
by reusing the .deb files - but only if the username and path of the build directory are the same.
*) Run the deployment section to install the .deb files
$ ./bin/buildout install zimbra-deploy-all
The files will not be really installed by dpkg, but uncompressed under the 'zbuild/home' directory.
If setcap is required at this point (for ldap and postfix) a root password might be asked.
The files will not be really installed by dpkg, but uncompressed under the 'zbuild/home' directory.
If setcap is required at this point (for ldap and postfix) a root password might be asked.
*) Configure zimbra
Be sure to have sourced the environment variables for SlapOS components
Be sure to have sourced the environment variables for SlapOS components
$ source /home/user/zbuild/environment.sh
and the ones that refer to Zimbra components:
and the ones that refer to Zimbra components:
$ source /home/user/zbuild/home/.bashrc
Now run the actual configuration script.
Now run the actual configuration script.
$ cd /home/user/zbuild/home/; ZIMBRA_INSTALLED_PKGS="zimbra-core zimbra-ldap zimbra-mta zimbra-store" ./libexec/zmsetup.pl
The last two lines are printed after running "buildout install zimbra-deploy-all".
The last two lines are printed after running "buildout install zimbra-deploy-all".
*) Fill the required options in the configuration menu.
Usually, only an admin password is required: menu 3 and then 4.
Other mandatory options (as in case of zimbra-deploy-store) are be marked by an asterisk.
Usually, only an admin password is required: menu 3 and then 4.
Other mandatory options (as in case of zimbra-deploy-store) are be marked by an asterisk.
Refer to the official Zimbra documentation for this part of the setup.
Here you can also change things like IPv4/IPv6, etc.
Refer to the official Zimbra documentation for this part of the setup.
Here you can also change things like IPv4/IPv6, etc.
After typing (a)pply, many configuration files, certificates, and databases are created.
A verbose log will show up on the screen.
After typing (a)pply, many configuration files, certificates, and databases are created.
A verbose log will show up on the screen.
At the end of this process, the log is copied in home/log/zmsetup.*.txt
and the zimbra services are run.
At the end of this process, the log is copied in home/log/zmsetup.*.txt
and the zimbra services are run.
*) Check that zimbra is running:
......@@ -242,12 +242,12 @@ How to install Zimbra
zmconfigd Running
*) You should now be able to connect to https://myserver.mydomain.com
and send/receive emails, and log in to the administration interface
(drop-down menu, top right).
and send/receive emails, and log in to the administration interface
(drop-down menu, top right).
*) Before running any of the maintenance commands in bin/ or libexec/,
the following files must be sourced by the shell:
the following files must be sourced by the shell:
$ source /home/user/zbuild/environment.sh
$ source /home/user/zbuild/home/.bashrc
......@@ -319,7 +319,7 @@ Useful commands
$ zmprov ds "myhost.mydomain.com"
(must be run on the ldap server)
(must be run on the ldap server)
- add ipv6 to an existing ipv4 install:
......
software/zimbra/README.txt
View file @ ab983a08
......@@ -191,77 +191,77 @@ Assumption 4: scripts, binaries, libraries, configuration files and databases wi
A layered approach has been applied:
- when possible, replace /opt/zimbra with ${ZIMBRA_HOME} in bash
(and /usr/local/java with JAVA_HOME)
*) when possible, replace /opt/zimbra with ${ZIMBRA_HOME} in bash
(and /usr/local/java with JAVA_HOME)
Pay attention to the quotes. Inside shell scripts, "$VAR" does variable
replacement, but '$VAR' does not. Therefore, in order to replace
'/opt/zimbra' the quoting must be changed as well: "${ZIMBRA_HOME}"
and not '${ZIMBRA_HOME}'. Proper escaping of quotes must be applied
in case of embedded command strings, and strings written to files that
will later be executed.
Pay attention to the quotes. Inside shell scripts, "$VAR" does variable
replacement, but '$VAR' does not. Therefore, in order to replace
'/opt/zimbra' the quoting must be changed as well: "${ZIMBRA_HOME}"
and not '${ZIMBRA_HOME}'. Proper escaping of quotes must be applied
in case of embedded command strings, and strings written to files that
will later be executed.
Make the variable mandatory and remove assignments to the old default.
An error is returned in buildThirdParty.sh if ZIMBRA_HOME is not set up.
Make the variable mandatory and remove assignments to the old default.
An error is returned in buildThirdParty.sh if ZIMBRA_HOME is not set up.
- use $(ZIMBRA_HOME) in makefiles
Be careful of using proper parens: $() and not ${}
*) use $(ZIMBRA_HOME) in makefiles
Be careful of using proper parens: $() and not ${}
Makefiles will automatically use the envvar if defined, but when debugging
we need to build individual Third Party packages, and be sure that
environment.sh has been sourced.
By removing the many "ZIMBRA_HOME ?= /opt/zimbra" from all the Makefiles,
we make sure we remember to use of environment.sh
Makefiles will automatically use the envvar if defined, but when debugging
we need to build individual Third Party packages, and be sure that
environment.sh has been sourced.
By removing the many "ZIMBRA_HOME ?= /opt/zimbra" from all the Makefiles,
we make sure we remember to use of environment.sh
- plain sed replacement
Before starting the build, all remaining /opt/zimbra occurrences are replaced
with a global
*) plain sed replacement
Before starting the build, all remaining /opt/zimbra occurrences are replaced
with a global
sed 's#/opt/zimbra#${ZIMBRA_HOME}#g'
sed 's#/opt/zimbra#${ZIMBRA_HOME}#g'
(see buildout.cfg:[zimbra-sources-search-replace])
(see buildout.cfg:[zimbra-sources-search-replace])
- replace s/../../ with s|..|..| in bash (and m|...| in Perl)
There are several occurences of /opt/zimbra in regular expressions, where
it appears as \/opt\/zimbra.
*) replace s/../../ with s|..|..| in bash (and m|...| in Perl)
There are several occurences of /opt/zimbra in regular expressions, where
it appears as \/opt\/zimbra.
The delimiter has been changed in bash and Perl scripts, therefore
a s/\/opt\/zimbra\/whatever/ become s|/opt/zimbra/whatever| and can be
replaced by the sed command described above.
The delimiter has been changed in bash and Perl scripts, therefore
a s/\/opt\/zimbra\/whatever/ become s|/opt/zimbra/whatever| and can be
replaced by the sed command described above.
Pay attention to Perl: regexps can be 'naked', therefore an expression like
Pay attention to Perl: regexps can be 'naked', therefore an expression like
$cmdline =~ /\/opt\/zimbra\/db/
$cmdline =~ /\/opt\/zimbra\/db/
would be changed to
would be changed to
$cmdline =~ m|/opt/zimbra/db|
$cmdline =~ m|/opt/zimbra/db|
As always, in bash, look the quote characters around the regexp, if present,
and change them from ' to " where needed.
As always, in bash, look the quote characters around the regexp, if present,
and change them from ' to " where needed.
- sed replacement for awk
*) sed replacement for awk
Unfortunately, awk cannot use other characters in place of the slash delimiter.
A more complex sed substitution is performed for these cases:
Unfortunately, awk cannot use other characters in place of the slash delimiter.
A more complex sed substitution is performed for these cases:
ZIMBRA_HOME_WITH_BACKSLASHES=`echo $ZIMBRA_HOME | sed "s#/#\\\\\\\\\\\\\\\\/#g"`
SUB3="s#\\\\/opt\\\\/zimbra#$ZIMBRA_HOME_WITH_BACKSLASHES#g"
ZIMBRA_HOME_WITH_BACKSLASHES=`echo $ZIMBRA_HOME | sed "s#/#\\\\\\\\\\\\\\\\/#g"`
SUB3="s#\\\\/opt\\\\/zimbra#$ZIMBRA_HOME_WITH_BACKSLASHES#g"
- sed replacement for Java code
*) sed replacement for Java code
There is also a case of '/opt/zimbra' that is built by string composition in Java.
There is also a case of '/opt/zimbra' that is built by string composition in Java.
A file-specific substitution is applied here:
A file-specific substitution is applied here:
find . -name LocalConfig.java -exec sed -i 's#= FS + "opt" + FS + "zimbra"#= "${:ZIMBRA_HOME}"#g' {} \;
find . -name LocalConfig.java -exec sed -i 's#= FS + "opt" + FS + "zimbra"#= "${:ZIMBRA_HOME}"#g' {} \;
A grep search for all occurrences of 'opt' in Java sources may help to detect similar cases.
A grep search for all occurrences of 'opt' in Java sources may help to detect similar cases.
Assumption 5: processes can be run by a specific user (zimbra, postfix, postdrop) or as root
......@@ -280,100 +280,100 @@ Assumption 5: processes can be run by a specific user (zimbra, postfix, postdrop
The changes can be grouped by purpose:
- Removing user checks
The first thing to remove are the parts of code that abort a script when run by a different user.
This change should generally be applied as soon as possible, so that further permission problems can be detected.
*) Removing user checks
The first thing to remove are the parts of code that abort a script when run by a different user.
This change should generally be applied as soon as possible, so that further permission problems can be detected.
The code often looks like
The code often looks like
if [ x`whoami` != xzimbra ]; then
echo Error: must be run as zimbra user
exit 1
fi
or with `id -un` in place of whoami.
In Perl, the checks can take very different forms, which are hard to find with grep:
or with `id -un` in place of whoami.
In Perl, the checks can take very different forms, which are hard to find with grep:
($>) and usage();
- Removing usage of su/sudo
*) Removing usage of su/sudo
This goes both ways: scripts run by root that need to run scripts as zimbra, and vice-versa.
For the latter, Zimbra requires /etc/sudoers to be properly set up:
This goes both ways: scripts run by root that need to run scripts as zimbra, and vice-versa.
For the latter, Zimbra requires /etc/sudoers to be properly set up:
%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmstat-fd *
%zimbra ALL=NOPASSWD:/opt/zimbra/openldap/libexec/slapd
%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmslapd
%zimbra ALL=NOPASSWD:/opt/zimbra/postfix/sbin/postfix, /opt/zimbra/postfix/sbin/postalias,
/opt/zimbra/postfix/sbin/qshape.pl, /opt/zimbra/postfix/sbin/postconf,
/opt/zimbra/postfix/sbin/postsuper
%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmqstat,/opt/zimbra/libexec/zmmtastatus
%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmmailboxdmgr
%zimbra ALL=NOPASSWD:/opt/zimbra/bin/zmcertmgr
%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmstat-fd *
%zimbra ALL=NOPASSWD:/opt/zimbra/openldap/libexec/slapd
%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmslapd
%zimbra ALL=NOPASSWD:/opt/zimbra/postfix/sbin/postfix, /opt/zimbra/postfix/sbin/postalias,
/opt/zimbra/postfix/sbin/qshape.pl, /opt/zimbra/postfix/sbin/postconf,
/opt/zimbra/postfix/sbin/postsuper
%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmqstat,/opt/zimbra/libexec/zmmtastatus
%zimbra ALL=NOPASSWD:/opt/zimbra/libexec/zmmailboxdmgr
%zimbra ALL=NOPASSWD:/opt/zimbra/bin/zmcertmgr
We have removed all the explicit calls to sudo.
Sometimes it's as easy as removing the 'sudo' word before a command, but at times the
subprocess behavior must be retained, so that
We have removed all the explicit calls to sudo.
Sometimes it's as easy as removing the 'sudo' word before a command, but at times the
subprocess behavior must be retained, so that
$SU = "su - zimbra -c -l ";
becomes
becomes
$SU = "bash -c ";
While applying this kind of change, string quoting/backquoting and escaped characters
may need to be adjusted, or parens added for grouping command pipes:
While applying this kind of change, string quoting/backquoting and escaped characters
may need to be adjusted, or parens added for grouping command pipes:
su - zimbra -c "${zimbra_home}/bin/zmprov -m -l -- ${zmprov_opts} ${key} | sed -e 's/^${key}: //' > ${tmpfile} 2> /dev/null" 2>/dev/null && mv -f ${tmpfile} ${file} 2> /dev/null
becomes
becomes
( ${zimbra_home}/bin/zmprov -m -l -- ${zmprov_opts} ${key} | sed -e "s/^${key}::* //" > ${tmpfile} 2> /dev/null ) && mv -f ${tmpfile} ${file}
- Configuration changes
Users "zimbra", "postfix" and "postdrop" are referenced in the configuration files
used by postfix, opendkim, amavis, clamd, dspam.
Some of these files are provided as templates and need to be patched by sed replacement
(see buildout.cfg:[zimbra-sources-search-replace]).
The actual configuration files are written by zmconfigd.
*) Configuration changes
Users "zimbra", "postfix" and "postdrop" are referenced in the configuration files
used by postfix, opendkim, amavis, clamd, dspam.
Some of these files are provided as templates and need to be patched by sed replacement
(see buildout.cfg:[zimbra-sources-search-replace]).
The actual configuration files are written by zmconfigd.
- Ad-hoc patches to C code
Three patches to postfix are provided, to avoid using initgroups(3), seteuid(2),
setgid(2), setsid(2) and explicit user checks.
*) Ad-hoc patches to C code
Three patches to postfix are provided, to avoid using initgroups(3), seteuid(2),
setgid(2), setsid(2) and explicit user checks.
A patch is also needed for the mailbox wrapper (zmmailboxdmgr) to avoid the stripping
of LD_PRELOAD from the environment variables.
The stripping of such variable is a security need when zmmailboxdmgr runs as root,
but we don't, so we allow it because authbind relies on it to preload libauthbind.so
A patch is also needed for the mailbox wrapper (zmmailboxdmgr) to avoid the stripping
of LD_PRELOAD from the environment variables.
The stripping of such variable is a security need when zmmailboxdmgr runs as root,
but we don't, so we allow it because authbind relies on it to preload libauthbind.so
- Removed calls to chown/chmod and zmfixperms
This also required directly changing permissions of files in the repository to allow +x.
*) Removed calls to chown/chmod and zmfixperms
This also required directly changing permissions of files in the repository to allow +x.
- Granting access to IP ports lower than 1024
This is a common requirement, and port forwarding through iptables is not always possible.
The only solution that we found that works with IPv4/IPv6, with all versions of Java and allows
LD_PRELOAD/LD_LIBRARY_PATH usage is the authbind package.
Versions 1.x only work with IPv4, therefore we backported 2.1.1 to Ubuntu 12.04 and provided
it together with the buildout.cfg
With authbind, if the application /path/to/binary needs the privilege to bind low ports,
it must be called as
*) Granting access to IP ports lower than 1024
This is a common requirement, and port forwarding through iptables is not always possible.
The only solution that we found that works with IPv4/IPv6, with all versions of Java and allows
LD_PRELOAD/LD_LIBRARY_PATH usage is the authbind package.
Versions 1.x only work with IPv4, therefore we backported 2.1.1 to Ubuntu 12.04 and provided
it together with the buildout.cfg
With authbind, if the application /path/to/binary needs the privilege to bind low ports,
it must be called as
$ authbind /path/to/binary [...options...]
or (as seen in bin/zmmailboxdctl) as
or (as seen in bin/zmmailboxdctl) as
$ authbind --deep /path/to/binary [...options...]
The latter form is required to grant the privilege to future subprocesses as well.
The latter form is required to grant the privilege to future subprocesses as well.
For openldap and postfix, we still use setcap inside the buildout.
This requires the sudo password, and could be dispensed with, now that there is support for
authbind. But it would require some changes to the wrapper scripts, as described above.
For openldap and postfix, we still use setcap inside the buildout.
This requires the sudo password, and could be dispensed with, now that there is support for
authbind. But it would require some changes to the wrapper scripts, as described above.
......@@ -388,7 +388,7 @@ of packages to setup. This would normally go through apt-get and detect what has
Other changes not described in the previous section:
- clamav:
- clamav:
Explicitly provide bzip2 from slapos.
- cyrus-sasl
......@@ -451,107 +451,107 @@ The following are characteristics of a software project that are easy to verify,
and can raise early warnings.
- The use of Perforce or other cumbersome VCS
*) The use of Perforce or other cumbersome VCS
While I don't deny the quality of the tool when used every day, it is not
intuitive to most developers, not transparent (and very slow) to anonymous
read-only users, and makes it difficult to propose improvements upstream.
There are a few Zimbra mirrors on github and similar sites, but they all
are all one-way, outdated, only track some branches, or have collapsed commits.
Attemps to directly use a git-p4 bridge have been disappointing, both for
lack of familiarity and for the limitations of the anonymous access.
While I don't deny the quality of the tool when used every day, it is not
intuitive to most developers, not transparent (and very slow) to anonymous
read-only users, and makes it difficult to propose improvements upstream.
There are a few Zimbra mirrors on github and similar sites, but they all
are all one-way, outdated, only track some branches, or have collapsed commits.
Attemps to directly use a git-p4 bridge have been disappointing, both for
lack of familiarity and for the limitations of the anonymous access.
- Support for a limited number of platforms
*) Support for a limited number of platforms
Linux distributions supported by ZCS 8.0.4:
Linux distributions supported by ZCS 8.0.4:
Ubuntu 10.04 (deprecated), 12.04
SUSE Linux Enterprise Server 11
Red Hat Enterprice / CentOS 6
Outside of this limited list, the build scripts *do* fail (i.e. on Ubuntu 13
or OpenSuse) and **there is no documented way** to deploy a production instance
without going through .deb or .rpm packages.
Outside of this limited list, the build scripts *do* fail (i.e. on Ubuntu 13
or OpenSuse) and **there is no documented way** to deploy a production instance
without going through .deb or .rpm packages.
For Zimbra, there is code to detect the distro inside get_plat_tag.sh which is
a starting point, but more if..else ad-hoc code in spread all over the makefiles
and administration scripts - but we only get to test them when we think the
build has succeeded and deployed.
For Zimbra, there is code to detect the distro inside get_plat_tag.sh which is
a starting point, but more if..else ad-hoc code in spread all over the makefiles
and administration scripts - but we only get to test them when we think the
build has succeeded and deployed.
Have a look at ZimbraNative/Makefile. There is code to specifically target
OS/X 10.4 PowerPC, 10.5 i386, 10.6, 10.7 with different compiler flags, and yet OSX
is not officially supported. Which ones have been recently tested?
Have a look at ZimbraNative/Makefile. There is code to specifically target
OS/X 10.4 PowerPC, 10.5 i386, 10.6, 10.7 with different compiler flags, and yet OSX
is not officially supported. Which ones have been recently tested?
Generally - the bigger the system, the more limited the number of platforms it can
be reliably built with. Very often, it's not only a matter of missing phone
support, there are technical reasons. Or simply all the developers use Ubuntu, all
the customers use CentOS.
It is useful to manually build an application on several distributions,
old and new, before attempting a port to buildout. Identify where the constraints
are, and how they can be removed.
Generally - the bigger the system, the more limited the number of platforms it can
be reliably built with. Very often, it's not only a matter of missing phone
support, there are technical reasons. Or simply all the developers use Ubuntu, all
the customers use CentOS.
It is useful to manually build an application on several distributions,
old and new, before attempting a port to buildout. Identify where the constraints
are, and how they can be removed.
- Third party libraries and applications cannot be provided separately
*) Third party libraries and applications cannot be provided separately
Not only does Zimbra provide its own mysql/openldap/perl/etc applications as part
of the zimbra-core*.deb, zimbra-ldap*.deb and such packages, but they
are expected to be installed in /opt/zimbra and compiled with a given set of features.
If the official documentation stated that you need a working mysql instance somewhere,
and just provide authentication credentials while running zmsetup.pl, it would be much
easier to reuse the mysql/mariadb component from SlapOS.
Not only does Zimbra provide its own mysql/openldap/perl/etc applications as part
of the zimbra-core*.deb, zimbra-ldap*.deb and such packages, but they
are expected to be installed in /opt/zimbra and compiled with a given set of features.
If the official documentation stated that you need a working mysql instance somewhere,
and just provide authentication credentials while running zmsetup.pl, it would be much
easier to reuse the mysql/mariadb component from SlapOS.
- Several toolchains are employed
*) Several toolchains are employed
Make, cmake, GNU autoconf/autotools/libtool, ant, cpan.. all of them in the
same project may require a lot of searches for specific flags to provide in
obscure cases.
This is not a big issue if the build already targets several platforms, and
there are hooks to provide locations for the required dependencies.
Also watch out for ancient C software that is still using plain Makfile.
Case in point: ftp://ftp.ucsb.edu/pub/mirrors/procmail/procmail-3.22.tar.gz
Make, cmake, GNU autoconf/autotools/libtool, ant, cpan.. all of them in the
same project may require a lot of searches for specific flags to provide in
obscure cases.
This is not a big issue if the build already targets several platforms, and
there are hooks to provide locations for the required dependencies.
Also watch out for ancient C software that is still using plain Makfile.
Case in point: ftp://ftp.ucsb.edu/pub/mirrors/procmail/procmail-3.22.tar.gz
- The deployment step is complex, long or requires a lot of interaction.
*) The deployment step is complex, long or requires a lot of interaction.
Let's say you are building the FooBar application.
Hopefully, the build system can also deploy, and put a working application
in /opt/foobar.
Let's say you are building the FooBar application.
Hopefully, the build system can also deploy, and put a working application
in /opt/foobar.
If the build system creates .deb or .rpm packages, or .tar packages that need
to be installed as root, watch out for control scripts: start/stop wrappers,
daemon scripts and cron configuration files. Any functionality there might need
to be examined and rewritten for buildout.
If the build system creates .deb or .rpm packages, or .tar packages that need
to be installed as root, watch out for control scripts: start/stop wrappers,
daemon scripts and cron configuration files. Any functionality there might need
to be examined and rewritten for buildout.
Even if the build deploys directly in /opt/foobar, a later configuration step
might be more compex than it seems.
Zimbra requires to run zmsetup.pl - an interactive dynamic menu and sub-menu
application that is very easy to use - it's magic! - totalling about 12000
lines of perl and bash, with a complexity equivalent to 24000 lines of
Python code.
This configuration menu is the biggest red flag we have met so far.
Even if the build deploys directly in /opt/foobar, a later configuration step
might be more compex than it seems.
Zimbra requires to run zmsetup.pl - an interactive dynamic menu and sub-menu
application that is very easy to use - it's magic! - totalling about 12000
lines of perl and bash, with a complexity equivalent to 24000 lines of
Python code.
This configuration menu is the biggest red flag we have met so far.
- The application can auto-update itself, install plugins and extensions
*) The application can auto-update itself, install plugins and extensions
Can the application update itself from the Internet? If so, any change we make to
the sources could be replaced by the new version. The new version may expect
things to be in /opt/foobar instead of /srv/slapgrid, or may rely on values in
/etc/ld.so.conf which can't be controlled in SlapOS, and so on.
Can the application update itself from the Internet? If so, any change we make to
the sources could be replaced by the new version. The new version may expect
things to be in /opt/foobar instead of /srv/slapgrid, or may rely on values in
/etc/ld.so.conf which can't be controlled in SlapOS, and so on.
Even for simple things like themes and plugins, try to download a few of them and
look for hardcoded pathnames, and bash/php/python code. Browser-side JavaScript
is usually harmless (see zimlets in Zimbra).
Don't overlook this point. If the application can be built, but the plugins
don't work, a customer could quickly lose interest.
Even for simple things like themes and plugins, try to download a few of them and
look for hardcoded pathnames, and bash/php/python code. Browser-side JavaScript
is usually harmless (see zimlets in Zimbra).
Don't overlook this point. If the application can be built, but the plugins
don't work, a customer could quickly lose interest.
- Installing the application changes /etc/sudoers
*) Installing the application changes /etc/sudoers
This might actually be useful to detect early which binaries and scripts will need to
be run as root, or as specific users. Try to find the reason behind this requirement
as soon as possible. Also see if setuid/setgid binaries have been installed.
This might actually be useful to detect early which binaries and scripts will need to
be run as root, or as specific users. Try to find the reason behind this requirement
as soon as possible. Also see if setuid/setgid binaries have been installed.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7