Monthly Archives: October 2009

Creating PHP bindings for RRDTool

Posted on by
Reply

Background

PHP is a very popular language for web development.  Providing bindings for directly calling rrdtool within PHP provides a simple and efficient means of providing a high-level scripting interface into the data management and display capabilities of rrdtool.  The stock installation of rrdtool does not provide any support for PHP so bindings must be created for it manually.

Setup

  1. Download the php_rrdtool archive from the contributions directory of the RRDTool site.
  2. Extract the archive contents into the /usr/include/php/ext directory.

    sudo tar xzvf php_rrdtool.tar.gz -C /usr/include/php/ext

  3. Change the owner and group to “root” and “wheel”.

    sudo chown -R root:wheel /usr/include/php/ext/rrdtool

  4. Navigate to the newly created rrdtool directory.

    cd /usr/include/php/ext/rrdtool

  5. Generate the configuration files for the PHP bindings.

    sudo phpize

  6. Execute the newly-generated configuration script for the PHP bindings.  Note that the --with-rrdtool argument takes as its value the “root” directory where the various rrdtool files are located.  If installed using the default values supplied by the MacPorts utility, the “root” directory would be /opt/local.

    sudo ./configure CFLAGS="-fnested-functions" --with-php-config=/usr/bin/php-config --with-rrdtool=/opt/local

  7. Make the php rrdtool extension.

    sudo make

  8. Install the php rrdtool extension.  Make a note of the directory into which the extension was deployed.

    sudo make install

  9. Make a backup copy of the /etc/php.ini file for safety.  If the file does not yet exist, then copy the /etc/php.ini.default instead.

    sudo cp php.ini php.ini.orig

    or

    sudo cp php.ini.default php.ini

  10. Edit the /etc/php.ini file and alter the value of the extension_dir variable to the deployment directory (noted in Step 8).

    extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20060613/"

  11. Edit the /etc/php.ini file and a new variable under the Dynamic Extensions section specifying the rrdtool extension.

    extension=rrdtool.so

  12. Restart the apache server to load the new configuration information.

    sudo apachectl restart

  13. Verify the rrdtool extension can be loaded from within PHP.

    php -m

Special Notice for Mac OS X Users

With the evolution from 32-bit to 64-bit architectures in progress, it may arise that the rrdtool module is accessible through some mechanisms and not through others.  For example, it has been observed on some hardware/operating systems that the module will load properly when referenced directly by the PHP interpreter (i.e. php -m), but is not accessible when referenced within a web page served by Apache (i.e. not listed as part of the phpinfo() output).  This situation is most likely due to Apache running in 64-bit mode while the PHP interpreter and associated extensions are running in 32-bit mode.  If  this situation arises, then the suggested solution is to force Apache to run in 32-bit mode.

Running Apache in 32-bit mode on Leopard

Posted on by
Reply

Background

With the evolution of Apple’s hardware from 32-bit to 64-bit compatibility, there are bound to be some difficulties.  They have tried to alleviate much of the complexity of running in this environment through their use of universal binaries, but sometimes there are unforeseen difficulties that require “undoing” some of Apple’s handiwork.

As an example, the standard Apache web server is actually made of 4 different executables:  32-bit and 64-bit versions for the PowerPC architecture, and 32-bit and 64-bit versions for the Intel (x86) architecture.  Normally, the operating system runs the “most appropriate” version depending on the nature of the hardware.  However, this may cause problems when trying to use Apache modules which may not support the “most appropriate” version.  A common occurrence of this is when using the PHP module and some of its extensions.

There are two possible methods of alleviating this problem:  recompile every module and extension so that it is in the supported architecture or strip the 64-bit binary from the Apache universal binary which forces the operating system to run it in 32-bit mode.  As the more expedient solution is simply to force Apache into 32-bit mode, that is the route explained below.

Special Notice

This procedure alters the installed Apache web server.  The changed binary may be over-written by a future update which may require this procedure to be repeated.  This procedure has been tested only on Leopard running on an Intel-based Mac Pro.  Older PowerPC-based systems or systems running Snow Leopard may not require this process.

Setup

  1. List the supported architectures in the Apache binary.

    file /usr/sbin/httpd

  2. Verify that “Mach-O 64-bit executable x86_64″ is listed as part of the universal binary.
  3. Copy the original executable to a backup location for safety.

    sudo cp /usr/sbin/httpd /usr/sbin/httpd.orig

  4. Stop the web server.

    sudo apachectl stop

  5. Remove the 64-bit executable from the Apache universal binary.

    sudo lipo /usr/sbin/httpd -remove x86_64 -output /usr/sbin/httpd

  6. List the supported architectures now in the Apache binary.

    file /usr/sbin/httpd

  7. Verify the “Mach-O 64-bit executable x86_64″ is no longer listed as part of the universal binary.
  8. Restart the web server.

    sudo apachectl start

Extending Service Discovery Cabilities on ReadyNAS

Posted on by
Reply

Background

The ReadyNAS appliance can advertise the services available on their system through the Bonjour or UPnP protocols.  These service discovery protocols can greatly simplify the client connection and configuration problems.  The web administration interface provides an easy method of controlling some of the services advertised, but there may be additional services running on the ReadyNAS that do not have an administrative interface for controlling their advertisement.

Because the ReadyNAS uses the open-source project avahi to handle service discovery, documentation on extending the list of services to be advertised is readily available.  With this information, it is relatively easy to create new service records for additional services and simplify the user experience.

Setup

In order to create additional avahi service records, it is necessary to enable root SSH access to the ReadyNAS system.

The service file is a simple XML file which defines a service-group record.  The service-group record contains a number of elements which may vary according to the service being advertised.  The two essential elements are the name record, which defines the displayed name for the service in question, and the service record, which defines the type, port, and any other connection-related information.

The name element has one possible attribute – replace-wildcards – which can take a value of “yes” or “no”.  If the attribute is present and the value is “yes”, then a %h can be used in the value which will be automatically substituted with the host name of the system.

The service element groups together the necessary information for service connectivity.  The two most essential elements it contains are the type element and the port element.  The type is the is the official service type as defined by RFC 2782 and the port is simply the listening port number.

Depending on the service, there may be additional elements or attributes that are necessary to have a properly formatted service file.  Be sure to consult the documentation to ensure the service is properly defined before making any changes.

Example

The following is an example configuration that enables service discovery for SSH:


<?xml version="1.0" standalone='no'?>
<service-group>
<name replace-wildcards="yes">SSH on %h</name>
<service>
<type>_ssh._tcp</type>
<port>22</port>
</service>
</service-group>

To activate this service, perform the following actions:

  1. Login (via ssh) as “root” to the ReadyNAS appliance.
  2. Navigate to the configuration directory.

    cd /etc/avahi/services

  3. Create a new file named ssh.service containing the configuration information listed above.
  4. Restart the avahi service to load the new service file.

    kill -SIGHUP `ps ax | grep avahi | grep -v grep | awk '{ print $1 }'`