<!-- $Id -->
<sect1 id="requirements">
<title>System Requirements</title> <para>Any platform that can run
&postgres; should be able to run
&slony1;.</para>

<para>The platforms that have received specific testing at the time of
this release are FreeBSD-4X-i368, FreeBSD-5X-i386, FreeBSD-5X-alpha,
osX-10.3, Linux-2.4X-i386 Linux-2.6X-i386 Linux-2.6X-amd64,
<trademark>Solaris</trademark>-2.8-SPARC,
<trademark>Solaris</trademark>-2.9-SPARC, AIX 5.1 and
OpenBSD-3.5-sparc64.</para>

<para>There have been reports of success at running &slony1; hosts
that are running PostgreSQL on Microsoft
<trademark>Windows</trademark>.  At this time, the
<quote>binary</quote> applications (<emphasis>e.g.</emphasis> - <xref
linkend="slonik">, <xref linkend="slon">) do not run on
<trademark>Windows</trademark>, but a <xref linkend="slon"> running on
one of the Unix-like systems has no reason to have difficulty
connecting to a PostgreSQL instance running on
<trademark>Windows</trademark>. </para>

<para> It ought to be possible to port <xref linkend="slon"> and <xref
linkend="slonik"> to run on <trademark>Windows</trademark>; the
conspicuous challenge is of having a POSIX-like
<filename>pthreads</filename> implementation for <xref
linkend="slon">, as it uses that to have multiple threads of
execution.  There are reports of there being a
<filename>pthreads</filename> library for
<trademark>Windows</trademark>, so nothing should prevent some
interested party from volunteering to do the port.</para>

<sect2>
<title> &slony1; Software Dependancies</title>

<para> At present, &slony1; <emphasis>as well as &postgres;</emphasis>
need to be able to be compiled from source at your site.</para>

<para> In order to compile &slony1;, you need to have the following
tools.

<itemizedlist>
<listitem><para> GNU make.  Other make programs will not work.  GNU
make is often installed under the name <command>gmake</command>; this
document will therefore always refer to it by that name. (On
Linux-based systems GNU make is typically the default make, and is
called <command>make</command>) To test to see if your make is GNU
make enter <command>make version</command>.  Version 3.76 or later
will suffice; previous versions may not.</para></listitem>

<listitem><para> You need an ISO/ANSI C compiler.  Recent versions of
<application>GCC</application> work.</para></listitem>

<listitem><para> You also need a recent version of &postgres;
<emphasis>source</emphasis>.  &slony1; depends on namespace support so
you must have &postgres; version 7.3.3 or newer to be able to build
and use &slony1;.  </para>

<para> Earlier versions of &postgres; are <emphasis> not </emphasis>
supported, but note that one user has <quote>hacked</quote> &slony1;
to do a 7.2-to-7.4 upgrade; see <link linkend="v72upgrade"> &postgres;
7.2 notes </link>. </para>

<para> Versions of &postgres; prior to 7.4.8 may run into a
longstanding race condition that leads to problems of <link
linkend="dupkey"> <quote>duplicate keys</quote></link>, so you may
want to consider upgrades if you are running earlier versions.</para>

<para> If you are running a version of &postgres; earlier
than 8.0, you need to make sure that server header files were
installed.  If installing from sources, this is done via the command
<command>make install-all-headers</command>.  Otherwise, you will
encounter the <link linkend="missingheaders"> missing headers for
libpqserver</link> problem described in the FAQ.
</para>

</listitem>

<listitem><para> GNU packages may be included in the standard
packaging for your operating system, or you may need to look for
source code at your local GNU mirror (see <ulink
url="http://www.gnu.org/order/ftp.html">
http://www.gnu.org/order/ftp.html </ulink> for a list) or at <ulink
url="ftp://ftp.gnu.org/gnu"> ftp://ftp.gnu.org/gnu </ulink>
.)</para></listitem>

<listitem><para> If you need to obtain &postgres; source, you can
download it from your favorite &postgres; mirror.  See <ulink
url="http://www.postgresql.org/mirrors-www.html">
http://www.postgresql.org/mirrors-www.html </ulink> for a
list.</para></listitem>

<listitem><para> This documentation is written in SGML using <ulink
url="http://docbook.com/"> DocBook </ulink>, and may be processed into
numerous formats including HTML, RTF, and PDF using tools in the
<ulink url="http://docbook.sourceforge.net/"> DocBook Open Repository
</ulink> along with <ulink url="http://openjade.sourceforge.net/">
OpenJade.</ulink> </para></listitem>

</itemizedlist> </para>

<para>Also check to make sure you have sufficient disk space.  You
will need approximately 5MB for the source tree during build and
installation.</para>

<note><para>There are changes afoot for version 1.1 that ought to make
it possible to compile &slony1; separately from &postgres;, which
should make it practical for the makers of distributions of
<productname>Linux</productname> and
<productname>FreeBSD</productname> to include precompiled binary
packages for &slony1;, but until that happens, you need to be prepared
to use versions of all this software that you compile
yourself.</para></note>
</sect2>

<sect2>
<title> Getting &slony1; Source</title>

<para>You can get the &slony1; source from <ulink
    url="http://developer.postgresql.org/~wieck/slony1/download/">
http://developer.postgresql.org/~wieck/slony1/download/</ulink>
</para>

</sect2>

<sect2 id="times">
<title> Time Synchronization</title>

<para> All the servers used within the replication cluster need to
have their Real Time Clocks in sync. This is to ensure that <xref
linkend="slon"> doesn't generate errors with messages indicating that
a subscriber is already ahead of its provider during replication.  We
recommend you have <application>ntpd</application> running on all
nodes, where subscriber nodes using the <quote>master</quote> provider
host as their time server.</para>

<para> It is possible for &slony1; itself to function even in the face
of there being some time discrepancies, but having systems <quote>in
sync</quote> is usually pretty important for distributed
applications.</para>

<para> See <ulink url="http://www.ntp.org/"> www.ntp.org </ulink> for
more details about NTP (Network Time Protocol).</para>

<para> Some users have reported problems that have been traced to
their locales indicating the use of some time zone that &postgres; did
not recognize.

<itemizedlist>

<listitem><para> On <productname>AIX</productname>,
<command><envar>TZ</envar>=CUT0</command> was unrecognized, leading to
timestamps pulled from system calls causing it to
break.</para>

<para> <command>CUT0</command> is a variant way of describing
<command>UTC</command></para>
</listitem>

<listitem><para> Some countries' timezones are not yet included in
&postgres;.  </para></listitem>

</itemizedlist></para>

<para> In any case, what commonly seems to be the <quote>best
practice</quote> with &slony1; (and, for that matter, &postgres;) is
for the postmaster user and/or the user under which
<application>slon</application> runs to use
<command><envar>TZ</envar>=UTC</command> or
<command><envar>TZ</envar>=GMT</command>.  Those timezones are
<emphasis>sure</emphasis> to be supported on any platform, and have
the merit over <quote>local</quote> timezones that times never wind up
leaping around due to Daylight Savings Time.</para>

</sect2>

<sect2><title> Network Connectivity</title>

<para>It is necessary that the hosts that are to replicate between one
another have <emphasis>bidirectional</emphasis> network communications
between the &postgres; instances.  That is, if node B is replicating
data from node A, it is necessary that there be a path from A to B and
from B to A.  It is recommended that, as much as possible, all nodes
in a &slony1; cluster allow this sort of bidirection communications
from any node in the cluster to any other node in the cluster.</para>

<para>For ease of configuration, network addresses should ideally be
consistent across all of the nodes.  <xref linkend="stmtstorepath">
does allow them to vary, but down this road lies madness as you try to
manage the multiplicity of paths pointing to the same server.</para>

<para>A possible workaround for this, in environments where firewall
rules are particularly difficult to implement, may be to establish
<ulink url="http://www.brandonhutchinson.com/ssh_tunnelling.html"
id="tunnelling"> SSH Tunnels </ulink> that are created on each host
that allow remote access through a local IP address such as 127.0.0.1,
using a different port for each destination.</para>

<para> Note that <application>slonik</application> and the
<application>slon</application> instances need no special connections
or protocols to communicate with one another; they merely need access
to the &postgres; databases, connecting as a <quote>superuser</quote>
<link linkend="morethansuper">that has the ability to update system
tables.</link></para>

<para> An implication of this communications model is that the entire
extended network in which a &slony1; cluster operates must be able to
be treated as being secure.  If there is a remote location where you
cannot trust one of the databases that is a &slony1; node to be
considered <quote>secure,</quote> this represents a vulnerability that
can adversely affect the security of the entire cluster.  As a
<quote>peer-to-peer</quote> system, <emphasis>any</emphasis> of the
hosts is able to introduce replication events that will affect the
entire cluster.  Therefore, the security policies throughout the
cluster can only be considered as stringent as those applied at the
<emphasis>weakest</emphasis> link.  Running a &slony1; node at a
branch location that can't be kept secure compromises security for the
cluster as a whole.</para>

<para>New in &slony1; version 1.1 is a feature whereby updates for a
particular replication set may be serialized via a scheme called <link
linkend="logshipping">log shipping. </link> The data stored in
<envar>sl_log_1</envar> and <envar>sl_log_2</envar> is also written
out to log files on disk.  These files may then be transmitted in any
manner desired, whether via scp, FTP, burning them onto DVD-ROMs and
mailing them, or, at the frivolous end of the spectrum, by recording
them on a USB <quote>flash device</quote> and attaching them to birds,
allowing some equivalent to <ulink
url="http://www.faqs.org/rfcs/rfc1149.html"> transmission of IP
datagrams on avian carriers - RFC 1149.</ulink> But whatever the
transmission mechanism, this allows one way communications such that
subscribers that use log shipping have no need of access to other
&slony1; nodes.</para>

</sect2>
</sect1>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:"book.sgml"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->
