Source Forge Installation on Mandrake 7.2
Author: Yves Bardout
Date created : Last modified : July 31st 2001
I have installed a SF2.5 release on a single host Pentium II with a linux
Mandrake7.2, having studied both Guillaume Morin's guide, that is more
extensive, particularly on the backend part, and Franck Shulte's guide
from sf-genericinst project, that is very comprehensive.
The installation of the platform itself is easier on Mandrake or RedHat,
because you can use RPMs, so no build are needed. Still There was some
hard problems for SSL module to launch, new hosts to be taken in account
in DNS, and so on, but there are particular to the configuration, I guess.
On Mandrake 7.2, assuming that you have setup postfix, apache, open-ssl,
php and mysql, with the adequate modules, which is likely if you run a
web server, needed a database, and planned to have some secure service,
you have most of the stuff.
Only the postgres must be updated from the .org site, since 7.2 contains
only postgres 7.1.
Note that all services should be started. Then there are a number of
check of each with the web server, if you didn't use them yet. Each of
the package is well documented. None of the packaged software there need
to configure, build and install, which makes it rather a breeze.
USE OF RPM: generalities
The "rpm" packaging is only used for linux distributions in RedHat (and
Mandrake that is derived). Indeed it was created for RedHat (rpm = "redhat
package manager") although rpm itself is available on a variety of
platform, and similar concept exists in a lot of unix (like HP Software
As Mandrake is based on Red Hat, it use the same packaging, and
all rpms works in principle.
For postgres, I took a rpm under a Mandrake dir, so I suppose
there is indeed some differences...
The real problem after, is that not knowing a lot about these
tools, even though you have them installed and running by pushing one button,
it is difficult to spot even simple problems, and you will always have
For this platform, the most vexing issue was to get openssl running
with apache. see below.
2.0 RPMS with extensions
2.5 debian package.
See lolando page
The sources are under debian-sf
project at savannah.
See How-To make
a rpm for mandrake. I provide a very simple level of packaging in a
RPM. The package doesnot include the platform software but it list them
as required, so that the installation can be automated.
By reusing and adapting scripts in the debian package and sf-genericinst,
it should be possible to have an automated installation on Mandrake.
The benefit of this package is to include some corrections, and
some extra files needed.
For now the content of the rpm (release 1) is :
If this should evolve, it would be with lo-lan-do scripts and corrections
the tar ball source forge release 2.5
enhancement to documentation :
merged Install_Guide.html for 2.5
addition of three documents: this one and SF2.5install.html SFAdaptation.html
database load (import files: init-extra.sql sfdocs.sql, as described in
my install doc
the script for backend: DataBaseDump.pl and include.pl rewritten based
on JF Legato patch, and using the system variable for genericity.
the specification file (listed below): give description, required packages,
and so on. This is quite easy using emacs. Emacs can automate much of the
work, with appropriate configuration file. A good start is Chmouel's. You
can find it on the web here
. Just open a file named .spec, and it display a template that you
have to fill!
an extension to make SSL optionnal.
include/html.php: a correction to access images
utils/Makefile: Created to compile utilities with config define macros,
avoiding to edit any .c (All *.c modified with these macros)
www/account/change_*, login.php : use of $sys_name for genericity
www/docman/index.php : enhance error message for usability
Each package define the required package to get running. It contains
the files, paths and access rights, as well as scripts to execute at different
phase of installation (pre, post...). You can built source packages and
binary packages. In the case of source forge, it doesnot make any sense
yet, since the code is interpreted, except for one small c program needed
for a suid. RPM does like other package system (HP Software depot is far
more complex, but does this the same way): It will test the dependancies
and inform you of the problems. urpmi handle the dependancies to install
all needed packages as one step. Also, it use a databse to know where the
packages are lcoated, so that you just have to put the CD in the drive.
It can be used from the command line or using a GUI, rpmdrake or krpm.
Here's the spec file that I built for sourceforge. file sourceforge.spec
(for your curiosity)
Summary: SourceForge Open Source Software Development web site
Copyright: VA Linux GPL
Packager: Yves Bardout
Requires: apache >= 1.3.6, openssl >= 0.9.4, mod_ssl >= 2.4.10, MySQL >= 3.22.25, postgresql >= 7.1
Requires: php >= 4.0, python >= 1.3, perl, cvs,
SourceForge is a community for open source software development offering
easy access to the best in web hosted project, including version control, mailing lists, change tracking, message boards/forums,
task management, site hosting, permanent file archival, full backups,
and total web-based administration.
It is relocatable from the prefixes: /home/dev/SF2.5mdk/
what is the list of operations ?
By installing the source forge RPM, using urpmi (e.g. via the RpmDrake
GUI), all required packages will get installed first. Note that you need
to have the mandrake 7.2 CDs available for urpmi to find the packages.
I believe the ones required are on the first and second CD of a packaged
distrib, but there are different boces, so this may vary.
tell RPM to use other installation pathes than the RPM is build for ?
Provided, the prefix is defined in the spec file, which I did for this
package, a RPM package is RELOCATABLE, this mean the original specified
location(s) can be changed at installation time to the directories you
indicate. By default, it install in the path defined in the package. Note:
I didn't check for the platform packages, and use them all at the standard
rpm --relocate /home/dev/SF2.5mdk=newpath sourceforge-2.5-1.i686.rpm
To get started with source forge on a local machine(s) you will have to
get several supporting applications running, at least, apache, ssl, postgresql,
php. All of the software are included on Mandrake
7.2 distrib, exception of the latest php and postgresql (check on Mandrake
8.0) and mailman.I used rpmdrake for install, some during the install
at the distrib, some after, when I got Source Forge. The first thing a
rpm package for SF could do have dependencies to automatically get those
installed as needed.
History from my install :
See the notes on architecture to understand the need of each tool. Some
service are implied, as ssh, part of openssl.
||Mandrake 7.2 (.rpm)
||3.22.29 (client 3.22.30 in PHP)
||4.0.4pl1 (download 1/11/01)
||7.1-1mdk.i586 for Mandrake7.2 (download) (1)
||2.0.6.tgz (download 7/29/01)
||1.2.2rc2-1 (download 7/29/01) (2)
Notes on packages:
the following packages have to be installed: postgresql-XXX-7.1-1mdk.i586.rpm,
where XXX are:
devel libs server python perl .
Optional: contrib test ?
It appears that proftpd 1.2.0rc2-mdk7 is available in Mandrake
distrib, but rpmdrake didn't find it.
I had wu-ftp-2.6.1 running and wanted to see if it would
work existing scripts, but the released config will make it simpelr with
proftpd. I don't believe sourceforge doesnt use any specific features.
Also, I needed to install via CPAN DBI:Pg in my perl libraries.
The perl module is a specific API, not the DBI one.
CONFIGURATION ON MANDRAKE
The principle is to follow the guidelines in sf-genericinst guide, except
for everything this is already managed by the RPM. E.g. there is never
need to install a service in /etc/init.d or /etc/inetd.conf This is always
done by the RPMs.
php.ini PATH .:/<SF>/web/include
follows INSTALL with mysql for dynamic module:
test: mysql Webadmin mysqlwebadm
ISSUE 1: starting at boot was not done after
an upgrade from postgres7.0 ? Should be OK for new install.
I created the links from /etc/rc.d/rcN.d to /etc/init.d/postgresql
/etc/rc.d/rc1.d/K90postgresql -> /etc/init.d/postgresql
/etc/rc.d/rc2.d/S90postgresql -> /etc/init.d/postgresql
/etc/rc.d/rc3.d/S90postgresql -> /etc/init.d/postgresql
/etc/rc.d/rc4.d/S90postgresql -> /etc/init.d/postgresql
/etc/rc.d/rc5.d/S90postgresql -> /etc/init.d/postgresql
You can start/stop it with
service postgresql start/stop/status
you can test it with provided test package, or just call a client:
su postgres; psql
You shall see the steps in SF2.5 install
to get the database setup and the web site and backend connect to it. When
you installed postgres from an RPM, the -i option which allows TCP/IP connections
is generally not on by default. My solution is to avoid IP connection,
and use unix socket when running a single box.
Configuration of the CVS Root ???
local.inc define the $sys_cvs_host only.
mkdir <your cvsroot>; ln -s <your cvsroot> /cvsroot
Option for SSL: A patch I propose to render SSL
optional eith the variable use_ssl in /etc/lcoal.inc is documented
in Adaptations: SSL optional.
For OpenSSL, just need to check /etc/httpd/conf/ssl/mod_ssl.conf The
default was fine for me. Test it with:
openssl s_client -connect <yourdomain>:443
(See SLL docs)
This apache server being hang when trying to get a page via https, is because
of some hack (as written) in script /etc/init.d/htppd in relation to security,
and the different users apache processes utilize.
The issue is that the ssl module will try to write a mutex lock into
the log directory, and apache will spawn processes in a loop, so that any
connection to the web server is blocked. The apache daemon runs as apache,
but fork children as nobody this works for http, but make the web
server hang on a request on https no more request (http or
https) are answered after that. in the error.log, loops with :
child cannot open ssl MUTEX lock file /var/log/httpd/ssl_mutex.<pid>"
I tried chmod a+rw /var/log/httpd/
and it keeps going back to perm only for owner, at each restart. reload
does not help.
There is a chmod in /etc/init.d/httpd that is documented "This
is a hack for the broken MSEC"
HACK (INSECURE): I commented out the hack and let the directory open:
TO STUDY: which user should apache run and who should own the
list all differences: See rpl.log for substitutions.
After following indication [SCHULTZE] 8.3 p 33, edit /etc/proftpd.conf
to define the host name, plus user and group as "ftp".
UserAlias anonymous ftp
Note that the configuration is quite minimal. There was more in the wu-ftp
configuration for security. Need to work on the setup to set limit on #
users, on allowed actions, ...
Note: see generic-variable.sh for my own choice of user,group and directories.
ldap is not used if you set in /etc/local.inc, which I did. So no need
to work wrestling around with ldap. This option make sense for a large
number of user, (an idea is more than 64K) and specifically for a intranet
in a company where the users are already managed that way.
Due to standard install path for php, the path to php has to be changed
in scripts with: (done in RPM)
perl -pi -e "s:/usr/local/bin/php:/usr/bin/php:g" *.php
#!/usr/local/bin/php --- > #!/usr/bin/php