NAME

INSTALL - Slash Installation

SYNOPSIS

This document describes how to install Slash, versions 2.2 and pre-releases of 2.3. For instructions on installation or upgrade of previous versions of Slash, see the INSTALL document included with those distributions.

These instructions have only been tested on Linux. Installation under BSD and other Unix OSes should work similarly, but there are problems with the Makefile and installtion under some non-Linux OSes. Feel free to submit bug reports (or better, patches) for any such problems. We've had reports of the 1.0.x version of Slash running on Windows, but have done no testing and have no further information, and have no information about Slash 2 running on Windows.

PostgreSQL was supported (alpha-quality) in earlier versions of Slash 2, but has not been updated at all since late 2001. At this point, Slash works only with MySQL.

Slash can always be downloaded from SourceForge.net, from the FTP site, and via CVS.

http://sf.net/projects/slashcode/
ftp://ftp.slashcode.com//pub/slashcode/
http://cvs.slashcode.com/

See the SourceForge.net page for patches and bug reports.

Which version should I use?

If you are using Slash 2.2.5 or before, including all 2.1.x, 2.0.x, and 1.x versions, you should upgrade to the latest version in the 2.2 tree, 2.2.6, as soon as possible. There are security issues with previous versions. You should not install previous versions.

As of this writing (June 2003), our last official release (2.2.6) was some time ago and many features have been added since. We have not yet released 2.3.0. If you want to use more recent code, check out CVS versions from cvs.slashcode.com. If you are installing a new Slash site, you probably do not want to use the very latest CVS, but you probably do want to use the latest "R_" tag available in CVS. See "VERSIONS", "CVS tags", below, for advice on choosing and maintaining a CVS installation.

Important Note

We know you want to get right into the installation, but you probably want to read this whole document first. Notably, the software and hardware requirements are given later on in the "REQUIREMENTS" section, which you probably want to go read now, to check for potential problems.

Also, you will find information on upgrading a Slash site (which can be tricky); uninstalling; and troubleshooting for common problems.

INSTALLATION

Installation Notes

For slashd (see utils/slash, which starts slashd), mod_perl (see httpd/httpd.conf), and MySQL, we set all processes to run in GMT. Then it is easy to convert dates to whatever the user's local time is. If you have date offset problems, check that all of these are properly set to run in GMT. Your server(s) do not actually need to have their operating systems set to GMT (ours aren't), but if you want to do that, it won't hurt anything.
You cannot have different versions of the Slash modules installed for different sites on the same Apache server. (Well, if you want to, you can try the Apache::PerlVINC module, but this is not recommended for performance reasons. Slash is designed to have one shared core of code for all Slash sites on a system.)
All of the installation steps below should be executed as root.

Installation Procedure

There are six steps to installation. Skip the parts you already have installed (making sure you have the correct versions). Make sure to read the special note about Apache / mod_perl installation.

Install MySQL.

Please refer to MySQL documentation for compilation and/or installation notes for any questions with this process.

Slash requires that your MySQL server run in the GMT timezome. Find your global my.cnf file (probably /etc/my.cnf or /etc/mysql/my.cnf), locate the [mysqld_safe] (or [safe_mysqld]) group, and add this line to it:
```
timezone = GMT
```
Start MySQL (it must be running for the installation of Perl modules and Slash).

Create a database to be used by Slash.

Create a username/password that can access that database (by default, we normally set the user to have all permissions, but that might not be appropriate for your site; make sure that you have at least privileges to select, insert, update, delete, create, drop, index and alter).
Install perl.

perl is likely already installed on your machine; make sure its version is at least the minimum required (see "REQUIREMENTS").
Install Apache and mod_perl.

You MUST install mod_perl and Apache as directed here. OK, that is not strictly true, but unless you really know what you're doing, just assume it's true. If you already have mod_perl installed, it is probably not configured properly to work with Slash and you will have to rebuild it.

If you are using the provided httpd.conf file from the slash distribution, and find that Apache is giving you errors, chances are mod_perl is not installed correctly, and you need to build it from scratch. Not following this direction is one of the most common reasons we see for a Slash install not working.

Of course, if you have your own Apache modules or build options, you will need to modify the instructions here appropriately.

First, untar apache and mod_perl. Then, go to the mod_perl directory, and have mod_perl build and install apache for you:
```
perl Makefile.PL APACHE_SRC=/where_you_have_the_source DO_HTTPD=1 \
        USE_APACI=1 PERL_MARK_WHERE=1 EVERYTHING=1 \
        APACHE_PREFIX=/where_apache_will_be_installed
make
make test
make install
```
NOTE: You may be unsuccessful with make test if the perl modules are not yet installed. However, some Perl modules will not install without Apache and mod_perl installed. If you wish, come back and run make test after installing here, and then installing the Perl modules, to make sure everything is OK. Also, as of January 2002, a make test has thrown spurious errors for several months because of a persistent minor bug; if you see "Can't locate object method 'new' via package 'URI::URL'", read this:

http://groups.google.com/groups?threadm=3B82CE4D.8BF0C1D0%40spamless.genwax.com

NOTE: If you know what you're doing, Slash will work with a DSO Apache. Be sure you're on the latest versions of Apache and mod_perl and remember PERL_MARK_WHERE=1 and EVERYTHING=1.
Install the Perl modules.

Slash is powerful and complex, and, rather than reinvent the wheel, it often relies on CPAN modules. Open-source code reuse has many advantages. One disadvantage is that installing all those modules can be tricky, as you may be about to find out.

You could install each module in Bundle/Slash.pm by hand, but this would be time-consuming. Instead, you'll want to install the bundle Bundle::Slash using CPAN.
Now that you have read the above notes, you're ready to install the perl modules.

To use the CPAN module, invoke the CPAN shell:
```
perl -MCPAN -e shell
```
(Or, you may have the unix command "cpan" already available, which does the same thing.)

If this is the first time you've invoked CPAN, you will be asked to configure it.

Next, install some important networking modules. Doing this first is optional but, if there are problems with these modules, you'll want to resolve them before moving on to the rest of the installation:
```
cpan> install Bundle::LWP
```
Make sure all those modules are installed and up to date before proceeding. Note that Net::Cmd has a history of being a little broken in its tests; if it fails on tests 8 and 9 of t/require, then it's OK; just do force install Net::Cmd and repeat install Bundle::LWP.

After the LWP has been installed and configured successfully, exit the CPAN, reinvoke it with the perl -MCPAN -e shell command, and install Bundle::Slash:
```
cpan> install Bundle::Slash
```
This will be a long process. Several modules will ask to be configured during this process. Here are some tips:

DBI

Don't worry about the threading warning.

DBIx::Password

See IMPORTANT NOTES above.

Apache::Test and Apache::Cookie

You will need httpd and apxs in your $PATH, and even if they are there, you will probably see the lengthy error that starts "Apache cannot spawn child processes as 'root'". This is because, ironically, Apache::Test's self-tests are a colossal pain to actually run. Personally I just force install Apache::Cookie which is lame but solves the problem.

Template

The Template Toolkit is a complex install. Try accepting all the defaults and see if it works. It has 90 test scripts with over 2000 tests, and installation will be halted if just 1 of these tests fails. Do a look Template and try your best to resolve the issues. The README includes a URL to the mailing list archives, where you may find help. If you're getting 100 errors, you need to fix them, but if you're down to 1 or 2 you can't fix, we suggest you make a note of what the failures were and just force install Template.

If you have problems, feel free to re-run install Bundle::Slash. It will safely skip anything already installed.

If you are feeling lucky and are in a big hurry, you might try force install Bundle::Slash, which will skip all tests for all modules -- but if you do this and later things start to fail, you're on your own, don't complain.

Again: once you are able to do install Bundle::Slash and see nothing but a long list of modules that are "up to date," you are done. Until you see that, you are not done with this step!
Install Slash.

Unpack the distribution and go to the new directory that creates, and type:
```
make
make install
```
Note: you will want the GNU versions of fileutils (version 4.0 recommended, for cp and install) and make. Older versions of install, and make and cp from other systems, might not work.

There are a few options to make and make install you may want to change.
```
option          default                 purpose
==========================================================
SLASH_PREFIX    /usr/local/slash        Location for
                                        installed files
INIT            /etc or /etc/rc.d       Location for init
                                        scripts
USER            nobody                  User to own files
GROUP           nobody                  Group to own files
CP              cp                      Name of or path to
                                        alternate `cp`
INSTALL         install                 Name of or path to
                                        alternate `install`
```
(USER and GROUP will also be changed later on a per-site basis, in step 6. while running install-slashsite.)

So, for example, you might type (although the default SLASH_PREFIX is strongly recommended):
```
make SLASH_PREFIX=/home/slash
make install SLASH_PREFIX=/home/slash
```
When done, a configuration file for Apache will be created at $SLASH_PREFIX/httpd/slash.conf. You can put its contents into your httpd.conf, or you can just Include it in your httpd.conf. You must do one or the other!

WARNING!

Please be aware that if you include $SLASH_PREFIX/slash.conf or $SLASH_PREFIX/sites/sitename/sitename.conf more than once, or if this file shares contents with directives in httpd.conf, that your Slash site WILL break. The directives in $SLASH_PREFIX/slash.conf should be run only ONCE in any any site context. Read through $SLASH_PREFIX/slash.conf to make sure it all looks proper.
Install your Slash site.

Go to your installation directory (by default, /usr/local/slash) and execute (where VIRTUAL_USER is the name of the virtual user given in the DBIx::Password distribution):
```
bin/install-slashsite -u VIRTUAL_USER
```
The program will prompt for answers to several configuration questions. Answer the questions. When done, another configuration file will be created at $SLASH_PREFIX/$SITENAME/$SITENAME.conf. You can put its contents unto your httpd.conf, or you can just Include it in your httpd.conf.

NOTE: Read the message printed at the end of running install_slashsite. Failure to pay attention here is another common reason we see for Slash installations not working.
Start it up.

After installation of the site is done, and Apache has been stopped and started (do NOT try to restart Apache, but do a full stop and start), run slashd. This should be done via the init script:
```
/etc/init.d/slash start
```
slashd is the daemon that runs routine maintenance on Slash sites, including sending out daily mailings, cleaning up the database, and updating stories. The init script above will start up an individual slashd daemon process process for each installed site.

INSTALLATION OPTIONS

Multiple Servers

You can, of course, have a separate database server from your Slash server. Further, you can have multiple web servers for one Slash site. Slashdot, for instance, has one primary server with all of the code (Apache, perl, etc.), and it runs slashd and NFS. Each web server then mounts the code read-only over NFS. Some notes:

Make sure the MySQL server allows the user to log in from each web server, and the NFS server.
Make sure, if you use the same httpd tree on all machines, that the httpd.conf is listening to the proper IP addresses. This can be done by putting all of the IP addresses in the conf file, or by having a separate Listen file on each machine. Similarly, make sure that each web server's logfiles unique to each machine, not written to the NFS volumes.

Virtual Hosts

Slash has support for virtual hosts, so you can have multiple Slash sites on one machine. Simply execute step 6 in the install process for each Slash site (after adding a new virtual user to DBIx::Password for each).

SSL

In Slash, there are two variables for the root URL of the site. absolutedir is the full URL, including protocol, while rootdir is the URL without protocol:

absolutedir     http://slashcode.com
rootdir         //slashcode.com

absolutedir is used only for creating external links to the site (such as in RSS files). rootdir is used for internal links; that way, you can use the same HTML pages for SSL and non-SSL. You don't have to do anything special to the code or preferences to allow it to work with SSL by itself, SSL and non-SSL together, or non-SSL by itself.

Non-Root

It is possible to install and run everything here without root.

It is not easy. If you don't know your flavor of unix intimately, we don't recommend trying this.

Describing the process for a non-root install would take up significant space and time, having to account for differences in various systems, and all the workarounds necessary for it to work. We don't support it, and we're not going to document it.

If you must have a non-root install, consult the various documentation for Apache, MySQL, and perl about running and installing without root access. Then, for Slash, you need to set the make variables PREFIX, SLASH_PREFIX, and INIT appropriately for your needs.

Note: Slash sites (or, more accurately, Apache + mod_perl and MySQL) take up a lot of system resources. It is not advisable for anyone to run Slash on any system, without the permission of the administrator of that system.

Separate Image Server

Those of you with infinite RAM will have no problems hosting as many Slash sites as you want on a single box running just Apache. Those whose RAM is limited may be able to keep your MaxClients down to a reasonable level to avoid going into swap, and still not lock clients out of your website, by using a separate webserver process to deliver your images.

This is possible with any website, of course, not just a Slash site, but because Slash's httpd clients all have mod_perl, a lot of perl modules, and a lot of templates all compiled into RAM, they are especially heavy. While serving an image may take only a few milliseconds, which would you rather have tied up on your computer for those milliseconds, 25 MB of RAM or 5 MB?

Slashdot, and some other Slash sites we're hosting, are currently using boa 0.94.14rc17 (http://www.boa.org/) for images. Boa is fast and has a small footprint. It's easy to build (./configure && make) but you have to install it yourself by copying the binary and mkdir'ing a little tree wherever you want it. We did roughly this. Your mileage may vary. This sets up an alternate server just for images on port 8080, and sets Slash's imagedir var to point to it. Your apache will still serve images at the old URLs if anyone requests them, but nobody will, because your site's pages will all point to boa:

# Install boa and set up its files.
cd /usr/local/src/boa-0.94.14rc17
./configure && make
mkdir /usr/local/boa
mkdir /usr/local/boa/bin
mkdir /usr/local/boa/htdocs
cp -a src/{boa,boa_indexer,webindex.pl} /usr/local/boa/bin/
ln -s /usr/local/slash/site/mysite/htdocs/images /usr/local/boa/htdocs/images.mysite.com
touch /usr/local/boa/htdocs/favicon.ico

# Set up and edit boa conf file.
cp examples/boa.conf /usr/local/boa/
# At this point we patched /usr/local/boa/boa.conf, changing
# Port to 8080, ServerName to www.mysite.com, DocumentRoot to
# /usr/local/boa/htdocs, and commenting out the DirectoryIndex,
# DirectoryMaker, Alias and ScriptAlias directives.

# Start boa.
/usr/local/boa/bin/boa

# In mysql client:
# UPDATE vars SET value='//www.mysite.com:8080/images.mysite.com' WHERE name='imagedir';
# UPDATE stories SET writestatus='dirty';

# Restart apache, slashd;  let slashd rewrite .shtml files both
# recent and archived.

You'll probably also want to create a script in your init.d and rcN.d directories so boa runs at startup along with apache.

UPGRADING

These upgrade procedures are still in testing. Please read them entirely before beginning. We are not responsible for any loss of data or functionality.

Slash 2.0 -> Slash 2.2

Slash 2.2 is a major upgrade from Slash 2.0. It takes a little bit of work to get it going.

BACK EVERYTHING UP ON THE EXISTING SITE.
Install Bundle::Slash. If you have done so previously, follow the instructions for removing the existing version of Bundle::Slash before proceeding.

Apply this patch to your installed Slash::Install module (probably easiest to hand-edit the file):

--- Install.pm~ Wed May  9 15:02:34 2001
+++ Install.pm  Fri Sep 28 12:44:41 2001
@@ -116,7 +116,7 @@
 sub writeTemplateFile {
        my($self, $filename, $template) = @_;
        open(FILE, '>' . $filename) or die "$! unable to open file $filename to write to";
-       for (keys %$template) {
+       for (qw(section description title page lang name template seclev)) {
                next if ($_ eq 'tpid');
                print FILE "__${_}__\n";
                $template->{$_} =~ s/\015\012/\n/g;

Run template-check on your site, and make a note of every change you've made to the standard templates. You will need to make those changes again, manually, later.

This is unfortunately unavoidable, because templates include code that changes significantly between releases. It is recommended that you compile your changes into a THEME so they may easily be updated and applied.
Stop Apache and slashd on the target machine(s).
Install Slash.

If installing on a different machine ...
1. Install slash 2.2 as normal. Do not yet run install-slashsite.
2. Make sure that from this machine, you can access not only the database used for this installation, but the one used for the old installation. You may wish to, instead of accessing that database directly if it on another machine, dumping it and adding it to your new database server under a different name.
3. Add a virtual user to DBIx::Password for the old installation.
If installing on the same machine ...
1. Create a new database for the new installation. You cannot use the same database for both installations.
2. Add a new virtual user to DBIx::Password for the new database, and update (and flush) MySQL privileges appropriately. You cannot use the same virtual user for both installations.
3. It is highly recommended that you move /usr/local/slash (or whatever your installation directory is) to a new location, such as /usr/local/slash-old, and install a clean slash 2.2 installation. However, this is not necessary to do; you may install slash 2.2 on top of the slash 2.0 installation.
  
  The reason to not move anything is that you can keep any customizations done (images, additional scripts and plugins, static files, etc.). The reason to move it is so that everything is clean. It is highly recommended that you move it, and then manually copy back the pieces you want.
4. In any event, either move the old directory, or don't, and then install slash 2.2 as normal. Do not yet run install-slashsite.
If you have plugins or themes from the old installation to install, copy them over now. Warning: some plugins and themes might need to be ported first. You may wish to deal with them later if they are not yet ported to slash 2.2.
Run install-slashsite. Use the new virtual user.
Copy over any files (images, FAQs, etc.) that need to be copied, if necessary.
Run update script, utils/slash2toslash2.2. Read its instructions!
Update templates.
Doublecheck Apache configs (httpd/slash.conf, site/sitename/sitename.conf). These configs have changed from the last version. Read the comments and set them up as desired.
Start Apache.
Start slashd.

Slash 2.2.x -> Slash 2.2.y

Read all of this section before doing any of it.

The first thing to do is to, as per the instructions below under INSTALLATION, unpack the latest distribution and run make and make install with the proper arguments.

Overwriting Changes

This process will overwrite any customizations of your installed modules, or customizations of the installed scripts in /usr/local/slash/themes/ and /usr/local/slash/plugins/ (for themes and plugins that come with Slash). If you ran install-slashsite with the default option of using symlinks, and made customizations to the originals instead of breaking the symlink and copying the file over, then this will overwrite your changes.

If you did modify the original instead of a copy, then break the symlink, copy over the original (as modified), and then continue. The original will be copied over by the new version, and your modified copy will remain intact.

Templates

With every update, there are changes to templates. But most people will modify their templates. A relatively simple way to see what has changed is to use template-tool and template-check. This procedure should help most users deal with the integration of new templates into an existing site (it will only work with the slashcode theme, but a simple modification to the code of template-check can fix that).

Dump

Use template-tool to dump your templates into an empty directory.

% mkdir templates
% cd templates
% template-tool -u VIRTUAL_USER -d

(Defaults to current directory.)

Compare

Use template-check to compare installed templates in /usr/local/slash/themes/slashcode/ and /usr/local/slash/plugins/ against the templates that have been dumped.

% template-check -u VIRTUAL_USER

(Defaults to current directory.)

This will use diff to show you the differences. You can either go into the templates with a text editor (in another window) and change the dumped ones by hand, edit them by hand in the Template Editor via the web browser, or take a note of every template you want to copy over your existing template.

After each directory of templates is done, hit "q" to continue to the next plugin/theme.

Sync

If you made changes by hand via the web, you are done. Otherwise, take the list of templates to update, and pass the full filenames to template-tool (this will either be the templates you modified by hand in the dump directory, or the unmodified ones in the installation directories). You might need to put each filename in quotes because of the ";" character in the filenames. This will overwrite your existing template with the new template.

% template-tool -u VIRTUAL_USER -s LIST

Slash 2.2.6 -> Slash CVS

Use the sql/mysql/upgrades file; see "VERSIONS", "CVS tags", below.

Slash 1.0 -> Slash 2.2

Please read the complete documentation of utils/slash1toslash2.2. It is a program that will convert your database from Slash 1.0 to a new Slash 2.2 database. The program documentation (which can be read with perldoc) details exactly what process it follows to do the conversion, so you can attempt to do it by hand if you prefer.

REQUIREMENTS

Software Requirements

Below, we list the main software components needed. The recommended version is noted, along with the earliest version that has been tested (or is expected) to work. The earliest versions are not necessarily supported, but should work. perl 5.6.0 is supported, but MySQL 3.22 is not.

perl

Version 5.6.1 (5.6.0). [NOTE: perl 5.6.0 may have some problems. 5.6.1 is recommended.]

http://www.cpan.org/

We believe everything works fine with perl 5.8.x, and have several small Slash installations on it, but we have not tested Unicode thoroughly, nor have we run Slashdot on it yet. If you're going with 5.8.x, we suggest 5.8.1 or later, as there are numerous small bugs in 5.8.0.

MySQL

Version 4.0.12 (3.23.42).

http://www.mysql.com/

Apache

Version 1.3.29 (1.3.6).

http://httpd.apache.org/

Do not use Apache 1.3.28. It has a nasty bug in it that causes Slash to talk to the web browser as though it is the database server.

mod_perl

Version 1.29 (1.21).

http://perl.apache.org/

Sendmail or other transport daemon

Refer to your OS distribution.

Perl module distributions

See http://search.cpan.org/ and http://www.cpan.org/ to get each module individually; however, we recommend you download them using the CPAN module. (See "INSTALLATION", item 4, "Install the Perl modules.")

The latest version of each module is recommended.

For Compress::Zlib, the zlib development library is required. For XML::Parser, the expat library is required. If they are not present on the system already, download and install them before installing the modules.

http://www.gzip.org/zlib/
http://sf.net/projects/expat/

On Debian Linux, try:

apt-get install zlib1g zlib1g-dev libexpat1 libexpat1-dev

The current list of required perl modules can be found in the Bundle/Slash.pm file.

Hardware Requirements

There are no specific hardware requirements.

Apache (with mod_perl) and MySQL both take up a lot of RAM. Running a complete system with 128MB might be possible, if you do some tuning of the configuration, but a practical minimum of 256MB is recommended, and you will be much happier with at least 1GB of RAM. See "INSTALLATION OPTIONS", "Separate Image Server" for tips on saving some RAM.

Disk space depends on how busy you expect the site to be. Slash keeps a small database -- even Slashdot.org's DB compresses down to under 2 GB. The disk files as installed are under 0.5 GB, and grow predictably as stories and comments are added (keep an eye on the site/foo/logs/ directory, too). A minimum of 1 GB of disk is recommended.

Necessary processor speed is also dependent on how busy the site is. Pentium 133 or equivalent might work, but a Pentium II/400 or better is recommended.

For the curious, Slashdot (as of September 2001) runs on nine machines: nine webservers (each is Pentium III/600, 1GB RAM, 9GB hard drive), one NFS server (600MHz PIII, 1GB RAM), and three database servers (quad 600MHz PIII, 4GB RAM). One database server is live, one is a replicated backup, and a third is for doing live searches and performance-intensive SELECTs by daemons etc.

However, this is certainly overkill for most sites (and possibly even overkill for Slashdot). slashcode.com runs on two web servers and one NFS/database server. Many sites can run fine on just one machine for everything (we use a minimum of two web server machines on every site for load balancing and redundancy).

VERSIONS

Each version of slash has a code name, and the files on CVS for that version are tagged with that name. The current release is always MAIN. The versioning scheme is as Linux and Perl are, revision.version.subversion. version is even for releases, and odd for development. The codename applies to the development version and subsequent release.

For example, 1.0.11 is a normal release, while 1.1.0 is the first development release for what will be the next release (either 1.2 or 2.0).

The CVS repository is tagged with version numbers, so to get release 1.0.3, use tag "v1_0_3_0". The last number (in this case a zero) will be incremented during development ("v1_0_3_1", "v1_0_3_2", etc.) until the next release.

Codenames

v1.0: beast
v2.0: bender
v2.2: fry

Security note

We are no longer releasing bugfixes, even for security, for the 1.0 or 2.0 versions, and do not recommend their use. If we become aware of security issues in the 2.2 tree, we will release another version. For this reason, if you are using any version of Slash in 2.2.x or earlier, we recommend you upgrade to the latest version of 2.2, which as of this writing (June 2003) is 2.2.6.

CVS tags

Our development of 2.3/2.4 has gone on exceptionally long without a tarball release of 2.3.0. Most Slash hosting sites are choosing to follow CVS instead of waiting, and we encourage this.

Installation of the latest CVS (as of June 2003) is almost identical to the installation of 2.2.

You probably do not want to use the very latest CVS, as the Slash developers are constantly updating it. If you wish to live on the edge, try a T_2_3_0_x tag ("Testing in 2.3.0 branch" -- one or two of these are added every week, Slashdot uses them, but they may have bugs). If you are content with recent code that the developers believe is likely to be free of major bugs, look for a recent R_2_3_0_x cvs tag ("Release candidates for 2.3.0").

To upgrade from 2.2.x to the CVS tree, you will need to follow the instructions in the sql/mysql/upgrades file. At the moment, these are just SQL commands you will need to issue, but read carefully because you may have to use judgement and issue command-line commands and so on. (We are working on a tool to automate this process.) Once you are upgraded to, or have installed, a given CVS tag, upgrading to later CVS tags is simply a matter of following along in that file -- we append as we go, and each T_* tag is clearly marked.

TROUBLESHOOTING COMMON INSTALLATION PROBLEMS

Here are some common reasons why Slash installations fail.

Failure to build mod_perl with PERL_MARK_WHERE=1 EVERYTHING=1.

We emphasize this in the instructions for a reason. Go back and reread the Installation Procedure, step 3.
Perl module installation troubles.

If you have a unix-like system with CPAN properly installed and no serious firewall issues, perl module installation will usually go pretty smoothly. Some modules will have overactive testing code; for example, if your system lacks nslookup, some of the net-related modules will complain and refuse to install themselves even though it isn't strictly speaking necessary. If you suspect overactive testing, force install Foo::Bar for the offending module and then try install Bundle::Slash again.

We list perl 5.6.0 as supported, but 5.6.1 is recommended. If you're having CPAN installation troubles, upgrading to the latest version will make life easier. Note that you'll want to recompile mod_perl/Apache after upgrading perl.
Multiple Perls installed.

If you have more than one binary file named perl, trouble awaits. It's OK to have a /usr/bin/perl5.00503 even after installing 5.6.1, but if your /usr/bin/perl is a different version from /usr/local/bin/perl, you may be in for a world of hurt.
httpd.conf errors.

After you install-slashsite, you're told that you probably want to add Include /usr/local/slash/httpd/slash.conf to its httpd.conf. Note that that file Include's your site-specific conf file at /usr/local/slash/site/sitename/sitename.conf. One way or another those site-specific directives have to be processed by Apache.

Are you doing virtual hosting? Make sure you've set it up correctly.
Database authentication issues.

For each dynamic page your Slash site delivers, an Apache httpd child needs to connect to your MySQL server. There's a chain of access to get from Apache to MySQL and a number of places where it can break:
- The Apache child httpd process needs to have read access to your DBIx/Password.pm module file. That process is probably running as "nobody:nobody" (or similar). If you don't know where DBIx/Password.pm was installed, try:
  
  # perl -MDBIx::Password -le 'print $INC{"DBIx/Password.pm"}'
  
  If that fails, it's probably not installed; check also
  
  # locate DBIx/Password.pm | grep perl
  
  Make sure the module is installed and that "nobody:nobody" can read its .pm file. If you've sharing that file over the network, did you set up ownership correctly?
  
  (If you are concerned about security on a multiuser system, first, don't let people on your system you don't trust, and second, you may wish to chmod DBIx/Password.pm 750, give it a group, and set Apache to run with that group.)
- The DBIx/Password.pm file needs to be correctly configured. Open it up with a text editor and make sure $virtual1 contains an entry for your Slash virtual user that is correct in every respect: driver, (MySQL) username, database, password, host, and connect string. These are the values you typed in when you installed the module but maybe you made a typo.
  
  If you have only one machine for your whole setup, host can be "localhost". Otherwise use an IP number.
- Network connectivity.
  
  Can the Apache machine connect to the MySQL machine?
- MySQL permissions.
  
  The username field in your DBIx/Password.pm file refers to a MySQL user which you set up in step 1 of the Installation Procedure. Make sure this user has permission to connect to the Slash site's database you also set up in step 1 (and check it from the Apache machine over the network too). If you don't fully understand MySQL permissions, don't guess; start your reading here:
  
  http://www.mysql.com/documentation/mysql/bychapter/manual_MySQL_Database_Administration.html#Privilege_system
- mod_gzip
  
  Are you finding that POST operations fail? Have you compiled in mod_gzip? mod_gzip 1.3.19.1a doesn't handle incoming POST very well, with the result that our User.pm handler() gets called twice, and the second time through, there's no more data on STDIN, so your form is empty. We use this patch to make it ignore POSTs:
```
--- mod_gzip_BROKEN_FOR_POST.c  2003-09-26 14:26:36.000000000 -0700
+++ mod_gzip.c                  2003-10-06 11:39:45.000000000 -0700
@@ -2155,12 +2155,15 @@
     ap_table_setn( r->notes,"mod_gzip_result",ap_pstrdup(r->pool,"DECLINED:UNHANDLED_REDIR"));
    }
  else
    {
     ap_table_setn( r->notes,"mod_gzip_result",ap_pstrdup(r->pool,"DECLINED:INIT1"));
    }
+   if ( r->method_number == M_POST ) {
+       return DECLINED;
+   }

  ap_table_setn( r->notes,"mod_gzip_input_size", ap_pstrdup(r->pool,"0"));
  ap_table_setn( r->notes,"mod_gzip_output_size",ap_pstrdup(r->pool,"0"));
  ap_table_setn( r->notes,"mod_gzip_compression_ratio",ap_pstrdup(r->pool,"0"));

  #endif
```
  Or just use mod_gzip 1.3.26.1a and omit POST from the list of methods it handles, in your httpd.conf:
```
mod_gzip_handle_methods GET
```
Make sure you don't confuse the different types of "users":
- Apache user -- a unix system user account, e.g. "nobody";
- DBIx::Password virtual user -- SlashVirtualUser directive;
- MySQL user -- DBIx::Password virtual user field, points to a database user.
If slashd doesn't seem to be working, check its log and make sure it has permission to write its files. It is probably running as your Apache user "nobody", and if that user doesn't have write permission to your web directories and/or .shtml and .rss files and so on, slashd's current behavior is to log an error and die. (If you want to make slashd run as a different unix system user, edit the second field in /usr/local/slash/slash.sites.)

If you've doublechecked all this, you're sure you followed the directions, and it still doesn't work, stop in IRC #slash on irc.slashcode.com and ask your question. Someone there may know the answer.

If you are trying to install Slash from someone else's package, maybe a BSD package, or an RPM that someone built, or by a Debian apt-get command -- good luck to you, we hope it goes well, we love packages, they're great when they work. But if installation fails, complain to the package maintainers, not us. For those who download our tarball and follow our instructions carefully, installation should go smoothly.

UNINSTALLING

If you want to uninstall a site, there are two steps you must follow:

Stop slashd with /etc/init.d/slash stop (/etc/rc.d/init.d/slash stop for Red Hat systems). Then edit /usr/local/slash/slash.sites to remove the line referencing the site you wish to uninstall. Then restart slashd with /etc/init.d/slash start.
Edit your Apache httpd.conf file so that the directives for the site's VirtualHost are not included. If you did the standard install, that file probably Includes /usr/local/slash/httpd/slash.conf, which Includes /usr/local/slash/yoursitename/yoursitename.conf, so you'll want to delete or comment out the Include line in the file /usr/local/slash/httpd/slash.conf. Restart Apache with /usr/local/apache/bin/apachectl stop ; sleep 10 ; /usr/local/apache/bin/apachectl start.

There are also five optional steps you may follow:

3.

Back up your site's database, if it has anything you care about: mysqldump -umysqlusername -p sitedatabasename > /some/dir/sitedb.sql.

4.

Drop your site's database: echo DROP DATABASE sitedatabasename | mysql -umysqlusername -p.

5.

Remove the virtual user for your site's database from the DBIx::Password file, whose location you can probably find with:

# perl -MDBIx::Password -le 'print $INC{"DBIx/Password.pm"}'

6.

Back up your site's html documents, if you care about any of them: cp -pvR /usr/local/slash/site/yoursitename/htdocs /some/dir/htdocs.

7.

Delete your site's directory tree: rm -rf /usr/local/slash/site/yoursitename.

VERSION

$Id$

POD ERRORS

Hey! The above document had some coding errors, which are explained below:

Around line 1292:: Expected text after =item, not a number
Around line 1297:: Expected text after =item, not a number
Around line 1304:: Expected text after =item, not a number
Around line 1309:: Expected text after =item, not a number

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

INSTALL.pod

INSTALL.pod

NAME

SYNOPSIS

Which version should I use?

Important Note

INSTALLATION

Installation Notes

Installation Procedure

INSTALLATION OPTIONS

Multiple Servers

Virtual Hosts

SSL

Non-Root

Separate Image Server

UPGRADING

Slash 2.0 -> Slash 2.2

Slash 2.2.x -> Slash 2.2.y

Slash 2.2.6 -> Slash CVS

Slash 1.0 -> Slash 2.2

REQUIREMENTS

Software Requirements

Hardware Requirements

VERSIONS

Codenames

Security note

CVS tags

TROUBLESHOOTING COMMON INSTALLATION PROBLEMS

UNINSTALLING

VERSION

POD ERRORS

Files

INSTALL.pod

Latest commit

History

INSTALL.pod

File metadata and controls

NAME

SYNOPSIS

Which version should I use?

Important Note

INSTALLATION

Installation Notes

Installation Procedure

INSTALLATION OPTIONS

Multiple Servers

Virtual Hosts

SSL

Non-Root

Separate Image Server

UPGRADING

Slash 2.0 -> Slash 2.2

Slash 2.2.x -> Slash 2.2.y

Slash 2.2.6 -> Slash CVS

Slash 1.0 -> Slash 2.2

REQUIREMENTS

Software Requirements

Hardware Requirements

VERSIONS

Codenames

Security note

CVS tags

TROUBLESHOOTING COMMON INSTALLATION PROBLEMS

UNINSTALLING

VERSION

POD ERRORS