Archives pour la catégorie Uncategorized

9 avril 2015 : Emeric Bréhier député PS de la 10e circonscription de Seine-et-Marne soutiens le #PJLRenseignement

Suite a ma prise de contact avec Mr Emeric Bréhier député PS de la 10e circonscription de Seine-et-Marne afin d’exposer mon point de vue de citoyen sur le Projet de loi Renseignement j’ai eu droit à une réponse que j’ai trouvé très formaté et au élément de langage bien cadré.  J’ai effectué une réponse très brève et un peu épidermique.

Bonjour Mr Valette

Merci pour la réponse du député Emeric Bréhier que vous m’apporter. J’ai pris le temps de la lire et d’en comprendre le sens.

Je constate que la réponse est standard et reprend la doxa du gouvernement.

Je ne suis absolument pas d’accord avec les arguments avancés et vous rappel qu’il ne faut pas prendre les enfants du bon dieu pour des canards sauvages !

J’ai partagé de façon brève mon impression sur mon blog : https://www.karlesnine.com/2015/04/07/emeric-brehier-depute-ps-de-la-10e-circonscription-de-seine-et-marne-soutiens-le-pjlrenseignement/ . Mais aussi sur twitter : https://twitter.com/Karlesnine/status/585369762139512832

Je partageras mon opinion avec mes amis et parents ainsi que prochainement a l’assemblé de copropriété de ma résidence ou je dois prendre la parole concernant le haut débit. Je pense que la note suivante explique très clairement les enjeux néfastes de ce projet de loi et je compte m’appuyer dessus : http://blog.jbfavre.org/2015/04/07/loi-renseignement-expliquee-simplement/

Sincère salutation

C.C.Croix

Je ne m’attendais pas à se que l’échange ce poursuive. Il est tout à l’honneur de Mr Emeric Bréhier et de son attaché parlementaire Mr Valette (qui doit tenir le clavier) . Cependant ma réponse à fait moucher et une contre argumentation vient de me parvenir. La voici :

Mr le député n’argumente que de nombreux changement sont intervenus par le jeu des amendements. Il me reste à analyser tout cela et trié avant de réponse 🙂

 

Imprimante HP B209a et Mac OSX Lion 10.7

J’ai une imprimante HP photosmart B209a depuis 2010. Je n’ai plus le carton, ni la doc, bref classique. Cette imprimante à la particularité d’être wifi et jusqu’à maintenant je l’utilisais via un câble USB. J’ai eu besoin de la reconfigurer et surtout de la passer en wifi et donc de modifier la paramètre réseau.

Pour les personnes que ça intéresse voici la manipulation pour saisir le SSID et la clef wifi dans les paramètres de l’imprimante B209a depuis un poste sous  Mac OSX Lion 10.7

 

La manipulation est la suivante :

  1. Restaurer les paramètres par défaut de l’imprimante
  2. Connecter en wifi sur le réseau adhoc diffusé par l’imprimante
  3. Une fois connecté en wifi avec l’imprimante et bien imprimer la configuration réseau de l’imp pour connaitre l’IP de l’imprimante.
  4. Sous  Safari, se connecter sur l’IP de l’imprimante  elle possède un serveur web embarqué
  5. Sous cette interface graphique, saisir les paramètres corrects de votre réseau Wifi (SSID et clef de cryptage)

Attention, lorsque l’on valide l’écran, l’on perd la communication avec l’imprimante car le réesau adhoc a disparu pour être remplacé par celui de votre point d’accès.

  1. Ce connecter sur son réseau
  2. Retrouver l’imprimante HP photosmart B209a via « préférence système -> imprimante et scanner -> etc.. »
Et voila

 

 

Besoins liés à l’exploitation dans le cloud IaaS

Définitions

Outil de gestion de configuration : Puppet, Chef, Cfengin etc..
Infrastructure : ensemble système et réseau logique assurant la production
plate-forme : ensemble système et réseau physique assurant la production
Instance : serveur au sens « operating system » physique ou virtuel
DB ou base de donnée : Au sens premier de gestionnaire de base de donnée, SQL comme NoSQL.
La Production : État ou l’ensemble des services sont disponibles, en lignes, actifs et assurent la prestation attendu par nos client.
Exploitation : Tout activité humaine assurant la disponibilité de La Production, son rétablissement ou sa pérénité.
Problème systémique : Instabilité ou déséquilibre de la plate-forme concerné du à un effet domino entre services impactant La Production
Nécessaire : Indispensable à l’exploitation de La Production
Souhaité : Doit faire l’objet d’un engagement de mise à disposition
Idéal : Objectif de l’état de l’art

 

Cas d’exploitation

Ajout, remplacement, augmentation, modification d’élément d’une plate-forme d’un infrastructure

  • Il n’y a pas de mise à niveau d’instance (changement de version d’un service), elle est remplacé. Toute la validation étant est faite en dehors de La Production et la coupure de service est réduite à son minimum. [Nécessaire]
  • Il y a des mise à jour d’instance (changement mineurs dans une même version). Changement nécessitant pas de validation et rendant un service immédiat  pour des question de sécurité ou de bug fix. [Nécessaire]
  • La mise à jour d’instance doit pouvoir être faire instance par instance ou par lot d’instance sans coupure de La Production. [Souhaité]
  • La mise en production de nouveau serveur de DB dans un rôle existant doit ce faire par création d’un esclave chainé aux serveur existant. La récupération, duplication, synchronisation des données est faire en temps masqué par rapport à La Production. Le nettoyage de donnée pouvant intervenir à postériori par exemple dans les cas d’extension de sharding sans retrait de l’instance de La Production. [Idéal]
  • Le remplacement d’un serveur de DB master doit ce faire par promotion d’un esclave. moyen rapide et sur facilement exécutable avec un impacte marginal sur La Production. [Souhaité]
  • Les backups des DB et les opérations de backoffice doivent ce faire sur un esclave pour limité leur impacte sur La Production. Si l’impact sur La Production  est cependant trop fort un esclave dédier à l’opération peux être mis en service. [Souhaité]
  • Un esclave de DB peux être mis en service ponctuellement pour des besoins de R&D, pour l’étude de nouvelle métrique BI ou la migration de schéma par exemple, ceci sans impacter  La Production. [Idéal]
  • La création d’un nouveau rôle dans l’infrastructure ne doit pas engendre d’autre R&D et validation que celui du service assumant ce rôle. L’ensemble du système et des autres service doit être déjà validé et disponible via l’outil de gestion de configuration. Ceci pour limiter la charge de travail et gagner en productivité. [Nécessaire]
  • En cas de mise en production d’une nouvelle instance de cache sur une plate-forme le warmup doit être transparent et automatique. [Idéal]
  • Le monitoring doit fournir un historique comparable entre toute les valeurs enregistrés, ceci implique une même duré d’historique, une même échelle de temps et des unités de mesure harmonisées. [Souhaité]
  • Les outils d’exploitation des plate-formes doivent répondre au même contrainte que La Production. Les outils sont scalable, dupliqué, redondant, sauvegardé etc..  [Souhaité]
  • Le poste de travail AdminSys, sa configuration ou sa connectivité ne sont pas des éléments bloquant. L’administration de la plateforme doit pouvoir ce faire de chez soi (astreinte), depuis d’autre locaux (désastre) ou depuis un poste de travail qui n’est pas le sien (urgence) facilement. Ceci n’exclue nullement le contrôles d’accès. [Nécessaire]

Cas d’incident & astreinte.

Résolution d’incident impactant La Production, en heure ouvrées ou en astreinte

  • Un serveur de DB doit posséder un esclave pouvant être activé à la demande afin de palier à une défaillance du serveur maitre et limité l’impact sur La Production. [Nécessaire]
  • Un rôle dans l’infrastructure doit être assumé par une instance. La perte de l’instance ne doit pas impacter plusieurs rôle afin de limité l’effet négatif sur La Production et / ou réduire le temps de retour de La Production [Nécessaire]
  • L’optimum en cas de défaillance d’une instance est que sa charge de travail soit répartis entre les instances restantes dans le même rôle [Idéal]
  • Si l’optimum n’est pas possible le remplacement de l’instance doit être le plus rapide possible par l’utilisation dans l’ordre de spare  [Idéal],
  • d’image de clone [Nécessaire],
  • la reconstruction via l’outil de gestion de configuration [Nécessaire].
  • L’autopsie post mortem doit pouvoir ce faire sur un instance sortie de La Production. L’instance reste en l’état est n’est plus adressé, ne reçois plus de flux entrant et ne produit plus de flux,  sortant, donc en dehors de La Production, mais toujours intégré à la plateforme et conforme à l’infrastructure [Souhaité].

Cas de problème systémique

  • En cas de problème systémique il doit être possible de fermer le service à nos client provisoirement tout en maintenant la plateforme conforme à l’infrastructure. Cela implique donc que l’ensemble des rôles restes actif et dans l’état pour assurer La Production [Nécessaire].
  • La fermeture du service implique forcement une réponse adapté aux requêtes de nos client [Nécessaire].
  • La fermeture du service impliquant que l’ensemble des rôles restes actif et dans l’état pour assurer La Production il est donc possible de tester l’ensemble des services et rôle d’un point de vue client [Nécessaire].
  • En cas de problème systémique le monitoring doit permettre de déterminer le premier domino tombé et l’ordre des suivant. De déterminer l’enchainement des causes  et conséquences, service par service puis instance par instance  [Souhaité].
  • En cas de présence de service de cache dans l’infrastructure une procédure de warmup doit être disponible afin d’initialisé les contenus par type de donnée ou dataset  [Souhaité].

Cas de Mise en production code produit.

  • La mise en production d’une version de code produit doit être le plus transparente possible et ne pas impacter La Production [Souhaité].
  • L’adaptation de l’infrastructure si nécessaire doit être réalisé en amont, ceci par changement des instances, ajout d’instance, modification des schémas de DB etc.. [Souhaité]
  • La mise en production d’une version de code produit ne concerne pas la migration de donnée [Idéal].
  • La migration de donnée vers un nouveau format ou support doit être réalisé au fil de l’eau sans coupure de La Production. Les ressources infrastructure nécessaire devant être anticipé et mise à disposition en amont [Idéal].
  • L’impact sur la qualité de La Production d’une nouvelle version de code doit être « monitorable », les métriques, graph et outils de monitoring doivent être conçus en ce  sens [Nécessaire].
  • La possibilité de RollBack vers une version de code antérieure est indispensable. La décision de retour arrière relavant du produceur (pour une question de qualité produit) et de l’infra / exploit pour une question de maintien de La production [Nécessaire].
  • Deux versions de code doivent pouvoir cohabité temporairement sur les différents rôles et instance sans impacter La Production. Le temps d’une migration ou d’un rollback par exemple [Idéal].
  • La mise en production de code produit sur la plate-forme de production doit être précédé d’une validation sur une plate-forme de pré-production [Nécessaire].
  • La plate-forme de pré-production doit être ISO avec l’infrastructure (séparation des rôle, instances, flux) sans être ISO avec la plate-forme de production d’un point de vue dimension  [Souhaité].
  • La plate-forme de pré-production doit opérer avec les données de la plate-forme de production (Même DB etc..) [Souhaité].
  • Des plate-forme de test / stage non ISO avec l’infrastructure et non ISO avec la plate-forme de production sont utilisé pour tester des évolutions  / branche avant leur intégration / fusion et leur validation en pre-prodution [Idéal].

Cas de goulot d’étranglement

  • En cas de goulot d’étranglement le monitoring toi permettre de déterminer sa localisation (Rôle, Instance, API / Service, Type d’appel) et le seuil d’effet [Souhaité].
  • La scalabilité horizontal par ajout d’instance dans un rôle doit être possible a chaud afin de maintenir le service avant toute optimisation [Souhaité].
  • Dans tout les cas la scalabilité vertical par augmentation des tailles d’instances (puissance serveur) doit être possible.
  • Manuellement [Nécessaire].
  • Automatiquement configurer sans son rôle en fonction de possibilité matériel [Idéal].

Cas de monter en charge

  • L’anticipation des montés en charge doit être la règle, grâce au monitoring et au prévisionnelle opération (évènement, marketing etc.) [Nécessaire].
  • L’ajustement de plateforme aux monté de charge (élasticité) doit être possible [Souhaité].

Cas de désastre

La perte d’une plate-forme ou de connectivité avec elle.

  • La construction d’une nouvelle plate-forme le plus rapidement possible par l’utilisation conjugué de spare, d’image de clone, ou construction d’instance via l’outil de gestion de configuration :
  • Dans une autre localisation géographique (AZ / DataCenter, Région) doit être réalisable pour rétablir La Production [Souhaité].
  • Chez un autre fournisseur  [Idéal].
  • La re-construction d’une nouvelle plate-forme implique la restauration de La Production avec des données froide provenant de sauvegarde au minimum  [Nécessaire].

Cas de débug.

  • Réalisable en production car non reproductible et non observable en infra isolée (dev ou maquette), corrélé à une charge, utilisation particulière ou car la cause pouvant être systémique et relever d’un conjonction Infa / Code / Aws environnement [Nécessaire].
  • Pourvoir faire une lecture en parallèle et simultané des logs applicatifs et systèmes pour un rôle / instances ou plusieurs rôle / instances sélectionnés comme pour la plate-forme en entier [Nécessaire].
  • Pourvoir augmenter ou diminuer  la verbosité des log applicatifs et systèmes pour un rôle ou plusieurs rôle sélectionnés comme pour la plate-forme en entier [Souhaité].
  • Pouvoir prendre en compte de nouveau log applicatifs à la demande du dev et/ou à chaque version de code  [Idéal].

Minify css et Js avec YUI compressor en ligne de commande

 

Le but

La compression des css et des javascripts est avec la l’optimisation des images un facteur de performance pour les sites web. J’ai fait la démonstration il y a quelque année avec voici.fr du gain et de la pertinence. Dans les deux cas le but est de transmettre moins de donnée (moins de bande passante consommé, moins de stockage, moins de donnée manipulé par les processus) , donc d’afficher plus rapidement une page, donc d’être mieux référencé par les moteurs de recherche.

 

yui-compressor

Yui Compresssor est un outil Yahoo  inventé par leurs développeurs de la performance team. Le yui-compressor est un outil java disponible dans votre dépôt debian. Alors laissez faite apt ou aptitude …

# apt-cache show yui-compressor
Package: yui-compressor
Priority: optional
Section: java
Installed-Size: 824
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Architecture: all
Version: 2.4.2-2
Depends: default-jre-headless | java5-runtime-headless, libjargs-java, java-wrappers
Filename: pool/main/y/yui-compressor/yui-compressor_2.4.2-2_all.deb
Size: 747892
MD5sum: 492d2c30c7f91a1307ce29bd4df7116a
SHA1: 69cc96ae9bd7c3e92a802576dc2a13892f02b8b7
SHA256: ea6577e753bdfa84ed980283f26f8aa392dd4e6595febc30da3bd767236536d5
Description: JavaScript/CSS minifier
 The YUI Compressor is a JavaScript compressor which, in addition to removing
 comments and white-spaces, obfuscates local variables using the smallest
 possible variable name. This obfuscation is safe, even when using constructs
 such as 'eval' or 'with' (although the compression is not optimal is those
 cases) Compared to jsmin, the average savings is around 20%.
 .
 The YUI Compressor is also able to safely compress CSS files. The decision
 on which compressor is being used is made on the file extension (js or css).
Homepage: http://developer.yahoo.com/yui/compressor/

Oui pour l’utiliser vous avez besoin de Java

# apt-get install yui-compressor
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
 ca-certificates-java default-jre-headless java-common java-wrappers libjargs-java liblcms1 libnspr4-0d libnss3-1d openjdk-6-jre-headless openjdk-6-jre-lib tzdata-java
Paquets suggérés :
 default-jre equivs libjargs-java-doc liblcms-utils libnss-mdns sun-java6-fonts ttf-dejavu-extra ttf-baekmuk ttf-unfonts ttf-unfonts-core ttf-sazanami-gothic ttf-kochi-gothic ttf-sazanami-mincho
 ttf-kochi-mincho ttf-wqy-microhei ttf-wqy-zenhei ttf-indic-fonts
Les NOUVEAUX paquets suivants seront installés :
 ca-certificates-java default-jre-headless java-common java-wrappers libjargs-java liblcms1 libnspr4-0d libnss3-1d openjdk-6-jre-headless openjdk-6-jre-lib tzdata-java yui-compressor
0 mis à jour, 12 nouvellement installés, 0 à enlever et 8 non mis à jour.
Il est nécessaire de prendre 33,8 Mo dans les archives.
Après cette opération, 91,9 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?

Résultat

Le résultat sur le fichier css du blog est éloquent

# cp -a style.css style.css.ori
# yui-compressor -v --type css style.css.ori -o style.css
#ls -lrth style.css*
-rw-r--r-- 1 root root 66K 16 févr. 09:27 style.css.ori
-rw-r--r-- 1 www-data www-data 50K 16 févr. 09:28 style.css

16ko de gagné sur ce seul fichier. Je vous laisse imaginer le gain sur l’ensemble des fichiers css et js, le facteur de multiplication avec votre audience etc..