SE Linux is a feature of the Linux kernel that provides mandatory access control. This policy based access control system grants far greater control over the resources on a machine than standard Linux access controls such as permissions.
Many modern Linux distributions are shipping with SELinux enabled by default, Fedora 14 and Rhel 6 both install with it enabled.
When you run Recital Web on a SELinux enabled machine and navigate to the default.rsp page you will see something similar to the screen shot below.

If you launch the SELinux troubleshooter you will see the following problem.
SELinux is blocking the apache server from accessing the Recital server running on port 8001.

To manage you SELinux policy you must have the policycoreutils package group installed. The policycoreutils contains the policy core utilities that are required for basic operation of a SELinux system.
If you wish to use a GUI tool, you must install the policycoreutils-gui package.
At the command prompt execute the following:
As root
$ yum install policycoreutils
$ semanage port -a -t http_port_t -p tcp 8001
$ service recital restart
$ service httpd restart
We use the semanage command here to allow the http server access to port 8001. Once you have completed the steps detailed above you can go and navigate back to the default.rsp page in your borwser, where you will find the permission denied message is now replaced by the default.rsp page.

SELinux does a great job of restricting services and daemons so rather than simply disabling it, why not work with it!
When it comes to security, every little bit helps...
When you start the loadbalancer.org appliance you will see the following:
Default login:
Username: root
Password: loadbalancer
Access to webclient from an external client is:
http://192.168.1.129:9080
http://192.168.1.129:9443
You can access the web administrator using the IP and ports described onscreen.
For the sri lanka porject we are looking for performance and the network diagram indicates we are happy to have the cluster on the same subnet as the rest of the network.
Direct routing is the fasted performance possible, it has the advantage over NAT that the Loadbalancer does not become a bottleneck for incoming and outgoing packets. With DR the loadbalancer simply examines incoming packets and the servers to route the packets directly back to the requesting user.
The web interfaceis the only way to fully configure the loadbalancer vm. The console tool lbwizard will get it initiallised and any further configurations can then be done via the webinterface.
Using lbwizard for the Sri lanka configuration follow these steps.
On the first Loadbalancer:
//Start
Is this unit part for a HA Pair?
YES
Have you already setup the Slave?
NO
Is this a one-armed configuration?
YES
Enter the IP Address for the interface eth0?
Enter IP address you wish to be assigned to the SLAVE loadbalancer.
Enter the netmask for interface eth0?
Enter netmask for the subnet.
Enter the Floating IP adrress?
Enter the IP address that will be IP assosiacted the the HA-pair of loadbalancers.
//Finish
On the 2nd loadbalancer VM, run the lbwizard.
//Start
Is this unit part of an HA-Pair?
YES
Have you already set up the Slave?
YES
What is the slave units UP address?
Enter the IP which you entered when configuring the other loadbalancer VM.
Is this a one-armed configuration?
YES
Enter the IP Address for the interface eth0?
Enter the IP that will be assigned to the MASTER loadbalancer
Enter the netmask for interface eth0?
Enter the subnet netmask.
Enter the Floating IP address?
Enter the IP address that will be IP assosiacted the the HA-pair of loadbalancers.
Enter the address of the default gateway?
Enter the deafult gateway for the subnet.
Enter the IP of the nameserver?
Enter the dns server.
Enter the port for the first Virtual server?
Enter 22 for ssh
Enter the IP address of the first real server?
Enter the real IP of the first appserver
//Finish
Now this is complete we need to go to the web admin interface to configure the 2nd Real Server. As the lbwizard program will only allow you to configure 1 real server.
Now login to the web admin using the default password:
username: loadbalancer
password: loadbalancer
Note: Connect to the IP you have now set for your master loadbalancer
Goto the edit configuration tab
Now click add a real server:
Enter a label
IP address of the server plus the port of the service i.e. 192.168.1.125:22
Edit Configuration -> Virtual Servers
persistancte -> NO
Scheduler-> LC
LC - Least-Connection: assign more jobs to real servers with
fewer active jobs.
Service to check -> custom1
Check port -> 22
Forwarding Method -> DR
Feedback Method -> Agent
Arp Problem when using DR
Every real server must be configured to respond to the VIP address as well as the RIP
address.
You can use iptables (netfilter) on the real server to re-direct incoming packets destined for the virtual
server IP address.
This is a simple case of adding the following command to your start up script (rc.local):
//replace 10.0.0.21 with the Virtual Server IP
iptables -t nat -A PREROUTING -p tcp -d 10.0.0.21 -j REDIRECT
chkconfig iptables on
- For building shared libraries on the MAC the following need to be set
-
- The shared library file extension should be .dylib
- The compile flag is -dynamic
- For accessing the shared libraries at runtime
-
- DYLD_LIBRARY_PATH needs to be set to the location of the shared libraries
- Useful utilities for shared library support
-
- The following command will display the table of contents of the dynamically linked library
otool -TV sharedlibraryfile.dylib
In this article Barry Mavin, CEO and Chief Software Architect for Recital, details on how to use the Client Drivers provided with the Recital Database Server to work with local or remote server-side JDBC data sources.
Overview
The Recital Universal .NET Data Provider provides connectivity to the Recital Database Server running on any supported platform (Windows, Linux, Unix, OpenVMS) using the RecitalConnection object.
The Recital Universal JDBC Driver provides the same functionality for java applications.
The Recital Universal ODBC Driver provides the same functionality for applications that use ODBC.
Each of the above Client Drivers use a connection string to describe connections parameters.
The basic format of a connection string consists of a series of keyword/value pairs separated by semicolons. The equals sign (=) connects each keyword and its value.
The following table lists the valid names for keyword/values.
| Name | Default | Description |
|---|---|---|
|
Data Source |
The name or network address of the instance of the Recital Database Server which to connect to. | |
| Directory | The target directory on the remote server where data to be accessed resides. This is ignored when a Database is specified. | |
|
Encrypt |
false | When true, DES3 encryption is used for all data sent between the client and server. |
| Initial Catalog -or- Database |
The name of the database on the remote server. | |
| Password -or- Pwd |
The password used to authenticate access to the remote server. | |
| User ID | The user name used to authenticate access to the remote server. | |
|
Connection Pooling |
false | Enable connection pooling to the server. This provides for one connection to be shared. |
| Logging | false | Provides for the ability to log all server requests for debugging purposes |
| Rowid | true | When Rowid is true (the default) a column will be post-fixed to each SELECT query that is a unique row identifier. This is used to provide optimised UPDATE and DELETE operations. If you use the RecitalSqlGrid, RecitalSqlForm, or RecitalSqlGridForm components then this column is not visible but is used to handle updates to the underlying data source. |
| Logfile | The name of the logfile for logging | |
| Gateway |
Opens an SQL gateway(Connection) to a foreign SQL data source on
the remote server.
servertype@nodename:username/password-database e.g. oracle@nodename:username/password-database mysql@nodename:username/password-database postgresql@nodename:username/password-database -or- odbc:odbc_data_source_name_on_server oledb:oledb_connection_string_on_server jdbc:jdbc_driver_path_on_server;jdbc:Recital:args |
To connect to a server-side JDBC data source, you ue the gateway=value key/value pair in the following way.
gateway=jdbc:jdbc_driver_path_on_server;jdbc:Recital:args
You can find examples of connection strings for most ODBC and OLE DB data sources by clicking here.
Example in C# using the Recital Universal .NET Data Provider:
////////////////////////////////////////////////////////////////////////
// include the references below
using System.Data;
using Recital.Data;
////////////////////////////////////////////////////////////////////////
// The following code example creates an instance of a DataAdapter that
// uses a Connection to the Recital Database Server, and a gateway to
// Recital Southwind database. It then populates a DataTable
// in a DataSet with the list of customers via the JDBC driver.
// The SQL statement and Connection arguments passed to the DataAdapter
// constructor are used to create the SelectCommand property of the
// DataAdapter.
public DataSet SelectCustomers()
{
string gateway = "jdbc:/usr/java/lib/RecitalJDBC/Recital/sql/RecitalDriver;"+
"jdbc:Recital:Data Source=localhost;database=southwind";
RecitalConnection swindConn = new
RecitalConnection("Data Source=localhost;gateway=\""+gateway+"\");
RecitalCommand selectCMD = new
RecitalCommand("SELECT CustomerID, CompanyName FROM Customers", swindConn);
selectCMD.CommandTimeout = 30;
RecitalDataAdapter custDA = new RecitalDataAdapter();
custDA.SelectCommand = selectCMD;
swindConn.Open();
DataSet custDS = new DataSet();
custDA.Fill(custDS, "Customers");
swindConn.Close();
return custDS;
}
Example in Java using the Recital Universal JDBC Driver:
//////////////////////////////////////////////////////////////////////// // standard imports required by the JDBC driver import java.sql.*; import java.io.*; import java.net.URL; import java.math.BigDecimal; import Recital.sql.*; ////////////////////////////////////////////////////////////////////////
// The following code example creates a Connection to the Recital // Database Server, and a gateway to the Recital Southwind database. // It then retrieves all the customers via the JDBC driver. public void SelectCustomers() { // setup the Connection URL for JDBC String gateway = "jdbc:/usr/java/lib/RecitalJDBC/Recital/sql/RecitalDriver;"+ "jdbc:Recital:Data Source=localhost;database=southwind"; String url = "jdbc:Recital:Data Source=localhost;gateway=\""+gateway+"\";
// load the Recital Universal JDBC Driver new RecitalDriver(); // create the connection Connection con = DriverManager.getConnection(url); // create the statement Statement stmt = con.createStatement(); // perform the SQL query ResultSet rs = stmt.executeQuery("SELECT CustomerID, CompanyName FROM Customers"); // fetch the data while (rs.next()) { String CompanyID = rs.getString("CustomerID"); String CompanyName = rs.getString("CompanyName"); // do something with the data... } // Release the statement stmt.close(); // Disconnect from the server con.close(); }
We are pleased to announce the immediate availability of Recital 10.0.1.
Included in this version are:
- Improved SQL query optimizer
- *New* apache plugin for building Recital web apps on x86_64 (mod_recital64.so)
- Performance improvements in connections to Recital Server and Recital Web.
- Recital ODBC driver performance improvements and bug fixes
- Miscellaneous bug fixes
Existing Recital 10 users can download the patch file and apply it to an existing installation.
Enjoy!
In this article Barry Mavin, CEO and Chief Software Architect for Recital provides details on how to use the Recital Universal .NET Data Provider with the Recital Database Server.
Overview
A data provider in the .NET Framework serves as a bridge between an application and a data source. A data provider is used to retrieve data from a data source and to reconcile changes to that data back to the data source.
Each .NET Framework data provider has a DataAdapter object: the .NET Framework Data Provider for OLE DB is the OleDbDataAdapter object, the .NET Framework Data Provider for SQL Server is the SqlDataAdapter object, the .NET Framework Data Provider for ODBC is the OdbcDataAdapter object, and the .NET Framework Data Provider for the Recital Database Server is the RecitalDataAdapter object.
The Recital Universal .NET Data Provider can access any data sources supported by the Recital Database Server. It is not restricted to only access Recital data. It can be used to access server-side ODBC, JDBC and OLE DB data sources also.
Core classes of the Data Provider
The Connection, Command, DataReader, and DataAdapter objects represent the core elements of the .NET Framework data provider model. The Recital Universal .NET Data Provider is plug compatible with the .NET Framework Data Provider for SQL Server. All SQL Server classes are prefixed with "Sql" e.g. SqlDataAdaptor. To use the Recital Universal Data Adaptor, simply change the "Sql" prefix to "Recital" e.g. RecitalDataAdaptor.
The following table describes these objects.
| Object | Description |
|---|---|
| RecitalConnection | Establishes a connection to a specific data source. |
| RecitalCommand | Executes a command against a data source. |
| RecitalDataReader | Reads a forward-only, read-only stream of data from a data source. |
| RecitalDataAdapter | Populates a DataSet and resolves updates with the data source. |
Along with the core classes listed in the preceding table, a .NET Framework data provider also contains the classes listed in the following table.
| Object | Description |
|---|---|
| RecitalTransaction | Enables you to enlist commands in transactions at the data source. |
| RecitalCommandBuilder | A helper object that will automatically generate command properties of a DataAdapter or will derive parameter information from a stored procedure and populate the Parameters collection of a Command object. |
| RecitalParameter | Defines input, output, and return value parameters for commands and stored procedures. |
The Recital Universal .NET Data Provider provides connectivity to the Recital Database Server running on any supported platform (Windows, Linux, Unix, OpenVMS) using the RecitalConnection object. The Recital Universal .NET Data Provider supports a connection string format that is similar to the SQL Server connection string format.
The basic format of a connection string consists of a series of keyword/value pairs separated by semicolons. The equal sign (=) connects each keyword and its value.
The following table lists the valid names for keyword values within the ConnectionString property of the RecitalConnection class.
| Name | Default | Description |
|---|---|---|
| Data Source -or- Server -or- Servername -or- Nodename |
The name or network address of the instance of the Recital Database Server which to connect to. | |
| Directory | The target directory on the remote server where data to be accessed resides. This is ignored when a Database is specified. | |
| Encrypt -or- Encryption |
false | When true, DES3 encryption is used for all data sent between the client and server. |
| Initial Catalog -or- Database |
The name of the database on the remote server. | |
| Password -or- Pwd |
The password used to authenticate access to the remote server. | |
| User ID -or- uid -or- User -or- Username |
The user name used to authenticate access to the remote server. | |
| Connection Pooling -or- Pool |
false | Enable connection pooling to the server. This provides for one connection to be shared. |
| Logging | false | Provides for the ability to log all server requests for debugging purposes |
| Rowid | true | When Rowid is true (the default) a column will be post-fixed to each SELECT query that is a unique row identifier. This is used to provide optimised UPDATE and DELETE operations. If you use the RecitalSqlGrid, RecitalSqlForm, or RecitalSqlGridForm components then this column is not visible but is used to handle updates to the underlying data source. |
| Logfile | The name of the logfile for logging | |
| Gateway |
Opens an SQL gateway(Connection) to a foreign SQL data source on the remote server.
The gateway can be specified in several formats: |
Populating a DataSet from a DataAdaptor
The ADO.NET DataSet is a memory-resident representation of data that provides a consistent relational programming model independent of the data source. The DataSet represents a complete set of data including tables, constraints, and relationships among the tables. Because the DataSet is independent of the data source, a DataSet can include data local to the application, as well as data from multiple data sources. Interaction with existing data sources is controlled through the DataAdapter.
A DataAdapter is used to retrieve data from a data source and populate tables within a DataSet. The DataAdapter also resolves changes made to the DataSet back to the data source. The DataAdapter uses the Connection object of the .NET Framework data provider to connect to a data source and Command objects to retrieve data from and resolve changes to the data source.
The SelectCommand property of the DataAdapter is a Command object that retrieves data from the data source. The InsertCommand, UpdateCommand, and DeleteCommand properties of the DataAdapter are Command objects that manage updates to the data in the data source according to modifications made to the data in the DataSet.
The Fill method of the DataAdapter is used to populate a DataSet with the results of the SelectCommand of the DataAdapter. Fill takes as its arguments a DataSet to be populated, and a DataTable object, or the name of the DataTable to be filled with the rows returned from the SelectCommand.
The Fill method uses the DataReader object implicitly to return the column names and types used to create the tables in the DataSet, as well as the data to populate the rows of the tables in the DataSet. Tables and columns are only created if they do not already exist; otherwise Fill uses the existing DataSet schema.
Examples in C#:
////////////////////////////////////////////////////////////////////////
// include the references below
using System.Data;
using Recital.Data;
////////////////////////////////////////////////////////////////////////
// The following code example creates an instance of a DataAdapter that
// uses a Connection to the Recital Database Server Southwind database
// and populates a DataTable in a DataSet with the list of customers.
// The SQL statement and Connection arguments passed to the DataAdapter
// constructor are used to create the SelectCommand property of the DataAdapter.
public DataSet SelectCustomers()
{
RecitalConnection swindConn = new
RecitalConnection("Data Source=localhost;Initial Catalog=southwind");
RecitalCommand selectCMD = new
RecitalCommand("SELECT CustomerID, CompanyName FROM Customers", swindConn);
selectCMD.CommandTimeout = 30;
RecitalDataAdapter custDA = new RecitalDataAdapter();
custDA.SelectCommand = selectCMD;
swindConn.Open();
DataSet custDS = new DataSet();
custDA.Fill(custDS, "Customers");
swindConn.Close();
return custDS;
}
////////////////////////////////////////////////////////////////////////
// The following example uses the RecitalCommand, RecitalDataAdapter and
// RecitalConnection, to select records from a database, and populate a
// DataSet with the selected rows. The filled DataSet is then returned.
// To accomplish this, the method is passed an initialized DataSet, a
// connection string, and a query string that is a SQL SELECT statement
public DataSet SelectRecitalRows(DataSet dataset, string connection, string query)
{
RecitalConnection conn = new RecitalConnection(connection);
SqlDataAdapter adapter = new RecitalDataAdapter();
adapter.SelectCommand = new RecitalCommand(query, conn);
adapter.Fill(dataset);
return dataset;
} - New MD5( expC ) function to calculate an MD5 crypto key from any character expression
- New MD5FILE( expC ) function calculates an MD5 crypto key for a given filename. If the filename is a pattern e.g *.* it will calculate the key across all files matching the pattern
- New mod_recital.so available for using Recital Web on linux x86_32
- New mod_recital64.so available for using Recital Web on linux x86_64
Recital is a dynamic programming language with an embedded high performance database engine particularly well suited for the development and deployment of high transaction throughput applications.
The Recital database engine is not a standalone process with which the application program communicates. Instead, the Recital database is an integral part of any applications developed in Recital.
Recital implements most of the SQL-99 standard for SQL, but also provides lower level navigational data access for performing high transaction throughput. It is the choice of the application developer whether to use SQL, navigational data access, or a combination of both depending upon the type of application being developed.
The Recital database engine, although operating as an embedded database in the user process, multiple users and other background processes may access the same data concurrently. Read accesses are satisfied in parallel. Recital uses automatic record level locking when performing database updates. This provides for a high degree of database concurrency and superior application performance and differentiates the Recital database from other embeddable databases such as sqlite that locks the entire database file during writing.
Key features of the Recital scripting language include:
- High performance database application scripting language
- Modern object-oriented language features
- Easy to learn, easy to use
- Fast, just-in-time compiled
- Loosely-typed
- Garbage collected
- Static arrays, Associative arrays and objects
- Develop desktop or web applications
- Cross-platform support
- Extensive built-in functions
- Superb built-in SQL command integration
- Navigational data access for the most demanding applications
- Scripting language is upward compatible with FoxPRO
Key features of the Recital database include:
- A broad subset of ANSI SQL 99, as well as extensions
- Cross-platform support
- Stored procedures
- Triggers
- Cursors
- Updatable Views
- System Tables
- Query caching
- Sub-SELECTs (i.e. nested SELECTs)
- Embedded database library
- Fault tolerant clustering support
- Chronological data versioning with database timelines
- Optional DES3 encrypted data
- Hot backup
- Client drivers for ODBC, JDBC and .NET