Metztli I. T.  Blog

It has been a while that I intended to explore -in a public post- how to install the Drupal content management system (CMS) using my hacked OS/2 Warp 4 (a.k.a. Merlin) operating system. And what better way to explore the hack than to install the Drupal 7.0 Release Candidate 1. Indeed, there are claims by the OS/2 (or "eCS") "pros" out there that they are running Drupal in their machines. Nevertheless, there seems to be a certain secretive nature to their work since I have not found any public illustrations of their claims online. Probably it is the fact that since they are used to a proprietary operating system, their achievements inherit a secretive "cave development" nature.

Of course there are exceptions to the above generalization. For instance Drupal, or as a matter of fact any Web application that depends on the Apache web server, MariaDB (MySQL fork), and PHP (AMP), would not be possible on OS/2 without the efforts of Paul Smedley, the OS/2 hacker. Please, seriously consider making a donation for his unique efforts and more importantly, for sharing his work unselfishly. We will be downloading AMP components to achieve the task in this post.

The steps to install AMP in OS/2 have been covered at considerable length in other posts in this blog. Accordingly, for this post, an OS/2 user of the name Xiuhtecuhtli will go relatively quick over the procedure so as to be more detailed when resolving the issues that arise when installing Drupal since these may frustrate the OS/2 user desiring to install AMP.

Downloading the individual components needed before we start our hack.

I will be illustrating the procedure using drive letter L: where I will be creating a working directory L:\workspace. We will be downloading the necessary individual components into this directory. Well, let's download:

• (Apache) httpd-2.2.17-os2-20101021.zip - also download libc063.dll (libc-0.6.3-csd3.zip)
• mysql-5.1.52-os2-20101105.zip - also download gcc445.dll
• php-5.2.14-os2-20100724.zip (OS/2 PHP 5.3 port is still "shaky" -hence I do not use it for this post)
• drupal-7.0-rc1.tar.gz
• Metztli-EMX.zip - I will be using this to decompress archives of extension .tar but disregard if you have another utility.
• pkos2250.exe self executable contains pkzip.exe which I will use to extract compressed zip files

Below is a snapshot of the contents in L:\workspace

Evidently it is assumed that you have an OS/2 Window open and that you have changed directory location to the L: drive. The subsequent procedures will be performed relative to the L: drive -please adjust your own drive letter accordingly if you will be following along.

If you need an utility to unpack compressed files in ZIP format, then execute the self-extractable PKOS225.EXE and place pkzip.exe utility under a directory in your path. For instance, you may place it under your OS/2 [root drive letter]:\os2 directory or folder. This has the effect of allowing you to unpack ZIP archives from any location you may happen to be in your file system directory.

If you do no have a utility to open TAR archive files (those ending in .tar) you may unzip the EMX utilities contained in Metztli-EMX.zip Decompressing this file will create a couple of directories or folders at the current directory location. For instance, since Xiuhtecuhtli is at the root of the L: drive, after extracting these files there will be two directories L:\OS2 and L:\EMX If desired, verify the archive contents as below:

pkzip.exe /view L:\Metztli-EMX.zip

If satisfied you can decompress the archive as:

pkzip.exe /extr /dir workspace/Metztli-EMX.zip

You will find a file L:\OS2\myEMX.cmd which will set the following variables when executed thus:

OS2\myEMX.cmd

Code

Please note item number four(4) above: "PATH \EMX\BIN;" You can expect that path to be added to the end of your current %PATH% statement when executing OS2\myEMX.cmd -hence make sure that your current OS/2 PATH statement ends with a semicolon (. As long as we are at this drive letter location (L: in our illustration) we can expect that those variables are valid because they reference the root of the drive.

First things first: OS/2 AMP needs libc063.dll and GCC445.dll to even come "alive."

Apache, MySQL, and PHP (AMP) ports of OS/2 need libc063.dll and GCC445.dll to instantiate. You must select a proper location referenced by the LIBPATH statement in you OS/2 CONFIG.SYS file. For instance, Xiuhtecuhtli selected his [OS/2 installation drive]:\OS2\DLL directory to place the DLLs of reference as follows:

pkzip /extr /dir workspace\libc-0.6.3-csd3.zip X:\OS2\DLL\.

Which will place the following files into hypothetical OS/2 installation drive X:\OS2\DLL\. relevant directory.

libc06.dll
libc061.dll
libc062.dll
libc063.dll
gcc335.dll
COPYING.LIB

If those files already exist, extraction utility pkzip.exe will prompt you for permission before replacing/overwriting
those.

Now we extract GCC445.dll into the hypothetical OS/2 installation drive X:\OS2\DLL\. in the same manner:

pkzip /extr /dir workspace\gcc445.zip X:\OS2\DLL\.

It will place GCC445.dll into X:\OS2\DLL\. again prompting you for input if it already exists.

That's it

Installing Apache web server into OS/2.

Well we are ready to install the Apache web server. Xiuhtecuhtli decompresses the Apache archive by typing:

pkzip /extr /dir workspace\httpd-2.2.17-os2-20101021.zip

We change directory to the newly created Apache2 directory -read the readme.os2- and make a backup of startup.cmd:

CD L:\apache2

COPY startup.cmd startup.cmdBAK

and modify startup.cmd contents from below default directives:

@echo off
rem adjust as necessary
set beginlibpath=u:\apache2\bin;u:\apache2\modules;
bin\httpd -d . 2>&1

to these:

set beginlibpath=L:\apache2\bin;L:\apache2\modules;
bin\httpd -d .

Please note that you need to leave the dot

The reason for leaving only the essential strings above is we want to be sure that any errors are printed to the OS/2 Window during setting up of the web server -and please replace the L: drive above with the actual drive letter where you are working.

If you enter DIR conf\ you will see two(2) files that now we must operate upon: conf\httpd.conf and conf\httpd.conf.sample

Next Xiuhtecuhtli renames (or MOVEs) the conf\httpd.conf file as a preliminary task:

MOVE conf\httpd.conf conf\httpd.confBAK

And renames the file conf\httpd.conf.sample file:

move conf\httpd.conf.sample conf\httpd.conf

The reason for the above is because the initial conf\httpd.conf references modules in GNU/Linux whereas the conf\httpd.conf.sample does reference the OS/2 port equivalents with file extension .dll

Well now it is time to start your web server by typing:

STARTUP

we should see no errors printed to our OS/2 Window only notices similar to output below:

set beginlibpath=L:\apache2\bin;L:\apache2\modules;
bin\httpd -d .
Apache/2.2.17 (OS/2)

Note: if you have not set your hostname in your OS/2 workstation, you will see a similar error as:

bin\\httpd: apr_sockaddr_info_get() failed for [hostname]
bin\\httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

Although your Apache web server will start, you can get rid of that error by typing (in Xiuhtecuhtli's specific setting):

SET HOSTNAME=Hecamalotl

(that setting will last for the current session. If you want that value to hold, please set the value directive in your CONFIG.SYS file and reboot your OS/2 workstation)

Additionally, you should also modify the file at OS/2 [root install drive]:/mptn/etc/hosts by adding the hostname you set above next to the IP address:

abc.def.ghi.jkl     Hecamalotl.your.domain     Hecamalotl

Of course you would replace the alphabet letters above with your own relevant IP settings and concatenate your own domain to the end of you hostname.

Anyhow, by directing your browser to http://localhost you should see the Apache default display phrase: It works!

Installing PHP 5.2 into OS/2.

Needless to say, PHP requires a php.ini directives file. You will not find a sample of that in the OS/2 port of PHP 5.2 decompressed archive but you can use a file from a GNU/Linux distribution. For instance, I have used a php.ini from a default Debian install. Here I make available the php.ini file for PHP 5.3 that I used. Please keep in mind that PHP 5.3 deprecates some directives in the php.ini file and the newer file may not be compatible with PHP 5.2.

Hence, these are the directives added to the Debian PHP 5.2 php.ini that I make available. Xiuhtecuhtli used them for illustrating the procedures in this blog post. Please note that I do not make explicit or implicit guarantees that it will work for you.

extension_dir   =   "/php5/modules"
extension=gd.dll
extension=mysql.dll
extension=mbstring.dll
extension=sqlite.dll
extension=imap.dll

Continuing ... now that Apache is set up, Xiuhtecuhtli changes directory to the root drive and decompresses archive thus:

pkzip /extr /dir workspace\php-5.2.14-os2-20100724.zip

Of interest above is the file (module) php5/apache2/modphp5.dll that we will need to reference (load) with a directive in Apache web server apache2/conf/httpd.conf configuration file. Please read the PHP5\readme.os2 file.

Accordingly we open the Apache configuration file with EPM, the OS/2 editor -or any other text editor -but not a word processor.

EPM apache2\conf\httpd.conf

Approximately at line 111 -after the block of modules, we add the directive:

LoadModule     php5_module     /php5/apache2/modphp5.dll

And we also add to the very end of apache2/conf/httpd.conf file the PHP relevant directives:

ScriptAlias   /php5/   "/php5"
AddType   application/x-httpd-php   .php
Action   application/x-httpd-php   "/php5/php.exe"

Now we create a sample file in \apache2\htdocs directory (Apache's DocumentRoot from where our content is served) to test if Apache and PHP 5.2 are playing well together:

EPM apache2\htdocs\phptest.php

and write the content:

<? phpinfo() ;  ?>

as illustrated below in screenshot of the OS/2 EPM editor:

After saving the file proceed to test Apache and PHP 5.2 by changing directory to PHP5:

CD php5

start a new OS/2 Window in the foreground that inherits the values set in our variables and label it appropriately:

start /f "PHP 5.2"

proceed by typing php.exe to start PHP 5.2 and, if shown, please disregard the error:

TlsAllocThreadLocalMemory error: init already done!

Now change directory to Apache:

CD ..\apache2

And start up Apache web server:

startup

You should see no errors. Now point your browser at http://localhost/phptest.php and we should see information similar to the snapshot below:

Install MySQL into OS/2 and create a database.

Well, Xiuhtecuhtli starts by decompressing the MySQL ZIP archive at his current L: drive location:

pkzip /extr /dir workspace\mysql-5.1.52-os2-20101105.zip

Do not forget to read the mysql51\readme.os2 file. Of particular attention is the following advice: For new users, to create the initial databases, unzip mysql_sample_database.zip in the mysql51 directory which will create a 'data' directory

Accordingly, Xiuhtecuhtli changes directory to mysql51:

CD mysql51

and decompresses referenced file to create the data directory:

\mysql51]pkzip /extr /dir mysql_sample_database.zip

Note that if you overlook the above procedure, you will get similar error as below and mysqld daemon will exit:

TlsAllocThreadLocalMemory error: init already done!
101203 2:04:52 [Warning] Can't create test file L:\mysql51\data\Hecamalotl.lower-test
101203 2:04:52 [Warning] Can't create test file L:\mysql51\data\Hecamalotl.lower-test
mysqld: Can't change dir to 'L:/mysql51\data\' (Errcode: 2)
101203 2:04:52 [ERROR] Aborting

101203 2:04:52 [Note] mysqld: Shutdown complete

Subsequently we start a shell that inherits our current session variables:

START /f "your own label to identify the process in OS/2 window"

New OS/2 Window will start in the current mysql51\ directory and Xiuhtecuhtli changes to the mysql51\bin directory to start the mysqld daemon:

CD bin

\mysql51\bin]mysqld

Now, we can use the previous to the immediately above OS/2 Window and change directory to mysql51\bin:

\mysql51\]CD bin

Since there is not been set a MySQL root or super user password Xiuhtecuhtli starts an MySQL root or super user instance without specifying a root password:

\mysql51\bin]mysql -u root

asks to see what databases are there:

mysql> SHOW DATABASES;

(as a security precaution in your production server, please delete the test database listed)

and proceeds to find out what users exist:

mysql> SELECT Host, User FROM mysql.user;

Xiuhtecuhtli then proceeds to create an OS/2 Drupal database:

mysql> CREATE DATABASE os2_drupal;

and grants all privileges to himself. Evidently, if you are not the database administrator somebody else would execute the procedure above. But here we are in a single user OS/2 workstation.

Subsequently Xiuhtecuhtli proceeds to verify his modifications by repeating the previous initial procedures, as shown in the snapshot below:

Please make sure to secure your MySQL by setting an appropriate strong password for the administrator or super user as well as those individuals who require a database for her/his web applications. There is link in mysql51/readme.os2 that will start you up in the right direction.

Intalling Drupal 7.0 RC 1 Open Source CMS into OS/2 -- finally!

Well, we have MySQL running in a process ready to accept connections and we know that Apache and PHP 5.2 work well together, what are we waiting to install Drupal?

Well Drupal needs to have module mod_rewrite enabled. We will verify that in effect mod_rewrite is enabled by opening Apache configuration file with OS/2 EPM editor:

Assuming we have returned to the root of the drive where we are operating type:

EPM apache2\conf\httpd.conf

In effect, we have to enable the module by changing the directive from not enabled (begins with # character):
# LoadModule rewrite_module modules/rewrite.dll

to enabled ... and save our modifications.

LoadModule rewrite_module modules/rewrite.dll

Additionally, and this generally holds true for any PHP based web application like Drupal, b2evolution, etc., locate the comment similar to

# DirectoryIndex: sets the file that Apache will serve if a directory
#is requested

and right below, a few lines down, there is a directive of the form:

DirectoryIndex index.html

Xiuhtecuhtli adds a space and then the string index.php because PHP based web applications need a index.php file to default to when a user in the Internet requests a directory in a site. After the modification the above directive should now be similar to:

Code

Additionally, in Drupal 7.0 RC 1 the PDO MySQL/MariaDB driver must be enabled. Hence, Xiuhtecuhtli enables it (by adding) the additional extension pdo_mysq.dll.

extension=pdo_mysq.dll

Please note that if above step is overlooked, Drupal 7.0 RC 1 will refuse to proceed at the Verify requirements step and will output similar message as follows:

Database support Disabled
Your web server does not appear to support any common PDO database extensions. Check with your hosting provider to see if they support PDO (PHP Data Objects) and offer any databases that Drupal supports.

Accordingly, assuming that we open the file found at the [root of your OS/2 installation]:\MPTN\etc\php.ini with the EPM editor, this how it would read -after Xiuhtecuhtli adds the required directive:

Proceeding, now we have to extract the Drupal Gzip compressed TAR archive. That is why we needed the EMX utilities. Again assuming a location at the root drive of our operations, Xiuhtecuhtli extracts drupal-7.0-rc1.tar.gz contents into Apache DocumentRoot directory apache2\htdocs\. with the following directive:

tar -C apache2\htdocs\. -xvzPf workspace\drupal-7.0-rc1.tar.gz

where the -C option directs tar.exe to change directory to apache2\htdocs and the -xvzPf extracts the compressed contents.

Xiuhtecuhtli now instantiates PHP 5.2 and Apache2 by spawning other OS/2 Windows --that inherit the current OS/2 Window session variables-- and labels it accordingly:

start /f "PHP 5.2 Hecamalotl Xiuhtecuhtli at Metztli IT"

CD php5
php.exe

start /f "Apache2 Hecamalotl Xiuhtecuhtli at Metztli IT"

CD apache2
startup

Well it is time to point our browser at:

http://localhost/drupal-7.0-rc1/install.php

after the operation Xiuhtecuhtli (and ourselves) can see the Drupal installation screen -he leaves the default standard option:

Since the English language is built-in, I did not have to "Chose language" (hum... is there Nahuatl?). The Drupal installation routine went smooth over the "Verify requirements" since we enabled a priori the PDO MySQL/MariaDB driver.

However, I want to call attention to this next snag that Xiuhtecuhtli encountered at the step "Set up database" and if not addressed properly will lead to undue frustration rather than the joy of Drupal 7.0. After user enters the pertinent database details in the fields, select ADVANCED OPTIONS (thus cascading additional fields). Of most importance to us is to replace the default Database host field value of localhost with its numeric equivalent: 127.0.0.1

The snapshot below illustrates how Xiuhtecuhtli replaced localhost with 127.0.0.1 [1]:

Do not overlook this step; otherwise your new Drupal 7.0 RC 1 will halt with error similar to:

Failed to connect to your database server. The server reports the following message: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket 'socketMySQL' (49).

Or if you are upgrading from Drupal 6.x to 7.0, you may experience a failure of the upgrade and related error:

PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket 'socketMySQL' (49) in drupal_get_installed_schema_version() (line 151 of L:\apache2\htdocs\drupal-6.19\includes\install.inc).

Having selected, naturally the Save and continue button at the bottom of the Database configuration page, the Install profile routine takes over. It lasts a couple of minutes and one can only stare at the progress bar at the top.

Eventually the process ends and we are presented with a couple of Drupal 7.0 RC 1 Site Information fields and a Site Maintenance Account. Xiuhtecuhtli enters relevant information and proceeds.

In due time the Drupal 7.0 RC 1 multi-step installation routine is satisfied -including the modification of critical files to a secure status: paquilizcayolli (Congratulations : ¡Felicidades), you installed Drupal 7.0!

Xiuhtecuhtli selects the Visit your new site blue lettered label, and is welcomed with a pleasant combination of colors and the Drupal site name that was specified in former steps. "Welcome to OS/2 Hecamalotl ... If any reader is curious, Hecamalotl is the Nahuatl word for whirlwind (and remolino in Spanish). And the phenomenon may describe the crazy history of the OS/2 itself -hence my predilection for naming this blog post thus.

From the Appearances tab, you can select a URL to obtain an archive and install a new Drupal theme or module. Or you can upload one to your host, as Xiuhtecuhtli did: he uploaded danland-7.x-1.0-rc1.tar.gz from The Danland Project.

As Xiuhtecuhtli uploaded Danland he remembered that in Drupal 6.x he had to manually decompress and place the theme or module in the relevant directories. Nevertheless, Drupal 7.0 even decompresses zip, tar, tgz, gz, bz2 archives and places them in their appropriate location...! Hence all he had to do is press (by selecting) the Install button under the long field and chinga'o! the theme is installed by Drupal 7.0 RC 1.

Now returning to Drupal 7.0 themes section, we can see that the Danland theme has been added, but it in a disabled state. Under its miniature representation there are two options: Enable and Enable and set default.

This latter option was activated by Xiuhtecuhtli; it can be seen as the very first snapshot of this post -at the top.

Enable the Drupal Clean URLs feature and make your OS/2 site search engine friendly.

For the sake of simplicity Xiuhtecuhtli did not touch the Apache2 configuration file beyond the most necessary to execute this Drupal 7.0 RC 1 hack on OS/2. Nevertheless, if you create some content in a node and observe the URL in your browser top field, you will realize that those are awful to look at. In fact these URLs will negatively impact the search engines activity, and your cool OS/2 site will not be indexed properly, possibly costing you visitors and/or customers.

For instance look at this quick article extraction created on OS/2 Hecamalotl home page:

If we select the blue Read more lettered hyperlink we will be taken to the node where the reader will find the complete article of the extracted text. Observe the browser search field at the top node URL: http://localhost/?q=node/1

In this current OS/2 set up, Xiuhtecuhtli will show how to modify Drupal by adding and/or modifying a few directives to his apache2\conf\htttp.conf file. These modifications/additions are necessary to activate the so called Clean URLs feature in Drupal that -as its name implies- will provide "friendlier" URLs for the search engines.

As a concrete example, Xiuhtecuhtli will use OS/2 text editor EPM to open the file L:\apache2\conf\httpd.conf

We localize DocumentRoot, copy the directive one line below and then "neutralize" it by adding a # character in front of directive. Proceed to concatenate the directory where Drupal 7.0 RC 1 was installed to the copy as shown below:

# DocumentRoot "/apache2/htdocs" (rem original directive with #)
DocumentRoot "/apache2/htdocs/drupal-7.0-rc1"

We proceed downward and locate statement < Directory "/apache2/htdocs"> wich again we duplicate one line below and at the same time we neutralize it by placing a # character in front of it. Subsequently we operate on the duplicate of the directive by concatenating the directory where we installed Druapl 7.0 RC 1.

# < Directory "/apache2/htdocs"> (rem original directive with #)
< Directory "/apache2/htdocs/drupal-7.0-rc1">

Finally notice the expressions stacked below the directive RewriteEngine on:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Below please see snapshot hiliting the operations described in the previous two(2) procedures:

After saving Apache configuration file, restart your Apache server. You could just localize the OS/2 windowed session and once active on it simply press CTRL-C to stop the web server. Restart Apache by executing startup.cmd once again.

Now go to your Drupal 7.0 RC 1 dashboard and select Configuration from the menu. Scroll down and in the section labeled SEARCH AND METADATA, please select by "clicking" the Clean URLs option.

Check the little square option: Enable clean URLs Use URLs like example.com/user instead of example.com/?q=user.

And a Drupal greenish dialog notifies us that: The Configuration options have been saved. Hence clean URLs have been enabled.

Now going back to the example article of the extracted text that we used to begin this section, we can see that we have a "clean" URL: http://localhost/node/1

whereas before enabling Drupal clean URLs feature the same node was: URL: http://localhost/?q=node/1

---

[1] Please read Shane Stillwell blog post: Zend Server Mysql Socket problem with PDO [Solved]

NOTE The views and/or opinions reflected here are my own and in no way necessarily reflect (by association) those of Metztli Information Technology as a whole and/or our business associates.

Suggestion code for commands entered at the OS/2 shell(s) prompt are provided on an AS-IS basis. Although due diligence has been applied, the information may not be accurate under all circumstances.

Any resource offered, like the GNU/Linux Debian php.ini file, is intended only for illustrative purposes and not intended for production environments where additional security measures should be applied. Accordingly, please do not hold myself, Metztli IT, and/or associates responsible if unforeseen effects are experienced. You are not obliged to use the information provided.

Metztli IT reserves the right to modify the procedure --including deleting the blog entry.