- Configure firewall to allow httpd requests: system-config-securitylevel
- Get PHP development RPM: http://rpm.pbone.net/index.php3/stat/4/idpl/8077900/com/php-devel-5.1.6-20.el5.i386.rpm.html
- Get PHP source RPM: ftp://ftp.pbone.net/mirror/ftp.centos.org/5.3/os/SRPMS/php-5.1.6-23.el5.src.rpm
- Use yum to handle RPM dependencies. yum install php-5.1.6-23.el5.src.rpm
- Update SPECS/php.spec and enable/disable options as necessary.
- rpmbuild -bb –target=i386 SPECS/php.spec - It’s good to specify the target, since otherwise, the RPM build may take a very long time.
- Force the installation of the updated RPMs. I did an ls of the RPMS directory and forced them all.
rpm -i –force php-5.1.6-23.i386.rpm php-bcmath-5.1.6-23.i386.rpm php-cli-5.1.6-23.i386.rpm php-common-5.1.6-23.i386.rpm php-dba-5.1.6-23.i38
6.rpm php-debuginfo-5.1.6-23.i386.rpm php-devel-5.1.6-23.i386.rpm php-gd-5.1.6-23.i386.rpm php-imap-5.1.6-23.i386.rpm php-ldap-5.1.6-23.i386.
rpm php-mbstring-5.1.6-23.i386.rpm php-mysql-5.1.6-23.i386.rpm php-ncurses-5.1.6-23.i386.rpm php-odbc-5.1.6-23.i386.rpm php-pdo-5.1.6-23.i386
.rpm php-pgsql-5.1.6-23.i386.rpm php-snmp-5.1.6-23.i386.rpm php-soap-5.1.6-23.i386.rpm php-xml-5.1.6-23.i386.rpm php-xmlrpc-5.1.6-23.i386.rpm
This is a very simple translation of a Drupal .info file into an RPM .spec file. It may be useful in identifying methods to assemble complex Drupal installations on dedicated servers or VPSs where the modules can be managed as RPMs. This would not be useful for casual users. It also assumes the modules will not be modified, and requires careful composition of the .info files by contributors.
I had difficulty posting the script in the blog, so the link provided must be used.
To run it, pass the URL of the module to download, for example: ./info2spec.sh http://ftp.drupal.org/files/projects/annotationfield-5.x-1.x-dev.tar.gz
It was tested with the annotationfield module.
Be sure to set up an .rpmmacro file at the account level.
* CAUTION *
- Hasn’t been (and isn’t going to be) tested with an actual RPM build
- Does not (and probably won’t) handle intermodule dependencies or conflicts
A Drupal RPM generator module could scan the modules installed and extract the following information:
- Source file (full URL)
- Requires - the modules required to support each module
- Provides - the name of the service/capability/feature provided by each module
- Conflicts with - modules which cannot be installed with each module
The standard BUILD, SPECS, SOURCE, RPM, SRPM directories can be used for the build process. The Drupal RPM generator would write .spec files to the SPECS directory for each module. .rpmmacros would indicate the target directory, and other common constants.
This allows a development environment to be quickly converted from a .tgz installation to an RPM managed production server.
RPM compliant web applications and toolkits must meet the following requirements:
- Dissociation of customization and extensions from the application. This includes all configuration parameters, such as database access settings, design elements, and plug-ins from the core application files. Thus, a web application can be installed as an RPM, accessed through a symbolic link, and customized for an account with the appropriate directories at the account level. In this way, multiple accounts can use the same core code, while remaining independent. This requirement can be waived if the application will be used with dedicated servers.
- Packaging with careful attention to Provides and Requires to ensure interdependencies are observed.
- Conflict resolution must be established to ensure incompatible components are not installed.
Popular web applications should consider an RPM compliant file system architecture for the following reasons:
- Disk space Most powerful applications require a significant amount of disk space. RPMs allow a single installation to serve an entire server.
- Security and maintenance RPMs can be managed with automatic updates, ensuring security and update patches are applied promptly, automatically.
- Local security Managed properly, using a common source to serve an application can allow a server administrator to provide the application, but prevent account holders from modifying it. This would be extremely valuable for hosting companies.
- Ease of installation/distribution By making RPMs available, distributing them with operating systems, and publishing them in repositories, they are easier to install and use.
- Standardization RPMs can ensure that web applications are always installed in the same place. This can be very helpful for technical support.
- Bandwidth RPMs may reduce the bandwidth required for distributing applications, by making them available from more sources.
Risks and disadvantages of this approach include:
- Loss of flexibility, all accounts will use the same core code. Extensions will have to be used to customize the applications.
- Skill level of the server administrator and application engineers must be adequate to ensure graceful use of the application within a shared architecture.
- Security, if the core code is compromised, all accounts on the server will be affected.
- Many web applications would require significant changes to use an RPM compliant filesystem architecture.
The next major step for Drupal will be assembly of an RPM repository that bundles compatible components into RPMs that can be managed as such. In order for this to succeed the server filesystem architecture must be created such that a single installation of Drupal can run multiple sites.