asyd’s blog

Le 16 Juin, à 19h30, se tiendra à Paris, chez Sun (attention, Sun a déménagé) une présentation technique autour de Solaris 10 / OpenSolaris, sur la gestion des IOs. Cette présentation est organisé par l’association GUSES. Au programme :

• Les différents composants : logiciel (système de fichiers), matériel
• La gestion du cache
• Le rôle du matériel
• Mesure de performances et optimisation

Comme vous l’aurez sans doute remarqué, cette présentation s’adresse avant tout à des administrateurs systèmes Solaris, mais les concepts abordés sont tout aussi vrai pour les autres UNIX.

Cette présentation sera assurée par Fabrice Bacchella, administrateur système senior.

Afin d’optimiser la place, nous vous serons reconnaissant de vous inscrire.

Depuis quelques jours (heures ?), Glassfish v3 preview est disponible. Comme Alexis est bien mieux placé que moi pour en parler, je vous engage à lire cet article pour la description de cette version. Au travers de ce petit billet, je résume ma toute première utilisation de Preview. Pour cela, mon cas d’utilisation est tout simple, déployer XWiki en version 1.8 dans un premier temps, mais au travers d’une source de connexions JDBC. Cas d’utilisation donc très simple.

Mes remarques, en vrac :

• Nécessite un JDK 1.6 (java -version pour vérifier). Utilisateur d’OS X, vous devez définir JAVA_HOME et PATH, la version par défaut étant encore en 1.5
• La commande start-domain ne met que quelques secondes à rendre la main ! Néanmoins, la console d’administration n’est pas disponible avant d’autres longues secondes . Pour rappel, la version 3 de Glassfish est construit autour d’OSGI, un système orienté composant.
• L’interface d’administration est proche de la version 2.1, on s’y retrouve donc assez facilement. Néanmoins, il y a une différence notable dans la gestion des applications. Il faut que je creuse le sujet.
• Il faut que je vérifie, mais lors de la configuration du pool de connexions JDBC, Glassfish me demandait un restart, que j’ai fait. J’avoue que cela me dérange un peu si c’est vraiment nécessaire, c’est quand même une opération simple !
• Temps d’arrêt très rapide, plutôt appréciable.
• J’en suis presque surpris (pas taper), mais le déploiement de XWIki est OK du premier coup ! Très bon signe !
• L’URL JMX n’est plus affiché lors du démarrage du domaine, c’est bien dommage !
• A priori pas de changements sur la taxinomie (namespace) des MBeans, ce qui est plutôt plaisant.

Bref, premier contact plutôt positif, même si j’ai constaté quelques petits soucis dans l’interface web, mais rien de bien méchant. Vivement la première version de production !

At my work, we currently use nagios and cacti for monitoring, the “standard” tools. However, why it’s difficult to replace nagios – for many reasons (it use standard flat configuration flies) – I’m looking for a way to replace Cacti. Indeed, it’s written in pure PHP, there is almost no CLI. So, when I add a new host, I need to use my browser, and my mouse, and I don’t like that. By chance, a friend of mine wrote his own tool, called JRDS, in pure Java. I’m actually in test phase, however, here are some pros:

• It’s Java, no need for php, whatever.
• JRDS use rrd4j, RRDTool Java implementation
• Use flat files for configuration, so it’s very easy to manage

However, one of its wort cons i s the lack of documentation! So here some notes to build JRDS :

1. Fetch and extract JRDS sources from the subversion repository
2. Fetch and extract RRD4j sources from the subversion repository (note: a dev.java.net account seem to be required)
3. Build RRD4j
   • # cd rrd4j/rrd4j
   • # ant
   • # cp rrd4j-<version>.jar $JRDS_HOME/trunk/lib
4. Build JRDS
   • If you don’t have it, download ivy and copy its jar in ~/.ant/lib directory
   • # cd $JRDS_HOME/trunk
   • # ant resolve
   • Extrat c.tld from lib/standard.jar and copy the file in the lib/ directory ( # unzip lib/standard.jar META-INF/c.tld ; mv META-INF/c.tld lib/ ; rmdir META-INF
   • # cp local.properties.sample local.properties
   • Edit local.properties, don’t forget to set jai.home at the end of file
   • # ant war
5. Before deploy jrds.war, you need to create a properties file, and some directories. See the inital setup chapter of JRDS Userguide.
6. Note: to deploy JRDS on Glassfish, the only way I found to create the property is to defined in the JVM options. I also have sometimes a deadlock, if that appears, you need to kill the Glassfish process and restart it.

jrds.properties

configdir=/Users/bbonfils/tools/jrds/config
rrddir=/Users/bbonfils/tools/jrds/probe
logfile=/Users/bbonfils/tools/jrds/log/jrds.log
libspath=/Users/bbonfils/sources/jrds/trunk/build/probes.jar
#loglevel=debug

config/host-kaoru.xml

<?xml version="1.0" encoding="UTF-8"?>
<host name="kaoru.asyd.net">
        <snmp community="secret" version="2"/>
        <probe type="TcpSnmp" />
        <probe type="IpSnmp" />
        <probe type="UdpSnmp" />
        <probe type="IcmpSnmp" />
        <probe type="MemLinux" />
        <probe type="CpuRawTimeLinux" />
        <probe type="UcdRawSystemCounter" />
        <probe type="PartitionSpace">
                <arg type="String" value="/" />
        </probe>
        <probe type="IfSnmp">
               <arg type="String" value="eth0" />
        </probe>
        <probe type="CpuLoadFloat" />
        <probe type="TcpStat" />
</host>

In my previous post, I demonstrate how to set a property for each http-service in a glassfish domain using groovy and jmx. Here the code to create a new JDBC Connection Pool, still using groovy and JMX/AMX APIs.

 
import javax.management.ObjectName
import javax.management.remote.JMXConnectorFactory as JmxFactory
import javax.management.remote.JMXServiceURL as JmxUrl
import javax.management.MBeanServerConnection
 
 
 
//def uri = 'service:jmx:rmi:///jndi/rmi://portal3:46302/jmxrmi'
def uri = 'service:jmx:rmi:///jndi/rmi://localhost:8686/jmxrmi'
def login = 'admin'
def password = 'adminadmin'
 
import javax.management.Query
 
def jmxurl = new JmxUrl(uri)
def attributes = new Hashtable()
 
def buffer = [ login, password ]
 
attributes.put("jmx.remote.credentials", (String[]) buffer)
 
def server = JmxFactory.connect(jmxurl, attributes).mBeanServerConnection
 
def createJDBCConnectionPool = { name ->
    def objectname = new ObjectName("amx:j2eeType=X-DomainConfig,name=na")
    def options = new ArrayList()
    options.add(name)
    options.add("com.mysql.jdbc.jdbc2.optional.MysqlDataSource")
    def properties = [
        'ResType':'javax.sql.DataSource'
    ]
 
    options.add(properties as Map)
 
    server.invoke(objectname, 
                "createJDBCConnectionPoolConfig",
                options as Object[],
                ["java.lang.String","java.lang.String","java.util.Map"] as String[] )
 
    /* To add other properties, we need to invoke setProperty to new object */
 
    objectname = new ObjectName("amx:j2eeType=X-JDBCConnectionPoolConfig,name=" + name)
 
    server.invoke(objectname, "setPropertyValue", [ "user", "xwiki"] as Object[], [ "java.lang.String", "java.lang.String"] as String[])
    server.invoke(objectname, "setPropertyValue", [ "password", "xwiki"] as Object[], [ "java.lang.String", "java.lang.String"] as String[])
    server.invoke(objectname, "setPropertyValue", [ "databaseName", "xwiki"] as Object[], [ "java.lang.String", "java.lang.String"] as String[])
    server.invoke(objectname, "setPropertyValue", [ "serverName", "localhost"] as Object[], [ "java.lang.String", "java.lang.String"] as String[])
    server.invoke(objectname, "setPropertyValue", [ "port", "3306"] as Object[], [ "java.lang.String", "java.lang.String"] as String[])
    server.invoke(objectname, "setPropertyValue", [ "networkProtocol", "tcp"] as Object[], [ "java.lang.String", "java.lang.String"] as String[])
}
 
createJDBCConnectionPool("xwikiPool")

As you probably noticed, I can’t create properties directly using the invokation of createJDBCConnectionPool. Indeed, we can specifly only few properties (take a look at the complete list). However, once the object is created, we can use the setPropertValue to create any properties we want.

Comme tout le monde, vous entendez parler du cloud computing, mais vous ne savez pas forcément ce qui se cache derrière ce terme ? Vous connaissez déjà, mais vous voulez en savoir plus ? Bref, dans tous les cas, si ce sujet vous intéresse, je vous invite à participer à la soirée organiser par cloudcamp. Cette soirée aura lieu le 11 Juin, à partir de 18h30. Pour ma part, je dois y intervenir pour parler de la sécurité.

Je me permet de rappeler, pour mes fidèles lecteurs, que Solaris/OpenSolaris est très proche du concept de cloud computing notamment grâce aux containers (zones + resource shapping), et OpenStorage.

• Introduction au cloud computing par Éric Bezille
• Programme complet et inscription
• Un billet d’Éric Bezille sur OpenStorage

At my new work, we have a lot of glassfish in production. For some of them, we even have almost 10 instances per DAS (Domain Admin Server). As a (good) system administrator, I’m a lazy man. After having to installed and created a glassfish with 10 instances, I was really tired to click, click, and click again through the web interface. Yes I know, it’s possible to edit the files directly, but I think it’s not very convenient. First, it’s easy to make mistakes, it’s not atomic, and finally you need to restart/reload the instance.

So, I was wondering if it’s possible to proceed some configuration using JMX/AMX (AppServer Management Extensions). I start to browse MBeans using JConsole, and check that’s really possible to modify the configuration, and the answer is yes. Ok, my first try is a simple one, I just want enable access.log, meaning set accessLoggingEnabled property to true for each http-service. Since I’m not really good to write Java, I wrote a groovy script. Here it comes :

 
import javax.management.ObjectName
import javax.management.remote.JMXConnectorFactory as JmxFactory
import javax.management.remote.JMXServiceURL as JmxUrl
import javax.management.MBeanServerConnection
 
def uri = 'service:jmx:rmi:///jndi/rmi://localhost:8686/jmxrmi'
def login = 'admin'
def password = 'adminadmin'
 
import javax.management.Query
 
def jmxurl = new JmxUrl(uri)
def attributes = new Hashtable()
 
def buffer = [ login, password ]
 
attributes.put("jmx.remote.credentials", (String[]) buffer)
 
def server = JmxFactory.connect(jmxurl, attributes).MBeanServerConnection
 
def enableAccessLog = { serviceUri ->
    properties = [ "accessLoggingEnabled", "true" ]
    def signature = [ "java.lang.String", "java.lang.String"]
    server.invoke(serviceUri, "setPropertyValue", properties as Object[], signature as String[] );
}
 
def checkAccessLog = { serviceUri ->
    def properties = [ "accessLoggingEnabled" ]
    def answer = server.invoke(serviceUri, "getPropertyValue", properties as Object[], "java.lang.String");
    println "Access log for: " + serviceUri + " enabled: " + answer
}
 
 
def query = new ObjectName("amx:*,j2eeType=X-HTTPServiceConfig")
 
server.queryNames(query, null).each { service ->
    checkAccessLog(service)
    enableAccessLog(service)
    checkAccessLog(service)
}

That’s magic… Sure I’ll post some others script to manage more complex configuration, like create a connection pool, etc.

As a member of the LSM staff, I organize a track about IAM. The schedule is almost closed, including:

• Pat Patterson, from OpenSSO, the famous Access Manager (SSO) of Identity Federation tool from Sun (english)
• Ludovic Poitou, from OpenDS, the future Sun’s Directory Server (english or french)
• Clément Oudot, from LemonLDAP::NG, an opensource Web SSO (english or french
• Tomas Gustavsson, from EJBCA, the most famous opensource PKI product (english)
• Jonathan Clarke, from LSC, a tool to synchronize directory from JDBC or LDAP (english or french)
• Myself, introducing about IAM, especially the provisionning (french)

This day is planned for July, the 10th, at Nantes. Check LSM website to register in a near future (registration are not opened yet). For OpenDS, LemonLDAP::NG and LSC talks, the language will be choosen according the audience.

Suite à mon précédent billet, voici les modifications à apporter à la configuration d’OpenDS pour activer le champ permettant d’obtenir la date de la dernière authentification (réussie) d’un utilisateur :

dn: cn=Default Password Policy,cn=Password Policies,cn=config
changetype: modify
replace: ds-cfg-last-login-time-attribute
ds-cfg-last-login-time-attribute: ds-pwp-last-login-time
-
changetype: modify
replace: ds-cfg-last-login-time-format
ds-cfg-last-login-time-format: yyyyMMddHHmmssZ

Attention ce champ n’est visible par défaut que par les administrateurs !

Ce qui donne :

% ldapsearch -Wxh localhost -p 1389 -D "cn=Directory Manager" -b "ou=people,dc=asyd,dc=net" '(uid=asyd)' 'ds-pwp-last-login-time'
[..]
# asyd, People, asyd.net
dn: uid=asyd,ou=People,dc=asyd,dc=net
ds-pwp-last-login-time: 20090428221635+0200

Un rapide poste qui je l’espère fera suite à d’autres pour exposer une petite surprise que j’ai eu avec LDAP (enfin de manière plus précises avec les serveurs). Lors d’un projet pour mon nouvel employeur, on me demanda d’installer un OpenSSO pour authentifier des utilisateurs et obtenir leurs attributs LDAP. Bon, jusqu’ici rien d’anormal. Néanmoins, dans les attributs utilisateurs, il est demandé un attribut fournissant la date de la dernière connexion d’un utilisateur (en pratique la date d’un dernier bind opéré avec succès). Sur le moment, je n’ai pas percuté. Ce n’est qu’au moment de revenir sur mon poste, et par acquis de conscience, que j’ai commencé à me renseigner.

Et quelle ne fut pas ma surprise lorsque je me suis rendu que :

• OpenSSO ne le permet pas de base. Après une rapide rechercher, il semblerait qu’une manière simple (c’est tout relatif) est d’écrire une classe (Java) qui sera exécutée après une authentification utilisateur.
• Active Directory semble fournir cette fonctionnalité de base (via l’attribut lastlogon)
• Sun Directory Directory Server Entreprise Edition (DSEE pour faire court) ne semble à priori pas le supporter dans toutes ses versions (>= 6.2 de mémoire, à prendre avec grande précaution) (tests en court)
• OpenDS le supporte (tests en court)
• Sun iPlanet 5.x ne le supporte tout simplement pas
• Je n’ai pas regardé pour les autres serveurs, si jamais vous avez des retours dessus, je suis preneur.

Évidemment, je vous laisse deviner quel serveur j’utilise. Donc, je me suis retrouvé à écrire un plugin (en C) pour iPlanet, j’avoue que cela est assez intéressant (enfin il y a bien pire comme tâche . Je vais mettre à disposition le code de ce plugin d’ici quelques jours, même si je doute qu’en Avril 2009 cela intéresse encore beaucoup de gens !

Pour information, pour obtenir cette fonctionnalité avec DSEE et OpenDS, il faut utiliser les password policies, et n’activer que la partie concernée. Cela va mettre à jour le champ ds-pwp-last-login-time (au moins vrai pour OpenDS).

Néannmoins, j’avoue que je suis assez surpris que cela ne soit pas de base, partout, dans tous les serveurs LDAP. Certes, cela demande un minimum de performances supplémentaires. En effet, cela provoque une écriture (opération considérée comme lente sur un annuaire LDAP) à chaque opération d’authentification réussie (mais on pourrait imaginer de vouloir l’équivalent pour un last failure). Mais au point de vue gestion d’identité, c’est quand même une information qui peut être très intéressante. Au hasard, sur un portail public, d’obtenir rapidement, et simplement, la liste des utilisateurs qui ne se sont pas connectés depuis une année.

Nos chers amis polonais (très actif dans la communauté OpenSolaris) nous propose d’assister à une session de formation sur les internes du noyau OpenSolaris. Je ne peux que vous encourager à vous inscrire pour suivre ce cours qui sera je le pense excellent !

Cela se passe ici !