[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110414123803.GD22037@openwall.com>
Date: Thu, 14 Apr 2011 16:38:03 +0400
From: "(GalaxyMaster)" <galaxy@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: LAMP
All,
On Thu, Apr 14, 2011 at 03:33:15PM +0400, (GalaxyMaster) wrote:
> its location once it's done. I'm considering to put it on
> ftp.ru.openwall.com under /pvt/galaxy .
I've tar'ed the tree and put it on
ftp://ftp.ru.openwall.com/pvt/galaxy/Owl-extra-20110414.tar.bz2 .
The tree contains the native/ directory and the Makefile symlink (well,
the idea was stolen from Owl and the hierarchy is the same). To be able
to build this stuff you will need to download sources from their
official mirrors. (Solar, should I also provide a ready-to-use source
directory?).
In order to prepare the tree you need to:
1. create a directory, say, owl-extra;
2. download the above archive to that directory and unpack it;
3. issue 'make symlink' to create all necessary symbolic links
4. create the sources/Owl-extra/packages directory, then create
subdirectories for each package, and download the corresponding
package's sources into these subdirectories.
5. once everything is in place you can do 'make buildworld'
Unfortunately, I didn't work on installworld.conf so after each
buildworld you will need to manually install the newly created RPMs from
RPMS/ and re-run the 'make buildworld' command (until there is nothing
to be built).
The following packages are included in Owl-extra:
===
ImageMagick
curl
dovecot
fcgi
freetds
ghostscript
git
httpd
httpd-mod_auth_mysql
httpd-mod_fcgid
httpd-mod_macro
httpd-mod_wsgi
httpd-suexec
libapr
libapr-util
libc-client
libevent
libexpat
libfreetype
libglib
libjpeg
libmcrypt
libmhash
libneon
libpng
libserf
libxml2
libxmlsec1
libxslt
memcached
mysql
nagios
nagios-plugins
net-snmp
nginx
php
php-ext-apc
php-ext-uploadprogress
php-ext-zend_optimizer
php-pear
postgresql
python
rpm-owlx
ruby
rubygems
sqlite
subversion
swig
tidy
unzip
zip
===
Most of them in a very good shape, however there are few which are not.
I didn't update postgresql for a long time for example. Many of them
were tested to build on a clean CentOS 5.6 (with no modifications to
their spec files). If .rpmmacros included with Owl-extra is used, then
packages are configured to be installed into
/opt/<package>/<version>-<release>, otherwise (if there is no .rpmmacros
or not the one from Owl-extra) packages are configured to be installed
system-wide, e.g. to /usr .
There were many thought and considerations during the creation of
Owl-extra, but I'm afraid it will be too much for this message.
However, let me illustrate the primary idea behind
/opt/<pkg>/<ver>-<rel> structure. I'll use the httpd package as the
example:
* each version is installed to /opt/httpd/<version>-<release>, e.g for
httpd-2.2.17-owlx0 it would be /opt/httpd/2.2.17-owlx0/{bin,sbin,...}
* there is primary configuration directory for each version-release and
it's located under the %_prefix/etc, e.g. for httpd-2.2.17-owlx0 it's
/opt/httpd/2.2.17-owlx0/conf
* then there is a common configuration area in /opt/<package>/config
(the per version-release configuration files includes stuff from the
common configuration area). For example, for the httpd package there
is an include of /opt/httpd/config/conf.d/*.conf and the user can put
something like "Include "config/virtwww/*.conf" into
/opt/httpd/config/conf.d/virtwww.conf and will have a separate
directory under /opt/httpd/config/virtwww/ where they are able to
define virtual hosts.
* everything related to the specific package version-release should go
under /opt/<package>/<version>-<release>. If something is common to
multiple versions of the same package, it should go into the
<package>-common subpackage. For example, Apache logs are something
which is common to all httpd packages, hence it should be packaged
into httpd-common.
* I was trying to stick to the rule that everything related to the
specific package series (e.g. httpd) goes to /opt/<package>. For
instance, /opt/httpd/logs is the place for the log files and all
configuration files expect it to be there. It's convenient for
users to have this directory under /var/log/httpd, so the can just
do 'mv /opt/httpd/logs /var/log/httpd && ln -s ../../var/log/httpd
/opt/logs' to move stuff around, yet to preserve the expected
location of the log file directory. I planed to write a set of
scripts (or extend owl-control) to take care of this, actually.
Well, the most interesting packages from the list are php, httpd, and,
perhaps, php-pear. All these packages were created to be able to be
installed in multiple versions/releases and so each system user could
run the version they want. php-pear package is a beloved child of mine
since it implements pear/pecl in the way I never saw it anywhere --
together with Owl-extra's php they provide a way to a non-privileged
user to install PECL/PEAR modules/extensions into their home directory
and the PHP is picking up these changes automatically.
I actually like the idea of having all new stuff that is not already a
part of the Owl core in /opt/ and to support multiversioning for these.
I invested quite a lot of my spare time into Owl-extras (I'm not
complaining about the time sponsored by Openwall clients :) ), and it
would be a pity to lose the flexibility Owl-extra provides.
Well, it's an Open Source world and I understand that my vision of
things may be different, so if we decide to just re-use specs and build
Owl specific, system-wide packages -- I think I'll have to continue to
enhance Owl-extra alone :) (and do backports from Owl). But it would be
really nice to have Owl-extra as a supplemental repository, since I
think it's a win-win situation. Owl core developers can still
concentrate on the most essential to system packages, while Owl-extra
can provide the user base with the rest, essential to the end-user
packages.
I'd appreciate your comments and/or suggestions.
--
(GM)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
