Casino Bonus g6VDSrg2g6wmazyDVVaRNe3mZt7Wk5Zqk0jB14JHCkU

Thibault Monteiro

Ingénieur Études & Développement

Voir mes références

Sur cette page vous trouverez tous les clients avec qui j'ai eu l'occasion de collaborer.

Mes références

Blog

Lire les derniers articles.

Blog

Références

  • All
  • Développement
  • Intégration
  • Serveur
  • TMA
ss (2014-02-28 at 03.50.00)
ss (2014-02-28 at 03.50.00)

www.thibaultmonteiro.fr

Première version site perso :

- Responsive

- Utilisation du framework skel.js

ss (2014-03-03 at 08.54.44)
ss (2014-03-03 at 08.54.44)

www.je-relooke-ma-cuisine.fr

Correction de bugs au niveau de la facturation de prestashop.

ss (2014-03-03 at 09.04.48)
ss (2014-03-03 at 09.04.48)

www.ninapeople.com

Refonte du template

ss (2014-03-03 at 09.07.18)
ss (2014-03-03 at 09.07.18)

www.label-cravate.com

Optimisations SEO

Mise en place de rich snippet

Nettoyage du template

ss (2014-03-03 at 09.10.22)
ss (2014-03-03 at 09.10.22)

www.mobilierunique.com

Audit SEO

ss (2014-03-03 at 09.18.26)
ss (2014-03-03 at 09.18.26)

Gesco

Transfert d’une appli PHP + debug pour migrer vers du php5

ss (2014-03-07 at 12.31.23)
ss (2014-03-07 at 12.31.23)

www.grossiste-enfant.fr

Diverses modifications des modules et du template.

ss (2014-03-13 at 01.29.23)
ss (2014-03-13 at 01.29.23)

www.capictures.fr

Création du projet + Hébergement

CMS Utilisé : Koken

depil
depil

www.depil-store.com

Intervention hébergement

Modification sur le template

promesse-politiques
promesse-politiques

www.promesses-politiques.info

Réalisation du site :

- Mise en place et personnalisation du template

- Réalisation d’un formulaire en ajax avec upload en asynchrone

Compétences

  • Développement Web

  • Programmation

  • Systèmes et réseaux

  • Management

  • Modélisation

  • Business Software

Blog

Principes de haute disponibilité sous Linux

OLYMPUS DIGITAL CAMERA

Lorsque vous décidez de monter un cluster de haute disponibilité sous Linux, vous allez trouver facilement des tutos, des aides pour votre configuration.
Par contre, la plupart d’entres-eux oublient le plus important : expliquer certains concepts de base de la haute disponibilité (HA). Dans cet article, je vais essayer de vous les expliquer.

Pour construire un cluster de haute disponibilité composé d’un noeud (node) qui dessert un certain nombre d’autres noeuds pouvant être disponible lorsque l’un d’entres eux tombent vous aurez besoin :

Cluster Messaging Layer (Couche de communication du cluster) :

Le Cluster Messaging Layer est une application qui est utilisée pour communiquer entre les noeuds.
Il est aussi utilisé pour déterminer si les autres noeuds sont encore en vie. Pour Linux, les deux outils les plus utilisés sont : Heartbeat ( http://linux-ha.org/wiki/Heartbeat ) et Corosync ( http://corosync.github.io/corosync/ ). Pour l’anecdote, sachez que les deux ont étés développés par les mêmes développeurs.

Pour communiquer entre les noeuds, cette couche utilise le multicast ou l’unicast UDP.

Cluster Resource Manager ( Gestionnaire de ressources de cluster ) :

C’est le Cluster Resource Manager (CRM) qui décide des ressources à déployer et sur quel noeud les déployer.

L’un des plus utilisé dans le monde de l’open source est Pacemaker ( http://www.linux-ha.org/wiki/Pacemaker ). Il peut être configuré pour hiérarchiser certains noeuds pour certains services. Exemple : Je veux que ma base de données soit exécuté sur le serveur avec le SSD, et je veux que mon serveur d’application soit celui où mon processeur est le plus performant.

Quand l’accès à un noeud échoue (voir la couche CML ci-dessus), le gestionnaire de ressources de cluster déplace les services d’un noeud à l’autre. C’est une décision risquée et importante et il faut être sûr que le noeud n’est vraiment pas accessible et que ce n’est pas juste un problème de connexion réseau. Pour prendre ces décisions le CRM utilise deux concepts : Quorum et STONITH.

Quorum

Le « Quorum » signifie que la majorité des noeuds sont toujours accessible et on peut donc décider qu’une action soit prise (migration etc…).

Dans un cluster à 3 noeuds, si le noeud 1 se déconnecte, les deux autres noeuds peuvent décider de prendre en charge les services du noeud 1. Si votre CRM est correctement configuré, le noeud 1 doit remarquer qu’il n’a plus de Quorum (les autres noeuds sont accessibles), il arrête donc les rôles principaux pour éviter d’avoir, par exemple, deux copies de la base de donnée (bdd) avec différentes modifications appliqués par les clients.

En clair, avoir le quorum dans un cluster signifie que les autres noeuds sont accessibles. Vous pouvez définir le comportement désiré lorsque le cluster perd le quorum, exemple : le noeud pourrait être chargé d’essayer d’éteindre l’autre noeud : STONITH.

STONITH

Comme vous l’aurez surement compris, STONITH ( Shoot The Other Node In The Head) signifie que vous éteignez une node dans le but de protéger les ressources partagées, soit par la desactivation du noeud, ou simplement en interdisant l’accès à celle-ci.

On l’utilise donc pour désactiver un noeud défaillant.

Resource Agents

Les RA sont des plugins ou des scripts shell qui sont utilisés par le gestionnaire de ressources (CRM) pour déterminer si un service est en cours d’exécution et peut également être utilisé pour démarrer ou arrêter un service.

Pour Pacemaker, il y a beaucoup de resource agents disponibles, vous n’aurez probablement pas besoin de les coder vous même.

Votre gestionnaire de ressource détermine quelles services doivent être démarrés et où, je vous conseille donc par défaut de désactiver tous vos scripts de démarrage sur vos serveurs. Cela évitera par exemple que deux services tournent sur deux serveurs différents.

Conclusion

J’espère que cela vous a aidé à comprendre un peu mieux le fonctionnement d’un cluster, c’était un article purement théorique, il existe des centaines d’articles sur d’autres blogs qui vous apprendront à mettre tout ça en place, maintenant vous savez comment tout cela fonctionne.

 

Namecoin

18.-namecoin-logo

Vous avez certainement tous entendu parler du bitcoin, la monnaie peer-to-peer décentralisée.

Aujourd’hui, je vais vous parler d’une autre crypto-monnaie moins connu mais tout aussi interessante : le Namecoin.

Le Namecoin est une crypto-monnaie qui agit également comme alternative DNS décentralisé, ce qui éviterait, par exemple, toute censure de l’ICANN, et permetterai de réduire le nombre de pannes.

Le Namecoin utilise l’algorythme du Bitcoin, il a donc la même limite de 21.000.000, chaque Namecoin est divisible jusqu’à 8 décimales.

En janvier 2014, 123616 domaines ont été enregistrés. A savoir que pour l’instant, les domaines .bit ne sont pas attribués, il faut donc avoir une copie de la chaine de blocs ou l’accès à un serveur DNS public participant au système Namecoin.

Pour avoir plus d’informations sur le Namecoin et le projet dot-bit, je vous propose d’aller faire un tour sur leur FAQ : http://dot-bit.org/FAQ

Sass 3.3 est sorti

logo-235e394c

Aujourd’hui petite news pour vous notifier de la sortie de Sass 3.3.

On a quelques petites features sympas qui viennent s’ajouter au métalangage de CSS.

Je vous invite à lire cette news qui fait très bien le tour de ces nouveautés : http://davidwalsh.name/future-sass

Fermez vos balises !

ss (2014-03-06 at 09.55.54)

Aujourd’hui petite news amusante, voici ce qu’il se passe lorsque vous oubliez de fermer vos balises h3 :

http://www.sewingandembroiderywarehouse.com/embtrb.htm

L’histoire du bug GnuTLS

computer-security

Vous avez surement entendu parler du bug critique GnuTLS, qui d’ailleurs à été récemment corrigé. De quoi s’agissait-il exactement? Pourquoi était-ce un gros problème? Que s’est-il passé?

Le bug était situé exactement ici : lib/x509/verify.c :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
 
static int
check_if_ca (gnutls_x509_crt_t cert, gnutls_x509_crt_t issuer, unsigned int flags)
{
    int result = 0;
    gnutls_datum_t cert_signed_data   = { NULL, 0 };
    gnutls_datum_t issuer_signed_data = { NULL, 0 };
    gnutls_datum_t cert_signature     = { NULL, 0 };
    gnutls_datum_t issuer_signature   = { NULL, 0 };
 
    /* Check if the issuer is the same with the
     * certificate. This is added in order for trusted
     * certificates to be able to verify themselves.
     */
    if (_gnutls_x509_get_signed_data (issuer->cert, "tbsCertificate", &issuer_signed_data) < 0 ||
        _gnutls_x509_get_signed_data (cert->cert, "tbsCertificate", &cert_signed_data) < 0 ||
        _gnutls_x509_get_signature (issuer->cert, "signature", &issuer_signature) < 0 ||
        _gnutls_x509_get_signature (cert->cert, "signature", &cert_signature) < 0
       )
    {
        gnutls_assert ();
        result = 0;
        goto cleanup;
    }
 
    /* If the subject certificate is the same as the issuer
     * return true.
     */
    if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_SAME))
    {
        if (cert_signed_data.size == issuer_signed_data.size &&
            !memcmp (cert_signed_data.data, issuer_signed_data.data, cert_signed_data.size) &&
            cert_signature.size == issuer_signature.size &&
            !memcmp (cert_signature.data, issuer_signature.data, cert_signature.size)
           )
        {
            result = 1;
            goto cleanup;
        }
    }
 
    switch (gnutls_x509_crt_get_ca_status (issuer, NULL))
    {
    case 1:
        result = 1;
        goto cleanup;
 
    case GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE:
        /* Handle V1 CAs that do not have a basicConstraint, but accept
         * these certs only if the appropriate flags are set.
         */
        if ((flags & GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT) ||
            !(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT) && gnutls_x509_crt_check_issuer (issuer, issuer) == 1
           )
        {
            gnutls_assert ();
            result = 1;
            goto cleanup;
        }
        break;
    }
 
    gnutls_assert ();
    result = 0;
 
cleanup:
    _gnutls_free_datum (&cert_signed_data);
    _gnutls_free_datum (&issuer_signed_data);
    _gnutls_free_datum (&cert_signature);
    _gnutls_free_datum (&issuer_signature);
 
    return result;
}
 
static int
check_if_ca (gnutls_x509_crt_t cert, gnutls_x509_crt_t issuer, unsigned int flags)
{
    int result = 0;
    gnutls_datum_t cert_signed_data   = { NULL, 0 };
    gnutls_datum_t issuer_signed_data = { NULL, 0 };
    gnutls_datum_t cert_signature     = { NULL, 0 };
    gnutls_datum_t issuer_signature   = { NULL, 0 };
 
    /* Check if the issuer is the same with the
     * certificate. This is added in order for trusted
     * certificates to be able to verify themselves.
     */
    if (_gnutls_x509_get_signed_data (issuer->cert, "tbsCertificate", &issuer_signed_data) < 0 ||
        _gnutls_x509_get_signed_data (cert->cert, "tbsCertificate", &cert_signed_data) < 0 ||
        _gnutls_x509_get_signature (issuer->cert, "signature", &issuer_signature) < 0 ||
        _gnutls_x509_get_signature (cert->cert, "signature", &cert_signature) < 0
       )
    {
        gnutls_assert ();
        result = 0;
        goto cleanup;
    }
 
    /* If the subject certificate is the same as the issuer
     * return true.
     */
    if (!(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_SAME))
    {
        if (cert_signed_data.size == issuer_signed_data.size &&
            !memcmp (cert_signed_data.data, issuer_signed_data.data, cert_signed_data.size) &&
            cert_signature.size == issuer_signature.size &&
            !memcmp (cert_signature.data, issuer_signature.data, cert_signature.size)
           )
        {
            result = 1;
            goto cleanup;
        }
    }
 
    switch (gnutls_x509_crt_get_ca_status (issuer, NULL))
    {
    case 1:
        result = 1;
        goto cleanup;
 
    case GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE:
        /* Handle V1 CAs that do not have a basicConstraint, but accept
         * these certs only if the appropriate flags are set.
         */
        if ((flags & GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT) ||
            !(flags & GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT) && gnutls_x509_crt_check_issuer (issuer, issuer) == 1
           )
        {
            gnutls_assert ();
            result = 1;
            goto cleanup;
        }
        break;
    }
 
    gnutls_assert ();
    result = 0;
 
cleanup:
    _gnutls_free_datum (&cert_signed_data);
    _gnutls_free_datum (&issuer_signed_data);
    _gnutls_free_datum (&cert_signature);
    _gnutls_free_datum (&issuer_signature);
 
    return result;
}

Vous avez vu le bug?

Voici le correctif :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
int result;
result =
_gnutls_x509_get_signed_data (issuer->cert, « tbsCertificate »,
&issuer_signed_data);
if (result < 0)
{
gnutls_assert ();
goto fail; // CHANGED
}
 
// snip
 
fail: // ADDED
result = 0;
 
cleanup:
// cleanup type stuff
return result;
}
int result;
result =
_gnutls_x509_get_signed_data (issuer->cert, « tbsCertificate »,
&issuer_signed_data);
if (result < 0)
{
gnutls_assert ();
goto fail; // CHANGED
}

// snip

fail: // ADDED
result = 0;

cleanup:
// cleanup type stuff
return result;
}

Le soucis venait des valeurs de retour. La fonction « check_if_ca » retourne true plutôt que 1, lorsque le certificat était validé (0 si non valide).

Par contre, les autres fonctions utilisées retournes des valeurs négatives quand elles échouent. En C, une valeur de nombre entier non nul est considéré comme une valeur vraie (true), donc le certificat passait comme valide.

De ce fait, la fonction utilisé par gnutls_x509_crt_verify (qui vérifie les certificats x509), passait tout les certificats non valide comme authentique.

Allons voir de quand ce bug date :

1
2
3
$ git clone https://git.gitorious.org/gnutls/gnutls.git
$ git checkout 6aa26f78150ccbdf^
$ git blame lib/x509/verify.c
$ git clone https://git.gitorious.org/gnutls/gnutls.git
$ git checkout 6aa26f78150ccbdf^
$ git blame lib/x509/verify.c

Le problème ce situait à la ligne 141/145 édité par Simon Josefsson… En 2005 (le bug ne date pas d’hier !).

Petite leçon à retenir : Si vous codez en C, soyez rigoureux dans la façon dont vous écrivez votre code et testez le bien !

Vizify acheté par Yahoo

ss (2014-03-05 at 10.06.05)

Pour la plupart d’entre vous Vizify ne vous dit rien, pourtant Yahoo vient de décider de racheter la startup.

Après avoir racheté Tumblr pour 1,1 milliard de dollars, la patronne de Yahoo!, Marissa Mayer (arrivée durant l’été 2012) nous montre bien qu’elle souhaite agrandir le catalogue offert à ses utilisateurs.

Vizify permet de visualiser de manière graphique les données de l’activité d’un internaute sur les médias sociaux pour créer des graphiques ou des vidéos.

Pour ceux qui ne connaissaient pas Vizify, c’est par ici : https://www.vizify.com/yahoo#transition

Presentation

smtp-server

Bonjour à tous et bienvenue sur ce blog.

Comme vous pourrez le constater, mon blog ne va pas faire le tour de l’actu au quotidien, mais juste reprendre quelques news IT qui auront marqué la journée ou la semaine.

N’hésitez pas à réagir dans les commentaires .

Have fun !

Page de contact

Votre Nom (Obligatoire)

Votre Email (Obligatoire)

Sujet

Votre message

captcha

Thibault Monteiro

Ingénieur Étude & Développement

Telephone: 0666664384
E-mail: thibault.monteiro@supinfo.com
Address: 36 rue Jacques Perdrix