View source

The OCF has migrated to a new web server setup as of Sunday, August 6.
Static content and most web applications should work correctly with no
changes.

If you have any questions or concerns, please email us at
[mailto:staff@ocf.berkeley.edu staff@ocf.berkeley.edu].

The following provides a more detailed description of the changes being 
made and how they might affect users.

== Abstract ==
The OCF is migrating to a new web server setup on a new machine.  This
change should bring much-improved server response times and better
security.  The new server machine is a [http://www.sun.com/servers/entry/v40z/index.jsp Sun Fire v40z] given to us by Sun
Microsystems; we thank them for their generous donation.

The new web server setup is running upgraded versions of many
commonly-used software packages.  While we have done extensive testing
to ensure compatibility, there is a possibility that the upgrade will
break some web applications.

While we believe most web applications will be unaffected, users whose
applications fall under one of the following categories may want to
review the relevant sections below.
* PHP users: see the notes on [[#PHP|PHP]] if you have you have your own <tt>php.ini</tt> file.
* Perl users: see the notes on [[#Perl|Perl]], especially if you haven't made any changes in a few years or are using an older version of Perl.
* Python users: see the notes on [[#Python|Python]] if you are using an old version of Python.
* MySQL users: see the note on [[#Databases (MySQL and PostgreSQL)|databases]].
* Compiled applications: see the note on [[#Compiled applications|Compiled applications]].  You will need to recompile.
* Movable Type users using the Blacklist plugin: see the note on [[#Endian issues|Endian issues]].

== Setup details ==
The new machine is a Sun Fire v40z with four AMD Opteron 870 processors
(eight cores) and 16 GB of RAM.  We run on this machine:
* Solaris 10 1/06
** Brings major improvements over Solaris 8, used on our old web server.
* Apache httpd 2.0.59
** This is a minor security and stability update over our old 2.0.50.
* PHP 4.4.2
** See the note on [[#PHP|PHP]] for a discussion of changes.
* Perl 5.8.8
** See the note on [[#Perl|Perl]] for a discussion of changes.
* Python 2.4.3
** See the note on [[#Python|Python]] for a discussion of changes.
* MySQL 4.1.18
* PostgreSQL 8.1.4
** MySQL and PostgreSQL are installed in a different manner for the new setup; see the note on [[#Databases (MySQL and PostgreSQL)|databases]] for details.

== Application-specific notes ==

=== PHP ===
The default version of PHP on the web server (<tt>/opt/local/bin/php</tt>) is
now 4.4.2; this is a minor upgrade over the previous default version 4.3.10,
which brings important security fixes.  We believe that all extensions that were
available in the old setup are available in the new one; if you need an extension
installed, please contact us ([mailto:staff@ocf.berkeley.edu staff@ocf.berkeley.edu]).

We now use dynamically-loaded PHP extensions (instead of having all of the available
extensions compiled directly into the binary).  This makes installing new extensions
and disabling unneeded ones easier.  However, if you have your own <tt>php.ini</tt>
file, and depend on a PHP extension that's not compiled into the new binary, you will 
need to make sure that extension is loaded in your <tt>php.ini</tt> file.  
For example, if you use the MySQL extension, you will need
 extension=mysql.so
in your <tt>php.ini</tt> file.  Note that most available extensions are loaded in the
default <tt>php.ini</tt> file, so you only need to do this if you have your own 
<tt>php.ini</tt> file.  If you don't know what <tt>php.ini</tt> is, you don't need
to do anything; your application will most likely work without changes.

Because we use dynamic PHP extensions now, <tt>/opt/local/bin/php-full</tt> is no
longer needed; while a symlink has been made for it (to our regular PHP binary),
you should modify your scripts to use the default PHP interpreter.

=== Perl ===
The default version of Perl on the web server (<tt>/opt/local/bin/perl</tt>) is
now 5.8.8; this is a minor upgrade over the previous default version
5.8.6.  All modules that were available in the old setup are available
in the new one, so far as we know; please contact us
([mailto:staff@ocf.berkeley.edu staff@ocf.berkeley.edu]) if you need a Perl module installed.

Older versions of Perl are no longer supported.  <tt>/usr/bin/perl</tt> is now
Perl 5.8.4 due to the Solaris 10 upgrade (as opposed to the 5.005_03 on
Solaris 8 boxes).  Perl 5.004, 5.005, and 5.6 are no longer available.
(<tt>/opt/local/bin/perl5.005</tt> is a symlink to Perl 5.8.8 to help ease
transition, and does NOT provide full compatibility with the older
version of Perl.)  See the Perl release notes and the notes for your web
application to see if there are any changes that need to be made.

Also, there are differences in the way Sun builds <tt>/usr/bin/perl</tt> that make it in some cases incompatible with data saved from the old server. For example, a change to use 64-bit integer types instead of 32-bit renders data stored via the Storable.pm module incompatible.  There are workarounds for various software packages at various places on the internet.  Also, refer to the section below on [[#Endian Issues|Endian Issues]].

=== Python ===
The default version of Python on the web server (<tt>/opt/local/bin/python</tt>) is
now 2.4.3; this is a minor upgrade over the previous default version
2.4.1.  All modules that were available in the old setup are available
in the new one, so far as we know; please contact us
([mailto:staff@ocf.berkeley.edu staff@ocf.berkeley.edu]) if you need a Python module installed.

Python 2.3.5 is available as <tt>/opt/local/bin/python2.3</tt>; this is a minor upgrade
over the previous default version 2.3.4.  All modules that were available
in the old setup are available in the new one, so far as we know; please contact us
([mailto:staff@ocf.berkeley.edu staff@ocf.berkeley.edu]) if you need a Python module installed
for Python 2.3.

Older version of Python (1.5, 2.1, 2.2) are no longer supported.  <tt>/opt/local/bin/python2.2</tt>
is a symlink to Python 2.3.5 to help ease the transition, but does NOT provide full
compatibility with the older release.  See the Python documentation and the notes for
your web application to see if there are any changes that need to be made.

=== Databases (MySQL and PostgreSQL) ===
MySQL and PostgreSQL no longer run in the same virtual container as the
web server and web applications.  This means that web applications
configured to use <tt>localhost</tt> or <tt>death.ocf.berkeley.edu</tt>
as the database server will no longer work.  While this has not been the
supported configuration for awhile, many web applications use <tt>localhost</tt> as a 
default setting.  You will need to make sure that your application is using 
the supported names <tt>mysql.ocf.berkeley.edu</tt> or 
<tt>postgresql.ocf.berkeley.edu</tt> (depending of course on which DB your 
application uses) to ensure that it works after the migration.

=== Compiled applications ===
The new machine has x86 CPUs, as opposed to the old server's SPARC
processors; as a result, binaries compiled on one will not run on the
other (scripts are unaffected).  If you need to compile Solaris x86 binaries,
you may log in to <tt>asteroid.ocf.berkeley.edu</tt> using [[SSH]] (you will
find GNU compilers and development tools under <tt>/usr/sfw</tt>, and Sun Studio
11 tools under <tt>/opt/SUNWspro</tt>).

=== Endian issues ===
The new machine has x86 CPUs, as opposed to the old server's SPARC
processors.  Due to differences in the way these two processor
architectures handle data (SPARC stores data with the most significant
byte first -- "big-endian" format, while x86 stores data least
significant byte first -- "little-endian" format), applications
that store binary data naively may function incorrectly.

In particular, this affects users of the Movable Type Blacklist plugin,
which stores its data in host byte order.  If you're affected by this,
see [http://www.ocf.berkeley.edu/fixing-mt-blacklist.pdf] for instructions
on how to correct the problem.

If you are developing your own application, and are storing binary
data, it is safest to store your data in network byte order (big-endian
format).  Most programming languages have some method of converting
binary data to network byte order; consult the documentation for your
programming language to determine how to do this.  If you are fixing
an existing application, note that storing and retrieving your data
in network byte order will allow you to read your old data (created
on the SPARC processor in big-endian format) without problems.