Archives pour la catégorie Techniques

HTML 5 expliqué à mémé, part2

Laisser une réponse
Twitt

Mémé, je vais parler technique, écoute moi si ça t’intéresses …

HTML5, concrètement c’est quoi ? Si vous n’avez pas lu la première partie de cette suite d’articles, je vous invite à le faire maintenant Nous l’avons vu, HTML permet l’affichage de contenu multimédia sur une page web. HTML5 lui va beaucoup plus loin. Passons en revu les différentes fonctionnalités qu’apporte cette nouvelle version du langage.

Je rappelle ici que je propose une explication volontairement simple des fonctionnalités HTML 5. Pour plus de précisions ou d’infos, n’hésitez pas à consulter le site du W3C, ou la doc de Mozilla : MDN (par exemple)

Les balises

Cette version du langage apporte aussi sont lot de nouvelle balises. Pour rappelle, les balises HTML servent à donner un sens aux contenus qu’elles contiennent. Le web n’étant pas uniquement lu par des humains, le sens des contenus doit-être indiqué. Ceci afin d’aider les robots(les moteurs de recherche par exemple) qui parcours le web de comprendre les pages. html 5 fournit une panoplie beaucoup plus large de balises permettant de donner d’avantage de sens aux pages web. Voici quelques exemples :

<article>

Une balise article est un conteneur global, c’est une partie de la page qui pourrait être prise individuellement et être utilisé ailleurs, comme par exemple un blog, un agrégateur de contenu, un magazine en ligne … Un contenu encadré d’une balise article ne doit pas être dénué de sens une fois “externalisé” le contenu doit-être autonome. Pour cela à l’intérieur de cette balise article nous devrions retrouver une autre nouvelle balise HTML 5 : header

<header>

Comme son nom l’indique une balise header encadre des informations d’entêtes et ce à plusieurs niveaux sur une même page. Nous pourrions avoir une balise header pour la partie haute de notre page web, mais aussi un balise header à l’intérieur d’une balise article. L’entête de la page contiendrait le logo, une phrase d’accroche, un menu peut-être. L’entête de l’article contiendrait lui, le titre de l’article, sa date de parution, l’auteur…

<footer>

Toujours dans notre balise article nous devrions aussi ajouter une autre nouvelle balise html5 : footer. Cette balise au nom équivoque, permet de spécifier des informations de bas de page. A l’instar de la balise header, footer peut(doit) être utilisé à plusieurs niveau de la page web. En pied de page global, mais aussi à l’intérieur de notre balise article. Le footer de la page web contiendrait les mentions légales, un lien de contact, un copyright… Le footer de l’article contiendrait les sources de l’article, une information de bas de page…

<nav>

Une page web contient beaucoup de liens, de différents “niveaux”. Le menu de navigation du site, pour aller de rubrique en rubrique par exemple devrait être encadré d’une balise nav.

<aside>

Si une balise article contient un contenu autonome (un texte, un diaporama, une vidéo…) aside lui, contiendra les contenus annexes de la page web : listes des derniers commentaires, les articles archivés, l’agenda … aside est en quelque sorte la colonne latérale que nous avons l’habitude de voir sur un site web.

<section>

Section doit-être vu comme un conteneur global. Par exemple si nous avons plusieurs articles dans une même pages, nous devrions les encadrer par une balise section.

JavaScript

Cette nouvelle version du langage, apporte non seulement son lot de nouvelle balise, mais elle apporte aussi une pléthore de nouvelle fonctionnalité. Pour ce faire HTML à besoin d’un autre langage : JavaScript. C’est grâce à ce langage qu’il est possible de “piloter” HTML5. Passons en revu quelques-une de ces nouvelles possiblités

Géolocalisation

Sans doute plus utile pour une version mobile d’une page web, cette fonctionnalité permet de positionner dans l’espace (géolocaliser), un utilisateur. C’est ainsi qu’il est possible d’afficher des contenus en rapport avec le lieu duquel vous être en train de consulter une page web. Trouver une restaurant proche de vous, vérifier si un de vos amis Facebook se trouve près de vous, “marquer” votre emplacement actuel sur carte … Cette fonctionnalité existait déjà sous un environnement “natif” comme un Iphone, mais l’avantage d’une utilisation via HTML 5 est qu’il est possible de l’exploiter d’une manière plus interopérable.

Canvas

Ce nouvel outil, permet de faire quelque chose que vous connaissez très bien mais via un autre outil : Flash. Canvas nous permet, sur une zone dédiée d’une page web, de dessiner, manipuler des images, animer des éléments, … Quel intêret d’utiliser un nouvel outil si Flash le fait depuis de nombreuses années ? Tout simplement Flash n’est pas (plus) disponible sur mobile ! Pour la réalisation de jeux sur mobile, Canvas est parfaitement adapté.

Audio / video

Pour lire des vidéos ou écouter des pistes audio sur un navigateur (de bureau ou mobile), l’outil le plus souvent utilisé pour cela est Flash. Celui-ci propose des interfaces simple et intuitive pour cela (en plus de prendre en charge les formats d’encodage, bien sur). Avec les API’s Audio et Vidéo, Html5 standardise ces outils. Plus besoin de flash, puisqu’il est possible de prendre en charge les sons et les vidéos directement en HTML via les balises <video>, <audio>. A l’instar de Flash, une interface paramétrable permet de gérer le volume, le lancement ou la pause, le temps écoulé depuis le lancement du média …

Il existe bien d’autres nouvelles balises (<figure>, <details>, <command>…), je vous rappelle que pour aller plus loin, n’hésitez pas à vous procurer le livre de Rodolphe Rimelé aux editions Eyrolles : HTML5

Et bien d’autres !

Voilà ma petite mémé, ça c’était pour la partie technique … tu peux te réveiller maintenant.

Pour toi lecteur (Grand-Mère dort encore) : pour la prochaine partie de cette série de billets, nous parlerons de CSS, ou quand se rencontre le graphiste et le développeur.

Accessibilité ? Mais lol quoi !

10 réponses
Twitt

La question est de moi, la réponse est de … je crois qu’il vaut mieux taire son nom ! La question était sincère et la réponse tout autant. En général quand on me demande mon avis sur un nouveau projet web top moumouth qui vient de sortir, ah ! c’est plus fort que moi il faut que je fasse un audit ! Qualité du code (HTML/CSS/JS), petit test de performance et mon petit test préféré : une consultation du site en mode texte. L’idée peut paraître saugrenue ou même carrément … lol ? Et pourtant ça n’a que des avantages.

« En mode texte ?! T’abuses Fab » …

Je ne sais pas mais ce doit être le vocabulaire qui dérange, je pense que si je remplaçais ces termes par « je test le site comme un robot Google » mes interlocuteurs seraient plus attentif. D’ailleurs pour vous inciter à continuer à lire ce billet vous allez entendre parler de stratégie digitale, de référencement naturel, de bonnes pratiques SEO, de partage de contenu mais aussi de performance, de mobile, d’expérience utilisateur… et j’en oublie !

Tout ça juste en partant d’un simple test d’un site en mode texte ? Tu m’intéresses là.

Travailler sur un projet web est belle aventure … tout du moins pendant la phase dite « phase Bisounours« . C’est la partie où se mêlent les grandes idées, les conceptions graphiques hyper créatives, la toute dernière techno web qu’il FAUT utiliser pour prétendre à un petit « award » à mettre en pied de page … Cette phase prend fin quand le client s’en mêle (quelle idée aussi !) et qu’il demande des résultats (en réalité cette phase est beaucoup plus courte, mais allons à l’essentiel).

A un moment, tôt ou tard, vous devez rendre des comptes sur l’efficacité du projet. Rendre compte à votre client parce que vous lui avez vendu un site qui boosterait son chiffre d’affaire, mais aussi rendre des comptes à vous-même et à l’équipe en charge du projet. C’est essentiel. Il y a les engagements contractuels que vous pourriez avoir pris avec votre client.  Et pour peu que vous aimiez votre métier, il n’est pas concevable de pouvoir conserver une dynamique d’entreprise quand vous savez que personne n’a d’intérêt pour votre travail !

Il y a donc forcément un moment dans le processus de réalisation du projet où vous devez vérifier comment les moteurs de recherche vont « voir » le site.

Tester son site en mode texte : le référencement

Les moteurs de recherche, pour référencer les sites, envoient des petits robots pas très très malins il faut le dire. Ils ne savent pas lire le JavaScript, n’interprètent pas les styles CSS et comble de tout, ne font même pas la différence entre un texte en image et un texte « texte ». Finalement, ils lisent un peu une page web comme nous pourrions le faire si nous consultions les sites web en mode texte : pas d’images, pas de JavaScript, pas de CSS (mise en page).

Les préconisations de Google sont d’ailleurs claires :

Pour vérifier le fonctionnement de votre site, utilisez un navigateur texte tel que Lynx. La plupart des robots d’indexation de moteur de recherche visualisent en effet votre site de la même manière que Lynx. Si certaines fonctionnalités (JavaScript, cookies, ID de session, cadres, balises DHTML ou contenus Flash) vous empêchent d’afficher la totalité de votre site dans un navigateur texte, il est possible que les robots rencontrent des difficultés similaires lors de leur exploration.

Pour ma part, je vous conseille de faire comme moi, c’est plus simple : testez le site via Html2Text, un service en ligne fourni par le W3C. Le rendu est sensiblement similaire à une vue sous Lynx et c’est vraiment plus simple !

Petit test :

Capture d'écran ou l'on voit mon site en mode texte

Nous pouvons voir sur la capture ci-contre, la page « qui suis-je » de mon site. On y voit l’essentiel, la page tel que la voit les robots d’indexation des moteurs de recherche !

J’ai ajouté 2 petites annotations pour mettre en avant des liens de la page. Certaines portions de textes étant des liens, on peut voir les liens complets directement dans la page … et c’est ainsi que les robots parcourent l’ensemble du site.

C’est à ce stade que l’on se rend compte de l’importance qu’il y a à renseigner les attributs « alt » et/ou « title » des liens et des images. Essayez de retrouver en mode texte une image sans ces attributs. Peine perdue, elle n’apparaitra même pas dans la page ! Tout cela plus les soucis potentiels de contenus générés en JavaScript, Iframe, Flash et j’en passe, vous rendez-vous compte des informations perdus pour le moteurs de recherche ?!

Concernant mon exemple ci-dessus, mon site étant très light c’est presque agréable à lire en mode texte, testez quelques sites célèbres et je ne peux que vous souhaiter bon courage pour l’analyse ! En effet la « philosophie » du « Mobile first » (le « pensez mobile en premier ») n’étant pas une généralité (loin s’en faut !) les pages web sont bien trop lourdes, indigestes et finalement illisibles dans la majorité des cas.

L’expérience utilisateur et le « Mobile first »

Comme nous l’avons vu précédemment, la plupart des sites sont quasiment indéchiffrables en mode textes. Ce qui soulève un point particulier. Si une page web doit être très dense en informations (formulaires, menus, diaporamas, pubs, carrousels, textes,…), il est indispensable d’avoir un design et une ergonomie parfaitement pensée pour satisfaire la majorité des utilisateurs du site et éviter de les perdre en quelques secondes.

Si la page est illisible en mode textes, soyez persuadé qu’il y a forcément des problèmes d’ergonomie dans son mode « complet ».

Il est vrai que généralement un site web est pensé, imaginé par un groupe de quelques personnes pour potentiellement quelques milliards. En essayant de toucher « la masse » vous ou plus souvent, votre client, aurez toujours tendance à trop en mettre. « Ces 10 blocs doivent absolument être en page d’accueil ». La zone utile, communément admise, de 1024px de large offre beaucoup d’espace. L’expérience utilisateur peut rapidement devenir un vrai cauchemar.

La philosophie du « Mobile First », comme vous l’aurez deviné, consiste à démarrer un projet web en le pensant d’abord pour un écran d’appareil mobile (smartphone, tablette). A mon sens, le meilleur argument que présente ce concept est que nous avons besoin de penser chaque bloc de contenu d’une page, de la façon dont il doit fonctionner et réagir. En effet en partant sur un minimum de 320px de large, chaque pixels compte et nous oblige à des trésors d’inventivités pour offrir une bonne expérience utilisateur. Nous devons penser « simple« , « riche« , « ergonomique« .

Je vous invite à lire le livre de Luke WROBLEWSKI, « Mobile first ». Les études de cas sont très intéressantes et c’est une excellente initiation à cette « philosophie ». Mais au-delà même de cette notion « Mobile first », ce que vous découvrirez dans ce livre c’est tout simplement que vous devez absolument penser aux mobiles dès maintenant, les chiffres présentés sauront vous convaincre !

Pensez « Mobile first » et la consultation de votre site en mode texte n’en sera que plus cohérente. La lecture en mode texte et sur mobile est un peu similaire : linéaire, du haut vers le bas.

Elevons-nous

Je vous ai parlé de deux notions essentielles sur le web, le référencement et l’expérience utilisateur(ou ergonomie avancée). Nous avons vu qu’un simple test d’un site web en mode texte suffit pour mettre le doigt sur un certain nombre de problèmes potentiels, en systématisant ce type de test, vous acquerrez de quoi développer des argumentaires solides pour cadrer vos clients.

En outre, dans la stratégie digitale que vous proposez à vos clients/prospects une part importante de celle-ci s’appuie sur des principes techniques, en effet comment argumenter sur le référencement (naturelle et/ou payant) sans parler de sémantique HTML, des microformats/micro data, de sites adaptatifs, de performance, de cdn, etc… Voilà d’excellentes raisons pour vous inciter à regarder au-delà du rendu visuel de vos projets.

Conclusion

J’avoue, le titre de ce billet est quelque peu … racoleur, trollesque, et je l’avoue mon objectif était de parler … d’accessibilité ! Oui, en suivant ces quelques recommandations, vous rendrez votre projet web plus accessible. Bien évidement il y a encore du travail pour avoir un site conforme aux différents référentiels d’accessibilités mais allons-y doucement et fixons nous des objectifs … accessibles !

J’ai bon espoir que ce billet attirera ceux qui n’y attachent pas d’importance et leur fera voir que d’une certaine façon l’accessibilité n’est qu’une question de bon sens.

Quand à moi, sachez que je ne suis pas expert en accessibilité, et je sais pourquoi : aucune ligne « optimisation accessibilité » dans les devis. Alors quand les lignes « webmarketing » et/ou « référencement » sont tout en haut, j’y vois tout de même une référence à l’accessibilité et de bonnes raisons de mettre en pratique les règles de bases de l’accessibilité.

J’espère pouvoir continuer la discussion dans les commentaires ci-dessous ;)

Responsive design, petit tour d’horizon

5 réponses
Twitt

Le responsive design. Il va peut-être être grand temps de franciser ce terme ! Donc juste pour se rappeler ce dont il s’agit, voici un extrait de ce qu’on peut lire sur wikipédia

« …il[ndlr : le terme responsive design] indique globalement qu’un site est conçu pour s’adapter aux différentes tailles d’écran et aux différents terminaux permettant d’afficher le site (navigateur, tablette, mobile, télé connectée, …). Ainsi, les mobinautes pourront avoir une expérience adaptée à leur terminal sans dégradation et sans devoir utiliser les fonctionnalité de zoom (ou un autre type de redimensionnement)… »
 

Au terme de Responsive Design, s’ajoute souvent : Mobile First. Si dès le départ, l’on doit penser son site web adaptif, il est de bon ton actuellement de commencer non pas par une version « complète » du projet, mais plutôt de sa version mobile. Pensez à la version « mobile » de votre projet en premier, puis pour les écrans disposant d’une résolution élevé, enrichissez votre page avec des éléments non essentiels à la navigation/action.

D’expérience, je dirais : « Oui ! pensez Mobile First« . La principale raison est que si la version mobile du projet n’est pas anticipée dès le départ (analyse, wireframe, maquette), vous offrirez toujours une version mobile à minima. Pourquoi ? Tout simplement parce que vous feriez disparaître des éléments potentiellement problématique à grands coups de CSS ou de JavaScript (délais de livraison oblige !). Par exemple un carrousel récalcitrant ne voulant pas s’adapter aux différentes résolutions, l’intégration d’un service tiers aux dimensions fixes (Facebook, Twitter, module de paiment …)  ou encore un menu sur 3 niveaux complètement déstructuré au moindre changement d’orientation du terminal. Je ne saurais trop vous conseiller, aujourd’hui, de démarrer tout projet sur le modèle suivant :

1) Si nécessaire

« Responsive design », « Mobile First » : oui, mais que si votre client le veut et en a besoin ! En effet inutile de proposer une version mobile du projet si votre client a besoin d’un site Internet proposant des coloriages à imprimer ou s’il propose des jeux en ligne pour PC.

2) Le temps des zonnings

Lors de définition des Wireframes (si, si, je sais que vous en faites systématiquement), ayez toujours côte à côte un schéma sur une base de résolution de 1024px et un autre de 320px. Attention, n’oubliez pas l’orientation du terminal, pensez-y ! Après avoir défini les grandes fonctionnalités, et déjà à ce stade, évoquez avec votre client l’ergonomie du projet sur les 2 types de résolution. Par exemple, ce diaporama doit-il être avant ou après le texte sur la version mobile ?

Le contenu doit aussi être abordé à ce stade : doit-on avoir les mêmes contenus sur une version mobile que sur la version de bureau ? Le sujet est un vaste débat, Jacobs Nielsen nous invite à séparer clairement un même site qu’il soit destiné à être affiché sur mobile ou sur un écran de bureau : « Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work. ». Un article paru sur le site de Smashing magazine contre avec efficacité les arguments de Nielsen. Il est évident que je n’aurais pas de réponse ici car tout dépend du projet. Mais il est vital pour le projet d’amorcer cette réflexion avant de passer aux étapes suivantes. Si vous n’avez pas toutes les réponses, vous aurez au moins pointé du doigt les contraintes (nous voulons le diaporama sur la version mobile, mais fixons à 5 visuels maximum, fixons 4 paragraphes par pages et utilisons une pagination si besoin, etc…)

3) La phase de créa : maquettes

Demandez à votre graphiste de travailler selon vos schémas : 2 maquettes en même temps, ainsi il pourra offrir un maximum de cohérence graphique entre les différentes versions. Et surtout insistez auprès de vos graphiste/webdesigner : le design doit pouvoir bouger, s’étirer, être caché entre le shéma 1 de 320px et le second de 1024px et pour le bonheur de ceux qui dispo d’un écran HD, offrez leur encore un peu plus de friandises graphiques !

3′) La phase créa : intégration

« De l’usage d’une bonne grille CSS ». Cette partie devrait quasiment être intégrée dans celle ci-dessus. Il faut que l’intégrateur travaille en étroite relation avec le webdesigner. En effet, qui dit responsive design, dit structure en unité relative (em, pourcentage). L’intégrateur est le seul qui saura dire « Stop » aux folies créatrices du graphiste/webdesigner. Offrir une mise en page capable de passer de 320px à 1024px (pouvant aller jusqu’a 1920px, écran HD) est techniquement complexe. En effet, il s’agit de prendre en compte la gestion des images, du positionnement des éléments, des menus, de la typo, etc… Une grille CSS est un excellent moyen de liaison entre le webdesigner/graphiste et l’intégrateur. Cela oblige le graphiste à aligner les éléments de la maquette sur une grille prédéfinie, ce qui permettra à l’intégrateur une construction HTML/CSS fidèle à la maquette.

Souvent ces grilles sont accompagnées d’autres déclarations CSS utiles, notamment pour l’uniformisation des formulaires, des titres (hn), ou plus globalement d’un « reset CSS » permettant l’uniformisation de l’interprétation qu’on les navigateurs des balises HTML (marges, paddings, font-size,…)

4) Les tests

La partie sans doute la plus délicate. Il est bien loin le temps ou nous devions vérifier le site sur IE et … comment déjà ? ha oui Netscape :) Aujourd’hui, nous avons Internet Explorer en 4 versions encore utilisées, la 5ème arrive bientôt, Chrome, Firefox, Opéra, Safari et … en gros les mêmes mais pour mobile (donc différent … sic !) et je vous épargne les navigateurs exotiques que vous pouvez trouver dans les PS3, TV, Box etc …

Bref, tester votre site Responsive avec toutes ces contraintes, c’est tout simplement impossible ! Du moins physiquement, heureusement pour nous il existe des émulateurs de la plupart de ces terminaux. Je vous propose ci-dessous quelques outils utiles pour vos tests. Faites bien attention cependant, ces outils ne sont qu’a titre indicatif, débrouillez-vous pour trouver les terminaux sur lesquels vous garantissez un rendu fidèle aux maquettes.

Conclusion

Pour conclure, nous avons parlé ici des bonnes pratiques à mettre en place pour assurer la conception d’un site web adaptatif, « Responsive » mais nous n’avons évoqué que les terminaux les plus communs. A savoir le smartphones et les ordinateurs de bureau/portable. Je vous invite à lire un excellent article de Fred Cavazza qui nous explique avec brio que les acteurs du web de demain seront ceux qui sauront proposer une offre selon un contexte multi-écran.

Tâchons dès aujourd’hui d’être maître dans la discipline du responsive Design !

Note du 02 juillet : Je vois que Google préconise l’utilisation de Responsive plutôt que le site mobile dédié : https://developers.google.com/webmasters/smartphone-sites/details 

Silex, une mini appli avec un bout de caillou

Laisser une réponse
Twitt

Silex framework PHPJ’ai récemment eu besoin de faire un dev pour une mini application permettant de récupérer les abonnés pour une mailing liste. Classique, rien de compliqué puisqu’il s’agissait d’un processus habituel : formulaire -> validation / erreur, gestion des différents retour (inscription validée que fait-on ? Erreur, comment informer l’utilisateur, etc…) . Lire la suite →

Les facettes du web qui ne rassurent pas …

Laisser une réponse
Twitt

Depuis quelques temps déjà, les navigateurs nous proposent un mode de « navigation privée ». On se crois donc assez naturellement à l’abris de flicage indélicat. Et pourtant…

Premier exemple, une initiative de L’Electronic Frontier Foundation (EFF) dont l’objectif essentiel de l’EFF est de défendre la liberté d’expression sur Internet (wikipédia) : Vous avez quasiment 85% de chance d’être reconnu par un site simplement par les infos que votre navigateur fourni, http://panopticlick.eff.org/  (je rappelle que vous êtes en mode navigation privée)

Le second est plus inquiétant, il s’agit de evercookie, une API javascript qui permet de créer un cookie dont il est quasiment impossible de s’en débarrasser. http://samy.pl/evercookie/ je vous invite à jeter un coup d’oeil sur la page de Samy Kamkar, pour une démo qui fait froid dans le dos.

Toujours confiant dans la navigation privée ?

Pour en savoir plus : 

http://www.siteduzero.com/news-62-36549-panopticlick-peut-on-etre-suivi-sur-le-web-sans-cookies.html

http://info2aaz.blogspot.com/2010/09/evercookie-suppression-impossible.html

Et bien sur : www.google.fr

 

 

 

 

 

 

Postfix, ISPConfig et Amavisd … quand les mails partent pas …

Laisser une réponse
Twitt

On va parler ici d’un problème que j’ai rencontré suite à l’installation d’un ISPConfig sous CentOS sur une Dédibox V3 : les mails ne partaient pas. Plutôt génant quand on sait que ce serveur allait me servir à rapatrier plusieurs sites existants (et fonctionnant ! ). Imaginez : formulaire de contact qui ne marche pas, commande dont on avait aucune trace mail … :s

Donc tout semblait ok sous Postfix, après quelques tests. ISPConfig semblait bien configuré et pourtant dans les logs (/var/log/mailog.log), j’avais en permanence :

Nov 23 20:51:08 localhost postfix/smtp[21243]: E2E474AA937: to=<xxx@gmail.com>, relay=none, delay=363264, delays=363264/0.14/0.01/0, dsn=4.4.1, status=deferred (connect to 127.0.0.1[127.0.0.1]: Connection refused)
Nov 23 20:51:08 localhost postfix/smtp[21242]: connect to 127.0.0.1[127.0.0.1]: Connection refused (port 10024)

Comme dirait un bon ami … « grrrrr » …

Au final le soucis : Amavisd (Sécurité du service de courrier électronique : amavisd-new). En effet celui-ci était tout simplement mal configuré. Car ISPConfig est sensé gérer le fichier de conf  puisqu’à la préparation du serveur pour l’install de celui-ci, il nous demande de modifier le fichier de conf d’amavisd (vi /etc/sysconfig/amavisd) pour y définir le fichier de conf d’amavisd (CONFIG_FILE= »/etc/amavisd/amavisd.conf ») mais ce fichier … n’existe pas à la base et ISPConfig ne la surement pas généré (je suppose).

Donc évidement impossible de lancer amavisd (/etc/init.d/amavisd start). Et c’est bien lui qui empêchait les mails de partir (bien que tous soient en queue ! attention au debug qui risque de vous faire crouler sous les mails de tests !). Pour corriger le soucis, j’ai simplement demander à amavisd de conserver son fichier de conf d’origine (/etc/sysconfig/amavisd :CONFIG_FILE= »/etc/amavisd.conf »).


Un yum update sur CentOs chez dédibox sur une v3 … et c’est la cata !

Laisser une réponse
Twitt

Après une mise à jour d’un serveur tournant sous CentOs sur une v3 suivi d’un reboot, j’ai eu la surprise de voir … rien. Le serveur n’a pas rebooté, aucune réponse au ping, rien, nada !

Donc passage au mode rescue :

  1. direction le panel d’admin de chez dedibox : https://console.online.net/ pour passer en mode rescue
  2. on lance une console et on monte les partitions :
    # sudo su
    # mkdir server
    # mount /dev/sda2 server
    # mount /dev/sda1 server/boot
    # mount –bind /proc server/proc
    # mount –bind /sys server/sys
    # mount –bind /dev server/dev
  3. puis on lance chroot pour gérer le serveur comme si on y étions :
    # chroot server
  4. de là, on va pouvoir lancer les commandes style yum update, yum upgrade, …

Bon tout cela c’est bien joli mais … ça ne marche toujours pas !  J’ai pensé à ISPConfig, au firewall, … mais rien, après 2 heures, j’ai quand-même déniché l’info :

Le Kernel de CentOs n’est pas fonctionnel sur une dedibox V3 ! Chez Dédibox ils ont leur propre version … les bougres … et pourquoi donc ?

« …la carte réseau Intel intégrée est relativement récente … Le kernel est donc plus ou moins custom tant que CentOS ne proposera pas par défaut quelque chose de décemment récent. »

Et donc pour corriger ça, on retourne en mode  rescue comme expliqué précédemment et on édite le fichier /boot/grub/menu.lst pour définir le Kernel par défaut : 2.6.34dedibox-r9-smp-x32

Soit :

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda2
#          initrd /initrd-version.img
#boot=/dev/sda2
default=2
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-194.26.1.el5) # SOIT 0
root (hd0,0)
kernel /vmlinuz-2.6.18-194.26.1.el5 root=/dev/sda2 md=
initrd /initrd-2.6.18-194.26.1.el5.img
title CentOS (2.6.18-194.17.4.el5) # SOIT 1
root (hd0,0)
kernel /vmlinuz-2.6.18-194.17.4.el5 root=/dev/sda2 md=
initrd /initrd-2.6.18-194.17.4.el5.img
title CentOS (2.6.34dedibox-r9-smp-x32) # SOIT 2
root (hd0,0)
kernel /vmlinuz-2.6.34dedibox-r9-smp-x32 root=/dev/sda2 md=
initrd /initrd-2.6.34dedibox-r9-smp-x32.img

Git, trucs et astuces

Laisser une réponse
Twitt

Recette du succès pour la gestion de vos projets sous GIT.

J’ai pas mal galéré, j’ai beaucoup fouiné, énormément lu pour utiliser GIT dans le cadre de la gestion de projets web(en agence ou à titre perso) et mes connaissances en administration système, étant relativement basique, m’ont franchement penalisé.

Ayant enfin l’impression d’avancer sur la partie « workflow » je vais décrire ci-dessous la méthodo et surtout expliquer la partie technique de mise en place de ce workflow.

Pour commencer l’environnement : Une debian sur un dedibox v3 avec Ispconfig en panel d’admin (très pratique pour la gestion des « sites », compte utilisateur FTP/SSH et base de données). Bon je passe sur les bases (PHP d’installé, MySQL, …)  et passons de suite sur un petit sommaire.

  • Création du dépot centrale
  • Création du projet en local
  • Configuration du système

Création d’un dépot central vide

Il faut au préalable crée un projet vide sur l’espace en ligne ou sont stocker tous les git –bare

git init --bare
git config user.name depo
git configure user.email depo@depo.com

On fait ensuite un clone en local

git clone ssh://user_git@git.depot.fr/~/projects/mon projet.git
git config user.name Fabien
git config user.email mail@gmail.com

On démarre notre projet ou l’on copie colle les fichiers existant d’un projet puis on push sur le depo central

git.exe push --progress  "origin" master:master

Voilou pour le partage d’un projet, il suffit de faire de même chez les collègues pour qu’ils puissent bosser sur le projet

Configuration du système

Ce qu’il faut maintenant c’est avoir une version en ligne de dev qui permet de partager le dev de tout le monde. Pour cela on va créer sur un espace de dev dédié et cloner notre projet comme on le fait en local (a noter que l’on reste sur la même machine dans cet exemple)

git clone  ... (path) (Attention : penser à redéfinir ensuite l'url du remote du fichier .git/config et le faisant pointer en direct. Ex : url = /var/www/site/projet.git)

Une fois cela fait il faudrait dans un monde parfait que cette version du projet en ligne se mette toute seule à jour au fur et à mesure des commits.

On va pouvoir faire cela grâce aux hooks de git. Il existe des fichiers de samples dans le repertoire hook de /.git. On va copier le post-receive.sample et le modifier

cp .git/hook/post-receive.sample .git/hook/post-receive && vim .git/hook/post-receive

Dans ce fichier on va appeler un script bash qui va s’occuper de faire un git pull pour le/les projets sous git de notre serveur

#!/bin/sh
sudo -u userdev /usr/local/bin/pullhere /var/www/html/dev/

Il faut à présent rendre le fichier executable :

chmod a+x hooks/post-receive

Le fichier pullhere est composé de ceci :

#!/bin/sh cd "$1" git pull

Il faut lui aussi le rendre executable :

chmod a+x hooks/post-receive

Bon là on va avoir un gros problème … un très gros problème … un problème de droits. Alors pour se faire il faut passer par sudo et expliquer à ce monsieur qu’il n’a pas besoin de mot de passe pour se faire passer pour l’utilisateur a qui appartient l’espace de dev. Pour ça il faut editer la conf de sudo via « visudo » et ajouter la ligne suivante :

usergit ALL = (userdev) NOPASSWD: /usr/local/bin/pullhere

Voilà pour l’essentiel. Je reviendrais affiner ce billet pour détailler un peu plus les manips et surtout mettre en avant les problèmes liés à ce workflow.

Petite note pour ceux qui galère :

Pour ceux qui utilise tortoisegit il faut bien respecter une certaine « procédure » sinon on risque de se casser un peu les dents sur des erreurs à répétition. Il faut par exemple laisser tortoise créer le répertoire sur votre poste en local. Sinon il n’arrive pas à cloner si le nom du repertoire git distant est le même que le rep en local que vous avez créé. Du coté server aussi, pensez à bien indiquer le chemin du dépot (source de galère sans nom).

 Astuces :

Il m’est arrivé de récupérer un dépôt git no-bare (c’est à dire sans fichier directement exploitable). Evidement, simplement le stocker sur un serveur distant n’a pas suffit pour faire un clone (erreur d’INDEX-PACK). J’ai simplement rapatrié le dépôt sur mon disque dur, puis j’ai cloné en local. Plus qu’à, reboutiquer et renvoyer sur un dépôt en ligne.

Supprimer un fichier dans le suivi. Il arrive que l’on souhaite ne plus suivre un fichier que l’on aurait ajouté par inadvertance (git add .). Voici l’astuce :
Commencez par un git rm –cached nomdufichier (« –cached » pour conserver le fichier physique) puis faite la mise à jour du dépôt via un commit. Pensez à ajouter ensuite le fichier dans le .gitignore pour éviter qu’il se retrouve à nouveau dans le suivi.

A voir aussi

Les docs « officiels »

Les articles et autres tutos bien fait

Wiki, Cheat sheet, les commandes de base

  • http://www.devdaily.com/git/git-cheat-sheet-git-reference-commands