![[Steve Friedl Logo]](/images/unixwiz-logo-140x80.gif){kind=logo}
This site uses advanced css techniques
NOTE: This procedure has not been updated in some time and is mostly out of date; consult the iSystems Evo Technical Guide for official word if you care to do this yourself.
The Evolution Payroll service-bureau system from iSystems, LLC employs a three-tiered architecture, with the backend being one or more Linux servers running the Firebird SQL database. Evolution is able to split the load across multiple DB servers on a per-client basis.
As Service Bureaus grow, it's common to add new DB servers to the system, and this Evo Tip covers the steps required to take a fresh Fedora Core system and prepare it for Evolution.
This Evo Tip is similar to (and loosely based on) the instructions provided by iSystems for their Franklin database upgrade, but we focus on building a machine from scratch rather than upgrading from one database version to another.
We use these very notes to configure our own machines, and we incorporate best practices from iSystems and from the rest of the Evolution technical user community.
On a naked machine with no OS, one must often do a bit of configuration before the operating system can be loaded. This includes RAID array setup and BIOS configuration.
First, avoid RAID 5: this is the most space efficient (only one drive is "wasted" for redundancy), but our experience has shown that it has the worst write performance. This is particularly the case where the RAID controller has no battery backup, which usually disables the write cache. This means atrocious disk performance.
We normally use RAID 10, which is mirrored, striped drives: this requires essentially doubling the disk space, but the performance improvements are enough that we simply won't consider RAID 5 again.
Second, many machines offer Intel processors sporting HyperThreading™, and we recommend enabling it for DB servers (though iSystems recommends disabling it for Windows machines). Our testing indicates that it provides a modest improvement in real performance, and we've not found any reason not to do this.
Systems with dual-core Xeon processors should always enable the dual core - these are real live extra processors and make a tremendous difference in processing speed.
We typically install Linux from CDs made from downloadable ISOs from the Fedora site and boot them on the system being built. Though it's possible with modern server equipment to use network-based booting and system building (Kickstart/PXE), it's unlikely that most service bureaus will need to build so many machines that it's worth the trouble to set this all up.
Our preference is for heavily stripped down machines — just the base operating system plus the compilers for building tools — and we normally install with in linux text mode. The graphical installer may be used instead by those who prefer it.
Recommended filesystem layout is discussed in the next section.
We typically de-select almost every package during installation, preferring to manually install the few we actually need. We do
We normally disable the firewall and the SELinux facilities as well. SELinux is a Security-Enhanced Linux, and it was developed in the main by the National Security Agency.
Though a powerful augmentation to system security, one should always look at security in terms of the threats it's going to face. SELinux mainly protects against hostile local users, something we don't expect much of in a payroll service bureau.
Likewise with the firewall: we normally expect that the enterprise has firewall protecton at the border, not requiring it inside.
Evolution typically keeps its data files in the /db/evolution directory, and this location is configured into the Registration Daemon on the Windows server. Though this location is not strictly required, technical support is probably going to be a lot easier if your installation relies on things being in the usual places (we've never seen a service bureau not use these locations). The rest of this Evo Tip assumes the default location.
It's a good practice to make /db/ a separate filesystem on its own partition, isolating it from the rest of the sytem. Should the root partition run out of space for whatever reason, it won't impact the client database file storage.
The size of the /db/ partition is normally defined during operating installation time, and plenty of space should be allocated for these very large files. Furthermore, choose a stable filesystem type (ext2 preferred over ext3). We have no experience with ReiserFS in a production environment and cannot yet recommend it for Evolution.
A representative new system with around 130 gigabytes of storage looks like this:
# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda5 4032092 647864 3179404 17% / /dev/sda2 101105 11067 84817 12% /boot /dev/sda6 132628932 94272 125797404 1% /db none 1036320 0 1036320 0% /dev/shm
We note that iSystems recommends putting /opt on its own partition so that a Firebird log filling up won't trash the whole machine, and this doesn't seem like a bad idea. It's not really necessary, though, if the Firebird configuration has been set properly.
Be sure to create the /db/evolution directory and make sure it's owned by Firebird: this allowed Evo to create new client databases.
# mkdir -p /db/evolution # chown firebird:firebird /db/evolution
We publish quite a few tools on our website, and it's not a bad idea to install them in each Linux DB server. We'll be using some of them during installation.
We suggest:
The Firebird - formerly Interbase - database is used by Evolution, and for now the older "Classic Server" is required rather than the newer "Super Server" version. The latter has a much better architecture, but iSystems reports serious data corruption issues with it and is not supported. DO NOT attempt to use the Super Server.
For Jamaica and prior releases, FirebirdCS-1.5.3 was used, but Killington and beyond uses version FirebirdCS-2.0.1; these can all be downloaded from the iSystems support site:
Though it can be downloaded via the GUI (KDE/Gnome) on the Linux machine, or via a standard Windows browser and then copied to the db server, we prefer to fetch the file directly from the command line.
Using a regular Windows browser, visit the iSystems support site and right-click on the link name.
Then, using a terminal emulation program (Secure Shell, preferably) login as root to the database server and use the evo-wget program to fetch the RPM file directly to the server; you should have set this up in a previous step to include your FTP/sbupdate credentials.
# cd /tmp # evo-wget http://is1.isystemsllc.com/sbupdate/9.0_Killington/Firebird/FirebirdCS-2.0.1.12855-0.i686.rpm
Alternately, simply save the file to the local Windows machine and get it to the Linux database box somehow.
However: Some builds of FireBird 1.5 were constructed with an older version of the compiler, and requires an older standard C++ library that is not normally included with Fedora releases. The failure to find this library manifests itself with an error of this nature:
/opt/firebird/bin/gsec: error while loading shared libraries:
libstdc++.so.5: cannot open shared object file:
No such file or directory
The libstdc++.so.5 library must be installed, and we do so using the yum installer tool to fetch a compatibility package. The version required depends on the Fedora release:
# yum install compat-libstdc++-8 # Fedora Core 3 or # yum install compat-libstdc++-33 # Fedora Core 5, RHEL5.1, CentOS 5
Red Hat Enterprise Linux 4 also requires the compat-libstdc++-33 package, but the Yum installer is not typically found: it's likely that the up2date system will fetch this package.
We've not seen this problem at all with Firebird 2.0 installations.
With the proper compatibility library in place, we can install Firebird:
# rpm -i FirebirdCS-2.0.1.12855-0.i686.rpm
This installs Firebird in the /opt/firebird/ directory and makes some adjustments to the operating system (we'll be making more of them later as well).
Firebird supports its own notion of users independent of those maintained by the operating system or Evolution itself, and Evo's Franklin release (2004) introduced the EUSER id to augment the system-provided SYSDBA.
Both are used by Evolution, and they must be configured using the gsec tool:
# /opt/firebird/bin/gsec GSEC> modify SYSDBA -pw pps97 GSEC> add EUSER -pw pps97 -fname Evo -lname User GSEC> display user name uid gid full name ------------------------------------------------ SYSDBA 0 0 EUSER 0 0 Evo User GSEC> control-D
Note that it's possible to use some other password for these accounts as long as Evolution is configured in the EEC to use them.
We don't customarily change the default password.
Firebird's turning is mainly driven by the file /opt/firebird/firebird.conf, and there are three settings that should be tuned. This is a straight ASCII text file that can be easily edited with vi, and the file saved.
These parameters are documented in the file in comments, so it should be a simple matter to find them and update the parameter.
inet server err: setting NODELAY socket option
Fatal lock manager error: semaphores are exhaustedWhen this happens, Evolution stops dead in its tracks, requiring a full restart of everything. It's hoped that upping this value to 128 will avert future occurrences of this calamity, though iSystems and I are researching the recommended value (which may increase in the future).
Evolution extends the power of Firebird with functions defined by iSystems: These UDFs (User Defined Functions) provide features not supported by the stock database, such as the ability to remotely query all the client database filenames, as well as supporting Evolution's time-domaining system on all DB records.
The User-Defined Functions are provided in a single file, EvolUDFs and must be placed in the /opt/firebird/UDF directory; Firebird will use these automatically once installed.
This file is found on the iSystems support website, and as of the Irasburg release, it was in the Irasburg_Upgrade_Files/EvolUDFs.tar.bz2 This should be downloaded to the Linux machine, unpacked and untar'd, and moved to the /opt/firebird/UDF/ location.
Once Firebird is installed, it must be configured to listen for network connections from the middle tier servers. This is done via the xinetd service, which is not always installed with Fedora by default.
First: insure that the xinetd service is installed properly:
# yum install xinetd
If it's not installed, agree to do so.
Next, the default firebird configuration must be updated, as it's not really suitable for the manner in which Evolution accesses it. This is found in the file /etc/xinetd.d/firebird file, and it can be edited with vi:
service gds_db
{
flags = KEEPALIVE NOLIBWRAP
socket_type = stream
wait = no
user = firebird
instances = UNLIMITED
per_source = UNLIMITED
cps = 400 5
server = /opt/firebird/bin/fb_inet_server
log_on_success =
disable = no
}
We'll touch on what these options mean.
Once done, start/restart the service and insure that it launches when the system boots:
# service xinetd restart # chkconfig --level 2345 xinetd on
Now that Firebird is configured, we turn to some base Linux configuration issues: none of these is strictly necessary, but we have found them to be helpful in the past.
... net.ipv4.tcp_keepalive_time = 300
... alias net-pf-10 off alias ipv6 off — Fedora 8
... blacklist net-pf-10
... NETWORKING_IPV6=no NOZEROCONF=yes — RHEL4 or FC5/6, at least
# LANG="en_US.UTF-8" -- this part disabled LANG="en_US" SUPPORTED="en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16"
...
# Path manipulation
if [ `id -u` = 0 ]; then
pathmunge /sbin
pathmunge /usr/sbin
pathmunge /usr/local/sbin
fi
pathmunge /usr/X11R6/bin after
pathmunge /opt/firebird/bin # add this
...
# rpm -e ODBCunix — Fedora Core # rpm -e unixODBC unixODBC_kde — Red Hat Enterprise # rpm -q -a | grep -i odbc — look for any ODBC pkgs
# rpm -q -a | grep -i odbc unixODBC-2.2.11-7.1 mysql-connector-odbc-3.51.12-2.2 unixODBC-2.2.11-7.1 # rpm -e unixODBC mysql-connector-odbc error: "unixODBC" specifies multiple packages # rpm -e --allmatches unixODBC mysql-connector-odbc
127.0.0.1 evodb.unixwiz.net evodb localhost localhost.localdomain
127.0.0.1 localhost 192.168.1.31 evodb.unixwiz.net evodb
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.15-1.2054_FC5smp)
root (hd0,0)
kernel /vmlinuz-2.6.15-1.2054_FC5smp ro root=/dev/VolGroup00/LogVol00 selinux=0
initrd /initrd-2.6.15-1.2054_FC5smp.img
# service iptables stop # chkconfig --del iptables
# zdump -v /etc/localtime | grep 2007 /etc/localtime Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST isdst=0 gmtoff=-28800 /etc/localtime Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT isdst=1 gmtoff=-25200 /etc/localtime Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 PDT isdst=1 gmtoff=-25200 /etc/localtime Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 PST isdst=0 gmtoff=-28800
This Evo Tip is not endorsed, approved, or supported by iSystems, LLC.
First published: 2006/09/23, but updated frequently
![[Steve's Email]](/images/steve-email.gif)
![[RSS Feed available]](/images/feed-icon-14x14.png){kind=icon}