My last blog in 2011: My 2012 wishes and predictions…

I almost stopped blogging during 2011 because of lots of complications I was dealing with but this entry is something I couldn’t just pass over.¬†Hopefully I will resume blogging during 2012 as actively as I was doing during late 2009 and early 2010.

My predictions for 2012 in technology realm specially when focused on Java is as follow:

  • Oracle will push Java forward like never before.
  • Java ecosystem will thrive with JavaFX getting open sourced and new big names joining JCP.
  • We will see the best Java release for Mac os, Java SE 7.
  • IBM will push the idea of how cool Rational set of IDEs are and how good Websphere is and people will believe it until the are caught with no way to return.
  • RIM will probably stop development of it’s own operating system and instead develop a powerpack for Android…
  • Google Chrome will eat other browsers marketshare as fast as browserly possible.
  • Some of the new cool boys in the JVM town that are claiming to be the next Java will vanish/start vanishing without any trace ūüėÄ
  • GlassFish will get more marketshare and more people will benefit from it’s modular and extensible architecture.
  • Google will market a revolutionary Android tablet that will change the concept.

What I wish for during 2012

  • No more war and instead of that some peace and quiet time around the globe.
  • No disasters like what we had in 2011 and instead some ground breaking¬†scientific¬†discoveries in medicine, energy and space travel.
  • No economy breakdown anywhere in the world.
  • A cell phone thinner than Motorola DROID RAZR ūüėÄ
  • Google to provide a good cloud storage for end users so I could stop using combination of DrobBox, Google and SkyDrive.

Other predictions for 2012 which I truly like to be proven wrong for them.

  • Iranian government will not go away and will not change to a sane governing body.
  • Pakistan army and ISI will continue supporting /training and harboring ¬†Al Qaeda and Taliban and continue destabilizing Afghanistan southern and central provinces.
  • Iranian government will continue meddling in other countries affair specially in Afghanistan and Arab countries.
  • Syrian dictatorship will remain intact by support of Iranian government and the region will stay unstable as it is now.

I wish everyone a happy new year with lots of joys and success.

Writing Solaris Service Management Facility (SMF) service manifest

SMF services are basically daemons staying in background and waiting for the requests which they should server, when the request come the daemon wake ups, serve the request and then wait for the next request to come.

The services are building using software development platforms and languages but they have one common aspect which we are going to discuss here. The service manifests which describe the service for the SMF and let the SMF manage and understand the service life cycle.

To write a service manifest we should be familiar with XML and the service manifest schema located at /usr/share/lib/xml/dtd/service_bundle.dtd.1.  This file specifies what elements can be used for describing a service for the SMF.

Next thing we need is a text editor and preferable an XML aware text editor. The Gnome gedit can do the task for us.

The service manifest file composed of 6 important elements which are listed below:

  • The service declaration: ¬†specifies the service name, type and instantiation model
  • Zero or more dependency declaration elements: Specifies the service dependencies
  • Lifecycle methods: Specifies the start, stop and refresh methods
  • Property groups: Which property groups the service description has.
  • Stability element: how stable the service interface is considering version changes
  • Template element: more human readable information for the service.

To describe a service, first thing we need to do is identifying the service itself. Following snippet shows how we can declare a service named jws.

<service name='network/jws’ type='service' version='1'>
<single_instance/>

The first line specifies the service name, version and its type. The service name attribute forms the FMRI of the service which for this instance will be svc:/network/jws. In the second line we are telling SMF that it should only instantiate one instance of this service which will be svc:/network/jws:default. We can use the create_default_instance element to manipulate automatic creation of the default instance.

All of the elements which we are going to mention in the following sections of this article are immediate child elements of the service element which itself is a child element of the service_bundle element.

The next important element is dependency declaration element. We can have one or more of this element in our service manifest.

<dependency name='net-physica' grouping='require_all ' restart_on='none' type='service'>
<service_fmri value='svc:/network/physical'/>
</dependency>

Here we are telling that our service depends on the svc:/network/physical service and this service needs to be online before our service can start. Some of the values for the grouping attribute are as follow:

  • The require_all which represent that all services marked with this grouping must be online before our service came online
  • The require_any which represents that any of the services in this grouping suffice and our service can become online if one of them is online
  • The optional_all presence of the services marked with this grouping is optional for our service. Our service works with or without them.
  • The exclude_all: ¬†specifies the services which may have conflict with our service and we cannot become online in presence of them

The next important elements are specifying how the SMF should start, stop and refresh the service. For these tasks we use three exec_method elements as follow:

<exec_method name='start' type='method' exec='/opt/jws/runner start' timeout_seconds='60'>
</exec_method>

This is the start method, SMF will invoke what the exec attribute specifies when it want to start the service.

<exec_method name='stop' type='method' exec=':kill' timeout_seconds='60'>
</exec_method>

The SMF will terminate the process it started for the service using a kill signal. By default it uses the SIGTERM but we can specify our own signal. For example we can use ‘kill -9’ or ‘kill -HUP’ or any other signal we find appropriate for our service termination.

<exec_method name='refresh' type='method' exec='/opt/jws/runner reload_cof' timeout_seconds='60'>
</exec_method>

The final method which we should describe is the refresh method in which we should reload the service configuration without disturbing its function.

The start and stop methods description are required to be present in the manifest in order to import it into the SMF repository but the refresh method description and implementation is optional.

The timeout_seconds=’60’ specifies that the SMF should wait for 60 seconds before aborting the method execution and retrying it over. We can use longer timeout when we know that the execution of the method take longer or lower timeout when we know that our service starts sooner.

The property group elements specify which property groups the SMF should associate with the service.  We can use as many of the SMF built-in property groups or define our own property groups.

<property_group name='startd' type='framework'>
<propval name='ignore_error' type='astring' value='core,signal'/>
</property_group>

The above snippet shows how we can define using a framework built-in property group. The built-in property groups and their properties have meaning for the SMF framework and change its way of dealing with our service.  For example the above snippet says that the SMF should ignore core dump termination of suppresses of this service via a kill signal from another application.

Next important element is the stability element which specifies whether the property names, service name, its dependencies and other service attributes may or may not change for the next release. For example the following snippet specifies that the service attributes may change in the next release.

<stability value='Unstable'/>

Finally we have the template element which contains descriptive information about the service, for example we can have something like the following element which describes our service for human users.

<template>
<common_name>
<loctext xml:lang=’Java'>Java Network Server </loctext>
</common_name>
<documentation>
<manpage title='JWS' section='1M' manpath='/usr/share/man'/>
</documentation>
</template>

The entire element is self describing except for the man page element which specifies where the man utility command should look for the man pages for the jws service.

All of these elements should be saved into an XML file with the following structure:
<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<service_bundle ...>
<service ...>
<single_instance .../>
<dependency ... />
<exec_method... />
<property_group .../>
<stability .../>
<template ...>
</service>
</service_bundle>

This is a raw representation of what the service manifest bare bone cal look like. The syntax is not accurate and the attributes and child elements are omitted to make it easier to scan by the eyes.

The service_bundle, service, and  start and stop method elements are mandatory while other elements are optional.

Now we should install the service into the SMF repository and then administrate it. For installing the service we can use the following command.

# svccfg import /path/to/manifest.xml

When we import the service manifest into the service repository, SMF will scan the service profiles and check whether this service is required to be enabled either directly or because of a dependent service or not. If required, the SMF will use the start method specified in the manifest to start the service. But before starting it, SMF will check its dependencies and start any required service recursively if they are not already online.

Reviewing the XML schema located at /usr/share/lib/xml/dtd/service_bundle.dtd.1 and the staying tuned for my next few entries is recommended for grasping a better understanding of the whole SMF and Solaris Services administration/management.

GlassFish security book contest: Here are the lucky winners

Thank you all who accepted the challenge and took the quiz. Now it is time to see who are the luckier ones winning the prizes which are copies of GlassFish Security book. To give you an statistic about the quiz participants,

GlassFish Security Book

I had 156 participants. though some of them, maybe 20 – 30 are quiz result submitted more than once by some of the participants.

Before we jump to the list of winners, I should explain the questions which I posted in the quiz.  The questions I selected for the quiz are mostly based on chapter 3 of the book which is available for free in packt website.

So the questions, the answers and the explanation about each question are as follow.


1. Which one of the following statements is correct?

A. We can specify which security realm we want our web module to use in the sun-web.xml.
B. We can specify which security realm we want our web module to use in the web.xml.
C. We can use sun-application.xml to specify which security realm we want our enterprise application to use
D. B and C are correct.

We can use both the web.xml and sun-application.xml to specify the security realm. In the web.xml we use the login-conf element as shown below:

<login-config>
  <auth-method>BASIC</auth-method>
  <realm-name>LDAP_Realm</realm-name>
</login-config>

And in the sun-application.xml we can specify the application wide security realm as shown in the following snippet.

<sun-application>
    <realm>LDAP_Realm</realm>
</sun-application>

The realm is an immediate child of the sun-application element.


2. Which one of the following statements shows new security features included in Java EE 6?

A. The programmatic login and logout methods in logout in HttpServletRequest interface.
B. Inclusion of @ServletSecurity Annotation to annotate a Servlet and enforce security.
C. Inclusion of the authenticate method in the HttpServletRequest interface.
D. All of the above.

Yes, all of this new features are included in Java EE 6 to enhance the security APIs and ease their use.


3. Where we should place the login-config element?

A. In web.xml
B. In sun-web.xml
C. In sun-application.xml
D. In A and C

The login-conf element goes to web.xml to specify the security realm and the authentication method. To see an snippet about this look at the explanation of the first question


4. What are j_username and j_password when it come to Java EE security?

A. These are two per-defined filed names which we must use in FORM authentication to pass the username and the password to the container.
B. These are two per-defined filed names which we must use in BASIC authentication type to pass the username and the password to the container.
C. Both of A and B are correct.
D. None of the above items.

To see some snippet about how we can have FORM authentication, you can take a look at the GlassFish security book chapter 3 which is freely available.


5. When we talk about security, which of the following sequences is more accurate?

A. Identification, Authentication, Authorization
B. Authentication, Authorization, Identification
C. Authentication, Identification, Authorization
D. Authorization, Authentication, Identification

‚ÄĆBefore we try to authenticate a credential we should receive a credential showing who the requester is claiming to be. After we received the credentials, we should check the credentials validity and finally after we find that the credentials are valid we can check the access level of the provided credentials.


And now the winners
The paper copy goes to: Bruno Antunes
First ebook copy goes to: Alireza Haghighatkhah
Second ebook copy goes to: Deny Wuysan

I have not received replys from some of the participants about their country of residence so I put them into the second list. I will contact the winners to coordinate the distribution of the copies with them.

I am looking for a way to have more contest about GlassFish security book in the coming month. Specially small 2 question quiz which the winner will receive a e-book copy of the title.

OpenSolaris Governing Board effort on turning some lights on OpenSolaris future

Well, After sometime that Oracle decided to keep complete silence, either on analog radio or via digital mediums, OGB (OpenSolaris Governing Board) which is a body of some experienced community member governing the community took action and called on Oracle publicly to decide about what it is going to do about the project.

Long story short, because of Oracle silence about what is going on behind the curtains community members turned restless of not knowing what will happen next which the piece of software they deployed into some of their customers server rooms. Some are looking to know when they can install the promised upgrade on the customer machines to reduce the disk space usage while other are ballistic not knowing whether they should go with OpenSolaris installations or they should turn to *BSD or Linux variants and give up on OpenSolaris.

These concerns raised many times in the mailing list to the point where “OpenSolaris is dead/ is dying” messages surpass all other technical discussions and Some of¬†thees¬†messages ¬†seemed inappropriate enough for the Oracle staff to threaten that they are prepared to take action ¬†up to “moderation and/or deactivation”¬†of the list.

Jim Grisanzio: warning about mail on this list Р[Tue Jun 29 16:43:47 UTC 2010]@ http://mail.opensolaris.org/pipermail/opensolaris-discuss/2010-June/057703.html

Recently there has been mail on this list that violates the website Terms of Use. Individuals are being warned. However, if this trend continues the Website Team is prepared to take action up to and including moderation and/or deactivation of the list. Please do not respond to hostile posts because that only escalates the situation.

Many more messages posted to the list with different comments and analysis of situation with Solaris/ OpenSolaris product and project.  These comments lead to another warning from Oracle staff:

Alan Burlison: Yet another warning about behaviour on this list – [Thu Jul 15 14:41:16 UTC 2010]@http://mail.opensolaris.org/pipermail/opensolaris-discuss/2010-July/058383.html

Despite repeated warnings, some people are continuing to badmouth each other on this list. ¬†As explained previously, this is not acceptable. We’ve been warning people who have overstepped the mark, from this point on we won’t be doing that, we’ll just be immediately closing accounts and unsubscribing people from all of the opensolaris.org ¬†lists.

If that proves ineffective we will consider other measures such as putting the list into moderation or shutting it down entirely.
Be quite clear, this unacceptable behaviour must stop, and now.

Apologies to the vast majority of the list members who clearly aren’t the cause of the problem.

The Oracle silence take long enough and the “OpenSolaris is dead/ going to die…” threads number and messages grow big enough¬†to the point where OGB decided to weigh in and take action, but OGB has almost no control over anything these days and the only thing that they decided to do is calling on Oracle publicly and letting Oracle staff know that they are going to step down and resign from being the OGB if they have no power, official knowledge about what is the faith of the software that they are governing. @ http://wiki.genunix.org:8080/wiki/index.php/2010_07_12_OGB_Agenda

The OGB is keen to promote the uptake and open development of OpenSolaris and to work on behalf of the community with Oracle, as such the OGB needs Oracle to appoint a liaison by August 16, 2010, who has the authority to talk about the future of OpenSolaris and its interaction with the OpenSolaris community. Otherwise the OGB will take action at the August 23 meeting to trigger the clause in the OGB charter that will return control of the community to Oracle.

Now that OGB decided to publicly call on Oracle as a body of members elected by the community, Oracle need to send some response back. But what can be the response from Oracle? I think one of the following will happen:

  • Oracle will appoint a liaison¬†and take part in the governance board, restructure¬†it and assure community about the what is going on.
  • Oracle will act like nothing happened and no message like that has even been published but come forth with some resolutions at a later time after the¬†ultimatum¬†ended.
  • Oracle will come forth with some tanks and carrier class ships filled with Stark industries Iron Men and close down the project axing everyone posted harsh comments ūüėÄ

I believe the first alternative is what will happen despite some of the community members believe on some version of the last alternative and demolish of OpenSolaris.

Introducing NIO.2 (JSR 203) Part 4: Changing File System Attributes and Permissions

This is the 4th installment of my entries covering NIO.2. In this entry I will discuss more about what we can do with attributes and permissions.  The NIO.2 lets us write the permissions and attributes of a file in addition to reading them. For example we can change the rwx permissions using the Attributes utility class and  PosixFilePermission.

You can execute the following sample code with almost no changes, the only thing you need to change is the path to our sample file and then you are ready to see how it works.

import java.io.IOException;
import java.nio.file.*;
import java.nio.file.attribute.*;
import java.util.*;

public class Perm2 {

    public static void main(String args[]) throws IOException {
        FileSystem fs = FileSystems.getDefault();
        Path p = fs.getPath("/home/masoud/dl");

        // Reading attributes using attributes views.
        // here we read both basic and posix attributes of a file
        Map att = (Map) p.readAttributes("posix:*, basic:*", LinkOption.NOFOLLOW_LINKS);
        // printing the attributes to output
        Set en = att.keySet();
        for (Iterator it = en.iterator(); it.hasNext();) {
            String string = it.next();
            System.out.println(string + ": " + att.get(string));
        }
        System.out.println("-------------Attributes printing finished----------");

        // definind a new permission set for our file
        Set
 st2 = PosixFilePermissions.fromString("rwxrwxrwx");
        // Setting the attribute using Attributes utility class
        Attributes.setPosixFilePermissions(p, st2);

        // looking up and creating a principal for the given user. If use does
        // not exists it will throws a UserPrincipalNotFoundException
        UserPrincipal up = fs.getUserPrincipalLookupService().lookupPrincipalByName("masoud");

        // Setting the owner to the owner we just looked up.
        // We should have enough permisison to change the owner otherwise it will
        // throw a FileSystemException: /home/masoud/a: Operation not permitted sort of thing
        Attributes.setOwner(p, up);

        //another way to read and write the owner value for a file is using FileOwnerAttributeView
        FileOwnerAttributeView fo = p.getFileAttributeView(FileOwnerAttributeView.class, LinkOption.NOFOLLOW_LINKS);
        fo.setOwner(up);

        //Now that we have changed the permissions lets see the permissions again:
        att = (Map) p.readAttributes("posix:permissions", LinkOption.NOFOLLOW_LINKS);
        System.out.println("New Permissions:" + ": " + att.get("permissions"));
    }
}

Let’s see what we have done starting from top: at the beginning we have just initialized the FileSystem object and got a file reference to /home/masoud/dl. Then we read all of this files basic and posix attributes using the attributes view notation. The following sample code shows this step

 FileSystem fs = FileSystems.getDefault();
        Path p = fs.getPath("/home/masoud/dl");

        // Reading attributes using attributes views.
        // here we read both basic and posix attributes of a file
        Map att = (Map) p.readAttributes("posix:*, basic:*", LinkOption.NOFOLLOW_LINKS);
        // printing the attributes to output
        Set en = att.keySet();
        for (Iterator it = en.iterator(); it.hasNext();) {
            String string = it.next();
            System.out.println(string + ": " + att.get(string));
        }
System.out.println("-------------Attributes printing finished----------");

Next step we have use the PosixPermissions class to create a permission set using the OS permissions presentation and then applied these permissions on our file

 // definind a new permission set for our file
        Set
 st2 = PosixFilePermissions.fromString("rwxrwxrwx");
        // Setting the attribute using Attributes utility class
        Attributes.setPosixFilePermissions(p, st2);

In the next step we created a user principal for a user named masoud and changed the ownership of our file to this user. We have done this using both available methods.

// looking up and creating a principal for the given user. If use does
        // not exists it will throws a UserPrincipalNotFoundException
        UserPrincipal up = fs.getUserPrincipalLookupService().lookupPrincipalByName("masoud");

        // Setting the owner to the owner we just looked up.
        // We should have enough permisison to change the owner otherwise it will
        // throw a FileSystemException: /home/masoud/a: Operation not permitted sort of thing
        Attributes.setOwner(p, up);

        //another way to read and write the owner value for a file is using FileOwnerAttributeView
        FileOwnerAttributeView fo = p.getFileAttributeView(FileOwnerAttributeView.class, LinkOption.NOFOLLOW_LINKS);
        fo.setOwner(up);

Finally we read the file permissions to see what has changed after we applied this new permissions on our file. using the following snippet.

 //Now that we have changed the permissions lets see the permissions again:
        att = (Map) p.readAttributes("posix:permissions", LinkOption.NOFOLLOW_LINKS);
        System.out.println("New Permissions:" + ": " + att.get("permissions"));

The output of running the above sample code is shown below:

lastModifiedTime: 2010-07-06T23:15:32Z
fileKey: (dev=805,ino=1922268)
isDirectory: false
lastAccessTime: 2010-07-11T14:15:46Z
isOther: false
isSymbolicLink: false
owner: masoud
permissions: [OTHERS_READ, OWNER_WRITE, GROUP_WRITE, OWNER_READ, GROUP_READ, OTHERS_EXECUTE, OWNER_EXECUTE, GROUP_EXECUTE, OTHERS_WRITE]
isRegularFile: true
creationTime: null
group: dip
size: 219
-------------Attributes printing finished----------
Permissions:: [OTHERS_READ, OWNER_WRITE, GROUP_WRITE, OWNER_READ, GROUP_READ, OTHERS_EXECUTE, OWNER_EXECUTE, GROUP_EXECUTE, OTHERS_WRITE]

You may ask what is the attribute view notation and what is meaning of that posix:permissions or posix:*. The first one means that we want to retrieve the permissions property of the file while the second one means that we want to retrieve all attributes of the file which can be seen using the posix view.

Now you are asking where you can found list of this attributes view notations, then you question is very right. The following links shows what attributes are available to read using each one of those views. Each attribute is one of the properties included in the interface.

Sure we have other views, you can find them in the JavaDocs linked above.

Next entry will be the last entry covering File System functionalities of the NIO.2 including the watch and change notification service and the ACL list. After that we will look at new features included for IO developers. You can find other entries of this series under the NIO.2 tag of my weblog.

GlassFish v3 and EJBCA 3.x a fair couple for mutual SSL authentication.

Please use the following articles while I am updating this entry

  1. How to have your Own CA and configure Glassfish and your clients for mutual authentication?
  2. How to have your Own CA and configure Glassfish and your clients for mutual authentication?, Part II

Please post any comment or question here so we can have one main reference for this.