KrISS feed 8.7 - Ein einfacher und schlauer (oder dummer) Feed-Reader. Von Tontof
  • Monday 14 June 2010 - 09:44
  • Wednesday 05 March 2014 - 14:34
    Je suis surpris de ne pas avoir vu ça plus tôt, tiens.
    Un bête <noscript> avec une balise ouvrante <a> et pas de balise fermante. Résultat : toute la page devient un lien vers la pub...

    Je viens de voir ça sur Les Echos (version mobile) : http://m.lesechos.fr/industrie-services/le-gouvernement-annonce-25-mesures-pour-encourager-l-usage-du-velo-0203350767071.htm

    Note : c'est un cas restreint, qui concerne le site mobile des Echos, et uniquement si on bloque TOUT le Javascript (dont celui du site) et que je n'ai constaté que sur Firefox. Mais dans le principe, je trouve ça tout de même un peu dérangeant...
    (Permalink)
  • Wednesday 25 June 2014 - 19:21
    Ayé, j'ai craqué, je me suis commandé le même microscope 800x.
    Et je l'ai trouvé à 27€ environs.

    Je joue comme un ptit fou avec. Merci pour l'idée, Bronco ^^
    (Permalink)
  • Sunday 15 February 2015 - 19:41
    Une nouvelle souche très virulente du HIV présente à Cuba. C'est assez inquiétant et cela doit nous rappeler qu'une détection précoce est primordiale pour une bonne prise en charge. Cette souche répond apparemment bien aux traitements, mais elle se développe plus vite que les autres, ce qui fait qu'il est souvent trop tard.  

    Alors sortez couverts et en cas d'accident ou de doutes, n'attendez pas pour vous faire dépister.

    via | http://sebsauvage.net/links/?wt_R9w
    (Permalink)
  • Sunday 15 February 2015 - 20:27
    Un petit tuto en images pour apprendre à travailler son Swing. Tout le swing est décortiqué et c'est assez bien fichu, même si ça n'a pas l'air tout récent.
    (Permalink)
  • Saturday 21 February 2015 - 17:22

    Et hop pour faire plaisir à un copain ! Je vous informe de la sorti du jeux vidéo Bomb sur pc et linux.

    un petit simulateur de vol dans le style graphique de Team Fortress.

    The post Le jeu vidéo « Bomb » appeared first on Le blog de Luc.

  • Sunday 22 February 2015 - 16:29

    Cela fait maintenant quelques mois que je n'ai pas édité de nouveau billet sur ce site, je vais donc couper cette période creuse en vous proposant un petit tutoriel sur la mise en place de php5-fpm avec apache2 et tout ça configurable au besoin dans des virtualhost .

    Nous avons déjà vu comment faire avec Nginx ( qui est franchement plus clair qu'apache ) mais parfois on a pas le choix du serveur web sur lequel on travail .. alors voyons comment faire ça proprement avec apache2.

    Etat des lieux

    Le tutoriel se base sur la version stable de Débian du moment, Debian 7 "Wheezy" .
    Nous allons également activer les dépôts contrib et non-free pour installer ce qui va suivre .

    Pour cela commencez par éditer le fichier /etc/apt/sources.list

    sudo vim /etc/apt/sources.list
    

    Et ajoutez à la fin de chaque ligne contrib non-free
    Ce qui donne quelque chose comme çà

    deb http://cloudfront.debian.net/debian wheezy main contrib non-free
    deb-src http://cloudfront.debian.net/debian wheezy main contrib non-free
    deb http://security.debian.org/ wheezy/updates main contrib non-free
    deb-src http://security.debian.org/ wheezy/updates main contrib non-free
    deb http://cloudfront.debian.net/debian wheezy-updates main contrib non-free
    deb-src http://cloudfront.debian.net/debian wheezy-updates main contrib non-free
    

    PS: ne faite pas attention à l'url de mes dépôts ci-dessus "cloudfront.debian.net" , j'utilise une instance (VM) Amazon pour réaliser mes tests .

    Installation des paquets nécessaires

    Nous allons installer les paquets suivants :

    sudo apt-get install php5-fpm libapache2-mod-fastcgi php5-cgi
    

    Puis il nous faut activer le module fastcgi et actions via la commande a2enmod

    sudo a2enmod actions fastcgi
    

    Configuration du module fastcgi

    Il nous faut lier le module fastcgi aux processus php5-fpm, pour celà nous allons éditer le fichier de configuration du module fastcgi

    vim /etc/apache2/mods-available/fastcgi.conf
    

    Pour arriver à ce résultat

    <IfModule mod_fastcgi.c>
     AddType application/x-httpd-fastphp5 .php
     Action application/x-httpd-fastphp5 /php5-fcgi
     Alias /php5-fcgi /usr/bin/php5-fcgi
     FastCgiExternalServer /usr/bin/php5-fcgi -socket /var/run/php5-fpm.sock -pass-header Authorization
    </IfModule>
    

    NB : il vous faut vérifier le chemin du socket php5-fpm dans votre cas, normalement, /var/run/php5-fpm.sock et la valeur par défaut pour l’environnement Débian 7, pour vérifier exécuter cette commande

    cat /etc/php5/fpm/pool.d/www.conf | grep "listen = "
    

    Le test

    Il ne vous reste plus qu'à tester cette nouvelle configuration, commençons par tester l'ensemble des paramètres d'apache via la commande très pratique

    sudo apache2ctl configtest
    

    Puis il ne reste plus qu'à relancer Apache si tout est ok

    sudo service apache2 restart
    

    Enfin, nous allons mettre un simple fichier php dans le DocumentRoot par défaut d'apache2

    sudo echo "<?php echo phpinfo();" > /var/www/lindev.php && chown www-data:www-data /var/www/lindev.php
    

    Il ne vous reste plus qu'à entrer l'url http://localhost/lindev.php pour voir le résultat .

    Conf spécifique par virtualhost

    Jusque là, les scripts php sont exécutés par l'utilisateur système www-data dans la plupart des cas, cela va être adéquat, mais si pour une raison quelconque vous devez utiliser un autre utilisateur pour exécuter un script/site en particulier, dans le virtualhost correspondant, il vous faudra surcharger la configuration du module fastcgi, ce qui donnera par exemple

    <VirtualHost *:80>
        ServerAdmin webmaster@lindev.fr
        ServerName lindev.fr
        ServerAlias www.lindev.fr
        DocumentRoot /var/www/lindev/
        ErrorLog /var/www/lindev/error.log
        CustomLog /var/www/lindev/access.log combined
    
        <IfModule mod_fastcgi.c>
            AddType application/x-httpd-fastphp5 .php
            Action application/x-httpd-fastphp5 /php5-fcgi
            Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi_lindev
            FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi_lindev -socket /var/run/php5-fpm_lindev.sock -pass-header Authorization
        </IfModule>
    
    </VirtualHost>
    

    Ici , j'ai donc donné un autre socket à utiliser, que j'ai nommé php5-fpm_lindev.sock. Ce socket devra bien évidement être configuré coté php-fpm, en créant un nouveau pool ( dans un prochain article certainement ), en attendant, pour tester copiez juste la conf du pool par défaut, et changer le paramètre listen pour spécifier le socket à créer pour ce pool.
    C'est également dans ce fichier de pool que vous pourrez spécifier l'utilisateur système à utiliser pour interpréter les fichiers php.

    cp /etc/php5/fpm/pool.d/www.conf /etc/php5/fpm/pool.d/lindev.conf
    

    Changer les paramètres listen, user et group , puis relancer php-fpm

    sudo service php5-fpm reload
    

    L'article touche maintenant à sa fin, vous savez maintenant installer apache, php5-fpm et configurer un pool spécifique de php pour un virtualhost.

    Ch.

  • Wednesday 25 February 2015 - 14:48
  • Friday 27 February 2015 - 07:31
    Robin Lemesle et moi-même sommes fiers de vous annoncer la disponibilité de notre dernier livre : Windows PowerShell...
  • Friday 27 February 2015 - 20:51
  • Sunday 01 March 2015 - 18:42
    Octopi 0.6.0 est dans les bacs et fête sa 25 ème release. Pour rappel, il s'agit de mon gestionnaire de paquets préféré sous Manjaro, en dehors du terminal :)
    (Permalink)
  • Sunday 01 March 2015 - 22:32
    Mon ami MVP Fabien Dibot (https://twitter.com/fdibot), alias Benduru dans le forum , annonce la création prochaine d'un groupe d'utilisateurs PowerShell...
  • Monday 02 March 2015 - 18:57
    Elle a l'air de roxer du poney cette nouvelle version (4.12) d'Xfce. D'un autre côté vu le temps qu'elle a mis à arriver, le contraire aurait été étonnant. Je pense que je vais la tester à l'occasion.
    (Permalink)
  • Monday 02 March 2015 - 19:38
    Encore une petite news sur Xfce 4.12, pour ce qui comme moi ne calent rien à l'anglais. :D
    (Permalink)
  • Tuesday 03 March 2015 - 18:12
    Fut un temps j'étais un peu dans le même cas. Avec un portable c'est moins facile :)
    (Permalink)
  • Tuesday 03 March 2015 - 18:24
    Encore un soft (GTK) sympa à tester, qui permet apparemment de piloter un appareil photo depuis son PC. Je garde ça sous le coude pour quand j'aurai le temps!
    (Permalink)
  • Wednesday 11 March 2015 - 18:12
    Pour vous la faire courte il s'agit d'un soft dont le but est de lister les paquets présents sur votre distribution, et de les afficher sous forme d'arbre. Ça a l'air super sympa.
    (Permalink)
  • Wednesday 11 March 2015 - 19:24
    Pour info j'ai baptisé "Mjolnir" le maillet avec lequel j'enfonce mes piquets au boulot (surtout pour ne pas qu'un collègue me le pique et dise que ce n'est pas le mien). Après avoir lu ça il est évident que je veux le vrai Mjolnir et c'est tout. Sinon je démissionne !!!

    via | http://lehollandaisvolant.net/
    (Permalink)
  • Thursday 12 March 2015 - 22:03
    Il ne fonctionnait plus correctement chez moi depuis la maj de Firefox. Avec cette version ça devrait aller mieux ;)
    (Permalink)
  • Sunday 15 March 2015 - 01:00
    IndieWeb (french) https://t.co/aCxvtxh8W9 — Pierre (@pierreozoux) 30 Janvier 2015 Aujourd'hui, on ne peut pas parler de blogging sans parler d'IndieWeb ! C'est la révolution à mon sens et au sens de beaucoup de personnes. J'en ai des frissons rien que d'y penser. indieweb (french) (Pierre Ozoux, 2015-01-31) Salut Pierre. Touché par ton pitch indieweb en français et plus largement par tous les efforts produits par IndieHosters pour soutenir la stratégie francophone indieweb 2015.
  • Thursday 19 November 2015 - 17:58

    AY82

    Même si nous avons tous nos petites habitudes en termes d’applications, c’est toujours intéressant d’en tester d’autres de temps en temps. Si vous utilisez souvent le terminal sous GNU/Linux, AltYO est un émulateur de terminal assez sympa que vous devriez peut-être essayer. Ce terminal un peu particulier a été écrit en Vala et repose entièrement sur libvte et GTK3. Il dispose d’une interface en ruban que les utilisateurs de Guake ou de yakuake connaissent bien et regorge d’un nombre de fonctions assez impressionnant.

    Vous pourrez entre autres invoquer le terminal à l’aide du raccourci clavier de votre choix, ouvrir un nombre d’onglets illimité, paramétrer un très grand nombre de raccourcis clavier, temporiser la fermeture du terminal et être notifié si des programmes sont en cours d’exécution (même en arrière plan) lors de la fermeture des onglets ou du terminal.

    Vous pourrez également travailler en multisession, customiser les titres dans l’entête du terminal, utiliser les couleurs de votre choix pour l’interface, programmer l’ouverture d’AltYO au démarrage de votre PC et paramétrer le terminal pour exécuter diverses applications lors de son lacement.

    Vous bénéficierez enfin de liens cliquables pour ouvrir les URL directement dans votre navigateur, de la possibilité d’être averti dans le cas où vous entreriez une mauvaise commande et de tout un tas d’autres trucs vraiment intéressants.

    Comme le montrent les trois captures d’écran ci-dessous, les options de paramétrage sont très nombreuses et celles-ci vont vous permettre de modifier à peu près tout. Même le CSS (GTK3 inside:)).

    AYsettings_003

    AYsettings_004

    AYsettings_005

    Dernière précision utile, si les fonctions vous plaisent mais que l’interface en ruban vous dérange, AltYo dispose d’une deuxième icône vous permettant de le lancer avec une interface classique.

    AY_1

    Bref je le dis de bon cœur, ça roxe du poney! Si vous voulez en savoir un peu plus sur AltYO vous pouvez visiter la page Github du projet, où sont évoquées l’ensemble des fonctions et des raccourcis claviers utilisés par défaut.

    Si vous tournez sur Ubuntu vous pouvez installer AltYO à l’aide du PPA suivant et de ces quelques lignes de commande :

    sudo add-apt-repository ppa:linvinus/altyo
    sudo apt-get update && sudo apt-get install altyo

    Pour supprimer AltYO entrez ceci dans votre terminal :

    sudo add-apt-repository -r ppa:linvinus/altyo
    sudo apt-get update && sudo apt-get remove altyo

    Si vous tournez sur Archlinux ou Manjaro c’est via AUR que ça se passe.

    Amusez-vous bien…

  • Wednesday 02 December 2015 - 18:17

    Aujourd’hui, j’ai fait un brew install (je sais, je suis un dingue) qui a mis à jour la bibliothèque icu, utilisée par l’extension int de PHP.

    Du coup, PHP est devenu inutilisable sur mon poste de travail puisque j’obtenais systématiquement la sympathique erreur suivante :

    # php -v
    dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.55.dylib
    Referenced from: /usr/local/bin/php
    Reason: image not found
    Trace/BPT trap : 5
    

    L’erreur peut semble quelque peu incompréhensible au premier abord, mais l’expérience m’a appris qu’elle veut tout simplement dire que l’exécutable PHP n’est pas capable de localiser la bibliothèque libicui18n.55.dylib à l’emplacement indiqué lors de sa compilation, ce qui est logique vu que brew a supprimé le fichier concerné au profit de libicui18n.56.dylib (et oui, les bibliothèques qui contiennent leur numéro de version dans leur nom sont une plaie).

    Et la solution est très simple, puisqu’il suffit de compiler une nouvelle fois PHP depuis ses sources en indiquant le nouveau chemin d’accès à la bibliothèque concernée lors de l’appel à ./configure.

    En effet, pour ceux qui ne le sauraient pas, une compilation classique de PHP sous UNIX se fait en trois étapes :

    1. Un appel à ./configure avec diverses options permettant de définir les chemins d’accès aux fichiers ou répertoires nécessaires à la compilation, l’installation et l’exécution de PHP ainsi que les extensions qui doivent être intégrées dans les binaires créés (au passage, ./configure --help est l’ami de ceux qui se lancent dans l'exercice pour la première fois) et qui génère le fichier Makefile correspondant ;
    2. Un appel à make qui utilise le fichier Makefile précédemment généré qui génère les différends binaires ;
    3. Un appel à make install qui provoque l’installation des binaires créés à l’étape précédente ainsi que celle de la documentation et des différents utilitaires associés à PHP (comme phpize qui permet de configurer les extensions PHP pour la version de PHP qui vient d’être installée).

    Sauf que je fais une configuration très spécifique de PHP lorsque je le compile et mon appel à `./configure` est donc relativement complexe.

    Lorsque je dois compiler PHP, j’utilise donc systématiquement la commande php -i | grep configure pour récupérer la commande configure qui a été utilisée pour compiler la version de PHP actuellement installée sur mon poste.

    Mais aujourd’hui, cette version était inutilisable et que PHP n’était donc plus en mesure de me fournir la commande configure que j’avais utilisé pour le compiler.

    Mais heureusement pour moi, configure génère dans le répertoire contenant les sources à compiler un journal nommé ./config.log qui contient entre autres le détail du dernier appel à configure.

    J’ai donc pu compiler PHP sans devoir reconstruire de zéro la commande suivante :

    ./configure --disable-all --sysconfdir=/private/etc --enable-xml --enable-cli --with-config-file-path=/etc --enable-type --with-libxml-dir=/usr --with-pare-regex --enable-pear --enable-hash --enable-json --enable-libxml --enable-session --enable-dom --enable-sockets --enable-tokenizer --enable-simpleml --enable-soap --enable-posix --enable-pcntl --with-libedit --enable-filter --with-sqlite3 --enable-mbstring --with-mysqli=mysqlnd --with-curl --with-openssl --with-ldap --enable-xmlwriter --enable-pod --with-pod-mysql --enable-into --with-apxs2 --with-icu-dir=/usr/local/Cellar/icu4c/56.1 --with-glib --with-crypt --enablte-opcache --enable-phpdbg
    
  • Thursday 10 December 2015 - 01:02

    So why would you monitor a drupal site?

    From a System Engineers point of view, Drupal itself is nothing else than a set of software that requires updates on a regular base. So what do you do? You treat it that way and update it whenever updates are needed and patch it as soon as security updates are available. The more tricky part is to always get notified immediately when security updates are required so you can patch all of your sites before shit hits the fan.

    Drupal itself offers a way to notify a site admin about regular updates and/or security updates by sending an email to a specified account. If you are only responsible for a couple of Drupal sites, this will be sufficient. However, if you have to keep track about lots of other stuff and might have chosen Nagios as a central platform for monitoring different servers and services it would be useful to go the same way with Drupal and keep everything in the same location.

    What about the drupal nagios module?

    I know there is a drupal nagios module out there, but this has to be added to drupal itself and activated in the module section. Unfortunately I do not have access to all site’s code and for a few sites I have no permission to add modules to it, so there had to be a different solution.

    DIY if you have to

    I was facing the above stated problems. In my company I use nagios/icinga to keep track of many servers with various services and states. The only remaining relict were numerous Drupal sites that were sending emails from time to time complaining about security updates. This way I had to keep an eye on two different systems. As I am a big fan of consolidation and could not find a suitable plugin for Drupal sites, I had to write my own.

    The thoughts

    As I have already written a few nagios plugins I was quite confident and set my goals high. I wanted the normal update notification as well as the security update only notification. With these two checks I would be on the same height as the Drupal functionality itself, so I was looking deeper into what else can go wrong on a drupal site:
    * Pending database updates
    * Incorrect file permissions on directories
    * Problems with cron
    * Basically everything the drupal status report can complain about

    The next thought was about the technology to use. Am I going to write in PHP and make use of drupal hooks to get all the required information? This idea was quickly refused as I currently have drupal 6 and 7 systems and in the future also drupal 8 ones. So it had to be something that is compatible between all versions.

    The idea came to me when I was checking a page against errors using drush. Drush is an already matured toolset for drupal, so why not just write a wrapper that gives me all desired information in a nagios plugin style output.

    The check_drupal plugin – first draft

    The goals were set, the technology was decided, I was ready to go and this is what I came up with in pure posix compliant bourne shell (not bash):

    check_drupal -d <drupal root> [-n <name>] [-s <w|e>] [-u <w|e>] [-e <w|e>] [-w <w|e>] [-m <w|e>] 
    

    The checks are as follows:
    * -s: security updates
    * -u: normal updates
    * -e: all core errors (what the status report shows as errors)
    * -w: all core warnings (what the status report shows as warnings)
    * -m: missing/pending database updates

    As well as the ability to specify the nagios severity (w warning and e error) for every single check.

    Problems with the first draft

    I was testing it back and forth and everything went smooth. After a few more days of testing and performance optimization in the wrapper script I noticed that the check itself can take up to three seconds to execute on some drupal instances (depending on the server and the database size of drupal).

    The check_drupal plugin – final version

    Nagios itself checks every 5 minutes. 3 seconds for a check that is run every 5 minutes is pretty long, so I had to reconsider in order to not waste too much time on those servers. The other idea was that I do not need to check for problems every five minutes. So, this is what I came up with:

    check_drupal -d <drupal root> [-n <name>] [-s <w|e>] [-u <w|e>] [-e <w|e>] [-w <w|e>] [-m <w|e>] [-l <logfile>]
    check_drupal_log -f <logfile>
    

    There is an additional parameter -l that will log all check results (including nagios exit codes) into a logfile. With this additional option, the check_drupal script can run on the drupal machine via cron and update the logfile every 6 or 12 or XX hours. The second plugin check_drupal_log will actually be triggered by nagios and parse the logfile which only takes milliseconds.

    The choice

    As you notice the -l option is optionally and you can use it either way. Either you just use check_drupal or you can use the combination of both to save some cpu cycles.

    The end

    This is my first contribution to drupal, even though it is not directly related to any drupal modules it is a nice addition. I hope you enjoy it and if you find a bug report it and I am happy to fix it.

    Find the source with install instructions on github:

    cytopia/check_drupal cytopia

    Latest Stable Version

    Update

    Officially added to:
    * Icinga Exchange
    * Nagios Exchange

    _

    The post check_drupal: Monitoring drupal with nagios appeared first on Everything CLI.

  • Sunday 13 December 2015 - 01:00
    Mise à jour à partir d’une ancienne version de Jekyll ? Quelques petites choses ont changé dans la version 3.0. Avant de nous lancer, ouvrez votre fenêtre de terminal et récupérez la dernière version de Jekyll : $ gem update jekyll html <div class="note feature"> <h5 markdown="1">Plongeon</h5> <p markdown="1">Vous voulez un nouveau site Jekyll et démarrer rapidement ? Lancez simplement <code>jekyll new NOMSITE</code> pour créer un nouveau répertoire avec un site Jekyll pré-installé.
  • Wednesday 16 December 2015 - 02:00
    Généralement, on utilise un texte en faux latin (le texte ne veut rien dire, il a été modifié), le Lorem ipsum ou Lipsum, qui permet donc de faire office de texte d’attente. L’avantage de le mettre en latin est que l’opérateur sait au premier coup d’oeil que la page contenant ces lignes n’est pas valide, et surtout l’attention du client n’est pas dérangée par le contenu, il demeure concentré seulement sur l’aspect graphique.
  • Tuesday 22 December 2015 - 12:00

    Jaco Watermark permet d'insérer un copyright en filigrane sur les images pour en revendiquer le droit d'auteur. Et dissuader toute utilisation malveillante.

    Vous avez profité de votre profil de mannequin pour exhiber votre belle plastique sur votre blog ? Vous avez créé un site où vous exposez les produits de votre e-boutique sur des mannequins ? Ou un site où vous publiez des photos de mode, voire de tourisme ou autre ? Ou encore un blog de tutoriels avec des captures d'écran illustrant vos démonstrations ? Quoi qu'il en soit, si vous les avez mises en ligne, c'est qu'elles ont une valeur intrinsèque quelconque – économique, esthétique, probatoire... Alors pensez à les protéger par un copyright en filigrane. 

     

    Une telle précaution répond à un double objectif :

    • un copyright incluant le nom de domaine de votre site sur chaque photo dissuade quiconque de vouloir se l'approprier pour l'utiliser sur son site ou à d'autres fins ;
    • un copyright incluant le nom de domaine de votre site sur chaque photo aiderait à faire connaître votre site si vos photos se retrouvaient sur la toile.

    Plusieurs utilitaires permettent de protéger ses photos. Jaco Watermark compte parmi les plus simples à utiliser.

     

    Gratuit, open source, compatible PC et Mac, Jaco Watermark est probablement celui qui vous posera le moins de problèmes. Et pour cause, son interface est épurée, ce qui rend son utilisation intuitif. Quelques clics suffisent pour parvenir à vos fins.

     

    Editeur : http://jaco-watermark.sourceforge.net

    License : Open source

    OS : Window, Linux, Mac.

     

    [Tuto] Mode d'emploi de Jaco Watermark

     

    Après avoir téléchargé le fichier JacoWatermark et l'avoir extrait, ouvrez le dossier jaco-watermark, puis double-cliquez sur le fichier jaco-watermark.bat :

     

     

    Le logiciel se lance. Vous pouvez alors protéger votre image en suivant les 6 étapes suivantes :

     

    1) Chargez l'image à protéger en cliquant sur Open ;

     

    2) Choisissez le style du texte parmi les diverses polices de caractères proposées ;

     

    3) Mettez le copyright suivi de l'URL de votre site. Pour faire le C de copyright, utilisez le code clavier Alt+0169 (pressez la touche Alt, puis, sans relâcher la pression, composez les chiffres 0169), ce qui donne :  © ;

     

    4) Sélectionnez la position, parmi les 9 possibilités, où vous voulez que le copyright apparaisse sur l'image ;

     

    5) Choisissez le format de l'image : PNG ou JPEG (il est conseillé de choisir JPEG pour accélérer l'affichage des images) ;

     

    6) Sauvegardez l'image éditée en cliquant sur Save :

     

     

     

    Résultat : votre image arbore désormais un filigrane à l'endroit où vous l'avez inséré :

     

     

    (Photo reproduite avec l'autorisation expresse de la mannequin)

     

    Vous pouvez aussi utiliser les filtres de la zone Effects pour personnaliser votre filigrane. Ainsi :

    • Font size permet de modifier la taille des caractères
    • Font Color permet de modifier la couleur des caractères
    • Font Style permet de modifier la police en gras (bold) ou italique (italic)
    • Anti-aliasing permet de réduire le crénelage (aliasing)
    • Drop Shadow permet d'obtenir l'effet d'ombre portée

     

     

     

  • Wednesday 30 December 2015 - 15:04

    Prestashop et ses bizarreries

    presta.png Je travaille quotidiennement sur Prestashop, car à mon grand regret, il n’existe pas aujourd'hui, beaucoup d'alternatives qui proposent un produit :

    • libre
    • fonctionnel et évolutif
    • supporté par une communauté active
    • avec une documentation complète ( pour l'utilisateur et le développeur )
    • développé en python sous Django par exemple .... humm ce dernier point sent le troll ;)

    Bref dans ma grande frustration personnel, je dois tout de même admettre que Pretashop offre une solution complète performante et fonctionnelle pour l'utilisateur final, mais dés qu'il s'agit de mettre les mains dans le code, la documentation et plus que maigre !! Et il faut investiguer, poser des questions qui bien souvent dés que ces dernières sont un peu techniques, restent sans réponse sur le forum officiel :( !!
    Nous ( développeurs ) sommes doc seuls devant le code et devons faire preuve de patience pour apprivoiser le code sans documentation approfondie. Ce manque d'information est selon moi voulu pour pousser le système économique qui tourne autour de Prestashop ( modules payants pour ajouter des fonctionnalités qui parfois devraient être disponibles par défaut dans la solution ).

    D'autant que certains choix fait par Prestashop semblent parfois peu efficaces, voir illogiques.
    Prenons le cas de la référence commande, qui est sous la forme d'une chaine de caractères aléatoire et unique .
    Pour une boutique qui n'a que quelques commandes / jour cela ne pose aucun problème (quoique), mais pour un flux plus important, cette référence qui sera utilisée par vous et vos clients n'est absolument pas pratique.

    Prenons un exemple. Si je vous donne la référence : QRFRUMBMF vous êtes bien avancé, ce n'est pas mnémotechnique et ne vous apprend rien sur la commande.

    Alors que ( par exemple ) une référence comme : 20151206-225 qui est la concaténation de :

    • 2015 : L'année de la commande
    • 12 : le mois de la commande
    • 06 : le jour de la commande
    • 225 : id unique de la commande

    Aurait était un choix beaucoup plus pertinent pour tout le monde ( client et marchand ).

    Posez la questions sur le forum et vous aurez avec un peu de chance, une âme charitable qui va vous guider pour effectuer ce changement. Dans le cas contraire, votre demande tombera dans les abîmes avec les autres messages du genre restés sans réponse .

    Aller au boulot, voyons comment faire ce changement dans le code.

    La surcharge

    Je ne vais pas détailler comment surcharger les différents éléments de Prestashop mais utiliser cette technique pour deux fichiers.

    Comme expliqué pus haut, prestashop est bien fini et permet de tout "surcharger" pour vous permettre de modeler/modifier les fonctionnalités de base de l'outil à volonté.

    Nous allons donc surcharger dans un premier temps les fichiers suivants :

    1. classes/order/OrderHistory.php
    2. classes/PaymentModule.php

    OrderHistory.php

    Cette classe gère l'historique des commandes et de ce fait, gère également l’expédition des emails liés à ces états. Mails dans lesquels est rappelé la référence de la commande.

    Nous allons donc créer le fichier de surcharge override/classes/order/OrderHistory.php , copier la méthode d'origine addWithemail et enfin le modeler à notre sauce.

    ce qui donne :

    <?php
    class OrderHistory extends OrderHistoryCore{
        
        /**
         * @param bool $autodate Optional
         * @param array $template_vars Optional
         * @param Context $context Optional
         * @return bool
         */
    
    	public function addWithemail($autodate = true, $template_vars = false, Context $context = null){
                if (!$context)
                    $context = Context::getContext();
    
                $order = new Order( (int)$this->id_order );
                $date = new DateTime($order->date_add);
    
                $data = array(
                    '{id_order}' => $date->format('Ymd').'-'.$this->id_order
                );
    
                if ($template_vars){
                    $data = array_merge($data, $template_vars);
                }
    
                return parent::addWithemail($autodate, $data, $context);
        }
    }
    

    Ne vous reste plus qu'à remplacer dans vos mails la balise {order_name} par {id_order}

    PaymentModule.php

    Cette classe est utilisée à la confirmation de commande et s'occupe également de l'expédition du mail de confirmation de commande ( pourquoi avoir séparé ce mails des autres ? ). Bref, nous allons donc également surcharger cette classe et plus précisément la méthode validateOrder.

    Nous allons donc créer le fichier de surcharge override/classes/PaymentModule.php , copier la méthode d'origine validateOrder() et enfin le modeler à notre sauce.

    class PaymentModule extends PaymentModuleCore{
        
            /**
         * Validate an order in database
         * Function called from a payment module
         *
         * @param int $id_cart
         * @param int $id_order_state
         * @param float   $amount_paid    Amount really paid by customer (in the default currency)
         * @param string  $payment_method Payment method (eg. 'Credit card')
         * @param null    $message        Message to attach to order
         * @param array   $extra_vars
         * @param null    $currency_special
         * @param bool    $dont_touch_amount
         * @param bool    $secure_key
         * @param Shop    $shop
         *
         * @return bool
         * @throws PrestaShopException
         */
        public function validateOrder($id_cart, $id_order_state, $amount_paid, $payment_method = 'Unknown',
            $message = null, $extra_vars = array(), $currency_special = null, $dont_touch_amount = false,
            $secure_key = false, Shop $shop = null)
        {
    
            ...
            ...
            ...
            //contenu de la méthode d'origine ( copier - coller de la methode validateOrder dans le fichier classes/PaymentModule.php )
            ...
            ...
            ...
            // Avant la liste des paramétres, o va formater la date de la commande
            $dateOrder = new DateTime($order->date_add);
            ....
            //Vers la ligne 622 dans la liste des paramètres balancés au template du mail, ajouter la ligne 
            ...
            '{id_order}' => $dateOrder->format('Ymd').'-'.$order->id
            ...
            ...
            ...
        }
    }
    

    Voilà , ne vous reste plus qu'à mettre à jour le mail orderConf pour remplacer {order_name} par {idorder}

    vider le cache

    Afin que les surcharges soient bien prises en compte, vous devez supprimer le fichier de cache suivant :

    cache/class_index.php

    Conclusion

    Voilà comment changer une partie de prestashop sans toucher au code d'origine.
    Si ce que vous avez fait ne fonctionne pas ou casse quelque chose, il vous suffit alors de supprimer ces fichiers ( dans le répertoire Override ) et remettre les balises dans les mails.
    Pas d'inquiétude donc lancez-vous.

  • Wednesday 30 December 2015 - 15:04

    S3, espace de stockage illimité chez Amazon avec des tarifs défiant toute concurrence. Qui en plus de son prix, offre des options plus qu’intéressantes...

    • chiffrement des données
    • versioning automatique
    • rotation ou mise en glacier des vielles versions ..


    Etc ...
    Je ne vais pas détailler ces options dans ce billet, mais juste expliquer comment monter un Bucket S3 ( répertoire S3 ) sur une machine / serveur linux afin d'y accéder comme un simple montage réseau . Nous verrons également comment le monter automatiquement via une simple ligne dans le fstab.

    Prérequis

    Nous allons utiliser fuse pour monter ce bucket, et l'authentification peut être chiffrée selon vos options, nous allons installer tout ce qu'il nous faut...

    sudo apt-get install build-essential git libfuse-dev libcurl4-openssl-dev libxml2-dev mime-support automake libtool fuse-utils pkg-config libssl-dev
    

    S3fs-fuse

    Maintenant, S3 + fuse n'étant pas un "système de fichiers" conventionnel, nous allons utiliser l'outil s3fs-fuse disponible sur un dépôt Gît

    cd /usr/local/src/
    git clone https://github.com/s3fs-fuse/s3fs-fuse
    cd s3fs-fuse/
    ./autogen.sh
    ./configure --prefix=/usr --with-openssl 
    make
    sudo make install
    

    Authentification S3

    Sauf si votre serveur se trouve sur la plateforme Amazon et que vous lui avez donné des droits spécifiques (S3) à sa création, il vous faudra obligatoirement préciser le couple "Access Key / Secret Key" récupéré sur la plateforme Amazon.
    Personnellement, je donne à mes utilisateurs un minimum de droits. Dans mon exemple donc, mon utilisateur fictif "John Doe" aura uniquement accès à son bucket, qui sera appelé "jdbucket".
    Nous allons donc éditer le fichier qui va lister les authentifications passwd-s3fs.

    sudo vim /etc/passwd-s3fs
    

    Le contenu devra respecter la forme suivante bucketName:accessKeyId:secretAccessKey :

    jdbucket:AKIAIOSFODNN7EXAMPLE:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
    

    Nous allons maintenant retirer un maximum de droits au fichier passwd-s3fs

    sudo chmod 600 /etc/passwd-s3fs
    

    Montage

    Ne nous reste plus qu'à monter notre bucket jdbucket . Disons sur le répertoire /var/mntJdBucket

    Commençons par créer le répertoire de montage.

    sudo mkdir /var/mntJdBucket; sudo chmod 777 /var/mntJdBucket
    

    Testons le montage avant de la mettre dans le fstab

    /usr/bin/s3fs jdbucket /var/mntJdBucket -ouse_cache=/tmp,passwd_file=/etc/passwd-s3fs
    

    Note: Spécifier le fichier de mot de passe S3 n'est pas obligatoire.
    Si tout va bien .. vous voilà connecté à votre S3 !
    Ne vous faite pas berner par le débit ( important ), ici le débit apparent sera celui de votre disque dur, car l'option use_cache=/tmp utilise un répertoire local comme cache entre votre système et le S3.

    Fstab

    Ne nous reste plus qu'à configurer notre montage dans le fstab, afin que le montage se fasse à chaque démarrage.

    sudo vim /etc/fstab
    


    Voici la ligne qu'il faut ajouter

    #Fuse
    s3fs#jdbucket	/var/mntJdBucket	fuse	rw,_netdev,use_cache=/tmp,allow_other,passwd_file=/etc/passwd-s3fs	0	0
    

    Au niveau des options, du classique, droits en lecture et écriture pour les utilisateurs, attente de la connexion réseau pour tenter de monter le bucket, configuration du répertoire de cache et du fichier de mot de passe ( toujours facultatif )

    Conclusion

    Nous avons maintenant fait le tour du montage S3 sur une machine debian, rien de bien méchant. Cependant, suite à mes tests, je conseille d'utiliser les commandes s3cmd pour envoyer de gros fichiers ( plusieurs Gb ) celle-ci étant plus adaptée.

    N'hésitez pas si vous avez des questions.

    Ch.

  • Saturday 09 January 2016 - 12:42

    Local vs Remote SSH port forwarding

    When it comes to the art of SSH tunnelling, there are basically two options where to relay a port to.

    You can relay a port from a remote server to your local machine with ssh -L, hence called local port forwarding. A very basic use-case is if your remote server has a MySQL database daemon listening on port 3306 and you want to access this daemon from your local computer.

    The second option is to make your local port available on a remote server (ssh -R). Remote port forwarding might come in handy if you for example want to make your local web-server available on a port of a public server, so that someone can quickly check what your local web-server provides without having to deploy it somewhere publicly.

    It should now be pretty easy to remember: Local and remote port forwarding always refers to where to relay the port to. The SSH command syntax uses the same easy to remember abbreviations: -L (forward to my local machine) and -R (forward to my remote machine).

    Article series
    SSH tunnelling for fun and profit

    1. Local vs Remote
    2. Tunnel options
    3. AutoSSH
    4. SSH Config

    TL;DR

    Remote MySQL server (remote port 3306) to local machine on local port 5000:

    ssh -L 5000:localhost:3306 cytopia@everythingcli.org
    

    Local web-server (local port 80) to remote server on remote port 5000:

    ssh -R 5000:localhost:80 cytopia@everythingcli.org
    

    Local port forwarding

    (Make a remote port available locally).

    In this example we are going to make a remote MySQL Server (Port 3306) available on our local computer on port 5000.

    Let’s start with the general syntax of local port forwarding:

    ssh -L <LocalPort>:<RemoteHost>:<RemotePort> sshUser@remoteServer
    
    Argument Explanation
    LocalPort The port on your local machine where the whole thing should be reachable.
    RemoteHost This specifies on which interface inside the remote server (remoteServer) the daemon is listening on. This can be either 127.0.0.1, localhost, a specific IP address or even 0.0.0.0 which refers to all interfaces. If you are unsure, simply ssh into the remote machine and check all interfaces for port 3306 by issuing:
    netstat -an | grep 3306 | grep LISTEN.
    RemotePort This is the actual port on the remote machine (remoteServer) you want to relay to your local machine. In our case (MySQL listens on 3306 by default) it is simply 3306
    sshUser This is the SSH username you have on the remote server
    remoteServer The address (IP or hostname) by which your remote server is reachable via ssh

    Now let’s simply forward our remote MySQL server to our local machine on port 5000.

    ssh -L 5000:localhost:3306 cytopia@everythingcli.org
    

    That’s all the magic! You can now simply reach the remote database from your local machine with mysql --host=127.0.0.1 --port=5000 or any other client.

    But wait… which local address does it listen on?

    Yes, you are right! The complete syntax is:

    ssh -L [<LocalAddress>]:<LocalPort>:<RemoteHost>:<RemotePort> sshUser@remoteServer
    
    Argument Explanation
    LocalAddress The local address is an optional parameter. If you do not specify it, the remote port will be bound locally to all interfaces (0.0.0.0). So you can also only bind it locally to your 127.0.0.1 (on your local machine).

    This is the full example:

    ssh -L 127.0.0.1:5000:localhost:3306 cytopia@everythingcli.org
    

    Remote port forwarding

    (Make a local port available remotely).

    In this example we are going to make our local web-server (Port 80) available on a remote server on Port 5000.

    Let’s start with the general syntax of remote port forwarding:

    ssh -R <RemotePort>:<LocalHost>:<LocalPort> sshUser@remoteServer
    
    Argument Explanation
    RemotePort The port on your remote server (remoteServer) where the whole thing should be reachable.
    LocalHost This specifies on which interface inside your local computer the daemon is listening on. This can be either 127.0.0.1, localhost, a specific IP address or even 0.0.0.0 which refers to all interfaces. If you are unsure, simply check all interfaces (on your local machine) for port 80 by issuing:
    netstat -an | grep 80 | grep LISTEN.
    LocalPort This is the actual port on your local machine you want to relay to the remote server (remoteServer). In our case (The web-server listens on 80 by default) it is simply 80
    sshUser This is the SSH username you have on the remote server
    remoteServer The address (IP or hostname) by which your remote server is reachable via ssh

    Now let’s simply forward our local web-server to our remote machine on port 5000.

    ssh -R 5000:localhost:80 cytopia@everythingcli.org
    

    That’s all the magic! You can now simply reach your local webserver via http://everythingcli.org:5000.

    But wait… which remote address does it listen on?

    Yes, you are right! The complete syntax is:

    ssh -R [<RemoteAddress>]:<RemotePort>:<LocalHost>:<LocalPort> sshUser@remoteServer
    
    Argument Explanation
    RemoteAddress The remote address is an optional parameter. If you do not specify it, the remote port will be bound remotely (on remoteServer) to all interfaces (0.0.0.0). So you can also only bind it remotely to a specific interface.

    This is the full example:

    Assuming the IP address of everythingcli.org is 109.239.48.64 and you only want to bind it to this IP.

    ssh -R 109.239.48.64:5000:localhost:80 cytopia@everythingcli.org
    

    But wait… it doesn’t work
    By default, the listening socket on the server will be bound to the loopback interface only. This may be overridden by specifying RemoteAddress. Specifying a RemoteAddress will only succeed if the server’s GatewayPorts option is enabled (on the remote server):

    $ vim /etc/ssh/sshd_config
    GatewayPorts yes
    

    Some more details

    Ports below 1024

    Every system user can allocate ports above and including 1024 (high ports). Ports below that require root privileges.
    So If you want to relay any port to a port to for example 10, you must do that like so:

    As you allocate a low port on your local machine, you must either do that as root (locally) or with sudo (locally):

    sudo ssh -L 10:localhost:3306 cytopia@everythingcli.org
    

    As you allocate a low port on the remote server, you will need to ssh into the machine as root:

    ssh -R 10:localhost:80 root@everythingcli.org
    

    _

    The post SSH tunnelling for fun and profit: local vs remote appeared first on Everything CLI.

  • Wednesday 13 January 2016 - 14:37

    If you have read the previous article of this series, you should be able to create forward and reverse tunnels with ease. In addition to the previously shown examples I will address some more advanced options for SSH tunnels in general.

    Article series
    SSH tunnelling for fun and profit
    1. Local vs Remote
    2. Tunnel options
    3. AutoSSH
    4. SSH Config

    SSH Login shell

    Remember the following example:

    ssh -L 5000:localhost:3306 cytopia@everythingcli.org
    

    Once you have executed the above command, a tunnel is established. However, you will also be logged in into the remote server with a SSH session. If you simply want to do some port forwarding you will not need or might not even want a remote login session. You can disable it via -N, which is a very common option for SSH tunnels:

    ssh -N -L 5000:localhost:3306 cytopia@everythingcli.org
    

    The -N option is also very useful when you want to create SSH tunnels via cron

    Argument Explanation
    -N After you connect just hang there (you won’t get a shell prompt)
    SSH man: Do not execute a remote command.
    Note: Only works with SSHv2

    So if you are not going to execute remote commands and will not need a login shell, you also do not need to request a pseudo terminal in the first place.

    ssh -T -N -L 5000:localhost:3306 cytopia@everythingcli.org
    
    Argument Explanation
    -T Disable pseudo-terminal allocation.
    This makes it also safe for binary file transfer which might contain escape characters such as ~C.

    SSH tunnel via cron

    Imagine you want to have a SSH tunnel be established (or checked and if it doesn’t run re-opened) via cron every hour. For that to work, SSH must go into background. For that we use -f.

    ssh -f -L 5000:localhost:3306 cytopia@everythingcli.org
    
    Argument Explanation
    -f Requests ssh to go to background just before command execution.

    But hey, if SSH is in the background anyway, we do not need a login shell (-N) and therefore also do not need a tty (-T). So the full command ready for cron would be:

    ssh -f -T -N -L 5000:localhost:3306 cytopia@everythingcli.org
    

    Note: Be aware that this example requires private/public key authentication as cron will not be able to enter passwords.

    SSH tunnel on a non-standard port

    What if the SSH server is listening on a non-standard port (not tcp22). You can always add a port option. Let’s imagine SSH itself is listening on port 1022:

    ssh -T -N -L 5000:localhost:3306 cytopia@everythingcli.org -p 1022
    
    Argument Explanation
    -p Port to connect to on the remote host.

    SSH tunnel with a non standard private key

    Let’s assume you have many different private keys for different servers. If not explicitly specified, SSH will look for a file called ~/.ssh/id_rsa. In this case however, your file is called ~/.ssh/id_rsa-cytopia@everythingcli. So you will also pass this information to the tunnel command.

    ssh -T -N -L 5000:localhost:3306 cytopia@everythingcli.org -i ~/.ssh/id_rsa-cytopia@everythingcli
    

    SSH tunnel via SSH config

    The most complex example from this tutorial is:

    ssh -f -T -N -L 5000:localhost:3306 cytopia@everythingcli.org -p 1022 -i ~/.ssh/id_rsa-cytopia@everythingcli
    

    We all are lazy-ass and don’t want to type the whole thing every time we need a quick tunnel. This is where ~/.ssh/config comes into play.

    Adding user and host

    $ vim ~/.ssh/config
     Host cli
        HostName      everythingcli.org
        User          cytopia
    

    With this, we have created an alias cli for host everythingcli.org with user cytopia. Now our command can be written like this:

    ssh -f -T -N -L 5000:localhost:3306 cli -p 1022 -i ~/.ssh/id_rsa-cytopia@everythingcli
    

    Adding port and identity file

    $ vim ~/.ssh/config
     Host cli
        HostName      everythingcli.org
        User          cytopia
        Port          1022
        IdentityFile  ~/.ssh/id_rsa-cytopia@everythingcli
    

    Now the ssh command looks like this:

    ssh -f -T -N -L 5000:localhost:3306 cli
    

    Adding tunnel config

    In the above example we have a generic configuration for the host everthingcli.org which will work for normal ssh connection as well as for establishing a tunnel. Let’s copy all of the above block under a new alias cli-mysql-tunnel and add the tunnel specific configuration:

    $ vim ~/.ssh/config
     Host cli-mysql-tunnel
        HostName      everythingcli.org
        User          cytopia
        Port          1022
        IdentityFile  ~/.ssh/id_rsa-cytopia@everythingcli
        LocalForward  5000 localhost:3306
    

    Now we can create the tunnel in a much shorter way:

    ssh -f -T -N cli-mysql-tunnel
    

    _

    The post SSH tunnelling for fun and profit: Tunnel options appeared first on Everything CLI.

  • Sunday 17 January 2016 - 23:46

    I just ran into the problem of having to display a PDF file on my TV. Unfortunately there is no built-in feature, which is able to do so. It is only capable of playing movies, so I had to convert the PDF to a mp4 file.

    As I could not find a direct approach, I had to extract all images from the PDF using convert and then concatenate all images into a video stream with ffmpeg.

    PDF to PNG’s

    convert -density 400 input.pdf pic.png
    
    Option Description
    -density 400 Set the horizontal resolution of the image

    This will create one picture for every PDF page with the following naming convention pic-<NUM>.

    PNG’s to MP4

    ffmpeg -r 1/5 -i pic-%02d.png -c:v libx264 -r 30 -pix_fmt yuv420p out.mp4
    
    Option Description
    pic-%02d.png Read all images from the current folder with the prefix pic-, a following number of 2 digits (%02d) and an ending of .png
    -r 1/5 Displays each image for 5 seconds
    r 30 Output framerate of 30 fps.
    -c:v libx264 Output video codec: h264
    pix_fmt yuv420p YUV pixel format

    Scale the Movie

    As the final movie was >4k, my TV wasn’t able to play it, so I in the last step I had to scale it down to an appropriate resolution of 720p:

    ffmpeg -i out.mp4 -vf scale=-1:720  out_720p.mp4
    

    Voila, the final movie plays every page for 5 seconds with a frame rate of 30 frames per second and a horizontal resolution of 720 pixels.

    Reference

    _

    The post Convert PDF to MP4 appeared first on Everything CLI.

  • Tuesday 19 January 2016 - 19:44

    Il y a longtemps maintenant, je vous ai parlé du jeu de société Diaballik, lui même décliné en version iPad. Beaucoup d’eau a coulé sous les ponts et Philippe Lefrançois (le créateur a passé un deal avec un nouvel éditeur FERTI).

    plateau animé

    On y gagne un visuel très différent et deux nouveaux modes de jeux. Très honnêtement c’est vraiment excitant de se replonger dans ce jeu qui n’a pas pris une ride. je vous laisse le redécouvrir :

    figurines senseï

    Les pions et le plateau

    ensemble figurine et plateau

    Le jeux est disponible chez tous les bon vendeurs au prix de 32,15€.

    The post Diaballik devient Senseï appeared first on Le blog de Luc.

  • Wednesday 20 January 2016 - 09:56

    Now that you are able to create various forward or reverse SSH tunnels with lots of options and even simplify your live with ~/.ssh/config you probably also want to know how make a tunnel persistent. By persistent I mean, that it is made sure the tunnel will always run. For example, once your ssh connection times out (By server-side timeout), your tunnel should be re-established automatically.

    I know there are plenty of scripts out there which try to do that somehow. Some scripts use a while loop, others encourage you to run a remote command (such as tail) to make sure you don’t run into timeout and various others. But actually, you don’t want to re-invent the wheel and stick to bullet-proof already existing solutions. So the game-changer here is AutoSSH.

    Article series
    SSH tunnelling for fun and profit
    1. Local vs Remote
    2. Tunnel options
    3. AutoSSH
    4. SSH Config

    TL;DR

    autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -L 5000:localhost:3306 cytopia@everythingcli.org
    

    or fully configured (via ~/.ssh/config) for background usage

    autossh -M 0 -f -T -N cli-mysql-tunnel
    

    What is AutoSSH

    http://www.harding.motd.ca/autossh/README

    Autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic.

    Install AutoSSH

    How to install AutoSSH on various systems via their package manager.

    OS Install method
    Debian / Ubuntu $ sudo apt-get install autossh
    CentOS / Fedora / RHEL $ sudo yum install autossh
    ArchLinux $ sudo pacman -S autossh
    FreeBSD # pkg install autossh
    or
    # cd /usr/ports/security/autossh/ && make install clean
    OSX $ brew install autossh

    Alternatively you can also compile and install AutoSSH from source:

    wget http://www.harding.motd.ca/autossh/autossh-1.4e.tgz
    gunzip -c autossh-1.4e.tgz | tar xvf -
    cd autossh-1.4e
    ./configure
    make
    sudo make install
    

    Note: Make sure to grab the latest version which can be found here: http://www.harding.motd.ca/autossh/.

    Basic usage

    usage: autossh [-V] [-M monitor_port[:echo_port]] [-f] [SSH_OPTIONS]
    

    Ignore -M for now. -V simply displays the version and exits. The important part to remember is that -f (run in background) is not passed to the ssh command, but handled by autossh itself. Apart from that you can then use it just like you would use ssh to create any forward or reverse tunnels.

    Let’s take the basic example from part one of this article series (forwarding a remote MySQL port to my local machine on port 5000):

    ssh -L 5000:localhost:3306 cytopia@everythingcli.org
    

    This can simply be turned into an autossh command:

    autossh -L 5000:localhost:3306 cytopia@everythingcli.org
    

    This is basically it. Not much magic here.

    Note 1: Before you use autossh, make sure the connection works as expected by trying it with ssh first.

    Note 2: Make sure you use public/private key authentification instead of password-based authentification when you use -f. This is required for ssh as well as for autossh, simply because in a background run a passphrase cannot be entered interactively.

    AutoSSH and -M (monitoring port)

    With -M AutoSSH will continuously send data back and forth through the pair of monitoring ports in order to keep track of an established connection. If no data is going through anymore, it will restart the connection. The specified monitoring and the port directly above (+1) must be free. The first one is used to send data and the one above to receive data on.

    Unfortunately, this is not too handy, as it must be made sure both ports (the specified one and the one directly above) a free (not used). So in order to overcome this problem, there is a better solution:

    ServerAliveInterval and ServerAliveCountMax – they cause the SSH client to send traffic through the encrypted link to the server. This will keep the connection alive when there is no other activity and also when it does not receive any alive data, it will tell AutoSSH that the connection is broken and AutoSSH will then restart the connection.

    The AutoSSH man page also recommends the second solution:

    -M [:echo_port],

    In many ways this [ServerAliveInterval and ServerAliveCountMax options] may be a better solution than the monitoring port.

    You can disable the built-in AutoSSH monitoring port by giving it a value of 0:

    autossh -M 0
    

    Additionally you will also have to specify values for ServerAliveInterval and ServerAliveCountMax

    autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3"
    

    So now the complete tunnel command will look like this:

    autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -L 5000:localhost:3306 cytopia@everythingcli.org
    
    Option Description
    ServerAliveInterval ServerAliveInterval: number of seconds that the client will wait before sending a null packet to the server (to keep the connection alive).
    Default: 30
    ServerAliveCountMax Sets the number of server alive messages which may be sent without ssh receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session.
    Default: 3

    AutoSSH and ~/.ssh/config

    In the previous article we were able to simplify the tunnel command via ~/.ssh/config. Luckily autossh is also aware of this file, so we can still keep our configuration there.

    This was our very customized configuration for ssh tunnels which had custom ports and custom rsa keys:

    $ vim ~/.ssh/config
     Host cli-mysql-tunnel
        HostName      everythingcli.org
        User          cytopia
        Port          1022
        IdentityFile  ~/.ssh/id_rsa-cytopia@everythingcli
        LocalForward  5000 localhost:3306
    

    We can also add the ServerAliveInterval and ServerAliveCountMax options to that file in order to make things even easier.

    $ vim ~/.ssh/config
     Host cli-mysql-tunnel
        HostName      everythingcli.org
        User          cytopia
        Port          1022
        IdentityFile  ~/.ssh/id_rsa-cytopia@everythingcli
        LocalForward  5000 localhost:3306
        ServerAliveInterval 30
        ServerAliveCountMax 3
    

    If you recall all the ssh options we had used already, we can now simply start the autossh tunnel like so:

    autossh -M 0 -f -T -N cli-mysql-tunnel
    

    AutoSSH environment variables

    AutoSSH can also be controlled via a couple of environmental variables. Those are useful if you want to run AutoSSH unattended via cron, using shell scripts or during boot time with the help of systemd services. The most used variable is probably AUTOSSH_GATETIME:

    AUTOSSH_GATETIME
    How long ssh must be up before we consider it a successful connection. Default is 30 seconds. If set to 0, then this behaviour is disabled, and as well, autossh will retry even on failure of first attempt to run ssh.

    Setting AUTOSSH_GATETIME to 0 is most useful when running AutoSSH at boot time.

    All other environmental variables including the once responsible for logging options can be found in the AutoSSH Readme.

    AutoSSH during boot with systemd

    If you want a permanent SSH tunnel already created during boot time, you will (nowadays) have to create a systemd service and enable it. There is however an important thing to note about systemd and AutoSSH: -f (background usage) already implies AUTOSSH_GATETIME=0, however -f is not supported by systemd.

    http://www.freedesktop.org/software/systemd/man/systemd.service.html
    […] running programs in the background using “&”, and other elements of shell syntax are not supported.

    So in the case of systemd we need to make use of AUTOSSH_GATETIME. Let’s look at a very basic service:

    $ vim /etc/systemd/system/autossh-mysql-tunnel.service
    [Unit]
    Description=AutoSSH tunnel service everythingcli MySQL on local port 5000
    After=network.target
    
    [Service]
    Environment="AUTOSSH_GATETIME=0"
    ExecStart=/usr/bin/autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -NL 5000:localhost:3306 cytopia@everythingcli.org -p 1022
    
    [Install]
    WantedBy=multi-user.target
    

    Tell systemd that we have added some stuff:

    systemctl daemon-reload
    

    Start the service

    systemctl start autossh-mysql-tunnel.service
    

    Enable during boot time

    systemctl enable autossh-mysql-tunnel.service
    

    _

    This is basically all I found useful about AutoSSH. If you thing I have missed some important parts or you know any other cool stuff, let me know and I will update this post.

    Discussions

    The post SSH tunnelling for fun and profit: Autossh appeared first on Everything CLI.

  • Saturday 23 January 2016 - 17:11

    Afin d'éviter de re-télécharger les paquets pour chaque projet nous allons voir ce petit truc extra simple qui est d'activer le cache local de pip.
    Le principe est simple, la première fois que vous installez un paquet, ce dernier est téléchargé, puis mis en cache.
    La seconde fois ( s'il s’agit de la même version ), pip va simplement l'installer depuis le cache.

    Ok, ça ne va pas vous changer la vie, mais moi je trouve ça sympa à utiliser, surtout lorsque vous devez installer des gros paquets avec une connexion d’hôtel faiblarde, ça peut vous faire gagner de précieuses minutes .

    Configuration de PIP

    Commençons par éditer le fichier de configuration de pip

    vim ~/.pip/pip.conf
    

    Ajouter dans la section "global":

    [global]
    download-cache=/usr/local/pip/cache
    

    enfin on donne les droits d'écriture

    mkdir -p /usr/local/pip/cache
    chmod -R 755 /usr/local/pip/cache
    

    Deuxième méthode un peu plus courte

    Simplement ajouter dans votre fichier de profil : ~/.bash_profile

    export PIP_DOWNLOAD_CACHE=$HOME/.pip_download_cache
    

    Voilà pour ce micro billet.

    Bon weekend .

  • Monday 25 January 2016 - 09:15

    This series has already covered a few basics about ~/.ssh/config in terms of how to simplify the usage of ssh tunnelling. In order to round this up a bit more, I will add some information you should be aware of about ~/.ssh/config. This is only intended to be a quick reminder about how it is done right and some useful hints you might not have heard about.

    The following uses examples with pure ssh connection commands, but it is also applicable to establish tunnels with ssh as they all read the same configuration file.

    Article series
    SSH tunnelling for fun and profit
    1. Local vs Remote
    2. Tunnel options
    3. AutoSSH
    4. SSH Config

    TL;DR

    Nope, this time you need to read it all.

    Structure of SSH Config

    Probably the most important part which is widely overlooked is the order of definition blocks in ~/.ssh/config and accordingly /etc/ssh/ssh_config in terms of generalization and specialization.

    You can basically categorize blocks into three stages:

    1. Most specific (without any wildcards)
    2. Some generalization (with wildcard definitions)
    3. General section (which applies to all).

    Let’s define a basic ~/.ssh/config containing the examples above and see what it does:

    Wrong way

    No, what many people do wrong is to define the general stuff at the top. Let’s do this for a second and see what the outcoming ssh connection string will be:

    Host *
        User root
        Port 22
        PubkeyAuthentication no
        ServerAliveInterval 30
    
    Host c*
        User cytopia
        Port 10022
        PubkeyAuthentication yes
        IdentityFile ~/.ssh/id_rsa__c_cytopia@cytopia-macbook
    
    Host c1
        HostName 192.168.0.1
    
    Host c2
        HostName 192.168.0.2
    

    If you want to ssh connect to c1 (ssh c1), the file is read as follows:

    1. Find section Host *
      1. Apply User: root
      2. Apply Port: 22
      3. Apply PubkeyAuthentication: no
      4. Apply ServerAliveInterval: 30
    2. Find section Host c*
      1. Ignore User (already defined above)
      2. Ignore Port (already defined above)
      3. Ignore PubkeyAuthentication (already defined above)
      4. Apply IdentityFile
    3. Find section Host c1
      1. Apply HostName: 192.168.0.1

    The final connection string that will be made internally will look like this:

    ssh root@192.168.0.1 -p 22 -i ~/.ssh/id_rsa__c_cytopia@cytopia-macbook -o PubkeyAuthentication=no -o ServerAliveInterval=30
    

    Now this is totally not what you intended to do!

    Right way

    Let’s restructure the ~/.ssh/config into the right order and check the resulting connection string:

    Host c1
        HostName 192.168.0.1
    
    Host c2
        HostName 192.168.0.2
    
    Host c*
        User cytopia
        Port 10022
        PubkeyAuthentication yes
        IdentityFile ~/.ssh/id_rsa__c_cytopia@cytopia-macbook
    
    Host *
        User root
        Port 22
        PubkeyAuthentication no
        ServerAliveInterval 30
    

    The important part to keep track of is the Host section (aligned to the left). Notice here that the general definitions are at the very top and more wildcarded definitions (using the asterisk *) are followed below.

    If you want to ssh connect to c1 (ssh c1), the file is read as follows:

    1. Find section Host c1 and use its corresponding HostName (192.168.0.1)
    2. Find more general section Host c* and use their values (User, Port, etc).
    3. Find most general section Host *
      1. Don’t use User as it has already been defined for this connection in c*
      2. Don’t use Port as it has already been defined for this connection in c*
      3. Don’t use PubkeyAuthentication as it has already been defined for this connection in c*
      4. Use ServerAliveInterval as there is no previous definition.

    So from that you must always remember that whenever a specific value has been found, it cannot be overwritten by values defined below. It is a first come first server here. The final connection string that will be made internally will look like this:

    ssh cyptopia@192.168.0.1 -p 10022 -i ~/.ssh/id_rsa__c_cytopia@cytopia-macbook -o PubkeyAuthentication=yes -o ServerAliveInterval=30
    

    Now this is how you intended to connect. So always remember:

    1. Specific definitions at the top
    2. General definitions at the bottom

    Why use SSH config anyway?

    Simpler usage

    Imagine you have a couple of dozens or even hundred servers you have to take care of. Each of them is having different login options such as: some still use passwords, others use rsa keys, others ed25519 keys, lots of different initial users to use for the connection and much more. Wouldn’t it be much more simple to define everything into a file and don’t care about the rest anymore?

    You could for example use a naming convention for clouded vs. dedicated hosts as so:
    c1, c2, c3, …, d1, d2, d3

    Or you use hosts per customer:
    google1, google2, google3, …, apple1, apple2, apple3

    All those hosts might have completely different settings even different ports and you simply need to

    $ ssh c1
    $ ssh d2
    $ ssh google1
    $ ssh apple3
    ...
    

    Other applications make use of it too

    Most programs that make use of ssh can use the same alias specified in ~/.ssh/config with the same options, simply by specifying the alias inside this program.
    For example on OSX I am using Sequel Pro to manage all my MySQL connections. Instead of having to specify host, user, port and certificate (in the ssh tunnel section), I simply only specify the ssh alias and it will auto-grab all details from my ~/.ssh/config.

    I am sure there are many other programs out there that are also able to make use of it.

    On top of that, if you need to alter settings of one server, you do it in a central place and it will have an effect on all tools instantly.

    Autocompletion

    You will have autocompletion (at least under bash or zsh) for every host and every alias defined. This is true for hosts and even IP addresses. When I type ssh 1 and hit tab:

    $ ssh 1
    192.168.0.1     192.168.0.2     192.168.0.3     192.168.0.4     192.168.0.5     192.168.0.6
    192.168.0.7     192.168.0.8     192.168.0.9     192.168.0.10    192.168.0.11    192.168.0.12
    

    Note: I have replaced the IP addresses with internal once.

    Hostnames

    $ ssh c
    c1                               c15.example.de                   c4
    c1.example.de                    c16                              c4.example.de
    c10                              c16.example.de                   c5
    c10.example.de                   c17                              c5.example.de
    c11                              c17.example.de                   c6
    c11.example.de                   c18                              c6.example.de
    

    Note: I have replaced the domains with example.de once.

    Defaults

    Within the most general configuration section you can define settings that must be applied for every ssh ... you type.

    So hopefully the ~/.ssh/config has raised your attention by now.

    What your mother never told you about ~/.ssh/config

    Identity leak via ssh keys

    If you are a big fan of ssh keys in combination with ssh-agent, then you should be aware that once you connect to any ssh server, all of your public keys that are hold by your ssh-agent, are sent to this server.

    You can check which keys are stored inside your ssh-agent via ssh-add.

    $ ssh-add -l
    4096 SHA256:111_SSH_HASH_111 /Users/cytopia/.ssh/id_rsa__host_root@me (RSA)
    256  SHA256:111_SSH_HASH_111 /Users/cytopia/.ssh/id_ed25519__host_user@me (ED25519)
    ...
    

    By default, if you do not manually add any keys via ssh-add, all defaults (no custom name) for rsa, dsa ecdsa and ed25519 (usually id_rsa, id_dsa, id_ecdsa and id_ed25519) are added to the ssh-agent (once they are created).

    So this means, if you have created one default rsa key simply by typing ssh-keygen, you will have this key ~/.ssh/id_rsa and this key will also be added to your ssh-agent by default.

    This means if you connect a lot to many untrusted ssh servers, they might log your keys (just like websites track you via cookies) and might be able to identify.

    The problem has been address by https://github.com/FiloSottile/whosthere/ which can identify your github name.

    Test if your ssh client settings are vulnerable to github identity leak:

    $ ssh whoami.filippo.io
    

    This is the example from: https://github.com/FiloSottile/whosthere/, make sure to visit this github page.

    What FiloSottile recommends is to turn off public key authentification in general and explicitly turn it on per host (where u need it):

    # Turn on pubkey auth per specific HOST
    Host c1
        HostName 192.168.0.1
        PubkeyAuthentication yes
        IdentityFile ~/.ssh/id_rsa_specific
    
    # Turn off pubkey auth for all hosts
    Host *
        PubkeyAuthentication no
        IdentitiesOnly yes
    

    Securing known_hosts

    Let’s look at a line of a typical ~/.ssh/known_hosts file:

    cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
    

    Space separated fields in order of occurance
    1. [optional] markers
    2. hostnames (comma separated)
    3. Bits, exponent and modulus
    4. [optional] comment (not used)

    This file is pretty talkative and can tell all the hosts you have visited so far and therefore has some implications. You can read more about the problems here: Protecting SSH from known_hosts Address Harvesting

    So in order to only store hashes of the hostnames inside ~/.ssh/known_hosts, you will need to alter ~/.ssh/config:

    Host *
        HashKnownHosts yes
    

    The hashed version for the file will look like this:

    |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa AAAA1234.....=
    

    Note 1: Keep in mind that the hashing will start from now on and previous entries will not be hashed.

    Note 2: With hashing you will loose the autocompletion feature from known_hosts, but when you use aliases, you still have the alias based autocompletion described above.

    Multiple connections inside a single one

    SSH needs some time establishing a connection. This time grows as you use stronger/bigger private/public key-pairs. However, if a server receives a lot of connections, this time might matter and fortunately there is a way to reduce it by multiplexing multiple ssh connections over a single one from the same host/user by re-using an already established connection.

    So how can this be established? Again, you can configure this behavior inside your ~/.ssh/config globally as the following example shows:

    Host *
        ControlMaster auto
        ControlPath ~/.ssh/sockets/%r@%h-%p
        ControlPersist 600
    
    Option Description
    ControlMaster Tell SSH to re-use an existing connection (if there is already an established one) without having to authenticate again.
    ControlPath This is the path of the socket for open SSH connections. Every new connection will hook into this socket and can use the already established connection
    ControlPersist Keep the master (the first) SSH connection open for X seconds after the last connection has been closed. This means you have X seconds to connect again without authentification after all connections have been closed to this host.

    Where does this matter?

    Nagios

    If your nagios server does multiple SSH checks (check_ssh) against one server, it is recommended to setup the nagios’ servers ssh client to re-use existing ssh connections in order to speed up those checks.

    Git

    If you do a lot of work with git very frequently like pushing, using the autocomplete feature (which requires some remote connection to upstream), etc you are probably also a candidate to re-use existing SSH connections.

    I am myself are not a fan of enabling the whole thing globally (except for the nagios server), but rather for specific use cases.
    So If you want to enable this for specific hosts only you could do it like that:

    # For some host
    Host c1
        HostName 192.168.0.1
        ControlMaster auto
        ControlPath ~/.ssh/sockets/%r@%h-%p
        ControlPersist 600
    
    # For github usage
    Host github.com
        HostName github.com
        User git
        ControlMaster auto
        ControlPath ~/.ssh/sockets/%r@%h-%p
        ControlPersist 600
    

    Private ssh key leak

    Have you heard about the recents cve’s about possible private key leaks via ssh to a malicious SSH server: CVE-2016-0777 and CVE-2016-0778.

    In order to avoid this possible vulnerability add the following undocumented setting to your ~/.ssh/config at the bottom inside the general section:

    Host *
        UseRoaming no
    
    

    Useful tools

    As I have lots of ssh hosts configured in my ~/.ssh/config and it would be impossible for me to remember which domain is hosted on which server (especially if a single server is having more than 20 separate domains), I am using a little helper script, that will search my ssh configuration file for a given domain or any other keyword and will present me the server it is hosted on.

    For example, If I want to know on which server www.everythingcli.org is hosted I can simply type:

    $ sshf everything
    ------------------------------------------------------------
     c1
    ------------------------------------------------------------
     @vhosts: www.everythingcli.org another-domain.com
    

    So it told me, that there are two domains on server c1 including the one I was looking for (which will be auto-highlighted via grep --color). No I can simply go there via:

    ssh c1
    

    So if you find this useful, you can find the script at github:

    cytopia/sshf cytopia

    Eof

    I hope you enjoyed this little introduction to ~/.ssh/config and noticed that it is just as complex as the corresponding server configuration. Keep in mind that I just covered some basics mixed with a few specific examples. There is much more to this configuration file, so go on and read up about the power of your ssh client: man ssh_config

    _

    The post SSH tunnelling for fun and profit: SSH Config appeared first on Everything CLI.

  • Thursday 28 January 2016 - 00:00
    Petit tutoriel pour désactiver la lecture automatique d'une vidéo dans Firefox
  • Thursday 04 February 2016 - 15:44

    Le temps passe trop vite en ce moment... Ce blog se trouve donc délaissé. C'est dommage parce qu'il y a des infos qui ne peuvent pas attendre. Par exemple le kickstarter Ulule d'une traduction française pour les règles (libres) de D&D en version 5 à tellement de succès que plusieurs paliers sont parfois franchis durant la même journée.

    Si vous êtes rôliste, je vous conseil de vite, très vite, aller faire un tour sur la page du projet (rarement à jour tellement les paliers tombent vite, il faut alors aller voir sur la section "news").

    Les offres "early" sont passés depuis longtemps. Il reste deux offres, la "normale" à 59€, qui donne droit aux trois livres de base, et celle à 115€ (SEULEMENT 40 EXEMPLAIRES RESTANTS, et au rythme ou ça va, demain ou après demain il sera trop tard). Plus de deux cents sont déjà partis en à peine quelque jours ! Cette offre donne droit aux trois livres en version collector, à un jeu de société, à un set de dés, à probablement deux livrets de scénarios en suppléments etc. Quelque soit l'offre, les pdfs seront aussi fournis :)

    Bien qu'il existe en réalité deux projets de traductions, (celle ci et celle de blackbook), c'est celle d'Ulule qui me semble la plus prometteuse. (Et coté tarif, il n'y a photos). Je voulais aussi signaler que les auteurs sont très à l'écoute de la communauté, que les améliorations de chaque palier sont le résultat d'un vote systématique. Chapeau aussi aux votant qui ont récemment choisi d'augmenter la rémunération des traducteurs/illustrateurs. (C'est ce que j'avais voté, sans penser qu'on serait nombreux à le faire... Mais ce fut le cas, et tant mieux !)

    On peut aussi considérer que ces deux campagnes sont complémentaires, et que BlackBook réalise une traduction d'une campagne, et prévoit aussi des livres en format poche, ce qui pourrait être pratique en déplacement ou pour les joueurs. L'idéal sera peut être au final de "piocher" des deux cotés...

  • Friday 05 February 2016 - 20:06

    On peut exercer un contrôle parental sans installer quoi que ce soit sur son ordinateur. Qu'il s'agisse d'un PC ou d'un Mac, on peut tout à fait interdire l'accès aux sites de son choix ou à ceux réputés nocifs pour les enfants ou les ados en utilisant uniquement des astuces, et ce, sans éveiller leur soupçon. Explications.

    Votre enfant dispose d'un ordinateur dans sa chambre et vous, inquiet de la facilité avec laquelle on peut accéder aux sites pour adultes, aimeriez l'empêcher d'y accéder ? Vous aimeriez exercer le même contrôle parental sur votre ado sans qu'il/elle s'en rende compte ? Ou peut-être aimeriez-vous interdire l'accès à un site particulier, comme Facebook ou un site de jeux, qui l'éloigne de ses devoirs scolaires ?

     

    Découvrez comment y parvenir sans logiciel et sans que vos enfants vous soupçonnent d'avoir trafiqué quelque chose. S'ils y accédaient auparavant, ils croiront tout au plus que l'impossibilité de connexion est due à un bug et finiront pas se lasser de retenter en vain.

     

    Deux solutions s'offrent à vous en fonction de la problématique : un filtre DNS et la modification du fichier hosts.

     

    SOMMAIRE

    I. — Utilisation d'un serveur DNS qui filtre les sites Internet

     

    L'utilisation d'un serveur DNS qui filtre les sites Internet est la solution à adopter si vous voulez bloquer l'accès aux sites porno ou protéger vos enfants des dangers d'Internet.

     

    Internet est avant tout le plus grand des réseaux car il relie les réseaux du monde entier, un réseau désignant un ensemble d'ordinateurs et autres équipements informatiques reliés entre eux pour communiquer. C'est aussi un mot valise qui regroupe divers services en ligne comme le World Wide Web (le fameux Web), le courrier électronique, le transfert de fichiers, la visioconférence, le chat, les forums de discussion, etc. Beaucoup l'assimilent au Web, c'est une erreur : le Web désigne la partie d'Internet composée de sites Web, c.-à-d. de sites hébergeant des pages d'informations au format HTML, sur lesquelles on surfe au travers de liens hypertexte. Sur Internet, tous les sites ne sont donc pas des sites Web : tout site Web est un site Internet mais tout site Internet n'est pas un site Web !

    Pourquoi cette mise au point ? Pour une double raison : parce qu'un ordinateur ne peut pas aller sur Internet si les adresses de serveurs DNS ne sont pas configurées (ces adresses, fournies par les FAI via les Box ADSL, sont automatiquement configurées par le système d'exploitation de votre ordinateur) ; parce que le DNS est utile à la connexion à tout site Internet et pas seulement aux sites Web. Le DNS est donc un rouage essentiel dans le fonctionnement du réseau Internet. Mais qu'est-ce que c'est ?

     

    Il existe deux façons d'accéder à un site Internet : soit par son nom de domaine (ex. : www.google.fr), soit par son adresse IP (ex. : 64.15.116.219). Ainsi, si vous saisissez la série de quatre nombres de notre exemple dans la barre d'adresse de votre navigateur, vous allez tomber sur le site de Google France.

     

    Que s'est-il passé ? Pour simplifier, comme, sur Internet, les ordinateurs communiquent entre eux grâce au protocole TCP/IP (un empilement de deux protocoles : le TCP, chargé d'assurer l'échange de données entre les machines d'un réseau ; l'IP, chargé de l'acheminement de ces données à la bonne adresse), un serveur DNS a effectué la conversion de 64.15.116.219 en www.google.fr, et il sait le faire dans les deux sens ; ainsi, lorsqu'on tape www.google.fr, le système d'exploitation obtient du DNS l'adresse IP correspondante, 64.15.116.219, pour permettre au navigateur d'initier la connexion à l'ordinateur qui héberge le site de Google. C'est pour des raisons de commodité que www.google.fr et 64.15.116.219 sont associés par le DNS : cela permet aux internautes de retenir et taper le nom de domaine plutôt que l'adresse IP.

     

    Le DNS (Domain Name System) désigne le protocole qui sert à résoudre les noms de domaine, c.-à-d. à les convertir en adresses IP, ou, ce qui revient au même, à faire l'association entre les noms de domaine et les adresses IP. Il utilise le port 53.

     

    Un serveur DNS est un ordinateur qui exécute un programme chargé d'effectuer cette conversion ; on parle de résolution de noms de domaine. En informatique, un serveur est un hôte qui exécute un programme fournissant des infos ou des services à un client  ; à l'inverse, un client  est un hôte qui exécute un programme recevant des infos ou des services d'un serveur. Un hôte  (host, en anglais) désigne toute machine connectée à un réseau et disposant d'une adresse IP pour communiquer : ordinateurs, imprimantes réseau, routeurs, smartphones, etc.

     

    Par défaut, le système d'exploitation utilise les serveurs DNS fournis par votre fournisseur d'accès à Internet. Pour bloquer de manière générique les sites pornographiques et autres sites indésirables, il faut alors éditer les paramètres réseau de l'ordinateur de manière à changer le DNS en mettant à la place les adresses IP des serveurs DNS spécialisés suivants :

     

    DNS préféré (primaire): 208.67.222.123 ou 199.85.126.30

    DNS auxiliaire (secondaire) : 208.67.220.123 ou 199.85.127.30

     

    (Ce sont des adresses de filtre parental appartenant respectivement à OpenDNS et Norton ConnectSafe)

     

    Voici comment les éditer sous Windows, Mac OS et Linux.

     

     

    1. Changer le DNS sous Windows

     

    1) Ouvrez le Centre Réseau et partage (quelle que soit la version de Windows, il suffit de cliquer droit sur l'icône du réseau, située près de l'horloge, dans la zone de notifications, ou bien de dérouler le menu Démarrer > Panneau de configuration / Paramètres > Réseau et Internet...), puis cliquez sur Modifier les paramètres de la carte  :

     

     

    Ou bien tapez la commande ncpa.cpl dans Exécuter ou dans la zone de recherche située près du bouton Démarrer, ce qui aura pour effet de lancer l'utilitaire de configuration TCP/IP  :

     

    2) Cliquez droit sur votre carte réseau, puis cliquez gauche sur Propriétés :

     

     

    3) Cliquez sur la ligne Protocole Internet version 4 (TCP/IPv4), puis sur Propriétés (attention, cliquez sur le texte et non dans la case, qu'il ne faut surtout pas décocher) :

     

     

    4) Cochez la case Utiliser l'adresse de serveur DNS suivante, saisissez les adresses des serveurs DNS filtrantes, cochez la case Valider les paramètres en quittant,  cliquez sur Ok, puis deux fois sur Fermer:

     

    changer le DNS sous windows

     

    Désormais, vous ne pourrez plus accéder aux contenus pour adultes ou à ceux jugés dangereux pour les enfants. Le message suivant s'affichera : « OpenDNS : This domain is blocked due to content filtering

     

    Remarque. — Si, après le changement du DNS, vous remarquez que le blocage n'a pas fonctionné, pensez à vider le cache DNS en tapant la commande ipconfig /flushdns dans l'invite de commande. Si la commande génère l'erreur «Impossible de vider le cache DNS : La fonction a échoué lors de l'exécution», suivez ce tuto.

     

    >> Retour au sommaire

     

    2. Changer le DNS sous Mac (OSX)

     

    1. Cliquez sur l'icône des préférences système, dans la barre des tâches, puis sur l'icône Réseau :

     

     

    2. Cliquez sur l'onglet Avancé :

     

     

    3. Cliquez sur l'onglet DNS, puis sur le bouton + pour ajouter une adresse de serveur DNS. Saisissez alors les adresses filtrantes, puis cliquez sur Ok :

     

    changer le DNS sous mac os

     

    4. Terminez la configuration en cliquant sur Appliquer :

     

     

    Remarque. — Si, après le changement du DNS, vous remarquez que le blocage n'a pas fonctionné, pensez à vider le cache DNS en tapant la commande sudo discoveryutil mdnsflushcache;sudo discoveryutil udnsflushcaches;say flushed dans le Terminal.

     

    >> Retour au sommaire

     

     

    3. Changer le DNS sous Linux (Ubuntu)

     

    1) Cliquez sur l'icône qui symbolise le réseau (dans la zone de notifications), puis sur Modification des connexions :

     

     

    2) Choisissez la connexion à modifier (filaire ou wifi), puis cliquez sur Modifier :

     

     

    3) Cliquez sur l'onglet Paramètres IPv4, sélectionnez l'option Adresses automatiques uniquement (DHCP), saisissez les adresses DNS filtrantes dans le champ Serveurs DNS en prenant soin de les séparer par une simple virgule ou par une espace (mais pas les deux!), puis cliquez sur le bouton Enregistrer pour valider les changements :

     

    changer le DNS sous ubuntu linux

     

    4) Cliquez sur Fermer :

     

     

    Désormais, si vous vous connectez sur un site jugé nocif pour les enfants, la connexion échouera :

     

     

    Remarque. — Si, après le changement du DNS, vous remarquez que le blocage n'a pas fonctionné, pensez à vider le cache DNS en tapant la commande sudo /etc/init.d/dns-clean start dans le Terminal.

     

    >> Retour au sommaire

     

    II. — Modification du fichier hosts

     

    La modification du fichier hosts est la solution à adopter si vous souhaitez cibler un ou des sites en particulier, par exemple Facebook.

     

    Le fichier hosts est une sorte de carnet d'adresses où sont inscrits les les noms de domaine  et les adresses IP correspondantes. Il joue le même rôle que le serveur DNS et, à ce titre, peut être considéré comme un DNS local, d'autant qu'il est présent sur chaque ordinateur, quel qu'en soit le système d'exploitation. Les navigateurs le consultent avant de recourir aux serveurs DNS pour accéder à Internet : si l'adresse IP du site Internet s'y trouve, la connexion est immédiatement établie ; si l'IP du site ne s'y trouve pas, le système d'exploitation fait une requête DNS pour que le serveur DNS la lui indique afin que le navigateur établisse la connexion ; si un site s'y trouve avec l'IP 127.0.0.1, la connexion échoue.

     

    127.0.0.1, c'est l'adresse de bouclage (loopback, en anglais) ou du localhost (hôte local), c-à-d. qu'elle renvoie vers la carte réseau de l'ordinateur : au lieu que la connexion sorte vers Internet, elle est redirigée vers votre propre machine. D'où l'échec de la connexion à Internet.

     

    Une fois que le fichier hosts est ouvert, pour le modifier, il faut saisir ligne par ligne les sites à bloquer en respectant la syntaxe suivante :

     

    127.0.0.1[Touche TAB du clavier]www.site-à-bloquer.com

     

    Windows, Mac OS et Linux utilisent tous ce fichier pour gérer les connexions Internet. Voici comment le modifier.

     

    1. Modifier le fichier hosts sous Windows

     

    1) Ouvrez le Bloc-notes de Windows en mode administrateur. Pour ce faire, tapez "Bloc-notes" dans le moteur de recherche de Windows (près du menu Démarrer), cliquez droit sur l'icône du Bloc-notes, puis sélectionnez Exécuter en tant qu'administrateur :

     

     

    2) Déroulez le menu Fichier > Ouvrir : 

     

     

    3) Changez, au bout du champ Nom de fichier,  l'affichage des extensions en choisissant Tous les fichiers (*.*) à la place de Fichiers texte (.txt). Pour ce faire, il suffit de cliquer sur la flèche orientée vers le bas :

     

     

    4) Parcourez l'arborescence du disque dur à la recherche du fichier hosts. En voici le chemin d'accès:

    C:\Windows\System32\drivers\etc\hosts

    Une fois que vous l'avez trouvé, cliquez une fois dessus, puis cliquez sur Ouvrir :

     

     

    5) Editez le fichier hosts en mettant l'IP de la boucle locale 127.0.0.1 suivie de l'URL à bloquer. Commencez par aller à la ligne après la ligne ::1 localhost, puis allez à la ligne pour chaque site à bloquer. A noter que l'IP et l'URL doivent être séparées par l'espace de tabulation (voir la touche de tabulation de votre clavier).

     

     

     

    6) Enregistrez les modifications, puis fermez le Bloc-notes :

     

     

    Désormais, les sites pornographiques figurant sur l'image de l'étape 5 sont bloqués. Ce n'est qu'un exemple pour montrer comment saisir une liste de sites à bloquer. Si vous avez modifié le DNS comme expliqué dans la première partie, vous n'avez plus besoin d'inscrire ces sites dans le fichier hosts. Si, pour une raison quelconque, vous préférez les y inscrire vous-même, vous les trouverez facilement en épluchant les dix premières pages de résultats de Google ou en les piochant dans les listes, annuaires et autres référenceurs de sites porno comme ceux ci-après (ne pas oublier de les bloquer aussi) :

    http://www.porngatherer.com/

    http://toppornsites.com/

    http://steezylist.com/

    http://www.zweiporn.com/

    http://theporndude.com/

     

    Remarque. — S'il vous est impossible de modifier le fichier hosts pour manque de droits d'administrateur, suivez ce tuto.  

     

    >> Retour au sommaire

     

     

    2. Modifier le fichier hosts sous Mac OS

     

     1) Lancez le Terminal (Applications > Utilitaires > Terminal) :

     

     

     2) Exécutez la commande sudo pico /etc/hosts puis saisissez le mot de passe :

     

     

    3) Insérez, ligne par ligne, les sites Internet à bloquer, puis enregistrez les modifications via la combinaison de touches Ctrl + O Validez l'enregistrement, quittez Pico via la combinaison de touches Ctrl + X puis fermez le Terminal.

    Pour la saisie des sites, respectez la graphie suivante :

    127.0.0.1[Touche de tabulation]www.site-à-bloquer.com

    Dans notre exemple, nous avons bloqué www.facebook.com

     

     

     

    >> Retour au sommaire

     

     

    3. Modifier le fichier hosts sous Linux (Ubuntu)

     

    1. Ouvrez le Terminal (Ctrl + Alt + T), pour exécuter la commande :

    sudo xdg-open /etc/hosts

    Validez et saisissez le mot de passe :

     

     

     

    2. Saisissez l'URL du ou des sites à bloquer sur chaque ligne, en les précédant de 127.0.0.1 et en mettant une espace de tabulation avec l'URL comme suit :

    127.0.0.1[Touche de tabulation]www.facebook.com

    Cliquez sur le bouton Enregistrer, puis fermez successivement la boîte de dialogue et le terminal :

     

    modifier le fichier hosts sous Ubuntu

     

     

    >> Retour au sommaire

     

     

    III.  — Conclusion : quelle est la solution idéale ?

    On peut donc, sans logiciel, facilement bloquer les sites indésirables de son choix pour protéger les enfants. Si l'utilisation d'un serveur DNS est une solution efficace, elle peut toutefois s'avérer insuffisante à cause, entre autres, de l'émergence quotidienne de nouveaux sites. C'est pourquoi la solution idéale, c'est de combiner les deux solutions, c.-à-d.  modifier le DNS, puis ne pas hésiter à modifier le fichier hosts en cas de besoin. En effet, la modification du fichier hosts vous permettra d'être réactif en cas de retard d'indexation du serveur DNS ; vous bloquerez alors plus rapidement les nouveaux sites, sans compter que vous pallieriez d'éventuelles défaillances du filtre DNS, notamment au cas où certains sites n'auraient pas été intégrés au filtre.

     

    Par ailleurs, outre la réactivité, la seconde solution possède un autre atout : le fichier hosts peut aussi être modifié non pas pour bloquer un site, mais pour le rediriger vers un autre jugé plus bénéfique. Par exemple, au lieu de bloquer carrément Facebook ou le site de jeux préféré de votre enfant, vous pouvez le rediriger vers un site pédagogique comme Académie en ligne. Pour ce faire, ouvrez un shell (console DOS sous Windows, Terminal sous les dérivés d'Unix que sont Linux ou Mac OS), et exécutez la commande :

    ping  www.site-de-redirection.com

     

    Vous verrez alors défiler des informations au milieu desquelles figure l'adresse IP du site « pingué » (lire pi-ngué). C'est cette adresse qu'il faudra mettre à la place de 127.0.0.1. Pour Facebook et le site de l'Académie en ligne, ça donnera :

    195.220.181.70     www.facebook.com

    195.220.181.70     www.facebook.fr

     

    Quand l'enfant va tenter de se connecter à Facebook, c'est le site Web de l'Académie en ligne qui s'affichera. Magique, n'est-ce pas ?

     

    Si, pour une raison quelconque, vous ne souhaitez plus exercer de contrôle parental, sachez qu'il est toujours possible de revenir en arrière. Pour ce faire, il vous suffit de supprimer les lignes que vous avez rajoutées dans le fichier hosts et d'enregistrer les modifications ; s'il est corrompu, vous pouvez le restaurer.

    Concernant les serveurs DNS :

    • Sous Windows, il suffit de choisir l'option qui permet d'obtenir les adresses des serveurs DNS automatiquement à l'étape 4.1
    • Sous Mac OS, il suffit de supprimer les serveurs DNS enregistrés à l'étape 3.3, puis de valider les changements (Ok + Appliquer)
    • Sous Ubuntu, il suffit de choisir Automatique (DHCP) à l'étape 3.2, de supprimer les adresses présentes dans le champs DNS supplémentaires, d'enregistrer, puis de redémarrer le PC.

     

    Si les deux solutions présentées ici sont d'une efficacité redoutable et jamais démentie, rien ne vous empêche, en supplément, de vous tourner vers les navigateurs pour enfants comme Potati, qui propose une interface et des ressources adaptées aux enfants de 3 à 12 ans.

     

    Pour les parents férus de l'informatique, il est même possible de sécuriser le réseau domestique entier en configurant le routeur ou en passant par le service FamilyShield, d'OpenDNS. Exemple, ici, avec le routeur de la Freebox. Connectez-vous sur l'interface d'administration de la box en tapant 192.168.0.254 (ou www.mafreebox.fr) dans la barre d'adresse d'un navigateur Internet. Dans la partie Réseau local, double-cliquez sur l'onglet DHCP, reléguez l'adresse du serveur DNS 192.168.0.254 en dernière position et mettez à la place les DNS de votre choix (au moins 2), cliquez sur Appliquer puis Ok pour valider les modifications.

     

     

    Si votre FAI ne permet pas de modifier les serveurs DNS, achetez un routeur Wifi pour y configurer les DNS de votre choix. Inspirez-vous de l'étape 8 du tutoriel sur la configuration d'un routeur comme point d'accès. 

     

    Enfin, notez qu'il est aussi possible de modifier le DNS non pas pour exercer un contrôle parental, mais pour contourner une censure exercée par les FAI ou ordonnée par les autorités politiques. Ou pour surfer plus rapidement. Pour ce faire, tournez-vous vers les serveurs DNS publics répertoriés ci-après :

    • http://pcsupport.about.com/od/tipstricks/a/free-public-dns-servers.htm
    • https://www.serversopennicproject.org

    Par exemple, vous pouvez utiliser les adresses de serveurs DNS 199.85.126.10 et 199.85.127.10, de Norton ConnectSafe, pour surfer en toute sécurité (filtres anti-malwares, phishing et scams), ou les adresses 208.67.222.222 et 208.67.220.220, d'OpenDNS, pour surfer plus rapidement.

     

  • Saturday 13 February 2016 - 15:56

    Vagrant.png Je souhaite proposer aux différents développeurs d'un projet, un moyen simple d'avoir un environnement le plus proche possible du serveur de production, que ce soit au niveau de la distribution, mais également des versions des outils installés ( Php, Mysql MariaDb, MongoDb, python, uwsgi, etc ... ). Le but étant de mettre en place l'environnement en un minimum de temps possible, mais aussi de permettre aux développeurs de rester sur leur système d'exploitation préféré. (Linux Mac ou même Windows) pour développer.

    Première approche

    Peut être (certainement) dû à l'effet de mode, j'ai commencé mes tests avec Docker. Ce dernier permet ce genre de chose, mais je trouve la façon de faire un peu complexe ( Liaisons entre les conteneurs, maintenabilité de l’ensemble etc ) , juste pour avoir un environnement de dev ! Il est vrai que cette techno est vraiment intéressante, le partage de conteneurs avec les autres utilisateurs, le versionning grâce à l'union FS et tout ça sans exploser la conso d'espace disque.

    Plus simple, vagrant

    Puis un ami m'a parlé de Vagrant, une techno que je n'avais pas encore étudié plus que ça. Pour résumer, il n'y a rien de magique, c'est "juste" un écosystème de gestion de VMs , basé sur virtualbox, qui permet de créer/manager des VMs à partir de systèmes de bases disponibles sur le net ( catalogue Vagrant Boxes ) et surtout de provisionner ces VMs.

    C'est là que ça devient intéressant, on a donc un système de gestion de VMs compatible Linux,Windows,Mac, permettant une gestion de VMs très efficace, start, stop, freeze, resume, reload etc ... mais surtout, vous permet de monter une VMs configurée selon vos souhaits et ce de plusieurs façons.

    Testons avec un simple environnement LAMP

    Je vais volontairement aller vite sur les options disponibles, la doc en ligne de Vagrant étant extrêmement clair, je ne vais pas la copier/coller ici

    Commencez par installer Vagrant ( pas besoin d'explication pour cette étape triviale )

    Système de base

    Nous allons travailler sur une Debian Jessie . Commençons par créer un répertoire pour notre projet ( je le nomme lamp )

    mkdir lamp && cd lamp
    vagrant init debian/jessie64
    

    Dans notre répertoire lamp, nous trouvons maintenant un fichier de configuration de notre environnement nommé Vagrantfile. Nous allons bientôt mettre les mains dedans .

    Capture_d_e_cran_2016-02-13_a__14.53.05.png

    Le téléchargement est terminé ? oui ? très bien lançons notre "machine" et allons faire un tour dedans .

    Lancer la VM et tour du propriétaire

    vagrant up
    

    Une fois la machine lancée, prenons la main en ssh

    vagrant ssh
    

    Vous voilà connecté à notre machine. Le système est nu. Avez-vous remarqué au lancement de la vm, ces deux lignes :

    ==> default: Installing rsync to the VM...
    ==> default: Rsyncing folder: /Users/moi/lamp/ => /vagrant
    

    Par défaut, vagrant synchronise le répertoire local ( dans notre cas /Users/moi/lamp/ ) avec le répertoire /vagrant présent à la racine du système de fichiers de la VM.
    Nous pouvons bien entendu ajouter d'autres répertoires ( voir le fichier de configuration Vagrantfile ligne: config.vm.synced_folder "../data", "/vagrant_data" ).

    Retournons sur notre machine hôte ( Cmd + D )

    LAMP

    Linux ( Ok ça c'est fait ), Apache ( à installer ), Mysql/MariaDB ( à installer ), Php ( à installer ).
    Bon on sait ce qu'il nous reste à faire. Mettons les quelques lignes nécessaires à l'installation de ces derniers dans un script bash. Éditons donc dans le répertoire lamp, un fichier que nous nommerons bootstrap.sh

    Voici le contenu:

    #!/usr/bin/env bash
    
    #Login par defaut : root et pwd : rootpass ( à modifier bien évidemment )
    debconf-set-selections <<< 'mysql-server-5.5 mysql-server/root_password password rootpass'
    debconf-set-selections <<< 'mysql-server-5.5 mysql-server/root_password_again password rootpass'
    
    apt-get update
    apt-get install -y apache2
    apt-get install -y mysql-server
    apt-get install -y php5 php5-mysql php-pear
    
    
    if ! [ -L /var/www ]; then
      rm -rf /var/www
      ln -fs /vagrant /var/www
    fi
    

    Éditons ensuite le fichier Vagrantfile, et en dessous de la ligne config.vm.box = "debian/jessie64" ajouter :

    config.vm.provision :shell, path: "bootstrap.sh"
    

    Ne reste plus qu'à provisionner la VM

    vagrant reload --provision
    

    Capture_d_e_cran_2016-02-13_a__14.55.18.png

    Vous voilà avec un lamp de base, mais comment communiquer facilement avec ?

    Le réseau

    Il y a plusieurs solutions selon votre besoin.

    • Natter un port de votre machine hôte vers la VM
    • Créer un bridge avec une des vos interfaces pour que la VM soit présente comme n'importe quel autre poste sur votre réseau local
    • Créer un réseau privé permettant à la machine hôte d’accéder à la VM , tout en restant inaccessible depuis l'extérieur pour les autres postes ( solution retenu dans mon cas ).

    Éditons le fichier de configuration pour activer ce mode. dé-commenter/compléter cette ligne :

    config.vm.network "private_network", ip: "192.168.33.10"
    

    Relançons notre vm

    vagrant reload
    

    Testons notre serveur Apache, ouvrez un navigateur, et entrez l'ip de votre vm : http://192.168.33.10

    Et là ... vous avez un magnifique "404 not found" !!!.
    Normal, le vhost par défaut d'apache cherche ses sources dans le répertoire /var/www/html . et si vous avez bien observé, dans le fichier bootstrap.sh, nous avons ces lignes :

    if ! [ -L /var/www ]; then
      rm -rf /var/www
      ln -fs /vagrant /var/www
    fi
    

    Qui a pour but de mettre le répertoire "vagrant" ( partagé entre l'hôte et la vm ) accessible ( via un lien symbolique ) vers /var/www . Il nous suffit donc de créer un répertoire nommé html dans notre répertoire de projet, lamp ( sur la machine hôte ).

    Donc, sur notre machine hôte, dans notre répertoire lamp :

    mkdir html && cd html
    echo '<?php echo phpinfo();' > index.php
    

    Relançons notre vm

    vagrant reload
    

    Maintenant allons rafraichir notre navigateur . Vous devriez avoir la belle page de phpinfo qui s'affiche . Capture_d_e_cran_2016-02-13_a__13.54.36.png

    NFS

    C'est magnifique, mais si vous ajoutez des fichiers depuis la machine hôte dans le répertoire html, ces derniers ne seront pas accessibles ( synchronisés ) sur la VM. Il faudra pour celà lancer la commande

    vagrant rsync-auto
    

    Pas très pratique. Je me suis donc tourné vers le protocole NFS qui est pris en charge en natif avec vagrant ( attention.. ne fonctionne pas avec Windows ).
    Éditons notre fichier Vagrantfile et ajoutons ces quelques lignes avant de relancer notre vm

      config.vm.synced_folder ".", "/vagrant",
        :nfs => true
    

    Relançons la VM

    vagrant reload
    

    Vagrant va vous demander le mot de passe sudo, afin de modifier pour le fichier /etc/exports.
    Afin que le mot de passe ne soit pas demandé à chaque démarrage, vous pouvez soit:

    • Ajouter des règles dans le fichier de config sudo ou ...
    • Renseigner une bonne fois pour toute votre fichier exports et indiquer à vagrant qu'il n'a rien à faire . ( voir les options NFS ).

    Conclusion

    Voilà pour le premier tour d'horizon de Vagrant, nous avons dans nos main un système de gestion de VM bien ficelé, doté de nombreuses autres options, ( snapshots/restauration, share, ... ) je ne peux que vous conseiller d'aller faire un tour sur le site officiel pour découvrir les différentes options qui s'offrent à vous. Enfin, pour gérer vos environnements, je vous conseil de versionner votre projet ( dossier lamp dans notre exemple ) avec Git par exemple, car c'est grâce aux fichiers de ce répertoire que vous serez en mesure de remonter/partager une VM configurée à l'identique sans aucun effort et en un minimum de temps.

  • Thursday 14 April 2016 - 15:37

    Configurer Gitlab sur un sous-domaine sans se retrouver avec du mixed content est assez chiant pour être franc. J’ai pas mal tâtonné, soit je me retrouvais avec une erreur 502 Bad Gateway soit Gravatar passait par le protocole HTTP. J’ai fini par trouver la solution et je souhaitais la partager dans un mémo.

    Dans ce billet je pars du principe que :

     

    Configurer Gitlab sur un sous-domaine NGinx

    Configuration de Gitlab

    Commencez par éditer la configuration de Gitlab

    sudo nano /etc/gitlab/gitlab.rb

     

    Ajoutez et/ou modifiez les lignes suivantes

    external_url 'https://git.votre-domaine.tld' # A remplacer par le sous-domaine que vous souhaitez utiliser
    nginx['listen_addresses'] = ['192.168.1.2'] # IP du serveur GitLab
    nginx['listen_port'] = 8888 # port de votre choix
    nginx['listen_https'] = false # Vous lisez bien, https false

     

    Appliquez les changements de configuration

    sudo gitlab-ctl restart

     

     

    Configuration de NGinx

    Vous allez maintenant devoir créer un virtual host pour votre sous-domaine

    sudo nano /etc/nginx/sites-enabled/git.votre-domaine.tld

     

    Collez la configuration suivante mais surtout n’oubliez pas de l’éditer selon vos besoins

    upstream gitlab {
     server 192.168.1.2:8888;
    }
    
    
    server {
     listen 80;
     server_name git.votre-domaine.tld;
     return 301 https://git.votre-domaine.tld$request_uri;
     }
    
    
    server {
     listen 443 ssl http2; 
     server_name git.votre-domaine.tld
     root /dev/null;
    
     ssl_certificate /etc/letsencrypt/live/votre-domaine.tld/fullchain.pem;
     ssl_certificate_key /etc/letsencrypt/live/votre-domaine.tld/privkey.pem;
     ssl_protocols TLSv1.2;
     ssl_dhparam /etc/nginx/ssl/dh4096.pem;
     ssl_prefer_server_ciphers on;
     ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256";
     ssl_ecdh_curve secp384r1;
    
     add_header X-Content-Type-Options nosniff;
     add_header X-XSS-Protection "1; mode=block";
    
     # A modifier en fonction de la taille des fichiers que vous uploadez
     client_max_body_size 20m;
     
     location / {
     proxy_read_timeout 300;
     proxy_connect_timeout 300;
     proxy_redirect off;
     
     proxy_set_header X-Forwarded-Proto $scheme;
     proxy_set_header Host $http_host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-Ssl on;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header X-Frame-Options SAMEORIGIN;
     
     proxy_pass http://gitlab;} 
    
    }

     

    Vous pouvez maintenant tester votre configuration et si aucune erreur n’apparaît rechargez la configuration NGinx

    sudo service nginx reload

     

    Voilà vous avez terminé de configurer GitLab sur un sous-domaine et vous devriez maintenant pouvoir y accéder via git.votre-domaine.tld

     

    Cet article Configurer GitLab sur un sous-domaine NGinx est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Friday 16 December 2016 - 17:35
  • Wednesday 29 August 2018 - 11:58

    RSSHub is a lightweight and extensible RSS feed aggregator, it's able to generate feeds from pretty much everything.
    Permalink

  • Wednesday 29 August 2018 - 15:28
    Au cas où vous ne sachiez pas quoi faire Samedi 15 Septembre 2018, venez participer au PowerShell Saturday Paris...
  • Wednesday 29 August 2018 - 16:09
  • Wednesday 29 August 2018 - 22:37

    Plop! Juste un petit billet aide-mémoire sur les changements de DNS, car j’étais un brin emmerdé. Habituellement je passais toujours par l’outil de configuration dédié, NetworkManager, mais pour une raison étrange cette fois ça ne fonctionnait pas (du moins sur IPv4). Ce n’est peut-être plus lui qui gère ça, j’ai peut-être fais ma quiche, mais pour être franc j’ai la flemme de chercher des plombes. En résumé voilà donc ce que j’ai fait.

    Pour IPv4 j’ai simplement édité le fichier qui va bien à l’aide d’un petit :

    sudo gedit /etc/dhcp/dhclient.conf

    et ajouté la ligne suivante avant d’enregistrer les modifs :

    supersede domain-name-servers 208.67.222.222,208.67.220.220;

    Pour revenir en arrière éditez et supprimez cette ligne ou mieux encore, commentez-la avec un # pour la garder sous le coude.

    Pour IPv6 je suis passé par NetworkManager  et ça a fonctionné :

    Après une reboot j’ai vérifié à l’aide d’un petit :

    nmcli dev show |grep DNS

    et voilou. Je passe bien désormais par OpenDNS.

    Ce n’est pas grand-chose, mais ça peut servir ou si vous avez mieux à proposer, c’est bon à prendre.

    Bisous.

  • Thursday 30 August 2018 - 09:55