Après des années sans activités sur le blog, petite série d’articles dédiée au retrocomputing. Le premier épisode concerne le redémarrage de ma Sun SPARCclassic.
Cette belle petite station m’a gracieusement été offerte aux alentours de 2007 par la responsable informatique de mon école d’ingénieurs. Les salles informatiques de l’école étaient équipées de ces machines au début des années 90, avant d’être remplacées par des PC. Celle-ci avait survécu.
Depuis longtemps, j’ai l’habitude de ripper mes CD audio avec Exact Audio Copy, éditer les tags et la pochette plus ou moins manuellement (Exact Audio Copy puis Mp3tag), ensuite les déplacer sur mon NAS à l’endroit qui va bien pour qu’ils soient enfin ajoutés à mon audiothèque.
Je vous propose ici une méthode beaucoup moins chronophage et entièrement automatisée sous FreeNAS basée sur abcde.
Vous insérez le CD dans le NAS (s’il dispose d’un lecteur) : il sera automatiquement encodé en FLAC et les fichiers résultants tagués (avec la pochette), nommés, puis déplacés dans le bon répertoire, et enfin le CD éjecté.
Comme je l’avais indiqué dans mon précédent billet concernant la fibre Orange, l’IPv6 fonctionne comme l’IPv4, avec DHCPv6. Il faut de la même façon qu’en IPv4, envoyer des requêtes DHCPv6 en fournissant les bonnes valeurs d’options au serveur Orange : l’option 11 (AUTH), l’option 15 (USER_CLASS) et l’option 16 (VENDOR_CLASS).
Ceci, afin d’obtenir une délégation de préfixe IPv6 : un /56 entièrement routé jusqu’à l’équipement du client et utilisable comme bon lui semble.
Jusqu’à maintenant, seul dibbler fonctionnait (un peu par hasard), mais il est maintenant possible d’utiliser dhcpcd proprement, grâce à Roy Marples, son développeur, qui a implémenté toutes les fonctionnalités manquantes.
Depuis maintenant deux semaines, brimbelle.org a migré sur un accès fibre Orange, en remplacement de mon ancien accès ADSL Free. Suite à une innondation, les débits sur ma ligne étaient devenus catastrophiques (autour de 300kb/s d’upload).
Comme l’objectif est de s’amuser un peu et d’héberger ma petite infrastructure sur du matériel et logiciel maîtrisé, je me suis totalement débarrassé de la Livebox, remplacée par mon routeur OpenBSD (à base de PC Engines APU 1C4), branché directement derrière l’ONT.
Je ne vais pas réécrire les nombreux guides déjà présents sur Internet, l’objectif est de donner quelques astuces pour profiter de toutes les fonctionnalités.
Depuis les révélations de Snowden, Heartbleed en 2014 et l’actualité en général… la cryptographie et en particulier les protocoles SSL/TLS connaissent à juste raison une généralisation quelque soit le site web, service, application, etc.
Dans cet article, je vais présenter une check-list des bonnes pratiques lorsque l’on administre un serveur web sécurisé.
Je ne détaillerai pas toutes les différentes techniques mises en oeuvre : d’innombrables sites ou blogs le font très bien. Je vais en revanche lister les point importants pour rendre le protocole TLS particulièrement robuste. Ceci avec des exemples de configuration pour le serveur HTTP NGINX.
Ce soir, suite à un plantage en cours de « pkg_add -u », je dois ré-installer l’ensemble de mes packages. J’aurais sans doute pu l’éviter, mais « pkg_check » paraît interminable. J’en profite alors pour faire un tris des différents ports que j’ai sur ma machine, et je tombe sur mon vieux port d’ioquake3 1.35.
Comme je m’y attendais, celui-ci ne compile plus, l’infrastructure des ports d’OpenBSD a comme toujours beaucoup évolué. Après quelques tentatives rapides, je me dis qu’il serait préférable de repartir from scratch, avec les dernières sources d’ioquake3. Et là, merveilleux… en une poignée de commandes j’ai ioquake3 qui démarre sur mon OpenBSD -current.
Je fais partie des rares heureux à avoir eu la chance de pouvoir commander un Google Nexus 4 dans le petit laps de temps pendant lequel les ventes ont été ouvertes en France.
Ce que je vous propose n’est pas un test complet de l’appareil (il en existe des dizaines sur le net), mais mon ressenti après presque 3 semaines d’utilisation.
Du fait du fonctionnement du protocole TCP, il arrive très souvent que lorsque l’on télécharge et reçoit simultanément plusieurs fichiers, la vitesse soit fortement réduite, bien en deçà des capacités de notre connexion internet. Ce comportement est très amplifié par les connexions ADSL, par nature asymétriques.
Je propose dans cet article une manière efficace et rapide de corriger cela sur une passerelle OpenBSD à l’aide de quelques règles PF en utilisant une première approche avec le moteur de priorisation ALTQ et la nouvelle souplesse des règles match depuis la version 4.6, puis en utilisant le nouveau moteur de priorisation intégré disponible à partir de la version 5.1.
Dans cet article, je vais présenter la marche à suivre pour configurer une passerelle VPN utilisant les protocoles L2TP/IPsec sur un système OpenBSD (en version 5.1). Cette passerelle vous permettra de vous y connecter à l’aide de votre smartphone Android (testé avec Android 4.0 ICS) ou iPhone, puisque ces terminaux supportent maintenant nativement ces types de VPN.
Le protocole L2TP (Layer 2 Tunneling Protocol) est un protocole de tunneling à la popularité grandissante, car supporté nativement par de nombreux OS : Windows, MacOS X, Linux, etc. mais également par les plate-formes mobiles populaires que sont Android et iOS. De plus, L2TP permet aisément de réaliser des VPN au dessus d’infrastructures existantes puisqu’il est transporté dans des paquets IP/UDP sur le port 1701. Dans la suite du document, nous allons utiliser le nouveau daemon npppd(8), inclus dans le système de base d’OpenBSD.
Afin de rendre le VPN plus sûr, la méthode est de chiffrer le trafic L2TP dans un tunnel IPsec. Ici rien de bien nouveau, nous nous reposerons sur l’extrême simplicité de configuration offerte par OpenBSD.
En ces temps où toutes économies sont bonnes à prendre, je me suis attelé à mettre en place chez moi un « vrai » accès IPv6. Par vrai, je n’entends pas un accès natif (ce serait trop beau, aucun opérateur grand public français ne le propose à l’heure actuelle hormis Nerim dont l’offre est tout de même plus orientée vers les TPE), mais un accès offrant un espace d’adressage correct, ie. un /48.
Même Free qui propose de l’IPv6 à ses clients ne propose qu’un semblant d’accès natif, avec du 6rd mais il se limite à donner un /64.
Dans ce billet, je vais donc m’attacher à présenter les grandes lignes pour mettre en place à la maison (et même ailleurs) un accès IPv6 avec différents sous-réseaux, en utilisant un tunnel broker. Pour y arriver je présenterai des exemples de configuration pour une passerelle OpenBSD, ainsi que des astuces.