Recital

Login Register
Mac OS X leopard supports Universal Binaries so executables and dynamic libraries can be run on multiple architectures. A good example of this is the default apache install on Mac OS X. 
In order to compile apache modules for this architecture you must use the following flags when configuring the apache install.
 ./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' --with-apxs=/usr/sbin/apxs
Then you must pass the these additional flags to the apxs command in order to generate a Universal Binary shared module.
-Wl,-dynamic -Wl,'-arch ppc' -Wl,'-arch ppc64' -Wl,'-arch i386' -Wl,'-arch x86_64' 
-Wc,-dynamic -Wc,'-arch ppc' -Wc,'-arch ppc64' -Wc,'-arch i386' -Wc,'-arch x86_64' 
If you then do a file command on the shared module it should return; 
$ file mod_recital.so 
mod_recital2.2.so: Mach-O universal binary with 4 architectures 
mod_recital2.2.so (for architecture ppc7400): Mach-O bundle ppc 
mod_recital2.2.so (for architecture ppc64): Mach-O 64-bit bundle ppc64 
mod_recital2.2.so (for architecture i386): Mach-O bundle i386 
mod_recital2.2.so (for architecture x86_64): Mach-O 64-bit bundle x86_64
The apache module files are stored in the /usr/libexec/apache2/ directory on a default apache install on the Mac and the configuration file is /private/etc/apache2/httpd.conf
Published in Blogs
Read more...
Hdparm can be used to view or set many hardware characteristics of IDE or SATA drives including optical drives (and even some SCSI drives).  For example, the read-lookahead feature can be enabled or disabled.  Also of interest is that the on board write caching can be disabled.  This may or may not be of use when trying to optimize the writing of data to the drive especially when the operating system and/or file system itself may also perform write caching.

Some options of hdparm are dangerous and are generally listed as such in the man page.

Hdparm is available from SourceForge and there is even a version for Windows.
Published in Blogs
Read more...

This article talks about the log files available in Recital products and how to enable logging when required.

Overview

When discussing a problem with the Recital Support Team, one of the most common requests is that you enable logging and send them the log files produced. Log files along with error files are designed to provide detailed information about Recital processes and the prevailing environment and can be a fast-track to resolving a problem.

Log Files

There are three main types of log file:

  1. System Log
  2. Client/Server Communication Logs
  3. Custom Logs

System Log

The System log is a system-wide  all product log.  It tracks all login and logout operations from either Recital or the Recital Server. Logout details include the exit code: 0 for an error-free, 'normal' exit and the error number and message when an error has occurred. It also shows the licenses that have been loaded and any license error codes and messages. The system log filename is recital.log.
 

Client/Server Communication Logs

The Client/Server communication logs track the requests and responses between the Recital Server and its clients. The log files are as follows:


Filename Type Description

dbserver.log

System-wide

The Recital Server startup log. This logs any problems with the Recital Server startup.

port.log

System-wide

The port listener log. The port listener (or portserver) listens on port 8001 for client connection requests and spawns the appropriate server process.

net.log

Connection

The netserver log. The netserver is the Recital Server database and 4GL engine.

rsi.log

Connection

The Recital Server Interface (RSI) Gateway log. This logs communication with the Database Gateways to SQL databases.

rec.log

Connection

The Recital Database Gateway log. The Recital Database Gateway (or recserver) is the SQL database engine for Recital Gateway data access.

mys.log

Connection

The MySQL Database Gateway log.

ora.log

Connection

The Oracle Database Gateway log.

inf.log

Connection

The Informix Database Gateway log.

ing.log

Connection

The Ingres Database Gateway log.

pos.log

Connection

The PostgreSQL Database Gateway log.

jdb.log

Connection

The JDBC Driver Database Gateway log.


Custom Logs

The Recital/4GL USERLOG() function can be used to log information to a user-specific log file for debugging or audit trail purposes. For full information on this function, please see the USERLOG() documentation.

Enabling Log Files

For instructions on enabling log files for individual products, please follow these links:

Enabling Log Files: Recital Server for Windows

To enable the system log file for the Recital Universal Application Server for Windows, include the following command in the UAS\config.db file:

set syslogging on

The Recital Server Manager System Logging tab allows for the viewing and resetting of the System log.

Section

Item

Description

System Logging

DateTime

Date and time stamp of the action.

Name

Login name used by connection

Action

Action logged: Login, Logoff, Errot

Details

Details of action

Buttons

Purge

Allows the log file to be reset

Refresh

Refreshes the display

To set up Client/Server logging, use the Recital Server Manager Settings tab to update the server's Registry entries:

The following Log file settings can be configured:

Item

Description

Log files Directory Path

Enter the directory in which log files will be created. The default is the UAS\log directory.

Enabled

Check to enable log file creation.

Versions

Check to enable log file versioning.

Listener

Click to view the current port listener log file

Server

Click to view the current netserver log file

Purge

Click to purge all log files

Enabling Log Files: Recital Server for Linux

To enable the system log file for the Recital Server for Linux, include the following command in the conf/config.db file:

set syslogging on

To set up Client/Server logging, the Recital Server can be started with the 'logging' parameter, in which case, all relevant logging will take place.

# service startup logging<

Alternatively, one or more of the following environment variables can be added to the dbserver.conf file or set at the Operating System prompt.  The Recital Server must be restarted before environment variable changes will be recognized.  Each environment variable should be set to the name of a log file.

Environment Variable

Logs Activity of...

UASLOG_PORT

Port Server (db_rsiserver)

UASLOG_NET

(Net) Server (db_netserver)

UASLOG_ORA

Oracle Server (db_oraserver)

UASLOG_INF

Informix Server (db_infserver)

UASLOG_ING

Ingres Server (db_ingserver)

UASLOG_JDB

JDBC Server (db_jdbserver)

UASLOG_REC

Recital Server (db_recserver)

Extract from recital.conf:

UASLOG_PORT="port.log" ; export UASLOG_PORT
UASLOG_NET="net.log"   ; export UASLOG_NET
UASLOG_ORA="ora.log"  ; export UASLOG_ORA
UASLOG_INF="inf.log"     ; export UASLOG_INF
UASLOG_ING="ing.log"   ; export UASLOG_ING
UASLOG_JDB="jdb.log"   ; export UASLOG_JDB
UASLOG_REC="rec.log"   ; export UASLOG_REC
DB_LOGDIR

If the environment variable DB_LOGDIR is set to an existing directory, all log files will be written to this directory.  If not, the log files will be created in the bin directory.

DB_LOGDIR is set in the conf/recital.conf file. By default it is set to the log directory:

DB_LOGDIR=${ROI_ROOT}log/           ; export DB_LOGDIR
DB_LOGVER

If the environment variable DB_LOGVER is greater than 0, version numbers are added to the file names.  For example, the activity of the first Net Server process will be logged to net.log, the second to net001.log, the third to net002.log etc. up to the maximum value of DB_LOGVER.

DB_LOGVER is set in the conf/recital.conf file:

DB_LOGVER=10; export DB_LOGVER

Enabling Log Files: Recital Server for UNIX

To enable the system log file for the Recital Server for UNIX, include the following command in the conf/config.db file:

set syslogging on

To set up Client/Server logging, the Recital Server can be started with the 'logging' parameter, in which case, all relevant logging will take place.

# service startup logging

Alternatively, one or more of the following environment variables can be added to the <em>dbserver.conf</em> file or set at the Operating System prompt.  The Recital Server must be restarted before environment variable changes will be recognized.  Each environment variable should be set to the name of a log file.

Environment Variable

Logs Activity of...

UASLOG_PORT

Port Server (db_rsiserver)

UASLOG_NET

(Net) Server (db_netserver)

UASLOG_ORA

Oracle Server (db_oraserver)

UASLOG_INF

Informix Server (db_infserver)

UASLOG_ING

Ingres Server (db_ingserver)

UASLOG_JDB

JDBC Server (db_jdbserver)

UASLOG_REC

Recital Server (db_recserver)

Extract from recital.conf:

UASLOG_PORT="port.log" ; export UASLOG_PORT
UASLOG_NET="net.log"   ; export UASLOG_NET
UASLOG_ORA="ora.log"  ; export UASLOG_ORA
UASLOG_INF="inf.log"     ; export UASLOG_INF
UASLOG_ING="ing.log"   ; export UASLOG_ING
UASLOG_JDB="jdb.log"   ; export UASLOG_JDB
UASLOG_REC="rec.log"   ; export UASLOG_REC
DB_LOGDIR

If the environment variable DB_LOGDIR is set to an existing directory, all log files will be written to this directory.  If not, the log files will be created in the bin directory.

DB_LOGDIR is set in the conf/recital.conf file. By default it is set to the log directory:

DB_LOGDIR=${DB_ROOT}log/           ; export DB_LOGDIR
DB_LOGVER

If the environment variable DB_LOGVER is greater than 0, version numbers are added to the file names.  For example, the activity of the first Net Server process will be logged to net.log, the second to net001.log, the third to net002.log etc. up to the maximum value of DB_LOGVER.

DB_LOGVER is set in the conf/recital.conf file:

DB_LOGVER=10; export DB_LOGVER

Enabling Log Files: Recital Universal Application Server for OpenVMS

To enable the system log file for the Recital Universal Application Server for OpenVMS, include the following command in the db_uas:config.db file:

set syslogging on

To set up Client/Server logging, one or more of the following symbols can be added to the <em>db_uas:login.com</em> file.  The Recital Server must be restarted before symbol changes will be recognized.  Each symbol should be set to the name of a log file.

Symbol

Logs Activity of…

UASLOG_PORT

Port Server (db_rsiserver)

UASLOG_NET

(Net) Server (db_netserver)

UASLOG_ORA

Oracle Server (db_oraserver)

UASLOG_INF

Informix Server (db_infserver)

UASLOG_ING

Ingres Server (db_ingserver)

UASLOG_JDB

JDBC Server (db_jdbserver)

UASLOG_REC

Recital Server (db_recserver)

Extract from db_uas:login.com

$ uaslog_port :==  port.log
$ uaslog_net  :==  net.log
$ uaslog_ora  :==  ora.log
$ uaslog_inf  :==  inf.log
$ uaslog_ing  :==  ing.log
$ uaslog_jdb  :==  jdb.log
$ uaslog_rec  :==  rec.log
DB_LOGDIR

If the symbol DB_LOGDIR is set to an existing directory, all log files will be written to this directory.  If not, the log files will be created in the UAS directory.

DB_LOGDIR is set in the db_uas:login.com file. By default it is set to the UAS.log] directory:

$db_logdir    :== 'db_root'.log]               ! system logging directory
DB_LOGVER

If the symbol DB_LOGVER is enabled, version numbers are added to the file names. For example, the activity of the first Net Server process will be logged to net.log, the second to net001.log, the third to net002.log etc.

DB_LOGVER is set in the db_uas:login.com file:

$db_logver  :== true                           ! enable multiple log files

Enabling Log Files: Recital for Linux

To enable the system log file for Recital for Linux, include the following command in the conf/config.db file:

set syslogging on

Enabling Log Files: Recital for UNIX

To enable the system log file for Recital for UNIX, include the following command in the conf/config.db file:

set syslogging on

Enabling Log Files: Recital for OpenVMS

To enable the system log file for Recital for OpenVMS, include the following command in the db_ovd:config.db file:

set syslogging on

In Brief

  • Log files provide important information to aid problem resolution, but they are also an overhead, so logging should only be enabled when required, not in normal production operation.
  • The System log provides a system-wide view of logins, exits and error codes.
  • The System log can be viewed in table format via the SYSLOGGING System Table.
  • The System log is enabled using the SET SYSLOGGING ON Recital/4GL command in the conf/config.db file.
  • Client/Server logs provide detailed information on client/server requests and responses.
  • Client/Server logs are enabled using environment variables, symbols or Registry entries or by specifying the 'logging' parameter when starting the Recital Server.
  • The location of log files is determined by the DB_LOGDIR setting.
  • Versioning of log files is determined by the DB_LOGVER setting.
Published in Blogs
Read more...

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.

1
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.

2
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.


4
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...

Published in Blogs
Read more...

It would appear that gigabit LAN is not! In fact it often runs at the same speed as 100Mbps LAN. Let's look at why exactly.

After configuring your network you can use the ifconfig command to see what speeds the LAN is connected. Even though 1000Mbps is reported by the card, the reality is that the overall throughtput may well be ~100Mpbs. You can try copying a large file using scp to demonstrate this.

As it turns out, in order to use a gigabit LAN you need to use CAT6 cables. CAT5 and CAT5E are not good enough. End result, the ethernet cards throttle back the speed to reduce dropped packets and errors.

You can find a good article here titled Squeeze Your Gigabit NIC for Top Performance. After tuning up the TCP parameters i found that it made no dfifference. The principal reasons behind low gigabit ethernet performance can be summed up as follows.

  1. Need to use CAT6 cables
  2. Slow Disk speed
  3. Limitations of the PCI bus which the gigabit ethernet cards use

You can get an idea about the disk speed using the hdparm command:

Display the disk partitions and choose the main linux partition which has the / filesystem.

# fdisk -l


Then get disk cache and disk read statistics:

# hdparm -Tt /dev/sda0


On my desktop system the sata disk perfomance is a limiting factor. These were the results:

/dev/sda1:
Timing cached reads:   9984 MB in  2.00 seconds = 4996.41 MB/sec
Timing buffered disk reads:   84 MB in  3.13 seconds =  58.49 MB/sec

Well, that equates to a raw disk read speed of 58.49 * 8 = 467Mbps which is half the speed of a gigabit LAN.

So.. NAS storage with lots of memory looks to be the way to go... If you use the right cables!


Published in Blogs
Read more...

The Openfiler NAS/SAN Appliance (NSA) is a Storage Management Operating System / NAS Appliance distribution. It is powered by the Linux 2.6 kernel and Open Source applications such as Apache, Samba, LVM2, ext3, Linux NFS and iSCSI Enterprise Target. Openfiler combines these ubiquitous technologies into a small, easy to manage solution fronted by a powerful web-based management interface. Openfiler allows you to build a Network Attached Storage (NAS) and/or Storage Area Network (SAN) appliance, using industry-standard hardware, in less than 10 minutes of installation time.

Building upon the popularity of server virtualization technologies such as VMware, Virtual Iron, and Xen, Openfiler can also be deployed as a virtual machine instance or on  a bare metal machine.

This deployment flexibility of Openfiler ensures that storage administrators are able to make the best use of system performance and storage capacity resources when allocating and managing networked storage in a multi-platform environment.

Openfiler is ideally suited for use with High Availability Recital applications as it incorporates:

  • Heartbeat cluster manager
  • drbd disk replication
  • CIFS
  • NFS
  • Software and hardware RAID
  • FTP
  • rsync
  • HTTP/DAV
  • iSCSI
  • LVM2
  • Multiple NIC bonding for High Availability
  • Powerful web-based GUI

 

Published in Blogs
Read more...

DRBD:
DRBD (Distributed Replicated Block Device) forms the storage redundancy portition of a HA cluster setup. Explained in basic terms DRBD provides a means of achieving RAID 1 behavoir over a network, where whole block devices are mirrored accross the network.

To start off you will need 2 indentically sized raw drives or partitions. Many how-to's on the internet assume the use of whole drives, of course this will be better performance, but if you are simply getting familar with the technology you can repartition existing drives to allow for two eqaully sized raw partitions, one on each of the systems you will be using.

There are 3 DRBD replication modes:
• Protocol A: Write I/O is reported as completed as soon as it reached local disk and local TCP send buffer
• Protocol B: Write I/O is reported as completed as soon as it reached local disk and remote TCP buffer cache
• Protocol C: Write I/O is reported as completed as soon as it reached both local and remote disks.

If we were installing the HA cluster on a slow LAN or if the geogrphical seperation of the systems involved was great, then I recommend you opt for asyncronous mirroring (Protocol A) where the notifcation of a completed write operation occurs as soon as the local disk write is performed. This will greatly improve performance.

As we are setting up our HA cluster connected via a fast LAN, we will be using DRBD in fully syncronous mode, protocol C.
Protocol C involves the file system on the active node only being notified that the write operation was finished when the block is written to both disks of the cluster. Protocol C is the most commonly used mode of DRBD.

/etc/drbd.conf

global { usage-count yes; }
common { syncer { rate 10M; } }
resource r0 {
protocol C;
net {
max-buffers 2048;
ko-count 4;
}
on bailey {
device    /dev/drbd0;
disk      /dev/sda4;
address   192.168.1.125:7789;
meta-disk internal;
}
on giskard {
device    /dev/drbd0;
disk      /dev/sda3;
address   192.168.1.127:7789;
meta-disk internal;
}
}

drbd.conf explained:

Global section, usage-count. The DRBD project keeps statistics about the usage of DRBD versions. They do this by contacting a HTTP server each time a new DRBD version is installed on a system. This can be disabled by setting usage-count no;.

The common seciton contains configurations inhereted by all resources defined.
Setting the syncronisation rate, this is accoimplished by going to the syncer section and then assigning a value to the rate setting. The syncronisation rate refers to rate in which the data is being mirrored in the background. The best setting for the syncronsation rate is related to the speed of the network with which the DRBD systems are communicating on. 100Mbps ethernet supports around 12MBps, Giggabit ethernet somewhere around 125MBps.

in the configuration above, we have a resource defined as r0, the nodes are configured in the "on" host subsections.
"Device" configures the path of the logical block device that will be created by DRBD
"Disk" configures the block device that will be used to store the data.
"Address" configures the IP address and port number of the host that will hold this DRBD device.
"Meta-disk" configures the location where the metadata about the DRBD device will be stored.
You can set this to internal and DRBD will use the physical block device to store the information, by recording the metadata within the last sections of the disk.
Once you have created your configuration file, you must conduct the following steps on both the nodes.

Create device metadata.

$ drbdadm create-md r0
v08 Magic number not found
Writing meta data...
initialising activity log
NOT initialized bitmap
New drbd meta data block sucessfully created.
success

Attach the backing device.
$ drbdadm attach r0

Set the syncronisation parameters.
$ drbdadm syncer r0

Connect it to the peer.
$ drbdadm connect r0

Run the service.
$ service drbd start

Heartbeat:

Heartbeat provides the IP redundancy and the service HA functionailty.
On the failure of the primary node the VIP is assigned to the secondary node and the services configured to be HA are started on the secondary node.

Heartbeat configuration:

/etc/ha/ha.conf

## /etc/ha.d/ha.cf on node1
## This configuration is to be the same on both machines
## This example is made for version 2, comment out crm if using version 1
// replace the node variables with the names of your nodes.

crm no
keepalive 1
deadtime 5
warntime 3
initdead 20
bcast eth0
auto_failback yes
node bailey
node giskard

/etc/ha.d/authkeys
// The configuration below set authentication off, and encryption off for the authentication of nodes and their packets.
//Note make sure the authkeys file has the correct permisisions chmod 600

## /etc/ha.d/authkeys
auth 1
1 crc

/etc/ha.d/haresources
//192.168.1.40 is the VIP (Virtual IP) assigned to the cluster.
//the "smb" in the configuration line represents the service we wish to make HA
// /devdrbd0 represents the resource name you configured in the drbd.conf

## /etc/ha.d/haresources
## This configuration is to be the same on both nodes

bailey 192.168.1.40 drbddisk Filesystem::/dev/drbd0::/drbdData::ext3 smb

Published in Blogs
Read more...

Recital 10 Express Edition Linux x86 Free Download.

Recital 10 introduces the free single-user developer edition called Recital Express that can be used to develop and test multi-user Recital, Recital Server and Recital Web applications. Once the applications are ready for deployment a commercial license must be purchased. Recital Express, Recital Server Express and Recital Web Express can be used unlicensed for non-commercial purposes only.

What does this download include:

Recital 10

A powerful scripting language with an embedded database used for developing desktop database applications on Linux and Unix. Recital has a high degree of compatibility with Microsoft FoxPRO enhanced with many additional enterprise class extensions.

Web

Recital 10 Web

A server-side scripting language with an embedded database for creating web 2.0 applications. Includes plugins for apache and IIS. Coming soon! Recital Web Framework, a comprehensive OO framework built on YUI for building RIA (Rich Internet Applications) in Recital Web.

Recital 10 Server

A cross-platform SQL database and application server which includes client drivers for ODBC, JDBC and .NET enabling Recital data to be accessed client/server from Windows, Linux and Mac.

 Safe

Recital 10 Replication

A comprehensive replication product that addresses urgent data movement and synchronization needs to help support disaster recovery and business continuity for Recital applications.


Recital 10 Quick Start:

Graphical Installation

Note: The installation must be run as root. For systems with a hidden root account, please use ’Run as Root’.

  1. Download the distribution file into a temporary directory
  2. Check that the distribution file has the execute permission set
  3. Run the distribution file
  4. Follow the on screen instructions:
    1. License agreement
    2. Select components
    3. Installation directory and shortcuts
    4. Linking to /usr/bin
    5. ODBC Installation type (Recital Server / Recital Client Drivers)
    6. Java Virtual Machine selection (Recital Server / Recital Client Drivers)
    7. TomCat Installation type (Recital Server / Recital Client Drivers)
    8. Apache Firecat Plugin Installation (Recital Web Developer)
    9. Replication Service Type (Recital Replication Server)
    10. Install license file

Text Installation

Note: The installation must be run as root. For systems with a hidden root account, please precede commands with ’sudo’.

  1. Download the distribution file into a temporary directory
  2. Check that the distribution file has the execute permission set
  3. Run the distribution file
  4. Follow the on screen instructions:
    1. License agreement
    2. Select components
    3. Installation directory and shortcuts
    4. Linking to /usr/bin
    5. ODBC Installation type (Recital Server / Recital Client Drivers)
    6. Java Virtual Machine selection (Recital Server / Recital Client Drivers)
    7. TomCat Installation type (Recital Server / Recital Client Drivers)
    8. Apache Firecat Plugin Installation (Recital Web Developer)
    9. Replication Service Type (Recital Replication Server)
    10. Install license file


Published in Blogs
Read more...
Dave Michelle at ITPRO writes a good review of the DS3400 San here.
Published in Blogs
Read more...
Twitter

Copyright © 2024 Recital Software Inc.

Login

Register

User Registration
or Cancel