Croco's Owl-based LAMP

WARNING: the text on this page, as well as all the mentioned software, and all the related stuff was NEVER endorsed, approved or in any other way authorized or supported by Openwall, Inc. or any of its officials. This is only a private initiative by Andrey "Croco" Stolyarov. Noone else should share any responsibility for this page and all the stuff mentioned here.

Please note that packages explained here are prepared/built under Owl-current-20130408-i686 which, at the time of this writing, was relatively new. However, please consult your calendar as you read this whether this is still more-or-less up-to-date, or not; it is unlikely I'll have time to update this page very often.

Owl is a great server distribution, small, efficient, secured as a hell, and perhaps the best server operating system I have ever seen. Having said all this, I've got to confirm there's a big, big usability problem with this great distribution: out-of-a-box it has no HTTP server, no database management system and no support for a lot of popular languages, including that damn PHP. Most Owl users just compile Apache, MySQL and PHP (which constitues A, M, and P in LAMP; Owl constitues the L) up from sources every time they install a new Owl-powered server. It takes a lot of time and effort, yet Owl worth it. However, as of me, I've got more than one Owl-based server, and repeated compilations don't make me happy, so I've been asking people around for packaged versions of all that stuff. Actually, my goal was to run Drupal for my sites, using Owl as both the host and OpenVZ-container operating system; Drupal is used to run with PHP and MySQL, so I just went on for the classic LAMP environment.

The only guy who could help me was Gremlin who maintains Gremlin's unofficial archive of Openwall GNU/*/Linux packages. Unfortunately, Gremlin in his packages follows his own conventions that aren't comfortable for me. That's why I decided to create my own collection of packages. Yet I used packages from his collection as the base, rewriting his spec files and even importing some packages as they are. So let's thank Gremlin for the great work he did.

• Apache. Well, it's hard to live without it. Some people could call me (and Gremlin) conservators, but we still prefer Apache 1.3.* series. So, the collection includes the RPM for Apache. My package differs from the Gremlin's one:
  • Version upgraded to 1.3.42
  • The module mod_rewrite enabled
  • Userdirs are changed back to the traditional public_html (Gremlin uses www)
  • Added the init.d script, and the package registers itself with chkconfig; the script is very, VERY primitive, it just runs apachectl. If you write a better script, please share it with me :)

However, I've got to say that my package has at least one disadvantage: It doesn't support SSL. Sorry guys, it's too hard to pack. I don't need https at present, that's why I didn't bother.

Please note in this version suexec.c is patched so that it executes /usr/bin/php-cgi to run any of your PHP scripts. Hence, it is suexec who knows how to process damn php scripts.

• MySQL. Another character from the LAMP abbreviation. When I prepared the first verision of this collection, I started with Gremlin's mysql.spec, picked fresher version of the original software (hmmm… looks a bit bloated to me), added the init.d script, made a little of tuning (these pre- and post-install scripts, you know, and a bit of ./configure options), and that's all. Well, almost all. MySQL comes with its own script to be used as the init.d (or, generally speaking, bootup start) one, but it is not suitable for chkconfig, so I wrote a maximally-primitive mysql.init script which just runs the one from MySQL distribution, which is installed under /usr/bin/mysql.server.init. Okay, but this is not where the story ends. Once in 2013, I tried to rebuild that package again, for more recent version of Owl, and I failed. So I decided to upgrade the version of the MySQL itself… heh… please tell these people who invented cmake that I hate them all. And if you are one of them, never tell me; perhaps I could kill you, so I'll be in prison and you'll be dead. Don't tell me anything good about cmake. I don't care. The thing I care is that I wasted several days (!) trying to make an RPM out of that damn MySQL-5.5.*, which is now built with cmake. Well I found absolutely no way to do so. I read tons of various docs, I asked dozens of questions, I performed endless hopeless attempts to do anything to that crap. Well, I hate the people who invented cmake and I hate all those who use it, specially the present MySQL crew, after the project was bought by Oracle. Needless to say I hate Oracle, too :) Their experiments with “modern” build system costed me way too much. The problem is that there's no clear and simple way to do the thing which is done wish DESTDIR variable using traditional make (and don't tell me about PREFIX, it has nothing to do here). Finally I noticed that mysql-5.1.* is still built using traditional make so I went back to 5.1.79 and the story came to its end. Once again: for the people who invent ugly idiotic 'novel technologies' like cmake, grub, hal, c99 and the like: your attempts to 'make the world better' cost too much to people like me who have to waste time learning all that shit.

• PHP. Oh, this is where most of my blood was poisoned. Yes, you see, I don't like PHP. I hate the very idea of it. They who invented PHP, intended to run PHP from within the webserver itself, with no intermediate or external programs. Haha. When, in the last years of the former century, I was working at DataForce, we faced a terrible problem of users wishing to use PHP. They demanded we provide them with PHP on our hosting, but it was clear for us we can't let this go as it is: all the users' code must be run under their own privileges, not the server's. The obvious security hole with all that stuff forced us to follow the only sane scheme we knew: compile PHP as a stand-alone interpreter, then run all PHP scripts as CGIs via suexec, so that they're executed under the users' accounts. This scheme is the only acceptable one, and definitely it ruins all intended advantages of PHP. There are better languages. Okay, never mind. I still hate PHP, but I like the things some people created, such as Drupal. Sad enough, they are implemented in PHP. But before PHP is installed (or even compiled), some libraries need to be compiled and installed. Hence there are, as well:
  • libjpeg, libpng and gd. These are just taken from the Gremlin's collection as they are; I only recompiled them with rpmbuild –recompile. Why bother repacking the stuff if I don't see anything to be fixed and there are ready packages? So, thanks go to Gremlin once again.
  • libxml2 I've already had it in a package, so I took my own package, but didn't take a single look inside it.

Please use FTP to access the ftp://ftp.croco.net/pub/software/Owl/LAMP directory. The directory contains both SRPMs and the binary RPMs for i686.

First of all, have Owl up and running. I strongly recommend you to create an OpenVZ container and run all the stuff inside it. If you're short of IP addresses, make the container run on an intranet address, e.g. 192.168.55.55, and use static NAT to forward the 80th port there.

Second, please note I compiled all the stuff within Owl-current-20130408-i686 version of Owl. If your version is different, there's always a chance the binary packages won't work. If this is the case, please consider starting with SRPMs and rebuild them. It is easy: just download them and issue the command rpmbuild –rebuild for each of the packages. Please note the libraries (libjpeg, libpng, gd and libxml2) must be not only recompiled but also installed before you try compiling the packages depending on them (in this particular case, only the php package requires the libraries). Ah, forgot one more thing. Or two things. First, don't do this as root! Don't even think about it. And second, prepare the account you use to be used with RPM (if you didn't do this yet) – run the rpminit command under your account. This will create the .rpm.d directory under your home, and you'll get the resulting packages somewhere under .rpm.d/RPMS/i686 or the like.

To install an RPM, it is better to use rpm -Uvh command.

After you install Apache, I'd recommend you to edit /etc/httpd/httpd.conf changing the port 8080 to 80 Okay, 8080 is there for a reason. Before you open the port 80, the system wishes to rest assured you know what you do. Another change I'd recommend is to add the line

    Include "/etc/httpd/virtuals.conf"

and then add the file /etc/httpd/virtuals.conf in which all your virtual sites will be described. Heh, yes, you do need virtual sites because suexec of this version will not run for the default site, as well as for userdirs. Only the virtual site mechanics will do. Virtual sites are easy, look at this example:

<VirtualHost example.com:80>
   ServerName example.com
   ServerAlias *.example.com
   DocumentRoot /home/w_example/public_html
   AddDefaultCharset utf-8
   User w_example
   Group websites
   UserDir disabled
   ServerAdmin webmaster-remove-this-crap@remove-all-this-too.example.com
   <Location />
      Options Includes +ExecCGI +FollowSymLinks
      DirectoryIndex index.html index.php
   </Location>
   <Directory /home/w_example/public_html>
      Options +ExecCGI +FollowSymLinks
      AllowOverride All
   </Directory>
   CustomLog /var/log/httpd/example_com.access combined
   ErrorLog /var/log/httpd/example_com.error
</VirtualHost>

In the above example, it is assumed that your site is named example.com, and you have created a user account for the site, with login name w_example, which belongs to a group named websites. Well, your mileage may vary. Please keep in mind that both UID of the user and GID of the group must be no less than 1000, or else suexec will refuse to run under them.

To run Apache, type

service httpd start

If you want it to be started at the boot time, do

chkconfig httpd on

Once the package is installed, I'd recommend to bring the server up:

service mysql start

and run the famous /usr/bin/mysql_secure_installation script. Just type its name and answer the questions.

If you wish your MySQL to be launched at startup, do

chkconfig mysql on

Be sure to install libjpeg, libpng, gd and libxml2 before (or together with) the php package. Perhaps the beast should work right off, but you'd better visit the file /etc/php.ini and tune the timezone to your location.

To test the beast, go to the root directory of one of your configured virtual servers (you already created one, didn't you? remember, this version of PHP won't work outside of virtuals), create a file named, e.g., info.php and place the following text inside it:

<?php phpinfo( ); ?>

Then, do the following:

chmod 755 info.php

And point your browser to it (e.g. www.example.com/info.php). You should see some useful information. If you see a confusing error message instead, please check the following: the owner of the site must have UID/GID no less than 1000, its home directory and the public_html in it both must have mode 755 (or at least 711 – but not more than 755, as suexec will refuse to run if something is writable by others). If everything's okay, it should work now. If it doesn't… well… please accept my apologies, and try figuring out what's wrong this time. Sorry, I can't foresee all possible situations, I'm not a wizard.

The scheme with stand-alone interpreter run by suexec is the most sane but nevertheless not too common across the world, so distributions of PHP-based software packages are not oriented nor prepared for this setup. Okay, everything is not that bad. There are two things to take into account. First, all your .php files must have the executable bit set. And second, both read and executable must be set for all the world, but writable must be set for the owner only. After unpacking your PHP application (e.g. Drupal) within your web server tree, change to the web server root directory (e.g. your public_html) and issue the following commands:

find -type f -name '*.php' -exec chmod +x '{}' \;
chmod ugo+rX * -R
chmod go-w * -R

Perhaps this will set the permissions as they must be.

Please check the following:

• Is your site configured as a virtual host within the Apache's configuration? If it isn't, suexec won't be invoked, and hence the PHP interpreter /usr/bin/php-cgi is not being run, as it is suexec who is to perform this.
• Does your user and group have UID and GID with the value 1000 or greater? If not, suexec will refuse to run under them.
• Does your document root directory belong to that particular user and that particular group? Or, should I say, are the user/group specified in your VirtualHost configuration the same as the user/group owning your DocumentRoot?
• Isn't either the home directory of your user or the DocumentRoot directory writable by anyone else than that user?
• Have you performed the suggested chmod operation, or somehting similar, so that all your .php scripts have the +x (executable) permission enabled?
• Do all your PHP scripts have the .php suffix?

more suggestions are probably to come