Introducing Vista Search

The first version of the Vista Logic and Protocol bundles have been merged into the default branch.  Vista provides a fast full-text indexing method for content stored on the OpenGroupware Coils server.  The Vista component can currently index Contact, Document [meta-data], Enterprise, Note, and Task entities.  All the text fields of these entities are indexed including the values of object properties and company values. Utilizing the power of Vista search is performed by performing HTTP requests to the protocol exposed at "/vista" on the server. 

curl -v -u fred -o output 'http://coils.example.com/vista?term=detroit&term=steel&archived&type=enterprise'
Authenticate as user fred and search for enterprise entities, regardless of archived status, that contain the terms "detroit" and "steel".

The results of the HTTP request are JSON encoded Omphalos representations of the first 100 entities to match the specified criteria.  The default Omphalos detail level is 2056 [Comment + Company Values].  If an alternate detail level is desired this default can be overridden using the "detail" URL parameter.   The following URL parameters are supported:

• archived - Include entities in the search regardless of there archived status. If no specified archived entities will be excluded from the search results.
• detail - The Omphalos detail level to use when representing entities in the response.  It is important to recognize that specifying a high detail level will reduce performance.
• term - Specify a search term.  Any number of terms may be specified.
• type - Limit the searched entities by type.  If no type is specified all indexed entities are searched regardless of type.  Multiple type parameters may be specified.

For code local to the server searches can be performed using the "vista::search" Logic command:

results = ctx.run_command('vista::search', keywords = [ 'detroit', 'steel' ],
                                                                    entity_types = [ 'enterprise' ],
                                                                    include_archived = True)
Peform a Vista search via Logic for all enterprises, regardless of archived status, that contain the terms "detroit" and "steel".

The recently packaged tool coils-request-index can request the creation or update of an entities search vector.  Normally when an entity is modified a re-index is requested automatically [search vector generation happens in the background and is performed by the coils.vista.index component].  However, if large changes are made to the database or for the initial index generation the use of coils-request-index may expedite the process.

coils-request-index --contact --enterprises --notes --documents --tasks
Request an index/reindex of all the entities of the specified types.

coils-request-index --objectid=10100
Request an index/reindex the entity with objectId 10,100.

If the index is already current for the entity the vector generation request will be discarded.
This new feature does require a schema update to existing OpenGroupware databases.  This schema update will be required for version 0.1.45.

CREATE TABLE vista_vector (
  object_id  INT PRIMARY KEY,
  version    INT DEFAULT 0,
  edition    INT,
  entity     VARCHAR(25) NOT NULL,
  event_date DATE DEFAULT 'TODAY', 
  archived   BOOL DEFAULT FALSE,
  keywords   VARCHAR(128)[],
  vector     tsvector);
CREATE INDEX vista_idx_i0 ON vista_vector (entity);
CREATE INDEX vista_idx_i1 ON vista_vector (event_date);
CREATE INDEX vista_idx_i2 ON vista_vector USING gin(vector);

Vista search utilizes PostgreSQL's powerful tsearch text indexing module.  tsearch provides lexeme oriented indexing - so the server knows, for example, that "rats" and "rat" share the same stem.  Thanks to tsearch Vista searches are not only fast - they're clever!

Accessing Server Configuration (Defaults)

When developing Logic, either a Command or a Service component, one frequent need is to check the value of a server's configuration directive [a "default" in OpenGroupware speak].  Accessing server configuration is performed using an instance of the ServerDefaultsManager object.  The following code retrieves the value of the CoilsListenAddress address; and if no such default is defined it returns the value "127.0.0.1".

sd = ServerDefaultsManager()
HTTP_HOST = sd.string_for_default('CoilsListenAddress', '127.0.0.1')

The ServerDefaultsManager will cache the server's configuration - so if you are going to be checking a lot of defaults is better to keep the object around rather than repeatedly creating it. The ServerDefaultsManager provides the following methods for retrieving server defaults:

• bool_for_default(directive) - Values of boolean configuration values are stored as "YES" and "NO" strings.  Actually, any value that isn't "YES" is interpreted as False, which is also the default if no such directive is defined. The value returned by the method is a Python bool type.
• string_for_default(directive, default value) - Returns the value of the default as string or returns the specified default value if no such directive is defined.
• integer_for_default(directive, default value) - Returns the value as an integer, or returns the specified default value if no such directive is defined. An exception is raised if the value cannot be represented as an integer.
• default_as_dict(directive, default value) - Returns the value of the specified directive as a dictionary, or the specified default value if no such directive is defined.  An exception is raised if the value is not a dictionary.
• default_as_list(directive, default) - Returns the value as a list, or the specified default value if no such directive is defined.  An exception is raised if the value is not a list.

Regarding the actually loading of defaults the defaults manager will load from (or save to) one of two sources.  If the file ".server_defaults.pickle" exists in the document root of the server the defaults are loaded from (and saved to) that Python pickle file; otherwise the defaults are loaded from (and saved to) the OpenSTEP plist file at ".libFoundation/Defaults/NSGlobalDomain.plist".  Use of the OpenSTEP plist file facilitates parallel operation of OpenGroupware Coils with Legacy - both OpenGroupware Coils and OpenGroupware Legacy will operate using the shared configuration. 

One caveat to remember is that OpenSTEP plist files are always stored in the ISO8859-1 encoding.  This includes both the server defaults and user defaults.  Both OpenGroupware Coils and OpenGroupware Legacy always store user defaults in OpenSTEP plist format.  Facilities for parsing and writing OpenSTEP plist files are provided by the coils.foundation module.

If you are developing a remote component that does not have access to the server's document root your component can acquire a copy of the server's configuration by sending a "get_server_defaults" message to the coils.administrator component.  The payload of the response should contain the cluster's GUID [as the "GUID" key] and a copy of all the server defaults [in the "defaults" key).

Invoking an OIE Route from PHP

The repository not contains a PHP class making it simple to invoke an OIE workflow from PHP.  See the oie.php file.  Using the OIEProcess class defined in the file processes can be created and the process id and input message UUID known.

$HTTPROOT   = "http://coils.example.com";
$ROUTENAME  = "TEST_MailBack";
$PARAMETERS = array('myParameter'=>'YOYO MAMA', 'otherParam'=>4);
$request = new OIEProcess($HTTPROOT, $ROUTENAME, $PARAMETERS);
if ($request->start('adam', '*******', fopen('/etc/passwd', 'r'), 'text/plain') == 'OK') {
    echo "\n";
    echo "Process ID: " . $request->get_process_id() . "\n";
    echo "Message UUID: " . $request->get_message_id() . "\n";    
}

The start method returns either "OK", "OIEERR" (OIE refused the request), or "SYSERR" (the curl operation failed).  The first and second parameters for start is the user credentials, the optional third and fourth parameters is the input message stream and the payload mimetype.  If no mimetype is specified a default of "application/octet-stream" is assumed.

RabbitMQ Appliance

An appliance for easily deploying RabbitMQ, the AMQP message broker, has been made available on SUSE Studio.  This simplifies the deployment of OpenGroupware Coils in a vritualized environment by removing the need to provision for that service. More information on the RabbitAMQPServer project page.

OpenGroupware Server Side Filters

OSSF [OpenGroupware Server Side Filter] modules provide for server-side transformations of work-flow messages and groupware documents via simple HTTP GET requests. Use of OSSF facilitates the simplification of client applications by allowing them to offline some complex and expensive operations to the OpenGroupware Coils server.  OSSF modules can be used when requesting message or document content via either the AttachFS or the WebDAV presentation protocols.

All activation of OSSF is performed by adding parameters to the URL when retrieving the document or message.  The URL parameter "ossfchain" activates a sequence of service-side filters. The value of this parameter is a comma-separated value of filters to activate; the filters will be daisy-chained in the order they are specified in the parameter. Parameters can be specified for each filter by passing those parameters in the URL prefixed by the appropriate filter's sequence in the OSSF chain. So a parameter of "0.name=value" will pass the specified value as the parameter "name" to the first filter in the chain. A value of "1.name=value" will do the pass the parameter to the second filter in the chain, and so on.

Even if only one filter is specified the parameters for that filter must be prefixed with "0.".
If a filter requires no parameters then no parameters need to be specified.

The sequence of filters may be important; in some cases a filter may change the MIME type of the data-stream and some filters will only accept input of an appropriate type.  For example in "count" mode the "json" OSSF will change the MIME-type of the document from "application/json" to "text/plain"  The "pdftotext" OSSF will also change the MIME type from "application/pdf" to "text/plain".

Currently implemented OSSF modules are:

•   json - Supports counting, paginating, and filtering JSON content.
•   pdftotext - Returns just the plain text portion of a PDF document.
•   thumbnail - Resizes image content allowing the client to quickly download just a thumbnail of the specified document.

The JSON OSSF

The json OSSF allows the client to request information about the contents of a JSON document or retrieve only a selected portion of the document. The primary use-case for the json OSSF is the instance where a client application needs to access a large JSON document; this can be slow and resource intensive if the client does not itself support streaming parsing or caching. With the json OSSF the client can paginate through the document, or filter it to just the desired records, just by specifying URL parameters.

The json OSSF can operate in one of two modes: "count" and "pagination". Mode is specified via the "mode" parameter. In both modes the filter requires a "path" parameter; this value specifies the path to the elements of the JSON document that should either to be returned either to the client or counted.

No additional parameters are supported in "count" mode. The result of "count" mode is a "text/plain" response indicating the number of records found in the JSON document.
In "pagination” mode a "range” parameter is supported; if no range is specified pagination will always process the entire input stream. The value format for range is two integers separated by a hyphen, such as "1001-2000”,to indicate a specific range or a head / tail range such as "-1000” or "1001-” which will return all items up to or following the specified value. Ranges are inclusive; so a range of "1-5” will return five elements [if available].

The "criteria” parameter allows the data elements from the JSON input document to be filtered based upon value; all the elements matching the specified path are evaluated until the specified range is filled or the input stream is exhausted. Criteria is specified in the form of "key,value”. If the key can be interpreted as an integer value all list, dictionary and string elements matching the path are evaluated; the key is used as a key for dictionary values and as an index for list and string elements. If the key is not numeric only dictionary elements are evaluated. Numeric types, either integer or decimal, cannot be evaluated with the criteria parameter. All evaluation is based upon equality; comparisons to character or string types are case-sensitive. When specifying a key to act as an offset in a string or list the first character of the value is 0.

http://coils.example.com/dav/Workflow/Routes/ExampleRoute/17945730/output?ossfchain=json&0.mode=pagination&0.path=item&0.range=1-5&0.criteria=1,70801310'
The URL to filter the JSON output message of process 17945730; this will return the first five elements [range=1-5] of the outer-most list [path=item] when the second element of the list has the value “70801310” [criteria=1,70801310].

The pdftotxt OSSF

The “pdftotxt” filter will attempt to return all of the text from the PDF input stream. The output of this filter is primarily intended to facilitate searching.  The output is unstructured text with a MIME type of “text/plain”.

The thumbnail OSSF

The "thumbnail" filter will modify either a PNG or JPEG image to be no larger than any of the dimensions specified; desired maximum width and height are specified using the "width" and "height" parameters, respectively.  If either "width" or "height" are not specified then they default to the original width or height of the image, respectively. The aspect ratio of the image is preserved.

Thumbnails are generated using a high-quality anti-aliasing filter.

An input stream representing data other than a PNG or JPEG will raise an exception thus terminating the filter chain and returning an HTTP error code for the clients request.

http://coils.example.com/dav/Projects/Facility%20-%20TriadService%20Troy/Documents/Photos/Facility-1-OGo16235520.JPG?ossfchain=thumbnail&0.width=200&0.height=200Retrieve a 200x200 thumbnail of the specified groupware document.

In Closing

OSSF makes some tedious things easier for your custom web UI or other client.  If you have an idea or need for a useful OSSF join the coils-project mail list and let's discuss implementing it.  Building an OSSF is almost as easy as using them.  More detail regarding OSSF is available in the WMOGAG [Whitemice OpenGroupware Administrator's Guide] document.

Log Rotation & OpenGroupware

OpenGroupware Legacy logs to numerous files in the directory /var/log/opengroupware; OpenGroupware Coils logs to the file /var/log/coils.log.  Managing these log files is an important part of service administrations - bad things happen if the system's /var/log fills up.  Rotating these files can be accomplished using the excellent logrotate facility provided by your LINUX distribution. logrotate reads all the files present in the /etc/logrotate.d directory - each service that requires log rotation can simply create configuration file for itself.  The recommended log rotation configurations for OpenGroupare Legacy and OpenGroupware Coils are as follows:

/var/log/opengroupware/*.log {
    copytruncate
    rotate 5
    daily
    size 10M
    missingok
    notifempty
    sharedscripts
    compress
}
The file /etc/logrotate.d/ogo for rotating OpenGroupware Legacy log files.

/var/log/coils.log {
    copytruncate
    rotate 5
    daily
    size 10M
    missingok
    notifempty
    sharedscripts
    compress
}
The file /etc/logrotate.d/coils for rotating OpenGroupware Coils log files.

You can adjust the "rotate" parameter to change how many log files you want to keep.  The setting of "rotate 5" and "daily" means the log rotator will keep 5 days worth of logs.  The most important option is "copytruncate" - this instructs the log rotator to make a copy of the current log file and then truncate the existing log file rather than moving the file and having a new file created, this allows the OpenGroupware services to continue to use the same file-handle for logging during [and after] the log rotation operation.

Installing Horde On CentOS6

Progress is being made on first-class integration between OpenGroupware Coils and Horde 4; that is, using Horde 4 as a Web 2.0 / AJAX front-end to the various services provided by OpenGroupware Coils.  This integration is primarily implemented using a custom JSON-RPC protocol bundle designed specifically for integration with Horde.  This article walks through the install to achieve a basic Horde installation.  Subsequent articles will document how to achieve OpenGroupware Coils integration.

This installation procedure assumes:

• You'll be using a memcache instance for caching.
• A PostgreSQL database for server meta-data and Horde user preferences;  probably the same PostgreSQL instance you use for your OpenGroupware databse. But for this example we are just setting up a local PostgreSQL instance.  We'll cover installing OpenGroupware Coils on CentOS6 soon.
• You'll be installing Horde into a virtual host in the folder "/srv/www/vhosts/horde".
• The horde install will have it's own PEAR repository as separated from the system PEAR repository as possible.
• The ImageMagick packages will be installed to allow Horde to manipulate images (such as creating thumbnails of image attachments to e-mail).
• GPG will be installed in order to support encrypted e-mails and notes.
• We are starting with a clean CentOS6 install of the basic server profile.
• SELinux is disabled (edit /etc/sysconfig/selinux). In a subsequent article re-enabling SELinux will be documented. 
• To access this instance remotely the TCP/80 port must be allowed via the host's firewall configuration. If you intend to enable TLS/SSL (secure) access port TCP/443 must also be allowed [on CentOS6 use the system-config-firewall-tui to perform basic firewall configuration configuration, production systems should consider using a more sophisticated tool such as FWBuilder].

Step#1 Install the required packages.

yum install php-devel php-pear make gcc libidn-devel pam-devel pcre-devel postgresql-devel libidn-devel memcached-devel memcached libmemcached zlib-devel cyrus-sasl-devel ImageMagick-devel ImageMagick php-ldap php-intl php-mbstring php-pdo php-pecl-apc php-pgsql php-soap php-tidy php-xml php-xmlrpc php-pecl-memcache libtidy-devel

Step#2 Create the vhost directory and initialize the PEAR package database.

mkdir -p /srv/www/vhosts/horde
pear config-create  /srv/www/vhosts/horde /srv/www/vhosts/horde/pear.conf
pear -c /srv/www/vhosts/horde/pear.conf install pear

Step#3 Add the Horde channel to the PEAR configuration and initialize the Horde role.  The last "run-scripts" command will prompt you for the root of the Horde installation; enter "/srv/www/vhosts/horde".

/srv/www/vhosts/horde/pear/pear -c  /srv/www/vhosts/horde/pear.conf channel-discover pear.horde.org
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf  install horde/horde_role
/srv/www/vhosts/horde/pear/pear -c  /srv/www/vhosts/horde/pear.conf run-scripts horde/Horde_Role

Step#4 Set the timezone in your php.ini file Edit the /etc/php.ini to set the date.timezone property to the server's local timezone.  For example: "date.timezone=America/Detroit"

Step#5 Install the re2c package from the DAG repo.  You can optionally add the DAG repo to your system or just pull this one package.  re2c is used by the PHP interpreter to efficiently compile regular expressions.

curl --location -o /tmp/re2c-0.13.5-1.el6.rf.x86_64.rpm http://mandril.creatis.insa-lyon.fr/linux/dag/redhat/el6/en/x86_64/dag/RPMS/re2c-0.13.5-1.el6.rf.x86_64.rpm
rpm -Uvh /tmp/re2c-0.13.5-1.el6.rf.x86_64.rpm

Step#6 As in Step#5 you can add the DAG repo to your system or just pull the two packages necessary to build the geoip module.  Horde will use this to relate hosts to geographic regions.

curl --location -o /tmp/geoip-devel-1.4.6-1.el6.rf.x86_64.rpm http://mandril.creatis.insa-lyon.fr/linux/dag/redhat/el6/en/x86_64/dag/RPMS/geoip-devel-1.4.6-1.el6.rf.x86_64.rpm
curl --location -o /tmp/geoip-1.4.6-1.el6.rf.x86_64.rpm http://mandril.creatis.insa-lyon.fr/linux/dag/redhat/el6/en/x86_64/dag/RPMS/geoip-1.4.6-1.el6.rf.x86_64.rpm
rpm -Uvh  /tmp/geoip-1.4.6-1.el6.rf.x86_64.rpm /tmp/geoip-devel-1.4.6-1.el6.rf.x86_64.rpm
pecl install geoip
echo "extension=geoip.so" > /etc/php.d/geoip.ini

Step#7 Build and install the Imagick extension which will allow Horde to efficiently manipulate images.

pecl install Imagick
echo "extension=imagick.so" > /etc/php.d/imagick.ini

Step#8 Build the tidy module which Horde can use to sanitize HTML content.

pecl install tidy
echo "extension=tidy.so" > /etc/php.d/tidy.ini

Step#9 Build the lzf module which allows Horde to efficiently compress and decompress data.

pecl install lzf
echo "extension=lzf.so" > /etc/php.d/lzf.ini

Step#10 Install the PEAR packages. In this example we manually install several PEAR modules first to verify that PEAR installation is working and because we want to ensure that these optional modules get installed as we will be depending on their existence in this setup.  Particularly the Net_Sieve and Horde_Memcache do not install my default./srv/www/vhosts.

/srv/www/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install HTTP_Request
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install Net_SMTP
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install Net_Sieve
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install Auth_SASL
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install Net_DNS2
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install horde/horde
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install horde/Horde_Memcache
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install horde/imp
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install horde/turba
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install horde/kronolith
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install horde/mnemo
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install horde/nag
/srv/www/vhosts/horde/pear/pear -c /srv/www/vhosts/horde/pear.conf install horde/ingo

Step#11 Initialize the configuration.

cp  /srv/www/vhosts/horde/config/conf.php.dist  /srv/www/vhosts/horde/config/conf.php
setfacl -m u:apache:rw /srv/www/vhosts/horde/config/conf.php
touch /srv/www/vhosts/horde/imp/config/conf.php
touch /srv/www/vhosts/horde/ingo/config/conf.php
touch /srv/www/vhosts/horde/turba/config/conf.php
touch /srv/www/vhosts/horde/kronolith/config/conf.php
touch /srv/www/vhosts/horde/nag/config/conf.php
touch /srv/www/vhosts/horde/mnemo/config/conf.php
setfacl -m u:apache:rw /srv/www/vhosts/horde/imp/config/conf.php
setfacl -m u:apache:rw /srv/www/vhosts/horde/ingo/config/conf.php
setfacl -m u:apache:rw /srv/www/vhosts/horde/turba/config/conf.php
setfacl -m u:apache:rw /srv/www/vhosts/horde/kronolith/config/conf.php
setfacl -m u:apache:rw /srv/www/vhosts/horde/nag/config/conf.php
setfacl -m u:apache:rw /srv/www/vhosts/horde/mnemo/config/conf.php

Step#12 Enable name based virtual hosting.
Edit the /etc/httpd/conf/httpd.conf file and uncomment the line reading "NameVirtualHost *:80".

Step#13  Create a virtual host entry for the Horde instance. If you have a server-name / domain-name you should substitute that for "horde.example.com". Otherwise if this instance is merely for testing/development adding horde.example.com to your workstation's /etc/hosts file should be sufficient to allow you to access the instance. The domain "example.com" will never be issued as an actual domain (see RFC2606) so it is safe to use for development deployments.  Depending on your site's policies you may want to configure custom logging for this virtual host.

(cat <<EOF
<virtualhost *:80>
    ServerAdmin webmaster@horde.example.com
    ServerName horde.example.com
    ServerAlias horde
    DocumentRoot /srv/www/vhosts/horde
    <directory /srv/www/vhosts/horde>
       Options Indexes Includes FollowSymLinks
       Order allow,deny
       Allow from all
    </directory>
   php_value include_path /srv/www/vhosts/horde/pear/php
   SetEnv PHP_PEAR_SYSCONF_DIR /srv/www/vhosts/horde
</virtualhost>
EOF
) > /etc/httpd/conf.d/x-vhost-horde.conf

Step#14 Start the web server (Apache) and Memcache daemon.

service httpd start
chkconfig httpd on
service memcached start
chkconfig memcached on

Step#15 You should now be able to hit the CentOS6 instance with your web-browser and automatically be logged in as the Horde administrator!  Go the the Administration / Configuration page via the left-hand menu and you should see a list of the installed Horde applications as well as the first level of Horde modules that provide services to those applications (such as "Horde_Alarm", "Horde_Activesync", etc...).  If you don't see those additional Horde modules listed then something went wrong with your PEAR installation; start over and carfully watch the output of the commands for errors or warnings.



Step#16 Generate new configurations for all applications; to perform this function click the "Update all configuration" button. This will fill in the various conf.php files we created in Step#11.

Step#17 Provision a PostgreSQL database for use by the Horde instance. Caution: If you are reusing a PostgreSQL instance from other applications do not perform the "service postgresql initdb" command.

yum install postgresql-server
service postgresql initdb
service postgresql start
sudo  -u postgres createuser --no-password --no-createdb --no-createrole --no-superuser horde4
sudo  -u postgres createdb -E utf-8 -O horde4 horde4

Once the database is provision you need to allow the Horde instance to connect to the database. For simplicity of this example we are connecting to the instance of PostgreSQL on the localhost so we will simply change the configuration to trust local connections. For production deployments at least a password should be configured for the connection. To grant access edit the /var/lib/pgsql/data/pg_hba.conf file and change "ident" to "trust" on the line reading "host    all         all         127.0.0.1/32".  Then restart the PostgreSQL database so that it rereads this file: "service postgresql restart"

Step#18 Configure the database connectivity of the Horde instance. Now that Horde is up and running subsequent configuration is simple. Select Administration / Configuration from the left-hand menu. From the list of applications select "Horde" and then choose the "Database" tab.

• For database type choose "PostgreSQL"
• Check the box enabling persistent connections.
• For "username" enter "horde4"
• Change protocol to "TCP/IP"
• For "hostspec" and "port" enter "127.0.0.1" and "5432".
• For "database" enter "horde4".
• Leave "charset" as "utf-8" and "splitread" as "Disabled"
• Once the form is filled in click the "Generate Horde Configuration"

Step#19: Now click the "Update all DB schemas" button; this will initialize the database with the required tables.  Every time applications are updated this button will allow the database schema to be automatically updated. This first time you initialize Horde you should perform this operation until no more database schema error or notices appear - typically this requires performing this operation twice.
Step#20The last steps involved in configuring the base Horde configuration is to enable a caching system to accelerate performance. For this example we are using the memcache service we enabled in Step#14. Navigate to Administration / Configuration, select the Horde application, and then choose the Memcache Server tab.

• Change the status to "Enabled"
• For "hostspec" and "port" enter "127.0.0.1" and "11211".  These are the default Memcache configuration parameters.
• Enable persistent connections by checking the "persistent" box
• Change to the "Cache System" tab.

• For the cache system driver select "Use a Memcache server".
• Click the "Generate Horde Configuration" button.

Your Horde configuration is now configured with database connectivity and an active caching system.  In subsequent articled the procedure for configuring specific applications and enabling OpenGroupware Coils integration.