lundi 6 novembre 2017

Ajouter la date et les secondes dans gnome shell

Dans un terminal exécuter :

gsettings set org.gnome.desktop.interface clock-show-date true
gsettings set org.gnome.desktop.interface clock-show-seconds true

vendredi 27 octobre 2017

Grok pattern conditionnel check

Problème

Lorsque l'ont veut appliquer un pattern grok sur une chaine envoyée par filebeat par exemple, il arrive que certains champs qui doivent respecter un pattern donné soit vide ce qui se traduit coté grok par un pattern qui ne correspond pas et donc par un parsing qui n'est pas envoyé correctement à elastic search. 

Exemple

Soit la chaine suivante : 
[27/Oct/2017:15:38:48 +0200] 127.0.0.1 - 200 80 212 GET /show HTTP/1.1

Et le pattern grock suivant : 
\[%{MONTHDAY}[./-]%{WORD}[./-]%{YEAR}[:]%{TIME}%{SPACE}[+]%{INT}\]%{SPACE}%{IP:[parameters][remoteip]}%{SPACE}%{USER:[parameters][user]}%{SPACE}%{INT:[parameters][httpcode]}%{SPACE}%{INT:[parameters][localport]}%{SPACE}%{INT:[parameters][processtime]}%{SPACE}%{GREEDYDATA:[parameters][requestfistline]}

Le résultat attendu :

{
  "MONTHDAY": [
    [
      "27"
    ]
  ],
  "WORD": [
    [
      "Oct"
    ]
  ],
  "YEAR": [
    [
      "2017"
    ]
  ],
  "TIME": [
    [
      "15:38:48"
    ]
  ],
  "HOUR": [
    [
      "15"
    ]
  ],
  "MINUTE": [
    [
      "38"
    ]
  ],
  "SECOND": [
    [
      "48"
    ]
  ],
  "SPACE": [
    [
      " ",
      " ",
      " ",
      " ",
      " ",
      " ",
      " "
    ]
  ],
  "INT": [
    [
      "0200"
    ]
  ],
  "[parameters][remoteip]": [
    [
      "127.0.0.1"
    ]
  ],
  "IPV6": [
    [
      null
    ]
  ],
  "IPV4": [
    [
      "127.0.0.1"
    ]
  ],
  "[parameters][user]": [
    [
      "-"
    ]
  ],
  "USERNAME": [
    [
      "-"
    ]
  ],
  "[parameters][httpcode]": [
    [
      "200"
    ]
  ],
  "[parameters][localport]": [
    [
      "80"
    ]
  ],
  "[parameters][processtime]": [
    [
      "212"
    ]
  ],
  "[parameters][requestfistline]": [
    [
      "GET /show HTTP/1.1"
    ]
  ]
}

Si dans la chaîne récupérée l'ip n’apparaît plus alors le pattern ne sera pas correspondant:
[27/Oct/2017:15:38:48 +0200]  - 200 80 212 GET /show HTTP/1.1

Solution

Utiliser le terme conditionnel pour la vérification du pattern.
Cela se traduit par l'utilisation de (?:le terme a mettre en conditionnel |).

Exemple : 

\[%{MONTHDAY}[./-]%{WORD}[./-]%{YEAR}[:]%{TIME}%{SPACE}[+]%{INT}\]%{SPACE}(?:%{IP:[parameters][remoteip]}|)%{SPACE}%{USER:[parameters][user]}%{SPACE}%{INT:[parameters][httpcode]}%{SPACE}%{INT:[parameters][localport]}%{SPACE}%{INT:[parameters][processtime]}%{SPACE}%{GREEDYDATA:[parameters][requestfistline]}

Maintenant le pattern est bien correspondant et la chaîne traitée correctement. 

jeudi 7 avril 2016

Docker registry avec certificat auto-signé (--insecure-registry)

Démarrer le registry sur le serveur

docker run -d -p 5000:5000 --restart=always --name registry \
  -v {chemin_du_fs_stockage_des_donnes}/data:/var/lib/registry \
  registry:2f

Authentification auto-signé (Voir https://docs.docker.com/registry/insecure/ ) 

myregistrydomain => ip, dns du serveur hébergeant le registry
Attention! Pas du tout adapté pour un environnement de PROD ! 

Génération du certificat sur le serveur hébergeant le registry

 mkdir -p certs && openssl req \
  -newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key \
  -x509 -days 365 -out certs/domain.crt
Be sure to use the name myregistrydomain.com as a CN.


Démarrage du registry avec les certificats

docker run -d -p 5000:5000 --restart=always --name registry \
-v {chemin_contenant_les_crt_key}:/certs \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key registry:2

Coté client

Attention testé uniquement sur Ubuntu, la facon diffère selon les distributions. Cela doit fonctionner sur distribution qui sont basés Debian sur car Ubuntu est développé a partir de celui-ci.
RedHat & les autres distribution ont leur propre facon d'ajout de certificat.


  1. Récupérer le certificat généré utilisé par le registry
  2. Sous Ubuntu aller dans /usr/local/ca-certificates
  3. Déposer le certificat update-ca-certificates
  4. service docker stop 
  5. vi /etc/default/docker
  6. Ajouter DOCKER_OPTS="--insecure-registry {url-registry}:5000" (Ex: DOCKER_OPTS="--insecure-registry myregistrydomain.com:5000" )
  7. service docker start 


Commandes 


myregistrydomain => ip, dns du serveur hébergeant le registry

Déposer une image sur le registry

docker push myregistrydomain.com:5000/{images}/{tag}

Obtenir une image du registry

docker pull myregistrydomain.com:5000/{images}/{tag}

Lister les images dans le docker repository

Sur le serveur hébergeant le registry ont peut trouver les repositories correspondant aux images déposés dans le registry

ls -l {chemin_du_fs_stockage_des_donnes}/data/docker/registry/v2/repositories

lundi 26 octobre 2015

Page blanche lors de l'installation de testlink

Problème

Après avoir installé (migration testlink 1.9.13 > 1.9.14) testlink j'avais une page blanche sur tout le site.
La page blanche survenait lorsque je copias le fichier config_db.inc.php contenant les infos de connexion à la base de donnée.

Solution

Après avoir déclaré un incident mantis a l'équipe gérant testlink (http://mantis.testlink.org/view.php?id=7311) il s'avère que c'était bêtement un problème de droits sur deux répertoires.

Il m'a suffit de changer les droits pour les répertoires en 775: 

{testlink_install}/gui/templates_c
{testlink_install}/logs



mardi 10 février 2015

Stubber des classes dans une chaine d'appel pour cloisonner les test d'intégration

Problème

Dans le code applicatif une classe qui faisait un appel web service vers une autre application. 

Je voulais tester ma méthode a travers un test d'intégration sans pour autant faire l'appel réel vers le web service afin de ne pas créer de couplage pendant l’exécution de mon test.

J'ai voulu utiliser Mockito et PowerMock afin de stubber la classe mais cette classe était utilisée très loin dans la chaine d'appel (Le TI que je faisait était de haut niveau). 

Mon test était donc dépendant du service distant.

Solution

Exclure les classes gênantes

J'ai exclu dans ShrinkWrap les classes gênantes dans la construction de l'archive java pour Arquillian : 

package fr.ftravaglia;

import org.jboss.arquillian.container.test.api.Deployment;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.shrinkwrap.api.Filters;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.asset.EmptyAsset;
import org.jboss.shrinkwrap.api.spec.JavaArchive;
import org.junit.runner.RunWith;

import fr.ftravaglia.RemoteServiceMails;
import fr.ftravaglia.RemoteServiceAdresses;


@RunWith(Arquillian.class)
public class ArquillianInit {
  
 @Deployment
 public static final JavaArchive createArchive() {
  return ShrinkWrap
    .create(JavaArchive.class, "demo-ftravaglia.jar")
    .addPackages(true, Filters.exclude(RemoteServiceMails.class, RemoteServiceAdresses.class), "fr.ftravaglia")
    .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
    .addAsResource("META-INF/persistence.xml",
      "META-INF/persistence.xml");
 }
}

Ajouter les stubs coté test

Dans la partie test du projet (src/test/java) j'ai crée deux classe remplaçant celle qui ont été exclues.
Dans mon projet j'utilise CDI. Les classes injectés le sont a travers des qualifiers car les instances sont représenté par des interfaces pour l'IOC.

Voici une des classes (la deuxième a la même structure) 


package fr.ftravaglia;

import fr.ftravaglia.RemoteServiceMailsEAO;
import fr.ftravaglia.RemoteServiceMailsImplWS.RemoteServiceMailsQualifier;

/**
 * Use for not call remote app.
 */
@RemoteServiceMailsQualifier
public class RemoteServiceMailsMock implements RemoteServiceMailsEAO {

 /**
  * Default constructor
  */
 public RemoteServiceMailsMock() {
  super();
 }
 
 /**
  * {@inheritDoc}
  */
 @Override
 public boolean isMailValid(String mail){
  boolean result = false;

  if (mail != null && !mail.isEmpty()) {
   result = true;
  }
  return result;
 }

}

Dans le code applicatif réel l'injection se fait par :

@Inject
@RemoteServiceMailsQualifier
private transiant RemoteServiceMailsEAO serviceMailEAO;

Du coup lorsque d'Arquillian se lance et publie l'application dans le serveur d'application embarqué, les classes sont supprimés de l'archive et celles définies en tant que stubs sont utilisés a la place des classes réelles.

En cas de questions n'hésitez pas ;)