Tuesday, December 4, 2012

Haproxy fails to reload on Fedora 17

The great load balancer Haproxy has indeed a small but annoying problem on Fedora 17 (64bit in my case). While start and stop works perfect via systemctl, the balancer reload fails without any clear message what is happened.

After few hours of digging in the starter bash script /etc/init.d/haproxy we found that the problem lies outside it, it is seems in Fedora's systemctl at all, in the /etc/init.d/functions include used in the balancer starter.

How to workaround the problem of Haproxy reload? Just remove following line from the end of functions file:
"x$1" = xreload -o \

After removal script code will look like this:
if [ "$_use_systemctl" = "1" ]; then
        if  [ "x$1" = xstart -o \
                "x$1" = xstop -o \
                "x$1" = xrestart -o \
                "x$1" = xtry-restart -o \
                "x$1" = xforce-reload -o \
                "x$1" = xcondrestart ] ; then

                systemctl_redirect $0 $1
                exit $?
        fi
fi
And Haproxy starter script finally is: 
#!/bin/sh
#
# haproxy
#
# chkconfig:   - 85 15
# description:  HAProxy is a free, very fast and reliable solution \
#               offering high availability, load balancing, and \
#               proxying for TCP and  HTTP-based applications
# processname: haproxy
# config:      /etc/haproxy/haproxy.cfg
# pidfile:     /var/run/haproxy.pid

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0

exec="/usr/sbin/haproxy"
prog=$(basename $exec)

[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog

lockfile=/var/lock/subsys/haproxy

check() {
    $exec -c -V -f /etc/$prog/$prog.cfg
}

start() {
    $exec -c -q -f /etc/$prog/$prog.cfg
    if [ $? -ne 0 ]; then
        echo "Errors in configuration file, check with $prog check."
        return 1
    fi

    echo -n $"Starting $prog: "
    # start it up here, usually something like "daemon $exec"
    daemon $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}

stop() {
    echo -n $"Stopping $prog: "
    # stop it here, often "killproc $prog"
    killproc $prog
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

restart() {
    $exec -c -q -f /etc/$prog/$prog.cfg
    if [ $? -ne 0 ]; then
        echo "Errors in configuration file, check with $prog check."
        return 1
    fi
    stop
    start
}

reload() {
    $exec -c -q -f /etc/$prog/$prog.cfg
    if [ $? -ne 0 ]; then
        echo "Errors in configuration file, check with $prog check."
        return 1
    fi
    #echo -n $"Reloading $prog by command: "
    #echo "$exec -V -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid -sf $(cat /var/run/$prog.pid)"
    $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid -sf $(cat /var/run/$prog.pid)
    retval=$?
    return $retval
}

force_reload() {
    restart
}

fdr_status() {
    status $prog
}

case "$1" in
    start|stop|restart)
        $1
        ;;
    reload)
        reload
        ;;
    force-reload)
        force_reload
        ;;
    check)
        check
        ;;
    status)
        fdr_status
        ;;
    condrestart|try-restart)
      [ ! -f $lockfile ] || restart
    ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|try-restart|reload|force-reload}"
        exit 2
esac
But take in account, applying this workaround we are letting all output (echo ect) from the reload code to be printed out to a console where systemctl reload haproxy.service (or old-style service haproxy reload) will be invoked. The same actual for other services that used /etc/init.d/functions, in Fedora 17 case it's ipsec, network and few else.


Sunday, April 29, 2012

Setup MongoDB on Fedora 14


MongoDB is an open source document-oriented NoSQL database system. It is used in many apps especially when it is a startup what should be cloud ready.

VMware's Cloud Found provides MongoDB out of the box and in time of writing this their Micro Edition proposes version 1.8.

To start develop with Cloud Foundry we need (it's recommended) to have the same versions of the services as on the cloud but locally.

Unfortunately Fedora 14 can propose only MongoDB 1.6, so we have to do the installation for the version 1.8 manually and there is a good description of steps we need - Use MongoDB to Store Application Data on Fedora 14 - but file locations will differ.

First ensure our system is up to date: yum update.

MongoDB will be installed in /opt/mongodb folder and data with logs will be in /var/lib/mongodb:
mkdir -p /var/lib/mongodb
mkdir data1
mkdir logs
touch /var/lib/mongodb/logs/data1.log

Create user mongodb with its home dir in our server folder:
useradd -M -r --home-dir /opt/mongodb mongodb
And make it able to access our data folder:
chown -R mongodb:mongodb /var/lib/mongodb

Download and unarchive MongoDB:
cd /opt/
wget http://downloads.mongodb.org/linux/mongodb-linux-x86_64-1.8.0.tgz
tar xvf mongodb-linux-x86_64-1.8.0.tgz
ln -s ./mongodb-linux-x86_64-1.8.0 ./mongodb

We linking actual directory to /opt/mongodb this will let us to switch between versions of MongoDB in case of a need in future.

Basic configuration of MongoDB is very simple. Need point to a listening address and set data and logs folders. Our configuration will be in /opt/mongodb/config/mongod.conf file:
# Configuration Options for MongoDB
#
# For More Information, Consider:
# - Configuration Parameters: http://www.mongodb.org/display/DOCS/Command+Line+Parameters
# - File Based Configuration: http://www.mongodb.org/display/DOCS/File+Based+Configuration

dbpath = /var/lib/mongodb/data1
logpath = /var/lib/mongodb/logs/data1.log
logappend = true

bind_ip = 127.0.0.1
port = 27017
fork = true

auth = true
# noauth = true

Create service control script /etc/rc.d/init.d/mongodb:
#! /bin/sh
#
# mongodb – this script starts and stops the mongodb daemon
#
# chkconfig: - 85 15
# description: MongoDB is a non-relational database storage system.
# processname: mongodb
# config: /optg/mongodb/config/mongod.conf
# pidfile: /opt/mongodb/mongo.pid

# Source function library
. /etc/rc.d/init.d/functions

user=mongodb
prog="mongod"
mongod="/opt/mongodb/bin/$prog --fork --config /opt/mongodb/config/mongod.conf"

RETVAL=0

start() {
  echo -n "Starting MongoDB... "
  daemon --user "$user" $mongod
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && touch /opt/mongodb/$prog.lock
}

stop() {
  echo -n "Stopping MongoDB"
  killproc $prog
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && rm -f /opt/mongodb/$prog.lock
}

restart() {
  stop
  start
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|reload|force-reload)
        restart
        ;;
  status)
        status $mongod
        RETVAL=$?
        ;;
      *)
        echo "Usage: $0 {start|stop|status|restart|reload|force-reload}"
        RETVAL=1
esac

exit $RETVAL
After this we can start MongoDB:
service mongodb start

And checking if it works
cd /opt/mongodb/bin
./mongo
MongoDB shell version: 1.8.0
connecting to: test
> 

MongoDB is up and running.


Sunday, March 14, 2010

eXo JCR 1.12 is out

This week we have released a next step of eXoJCR evolution.

What is new and major in version 1.12?

First of all eXoJCR it's an open-source implementation of JCR specification (JSR-170) and now it's under LGPL license (was AGPL). LGPL means freedom for use in closed (commercial, private etc) projects. Doing this step we want to get more feedback about JCR technology in real world usecases. At other hand lesser license opens us an opportunity to work with many JBoss teams and especially with Portal guys. GateIn portal it's a web face of a Content Repositories actually... as well as many other tasty features :).

But eXoJCR 1.12 is very interesting technically also.

Our new, big and #1 feature today - clustering.

It's not a very new option and we had a replication in 1.11. But it was designed for data synchronization between sites over Internet in on-line peer-to-peer mode (available since version 1.10). And then used by several our customers for a clustering in Intranet solutions. We gathered lot of feedback and real usecases and decided to re-implement it from the scratch in 1.12.

The new clustering goals mean intensively loaded Repository work in corporate network or a cloud. At same time a main look made on read operations scalability what is general for Web applications.
Technically the new cluster uses the same JGroups transport well known to us by 1.11 replication (and still used in asynchronous replication). But now the clustering work fully based on JBossCache. We rely on JBoss experience in this field. And we have implemented not trivial task - hierarchical JCR data caching over the JBossCache keeping a compatibility with existing persistence. We also reimplemented JCR indexer and locks support on JBossCache.
A complex work done and we're on a next iteration there.

Other main features of eXoJCR 1.12.0-GA since 1.11.2
- Lazy-load option for child nodes and properties read, improved items
dataflow for read/write operations
- Alternative data container optimized for read operations (consuming
less database queries). It's enabled by default.
- Support of Java6 and Java5 runtimes and JDK
- Database dialect can be autodetected (if not pointed in the configuration)
- Support for Values large of 2GiB
- Portal container configuration supports default definitions,
links and externally loaded parameters
- Support of MySQL/InnoDB database for multilingual content
- Concurrency improvements for Session registry and Values storage
- Concurrency improvements for XA transactions support (Repository
login and logout are faster now)
- Improved search based on Lucene 2.4
- Standalone container can use configuration stored in JBoss application server
configuration directory by default
- WebDAV server update-policy can be configured to different
versioning behaviour
- Two new REST services introduced:
* HTTP (RESTful) Backup agent with console client
* HTTP (RESTful) Repository management service

More info about inherited features from the previous versions 1.11.2 here.

eXoJCR 1.12 was tested on databases/JDBC drivers:
MySQL 5.1 MYSQL Connector/J 5.1.8
Oracle DB 10g (10.2.0.1) Oracle 10g (10.2.0.1)
PostgresSQL 8.3.7 JDBC4 Driver, Version 8.3-605
DB2 9,7 IBM Data Server Driver for JDBC and SQLJ (JCC Driver)
Version: 9.1 (fixpack 3a)
MS SQL Server 2005 SP3 JDBC Driver 2.0
MS SQL Server 2008 SP1 JDBC Driver 2.0
Sybase 15.0.2 JConnect v6.0.5 (Build 26564 / 11 Jun 2009)

Downloads of a standalone eXoJCR bundles available now.
Tomcat or EAR provides a network ready content server with several plain samples. It provides WebDAV and FTP (port 2121) services on the board.

eXoJCR 1.12.0-GA jars are on JBoss maven2 repo also.
There are short intro how to setup dev environment for eXoJCR 1.12.

Where you can see eXoJCR in action (soon):
eXoJCR 1.12 is a database of GateIn portal.
eXoJCR 1.12 also used in xCMIS - eXo's CMIS implementation.
And our services...

Lot of stuff... stay connected. Details more interesting.

Saturday, February 6, 2010

Setup of development on eXoJCR 1.12

Short intro in preparations to eXo JCR development.
(repost of setup, adopted to eXoJCR 1.12)

eXo and GateIn products development based on Maven2 project management. Easiest way to start the development it's to setup right Maven2 project (POM) and its dependencies.

Prerequisites
  • Java 5 (add JDK executables to the PATH on your system)
  • Maven2 (add Maven2 2.2.1 or higher executable to the PATH on your system, )
  • Eclipse (optional)
Creating project (POM)

We say that our project name is my-jcrapp (use your name instead of this dummy one).

In empty folder run Maven command:

For Java project:
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DgroupId=com.mycompany.exojcr -DartifactId=my-jcrapp
For Groovy enabled project:
mvn archetype:generate -DarchetypeGroupId=org.codehaus.groovy.maven.archetypes -DarchetypeArtifactId=gmaven-archetype-basic -DgroupId=com.mycompany.exojcr -DartifactId=my-jcrapp

The commend ask for a project version Define value for version: 1.0-SNAPSHOT: :
Press Enter or type your version, it then ask for confirmation - press Enter to agree.

This command creates the project folder named my-jcrapp with ready to use files structure. There are pom.xml, src folder with place for application code and tests. Project model (pom.xml) contains dependencies declaration, here is JUnit only (and Groovy runtime if you're groovy :) ).

eXo JCR dependency

Next, add eXo JCR dependency to the POM.
eXoJCR jar files lives on JBoss Maven2 repository. Add JBoss repo to Maven2 local repositories list: or into settings.xml or directly in the your project POM (add repositories element after the dependencies).
<repositories>
<repository>
<id>exo-int</id>
<name>jboss.org repository</name>
<url>http://repository.jboss.com/maven2 </url>
<layout>default</layout>
</repository>
</repositories>
Now add the JCR core dependency:
<dependency>
<groupid>org.exoplatform.jcr</groupid>
<artifactid>exo.jcr.component.core</artifactid>
<version>1.12.0-GA</version>
<scope>compile</scope>
</dependency>
If you need JCR Ext features then add this dependency (in fact you need only Ext one, it will points JCR core itself):
<dependency>
<groupid>org.exoplatform.jcr</groupid>
<artifactid>exo.jcr.component.ext</artifactid>
<version>1.12.0-GA</version>
<scope>compile</scope>
</dependency>
And it's ready to build!

Build project

Run given command and wait till eXo JCR with its dependencies will be downloaded to your local Maven2 repo (~25Mb):
mvn clean compile
and be sure you see BUILD SUCCESSFUL at the end of this execution.

If something goes wrong with the build check all step from the begin and proxy.

Successful? Voi-la, you're ready to eXo JCR development!


Eclipse IDE setup read there.

Several notes about Groovy support in Eclipse.
I have used Groovy-Eclipse plugin of version 2.0.0 (update site). After generation from maven2 project (via mvn eclipse:eclipse) and import into Eclipse I found that Groovy-Eclipse doesn't recognize the project as a Groovy project and as a result the plugin has no sense for development.
Trouble can be fixed by Eclipse project file (.project) manual editing. Add the next line to natures element

<nature>org.eclipse.jdt.groovy.core.groovyNature</nature>

and refresh the project.
Another issue with the plugin it's switch to Groovy 1.6.x compiler. Why 1.6? eXoJCR 1.12 bundled with Groovy 1.6.5, it's better to use closer version in IDE.

Enjoy!