Notes installing a new SBEAMS site
$Id: sbeams.installnotes 5297 2007-03-23 18:30:39Z sbeams $
This document describes how to install a new SBEAMS site.
Terms:
- SBEAMS: Systems Biology Experiment Analysis Management System
- SBEAMS site: an independent installation of SBEAMS with its own core tables
- SBEAMS instance: a version of source code, often for development, which
shares the core tables with other instances
If you find errors in these installation notes, please report them.
If you have suggestions for making some part of this clearer, please
send them along. It is recommended that you read this whole document
before delving into it. It's not simple. Database installations rarely
are. Some of these steps could be automated, but it is probably
helpful to do them manually to learn how the systems is set up and
development would proceed.
Typical installation time of this module for an experienced user is 50 minutes.
It is recommended that you read this entire document and install the software
manually by following the instructions in sections 1-9 below. However, there
is an automated installation script, described in Appendix, that will allow
the installation of a basic system with a minimum of configuration.
-------------------------------------------------------------------------------
1) Software Dependencies
The following software programs are required to run SBEAMS:
- Apache or similar web server software
- PHP (There are a few PHP pages, but nothing elaborate. As long as basic
PHP works with the web server, this should be fine)
- Perl ( 5.0 or greater required, recommend 5.8 or greater). SBEAMS
scripts assume perl will be located at /usr/local/bin/perl; see Appendix 1
for more details
- A relational database engine. This software was developed with SQL
Server. Products from either Microsoft or Sybase should work right away.
The Core, BioLink, and Microarray modules are known to work with mysql
(v5.x or above), and others are being actively ported.
Attempts has been made to make this software operable with other engines
such as Oracle, MySQL (5.0 minimum), and PostgreSQL, however some further
development is required to achieve this fully. If you do so, please
contribute your changes.
The following Perl Modules often not found on a standard UNIX/Linux
setup are required before installation can begin. Version numbers are
for what is used for development; older or newer versions may work:
Authen::Smb (For Windows Domain Authentication instead of UNIX auth)
Crypt::CBC
Crypt::IDEA
DBD-Sybase-1.06 (assuming Sybase or MS SQL Server is back end)
DBD-???? (if you are using a different type of back end RDBMS)
DBI
GD
GDGraph-XY-0.92
GDTextUtil-0.84
Regexp::Common
Time::HiRes
XML::Parser
XML::XPath
Two specially modified modules must be obtained at
http://www.sbeams.org/download/:
Data-ShowTable-3.3b
GDGraph-1.35a
Some versions of perl may require the following module be installed
URI
Additional common Perl modules are needed, but may not be on your system.
Should really write a little dependency checker program. FIXME.
---------------
The following non-Perl software is required:
FreeTDS (required by DBD-Sybase only. Allows UNIX -> MSSQL/Sybase)
libgd (required by GD Perl modules)
---------------
Certain modules (Proteomics) also require the following Perl modules:
Proteomics:
PDL
PDL::Graphics::PGPLOT
##### MySQL ###############
#
# DBD::mysql NOTE: to get 'make test' to run, may need to create
# symlink from /var/lib/mysql/mysql.sock to
# /tmp/mysql.sock
#
###########################
-------------------------------------------------------------------------------
2) Installation Location and unix users/groups
SBEAMS is designed to live entirely in the "htdocs" area of your Apache
web server. For the remainder of this installation, it will be assumed
that your installation is configured as follows; compensate for your
specific setup:
servername: db
DocumentRoot: /local/www/html
Primary location: directly located in DocumentRoot,
/local/www/html/sbeams --> http:/db/sbeams/
Development location: In a dev1 tree starting in the DocumentRoot,
/local/www/html/dev1/sbeams -> http:/db/dev1/sbeams/
There is typically significant ongoing development in an SBEAMS environment
and it is recommended that all development work be done in a devN area
which is then sync'ed with the primary area when changes are tested. This
is so users can continue to use the stable version until new features have
passed testing. Please note that directory names for dev areas must
conform to the following standard: "devN" or "devCC", where N is a digit
[0-9], and C is a letter [a-z,A-Z].
A Discussion of File Ownerships:
At a site with several developers, it is recommended that a generic
software maintenance account be created, who owns the production code
area and that each individual developer owns his or her development area.
For example,
/local/www/html/sbeams/ owned by the sbeams account
/local/www/html/dev1/sbeams/ owned by the user1 account
/local/www/html/dev2/sbeams/ owned by the user2 account
Since the web server must read/write data within this hierarchy, you should
create an 'sbeams' unix group, and make sure the sbeams, user1, user2, and
apache (or whichever user the web server runs as; see below) users all belong
to this group. All of the sbeams directories and their contents should be
owned by this group, including the sbeamcommon directory defined below. To
change the group of a file or folder, you can use the chgrp command:
chgrp -R sbeams mydirectory
Where the -R flag causes the command to recursively descend the specified
directory. If you are creating directories as root, you can also specify
the group while you are changing the ownership with chown:
chown -R apache:sbeams mydirectory
This assumes you are setting the user to apache and the group to sbeams, the -R
flag is working as stated above.
Developers need only log into the sbeams account to "roll out" code
to production (from SVN is recommended). All development is done by each
user in their area. Finished changes are checked into SVN and rolled out
to production using the sbeams account. Smaller sites with one developer
may choose to have everything owned by one person. It is not recommended
that the code be owned by root. Since you are the installer, your
account is what is referred to above as "user1".
-------------------------------------------------------------------------------
3) Configure Apache
(root access probably required)
Include in Apache's httpd.conf file the following execution permissions:
#------
deny from all
Options ExecCGI
SetHandler cgi-script
deny from all
deny from all
Options ExecCGI
SetHandler cgi-script
deny from all
deny from all
#------
Restart the Apache server, perhaps with something like:
/etc/rc.d/init.d/httpd restart
or:
/etc/init.d/apache2 restart
-------------------------------------------------------------------------------
4) Obtain and (optionally) unpack SBEAMS source files.
Do as much of this as possible as a regular user account, i.e. yours. These
notes assume an apache document root of /local/www/html.
# Set up HTMLROOT environment variable to point to the base html directory
# tcsh syntax:
setenv HTMLROOT /local/www/html
# *OR* bash syntax:
export HTMLROOT=/local/www/html
# Installation into your apache document root requires the ability to write to
# the html root folder. Substitute your username here for 'user1'. You will
# likely need root access (logging in as root or prefixing the command with 'sudo')
# to chmod this directory. Once sections 4 and 6 are complete, you may want to
# chmod this directory back to its previous permissions.
chmod a+w $HTMLROOT
cd $HTMLROOT
#####
# There are two ways to acquire the source code, now that the SBEAMS subversion
# repository is online. You can download a distribution tar archive and follow
# these instructions:
tar -zxvf ~/sbeams-0.22.0.tar.gz
# or, you can set up sbeams directly from subversion, which will make updating
# the system much easier. (This will require that you have a subversion client
# installed on the system):
svn checkout http://www.sbeams.org/svn/sbeams/trunk/sbeams
# For more information on subversion, or to obtain the client software, you can
# check the following site:
http://subversion.tigris.org/
-------------------------------------------------------------------------------
5) Create database instance and users
SBEAMS is being developed on SQL Server and should work quite easily
with either the Sybase or Microsoft versions. Most modules also work
with MySQL (version 5.x or above). Attempts are being made
to make it work equally well with DB2, Oracle, and PostgreSQL;
it's pretty close to working well, but this is not finished so please
contribute to this effort if you try different RDBMS engines.
(You can skip the following 3 steps if you already have a database and login.
No need to create "sbeams" dB. Use existing login/pwd for both accounts.)
- First, create a database called 'sbeams' or 'sbeamsdev' or similar
(whatever was referred to in the SBEAMS.conf DBPREFIX{Core} setting). If you
wish each module to exist in its own database, you must create those as well.
- Within it(them), create users "sbeams" and "sbeamsro" as a read/write
account and a read-only account, respectively.
- You will also need to create an administration account, "sbeamsadmin".
This account should be the one used to make changes to the schema, i.e.
create, update, and drop tables and constraints.
See Appendix C for information on the MySQL gui console or terminal.
- set your environment variable to be the sbeams base directory
( mostly commonly this is $HTMLROOT/sbeams)
-------------------------------------------------------------------------------
Sections 6-13 can be handled by quick start script, see Appendix B near the
end of this document.
-------------------------------------------------------------------------------
6) Create common directory structure (quickstart)
Create a sbeamscommon directory for sharing dynamic files between
different instances and create symlinks:
# This requires ownership of the base directory (as described in section 4)
cd $HTMLROOT
mkdir sbeamscommon
(for now, just create the directories for stuff to live in right here, but
it may be a good idea to make a sym link to another location or partition
since there could eventually be large amounts of data here!!!)
cd sbeamscommon
mkdir images images/tmp
mkdir lib lib/conf lib/conf/Core
touch lib/conf/Core/AvailableModules.conf
chmod a+w images/tmp
mkdir var var/resultsets var/logs var/upload var/sessions
chmod g+w var/*
(The previous command assumes that the owner of the web server process
e.g. "apache" is a member of the same group as the account with which
sbeams is being installed. Please adjust accordingly, or do a+w
instead.)
cd $HTMLROOT/sbeams
ln -s ../includes doc/includes
ln -s $HTMLROOT/sbeamscommon/var
ln -s $HTMLROOT/sbeamscommon/images/tmp images/tmp
cp lib/conf/SBEAMS.conf.template $HTMLROOT/sbeamscommon/lib/conf/SBEAMS.conf
ln -s $HTMLROOT/sbeamscommon/lib/conf/SBEAMS.conf lib/conf/SBEAMS.conf
ln -s $HTMLROOT/sbeamscommon/lib/conf/Core/AvailableModules.conf lib/conf/Core/AvailableModules.conf
For now, duplicate the main site to dev1, but eventually when there is
parallel development and production usage, these should be separate trees
kept in sync with SVN or some other such tool.
mkdir $HTMLROOT/dev1
cd $HTMLROOT/dev1
cp -a ../sbeams .
cd $HTMLROOT
chgrp -R sbeams dev1 sbeams sbeamscommon
-------------------------------------------------------------------------------
7) Edit the SBEAMS Configuration files (quickstart*)
This is an important step! If you do not set the configurations for your
site properly, you will have trouble later!
# Set the base sbeams directory in the dev1 branch. Working in the dev1
# area is a good habit.
setenv SBEAMS /local/www/html/dev1/sbeams
cd $SBEAMS/lib/conf
Almost all of the scripts used during the installation of sbeams reside in
the directory $SBEAMS/lib/scripts/Core. If you prefer, you can add this
directory to your $PATH variable, and then invoke the script without explicitly
defining the path (either relative or absolute). This document will continue
to reference the path for clarity. To append this to your PATH in bash:
export PATH=$PATH:$SBEAMS/lib/scripts/Core
The passwords needed to connect to the database are stored encrypted in the
SBEAMS.conf file. You will need to generate the encrypted versions at this
point. Run the encryption script as follows:
note that all SBEAMS scripts use /usr/local/bin/perl. If you do not
have a /usr/local/bin/perl, it is highly recommended that you create
a sym link from /usr/local/bin/perl to your actual perl, e.g.:
ln -s /usr/bin/perl /usr/local/bin/perl. If this is not practical given the
way your system is configured, see troubleshooting guide for suggestions on
systematically changing the path to perl for your scripts.
$SBEAMS/lib/scripts/Core/encryptDbPasswd.pl -p DB_PASSWORD -c SBEAMS.conf
Where DB_PASSWORD is the password to encrypt, and CONF_FILE is the location
of the SBEAMS.conf file that you want to use. The script will print out a
hexadecimal string that you can place in the SBEAMS.conf file as per below.
You will need passwords for the normal and read_only accounts for this
installation (by default sbeams and sbeamsro).
edit SBEAMS.conf
Important changes:
- Be sure to change WWW_UID to reflect the UID of the account running the
Apache web server. This might be accounts like 'apache', 'nobody',
'httpd', etc. The easiest way to find the id of the user is the id command.
Assuming the user is apache, try:
id apache
The first part of the printout is uid=somenumber, this is the uid. An
alternative method for finding this information is:
egrep apache /etc/passwd
The number after the first colon is the WWW_UID. If you don't even know
which user the web server is running as, the value is set in http.conf, or
you if the server is running you can find it by looking at the process table:
ps aux | grep httpd
or
ps -ef | egrep "apache|httpd|nobody|www"
Note that there will also very likely be one process running as root; this is
*not* the user you want!
- Change the CRYPT_KEY to some random strings for your site
- Change HOSTNAME to reflect the web server's name. If the site is in
an Apache virtual server, use the virtual server name
- Change DBADMIN to reflect your environment. The DBADMIN
name should reflect your real name like John Smith
- You may ignore CYTOSCAPE_URL for first-time installations
- Change the DB_* settings to reflect the default RDBMS on which the SBEAMS
databases will reside and the accounts that will access them. For DB_PASS
and DB_RO_PASS, use the encrypted versions generated above.
- Uncomment the DB_DRIVER that matches your RDBMS. MS SQL Server uses the
Sybase driver. Do not alter the DB_DRIVER values unless you know what
you're doing!! Set the DB_TYPE to reflect your RDBMS.
- Uncomment the DB_TYPE to match your RDBMS. Do not change the spelling.
- Change DBPREFIX{*} to reflect the absolute locations of your tables. For
RDBMS systems that use schemas or users, DBPREFIX{Core} will likely be
something like "sbeams.dbo." or "sbeams.Core." while with RDBMSs that do not
support such features (like MySQL), use just "sbeams.". The trailing
period is probably necessary except in rare cases. Most table name
references will be prefixed with these strings. You must set values for the
Core and BioLink plus whichever module(s) you wish to install. The others do
not need to be set to real values until you wish to set up one of those
modules, although you will need to leave in some default definition to avoid
errors.
- Set RAW_DATA_DIR{*} to a directory location where data products
related to a given module are located. For example, you might store
your Proteomics SEQUEST searches in /data3/proteomics/archive or similar.
If you're not sure about this yet, you can ignore for now.
- Below this are sections for the individual instances for your site.
You probably only need to change the PHYSICAL_BASE_DIR and UPLOAD_DIR
sections. Set PHYSICAL_BASE_DIR to the base dir of each sbeams installation,
for the main site this would be /local/www/html/sbeams (making assumptions as
above); for the dev1 site specified above this would be the value of $SBEAMS
env variable, or /local/www/html/dev1/sbeams.
Set the UPLOAD_DIR to a location where uploaded data files may be stored.
As noted in the SBEAMS.conf file itself, this can either be an absolute path
or can be specified relative to the PHYSICAL_BASE_DIR. This directory was
created above in the sbeamscommon directory, and should work with the default
setting. Note that the web server must read and write these directories.
- Note that you can override all of the settings in the [default] section
(including DB_SERVER, DB_PREFIX{*}, etc.) to set certain dev instances
to point to different locations. For example, dev2 might point to a
completely different RDBMS server or different databases for major
development, while dev1 might point to all the live databases for
final testing, or one dev instance may use the sbeams core database
but point to a different database for one of the modules (for
testing), etc.
This should allow for a fairly flexible development and production
environment.
-------------------------------------------------------------------------------
8) build and populate database schema (quickstart)
- Generate the appropriate schema for your type(s) of database as follows,
using the generate_schema.pl script. You can see the usage notes for this
script by invoking the command without any arguments.
(logged in as your account ("user1" above))
set dbtype=mssql #### Set to your RDBMS type: mssql, mysql, oracle, etc.
cd $SBEAMS/lib/scripts/Core
You will often need to define a prefix for the database you are going to build
the schema in. In this example, we assume a database of sbeams and a default
schema user of dbo, and use the mssql syntax. This yields a dbprefix of
'sbeams.dbo'. This corresponds to the DBPREFIX{Core} setting in SBEAMS.conf.
When using generate schema you can either specify a module with --module, in
which case the value defined in the SBEAMS.conf file is used, or else you can
explicity specify a prefix with --dbprefix.
./generate_schema.pl \
--dbprefix dbo. \
--table_prop ../../conf/Core/Core_table_property.txt \
--table_col ../../conf/Core/Core_table_column.txt \
--schema_file ../../sql/Core/Core \
--module Core \
--destination_type $dbtype
##### MySQL ###############
#
# In SBEAMS.conf, set DBPREFIX{Core} to 'sbeams.' or whatever the
# database was named when it was created. Note there is no 'dbo.'
# prefix, but there is a period following the name. This same name
# should be specified at DBPREFIX for all other modules which are
# subsequently installed (e.g. BioLink, Proteomics).
#
# To generate a schema file appropriate for MySQL, issue the command:
#
# ./generate_schema.pl \
# --table_prop ../../conf/Core/Core_table_property.txt \
# --table_col ../../conf/Core/Core_table_column.txt \
# --schema_file ../../sql/Core/Core \
# --module Core \
# --destination_type mysql
#
###########################
- You must also install and build the BioLink module, please see the install
notes for that module for details.
- Verify that the SQL CREATE and DROP statements have been correctly
generated in $SBEAMS/lib/sql/Core/
- Edit the bottom of the $SBEAMS/lib/sql/Core/Core_POPULATE.sql file
to include entries for *you* and *your* local username on the SBEAMS
server. Give yourself an encrypted temporary password in the SQL
statements, generated as described the following paragraph.
A Discussion of Passwords:
There are four possibilities for SBEAMS passwords. The preferred
method for larger sites is to create SBEAMS usernames that match NIS
accounts or Windows domain accounts. If there exists an SBEAMS
account with a NULL password, the authenticator attempts to run
/bin/ypmatch passwd to try to match a NIS password. If this does not
produce success, then the supplied Windows domain account is tested.
Although not currently fully coded, it would be possible to use local
UNIX/Linux account passwords; however, this may be severely hampered
by the fact that most modern UNIX/Linux systems use /etc/shadow files
that cannot be read by normal users to hold the encrypted passwords.
There are possible workarounds, but they are not part of the
distribution. The final possibility is to set a password manually in
the SBEAMS tables. Only UNIX crypted passwords should be placed in
the tables, never plain passwords. This may be the best solution for
small sites with only a few users. You can create encrypted passwords
with the $SBEAMS/lib/scripts/Core/crypt.pl
A Discussion of the 'admin' account:
You should never use the admin account. At one time, logging into the
admin account seemed like a good idea, but it no longer is. Rather,
persons who will administer the site should be given Administrator
privileges over the necessary data. The benefit here is that all
changes are tracked as the user who performed them and situations
where multiple people have "admin" account access and thus changes
cannot be traced to a person are avoided. The admin account remains
as the owner of various records but other Administrators can modify
those records if necessary, so logging in as admin is discouraged.
- Execute the statements below to create and populate the database with some
bare bones data and constraints:
cd $SBEAMS/lib/sql/Core
$SBEAMS/lib/scripts/Core/runsql.pl -u sbeamsadmin -s Core_CREATETABLES.mssql -delim GO
$SBEAMS/lib/scripts/Core/runsql.pl -u sbeamsadmin -s Core_POPULATE.sql
$SBEAMS/lib/scripts/Core/runsql.pl -u sbeamsadmin -s Core_CREATECONSTRAINTS.mssql -delim GO
$SBEAMS/lib/scripts/Core/runsql.pl -u sbeamsadmin -s Core_CREATE_MANUAL_CONSTRAINTS.sql -delim GO
##### MySQL ###############
#
# Edit Core_CREATE_MANUAL_CONSTRAINTS.sql to remove the dbo. in front of user_login
#
# Execute these commands instead of the ones given above for MS SQL:
#
# $SBEAMS/lib/scripts/Core/runsql.pl -u sbeamsadmin -s Core_CREATETABLES.mysql
# $SBEAMS/lib/scripts/Core/runsql.pl -u sbeamsadmin -s Core_POPULATE.sql
# $SBEAMS/lib/scripts/Core/runsql.pl -u sbeamsadmin -s Core_CREATECONSTRAINTS.mysql
# $SBEAMS/lib/scripts/Core/runsql.pl -u sbeamsadmin -s Core_CREATE_MANUAL_CONSTRAINTS.sql
#
###########################
Note that you will be prompted for the sbeamsadmin password; you can also
choose to specify it on the command-line with the -p flag, which is more
convenient but somewhat less secure. Also, the second command requires that
you specify the statement delimiter (semicolon). For help with this (and most
other) sbeams scripts, simply invoke it without any arguments and it will
print out some usage help text.
You should now be able to log in via the web interface, either as the
"admin" account (if you set a password above; not recommended) or with
your user account you added to Core_POPULATE.sql. Test your installation
by pointing a browser to the proper location like:
http://db.localdomain.org/dev1/sbeams/
You should see a welcome page with a link inviting a login. Click there
and you should be challenged with a login page. Once you login,
don't try to do anything else with the web interface yet; we're not
fully configured yet!
If this doesn't work. Do not proceed, debug first.
If your password is no accepted, reread the password section above and
try to determine the reason for failure.
-------------------------------------------------------------------------------
9) Populate the driver tables (quickstart)
Logged in as your account (that has a matching SBEAMS account configured
in the Core_POPULATE.sql file), run the following:
cd $SBEAMS/lib/scripts/Core
set CONFDIR = "../../conf"
./update_driver_tables.pl $CONFDIR/Core/Core_table_property.txt
./update_driver_tables.pl $CONFDIR/Core/Core_table_column.txt
If this doesn't work. Do not proceed, debug first.
Now that the Core driver tables are loaded, you should be able to
go to the web site again and click on the "Admin" link at the bottom of
the left Nav Bar and explore the tables. Do not try to run any of the
individual modules yet; they are not configured.
If this doesn't work. Do not proceed, debug first.
NOTE: You will potentially need to re-run this step every time either
of these files is updated (Core_table_property.txt and _column.txt)
-------------------------------------------------------------------------------
10) Populate core database tables (quickstart)
- Organism table:
cd $SBEAMS/lib/refdata/Core
../../scripts/Core/DataImport.pl --source_file organism.xml
If this doesn't work. Do not proceed, debug first.
Enable the "Tools" module, which is not really a module, but an extension
to the Core:
$SBEAMS/lib/scripts/Core/addModule.pl Tools
-------------------------------------------------------------------------------
11) Build the POD docs (quickstart)
cd $SBEAMS/doc/POD
./createPOD.csh
-------------------------------------------------------------------------------
12) Install required Modules (quickstart)
Follow the install notes for any required modules, currently BioLink.
SBEAMS/doc/BioLink/BioLink.installnotes
-------------------------------------------------------------------------------
13) Install Individual Modules (quickstart*)
Now follow the individual module install notes, e.g.:
$SBEAMS/doc/Proteomics/Proteomics.installnotes
$SBEAMS/doc/BioLink/GeneOntology.installnotes
*For supported modules, must be specified when running
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
============================
Appendix A: Troubleshooting.
============================
1) All of the setup and cgi scripts use /usr/local/bin/perl as the interpreter.
If your system doesn't have perl installed there, you have can either create a
symbolic link from your version of perl to /usr/local/bin, you can install a
new version of perl at that location, or you can modify the #! lines of any
affected files. If the following commands are run from the base of your sbeams
installation they will change the perl from /usr/local/bin/perl to /usr/bin/perl:
find . -name '*.pl' -exec perl -pi -e 's/(\/usr\/)local\/(bin\/perl)/$1$2/' {} \;
find . -name '*.cgi' -exec perl -pi -e 's/(\/usr\/)local\/(bin\/perl)/$1$2/' {} \;
2) As of version 1.70, there may be a problem if the UID of the user executing the
script is the same as the WWW_UID. If your system requires this setting,
( generally because the web server is being run by a non-privileged user) it
is suggested you temporarily set the WWW_UID to another value while running the
setup scripts; once run, you can restore the WWW_UID setting. If the UIDs are
not the same this is not an issue.
3) The --schema_file argument of generate_schema.pl is both a path and a prefix for
naming the various files created. If you simply give a path, you will see files such
as _CREATETABLES.mssql instead of Module_CREATETABLES.mssql. If the command is executed
from the destination directory, need only define filename prefix.
========================
Appendix B: Quick Start.
========================
In order to make the initial installation easier, there is a perl script that
will handled the tasks described in sections 6-13 above. It makes calls to
many of the command line tools, and should allow a user to get a system up and
running very quickly. Note that some initial preparation is needed, and some
further customization (i.e. editing of the SBEAMS.conf file) will likely be
desired after using this method.
Prerequisites:
-Install needed perl modules (section 1)
-Create sbeams group and make web server and installer users members(section 2)
-Install and configure apache web server (section 3)
-Obtain SBEAMS source as a tar.gz file or from subversion repository (section 4)
-Create a database instance in a supported rdbms, along with a db user with the
ability to create database objects (section 5)
-Edit the minimal configuration file, located at /lib/conf/Core/install_sbeams.config,
relative to the sbeams directory at the base of the source distribution (known
as $SBEAMS or $HTMLROOT/sbeams).
Once this is done, you are ready to run the install script:
$SBEAMS/lib/scripts/Core/install_sbeams.pl
It is recommended that it be run once with the -u flag, which will cause it to
print a usage summary. The script will perform the following tasks:
-Verify that the needed perl modules are installed
-Write the minimal config values to the actual configuration file, SBEAMS.conf
-Build the sbeamscommon infrastructure, with needed directories and sym links
-Test the connection to the database using the settings provided
-Run the schema generation scripts to generate DDL files appropriate for the
configured database type
-Run the SQL installer to build the schema objects as per the DDL files
-Populate the database with the initial configuration data
-Run the directory building and schema creation scripts for any supported
modules specified on the command line (see usage).
Note that you will need to run the script with a -f flag as sbeamscommon
doesn't exist if you got here after steps 1-5 only.
Here is an example use of the command:
$SBEAMS/lib/scripts/Core/install_sbeams.pl -f -m PeptideAtlas -m Proteomics -c $SBEAMS/lib/conf/Core/sbeams.config
==============================
Appendix C: MySQL
==============================
******** Can use MySQL from command line terminal ***************
--log in as root or someone with mysql insert privileges
mysql --user=root mysql
-- create sbeams database
mysql> create database sbeams;
mysql> use mysql;
-- create users sbeamsadmin, sbeams, and sbeamsro
mysql> grant all privileges on sbeams.* to 'sbeamsadmin'@'%'
identified by 'password' with grant option;
mysql> grant select,create,insert on sbeams.* to 'sbeams'@'%' identified by 'password' ;
mysql> grant select on sbeams.* to 'sbeamsro'@'%' identified by 'password' ;
mysql> flush privileges;
mysql> exit;
******** OR USE MySQL GUI ***************
The above steps to create the database, user accounts, and passwords
are most conveniently done using MySQL Administrator, a GUI admin
tool available from MySQL. See separate document on installing MySQL
5.0 server for details on installing MySQL Administrator.
After user accounts are created, the password for each account must
be reset to the old-style 16-byte encryption hash, since there is
no guarantee that clients connecting to the database will understand
the newer password hashing mechanism. From a shell, invoke the
mysql monitor, and issue this command for each account:
SET PASSWORD FOR @ = OLD_PASSWORD( );