Here is a simple shell script to copy your ssh authorization key to a remote machine so that you can run ssh and scp without having to repeatedly login.
#!/bin/sh
# save in file ssh_copykeyto.sh then chmod +x ssh_copykeyto.sh
KEY="$HOME/.ssh/id_rsa.pub"
if [ ! -f ~/.ssh/id_rsa.pub ];then
echo "private key not found at $KEY"
echo "create it with "ssh-keygen -t rsa" before running this script
exit
fi
if [ -z $1 ];then
echo "Bad args: specify user@host as the first argument to this script"
exit
fi
echo "Copying ssh authorization key to $1... "
KEYCODE=`cat $KEY`
ssh -q $1 "mkdir ~/.ssh 2>/dev/null; chmod 700 ~/.ssh; echo "$KEYCODE" >> ~/.ssh/authorized_keys; \ chmod 644 ~/.ssh/authorized_keys"
echo "done!"
In this article Barry Mavin explains step by step how to setup a Linux HA (High Availability) cluster for the running of Recital applications on Redhat/Centos 5.3 although the general configuration should work for other linux versions with a few minor changes.
auth sufficient pam_krb5.so try_first_pass
auth sufficient pam_unix.so shadow nullok try_first_pass
account required pam_unix.so broken_shadow
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
After split brain has been detected, one node will always have the resource in a StandAlone connection state. The other might either also be in the StandAlone state (if both nodes detected the split brain simultaneously), or in WFConnection (if the peer tore down the connection before the other node had a chance to detect split brain).
At this point, unless you configured DRBD to automatically recover from split brain, you must manually intervene by selecting one node whose modifications will be discarded (this node is referred to as the split brain victim). This intervention is made with the following commands:
# drbdadm secondary resource
# drbdadm disconnect resource
# drbdadm -- --discard-my-data connect resource
On the other node (the split brain survivor), if its connection state is also StandAlone, you would enter:
# drbdadm connect resource
You may omit this step if the node is already in the WFConnection state; it will then reconnect automatically.
If all else fails and the machines are still in a split-brain condition then on the secondary (backup) machine issue:
drbdadm invalidate resource
- 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 provides a wide variety of connectivity solutions to external data sources. This article provides an overview.
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
// declare an empty dynamic array
a = array()
// declare a simple dynamic array
a = array("barry", "recital", "boston")
foreach a as value
echo value
endfor
// declare an associative array
a = array("name" => "barry", "company" => "recital", "location" => "boston")
echo "length of a is " + len(a)
foreach a as key => value
echo "key=" + key + ", value=" + value
endfor
We are pleased to announce the release of Recital 10.0.2.
Here is a brief list of features and functionality that you will find in the 10.0.2 release.
- New commands
SAVE/RESTORE DATASESSION [TO variable]
CONNECT "connectString"
DISCONNECT - New functions (OData compatible)
startsWith(haystack as character, needle as character)
endsWith(haystack as character, needle as character)
indexOf(haystack as character, needle as character)
substringOf(haystack as character, needle as character)
concat(expC1, expC2) - New system variables
_LASTINSERTEDSYNCNUM - Enhanced commands
Added CONNSTRING "connectingString" to the USE command to connect to remote servers (Recital, MySQL, PostgreSQL, Oracle, ODBC) - Further SQL query optimizer improvements to boost performance
- Performance improvements in Recital Web
- Forced all temporary files into temp directory (improves performance when local tmpfs is used as temp directory and reduces network i/o)
- Fixed cookie and session variable problems in Recital Web
- Fixed problem with temporary files being left after some server queries involving memos and object data types
- Improved performance of the Windows ODBC driver
- Fixed a security flaw in Recital Web
- Fixed all reported bugs
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