[Mémo] Imposer des paramètres Mozilla Firefox pour un poste en entreprise

0

Pour éviter de chercher à chaque fois, et pour vous faire profiter de l’occasion, voici un petit mémo qui compile et filtre une partie de la littérature (souvent en anglais) à propos de la gestion de configuration des profils Mozilla Firefox, notamment en entreprise.

D’abord le point d’entrée

Ce fichier porte une trace forte héritée du long passé de Firefox et les recommandations pour son nom et son emplacement ont évoluées plusieurs fois. Pour les branches récentes (soit l’ESR actuelle (branche 52) et la précédente (branche 45), ça fonctionne), on utilisera un fichier « C:\Program Files\Mozilla Firefox\defaults\pref\autoconfig.js ». Ce fichier est le déclencheur pour la configuration forcée de Firefox. Bien évidemment, vous devrez adapter le chemin d’accès en fonction de votre contexte, sachant que ce qui est dit ici, et illustré dans un contexte Microsoft, fonctionne parfaitement en environnement Linux (voir les chemins d’accès courants en référence).

Dans ce fichier, on trouvera seulement trois lignes indiquant globalement l’utilisation d’un fichier de configurations forcées.

// Utilisation de configurations forcées
pref("general.config.filename", "mozilla.cfg");
pref("general.config.obscure_value", 0);

Notez que le commentaire en première ligne est obligatoire, quand bien même il serait vide (donc juste deux slashs).

De plus, remarquez l’apparition en clair du nom de fichier que nous allons aborder, ici « mozilla.cfg ». Il pourrait tout aussi bien s’appeler « monentreprise.cfg », le fonctionnement n’en serait pas affecté.

Ensuite le fichier de configuration lui-même

Ici aussi, je préfère ajouter une ligne de commentaire au début. Dans ce cas, c’est plutôt recommandé suite à un vieux bug (antérieur à la version 22). C’est normalement corrigé depuis bien longtemps mais on l’a gardé plus par habitude (commentez vos codes !) que par nécessité. Moi-même j’ai cédé et je l’ai gardé dans mes cas d’usage.

Le fichier en question, que nous appellerons « mozilla.cfg » pour être en phase avec le fichier précédent, se place directement dans « C:\Program Files\Mozilla Firefox\ ».

Il contient, outre le commentaire de la première ligne, et les éventuels commentaires à différents endroits de ce fichier, les configurations à effectuer.

Généralement, on appelle les trois fonctions suivantes :

  • lockPref : pour forcer une configuration (et verrouiller l’élément qui permet de la modifier dans l’interface utilisateur)
  • pref : pour écraser une configuration à chaque démarrage du navigateur
  • defaultPref : pour configurer certains paramètres lors de la création d’un profil (soit la plupart du temps à la première ouverture de Firefox)

En voici un exemple appliqué, lequel interdit l’exécution de la mise à jour automatique. Je ne recommande pas l’application de ces éléments si vous n’avez pas une politique fiable chargée du suivi de version et de la mise à jour par d’autres moyen.

// Fichier de configurations forcées
lockPref("app.update.auto", false);
lockPref("app.update.enabled", false);
lockPref("app.update.mode", 0);
lockPref("app.update.service.enabled", false);
lockPref("browser.search.update", false);

Mais on peut avoir des choses plus compliquées. Vous trouverez une référence pour aller plus loin, puisqu’après tout, c’est bien un fichier JavaScript, mais pour le coup, ça devient hors-sujet.

Et sinon

Il existe aussi un autre moyen de forcer des configurations en utilisant un fichier « user.js » dans le profil de l’utilisateur. Cela permet d’écraser les valeurs contenues dans « prefs.js » par celles de « user.js ». Cependant, un utilisateur averti saura se rendre dans son profil Firefox et modifier ou supprimer le fichier « user.js ».

Au moins, ce moyen a été cité !

Sachez qu’il existe un outil appelé CCK2 qui peut vous faciliter grandement la tâche. Mais comme je reste un adepte de la méthode manuelle (et donc formatrice), c’est celle-ci que j’ai décrite dans cet article.

L’avenir

Sachez qu’avec la version 60 ESR, Mozilla fournira un véritable outil de configuration. Difficile de dire avec précision s’il sera bien ou pas, ni comment il évoluera. Cependant l’initiative était vivement attendue depuis longtemps afin de cesser le bidouillage à base de fichiers comme indiqué ici. Affaire à suivre.

Références

[Astuce] Monter une image disque VirtualBox sous Linux

0

Introduction

J’ai besoin de transférer des fichiers lourds (quelques Gio) depuis le disque dur virtuel d’une machine VirtualBox vers la machine hôte. La machine virtuelle est sous Windows, mais les additions invités ne fonctionnent pas, et je ne désire pas modifier la configuration réseau pour mêler mon réseau local à celui de la machine virtuelle. Pour pouvoir transférer mes fichiers, je vais donc devoir monter l’image disque de ma machine virtuelle.

Émuler un périphérique bloc

Sous Linux, une manière de créer des périphériques blocs dynamiquement est de recourir au module noyau nbd. NBD est un protocole similaire à iSCSI, qui permet de créer des périphériques blocs à partir d’un serveur. On charge le module nbd avec la commande suivante :

sudo modprobe nbd max_part=8

Vous devriez voir apparaître plusieurs entrées nbd0, nbd1, etc. dans le répertoire/dev.

On cherche à faire de notre image disque VirtualBox un périphérique bloc, et pour ce faire, nous allons utiliser le serveur NBD qemu-nbd (sur certaines distributions, il est contenu dans un paquet qemu-utils). On le lance ainsi :

sudo qemu-nbd --connect=/dev/nbd0 monimagedisque.vdi

Si vous inspectez encore une fois le répertoire /dev, de nouvelles entrées sont arrivées pour représenter les différentes partitions contenues dans l’image disque, sous la forme nbd0p0, nbd0p1, etc.

Monter les partitions

Dans mon cas l’image contient deux partitions (la première contient le bootloader, la seconde l’OS et mes données), et je ne vais monter que la seconde (nbd0p1). On commence par créer un dossier dans lequel sera monté la partition :

sudo mkdir /mnt/vbpart1

Ensuite on peut monter la partition avec la commande mount :

sudo mount /dev/nbd0p1 /mnt/vbpart1

Si la commande mount s’exécute correctement, vous devriez pouvoir accéder aux fichiers de la partition dans le point de montage que vous avez configuré.

Démonter les partitions et arrêter le serveur nbd

La procédure à suivre se déroule en deux étapes. D’abord on démonte la ou les partitions montées :

sudo umount /dev/nbd0p1

Une fois toutes les partitions démontées du périphérique nbd0, on peut procéder à l’extinction du serveur NBD :

sudo qemu-nbd -d /dev/nbd0

[Sans contact] Un lecteur/encodeur RFID pour moins de 10€

0

J’avais besoin d’un lecteur/encodeur RFID pour un projet personnel, alors je me suis renseigné sur internet, et j’ai vu beaucoup de recommandations pour le lecteur/encodeur ACR122U, qu’on trouve un peu partout (eBay, Amazon, etc.) pour une trentaire d’euros. Je trouvais cela cher pour un dispositif RFID, j’ai donc cherché une solution alternative plus économique.

La solution trouvée consiste à associer un module RFID destiné à des projets électroniques à base d’Arduino à un adaptateur USB-UART.

Module NFC

Il faut acheter un module NFC basé sur la puce PN532 mais attention, toutes les cartes ne sont pas identiques ! En effet, la puce PN532 peut être exploitée par 3 interfaces (I²C, SPI, UART), et en fonction du choix du fabricant, il est parfois uniquement possible d’utiliser une des trois interfaces. Pour ma part, j’ai le module ElecHouse rouge :

Il dispose de deux interrupteurs pour sélectionner le mode d’interface à utiliser (appelé HSU sur le module : High Speed UART). On le trouve pour environ 5€ en provenance de la Chine.

Adaptateur USB-UART

Votre ordinateur étant peu probablement doté d’une interface UART accessible (sauf si vous utilisez un ordinateur embarqué, type Raspberry Pi), il nous faudra une interface USB-UART. On en trouve pour quelques euros sur internet. J’utilise pour ma part un adaptateur basé sur la puce FT232R :

Connection électrique entre adaptateur USB-UART et carte NFC

À l’aide d’un cable mâle-mâle, il faut effectuer les connexions suivantes :

  • VCC UART -> VCC NFC
  • GND UART -> GND NFC
  • TX UART -> RX NFC
  • RX UART -> TX NFC

Si votre adaptateur est doté d’un cavalier permettant la sélection de la tension VCC, mettez-le en position 3V3. Sinon assurez-vous que votre adaptateur avec des niveaux de tension 0-3V3.

Configuration pour l’utilisation avec libnfc

Sur Linux, la majorité des outils permettant de travailler sur le NFC sont écrits avec la bibliothèque libnfc (installée par défaut sur Kali Linux, disponible dans les dépôts Fedora). Pour pouvoir utiliser notre lecteur/encodeur avec libnfc, il va falloir créer un fichier de configuration.

On va d’abord avoir besoin de connaître le nom du fichier de l’adaptateur USB-UART. En ayant l’adaptateur débranché, listez les périphériques série sur votre système avec la commande :

ls /dev/tty*

Branchez l’adaptateur et répétez l’opération. La nouvelle entrée correspond à celle de votre adaptateur (par exemple dans mon cas /dev/ttyUS3).

Dans le dossier /etc/nfc/devices.d/, créez un fichier monrfid.conf (le nom du fichier importe peu, l’extension par contre oui), en prenant soin de remplacer le chemin du fichier de votre adaptateur USB-UART :

name = "Mon adaptateur RFID maison"
connstring = "pn532_uart:/dev/ttyUSB3"

Votre lecteur/encodeur NFC est prêt à être utilisé !

[Apple] Installer iWork sur iOS 5.1.1

0

Je possède un iPad de première génération qui est destiné à rester sous iOS 5.1.1, la dernière version d’iOS pour ce modèle d’iPad. Cette version est sortie il y a plus de 5 ans, et inévitablement le support logiciel est quasiment mort : il n’est plus possible de publier des applications compatibles avec cette version d’iOS. C’est malheureux, mais dans la mesure où les capacités matérielles de cet iPad étaient limitées, ce n’est pas trop aberrant.

Je voulais y installer la suite iWork (Pages, Numbers, Keynote) de manière à pouvoir l’utiliser comme un outil d’appoint pour rédiger des documents en mobilité, mais il n’est pas possible de procéder directement depuis l’iPad : on nous indique qu’il est trop vieux.

La solution consiste à passer par iTunes, sur Mac dans mon cas, pour bidouiller les requêtes qui interviennent lors du téléchargement de l’application.

Attention : il n’est plus possible de télécharger d’applications sur l’App Store iOS depuis iTunes à partir de la version 12.7!

Installation d’un proxy pour modifier des requêtes

L’idée est d’intercepter les requêtes vers l’iTunes Store pour changer le External Version Identifier (l’identifiant attribué à chaque version d’un logiciel distribué sur l’App Store). Pour ce faire nous utiliserons Charles, un proxy. Ce logiciel est payant ($50) mais la version gratuite suffit amplement.

Une fois l’application Charles lancée, vous devrez lui accorder les privilèges administrateurs pour qu’elle puisse intercepter les communications internes à votre ordinateur.

Nous allons devoir intercepter des communications chiffrées (SSL), donc il faut importer le certificat autogénéré de Charles, sinon iTunes rechignera à communiquer avec l’iTunes Store. Rendez-vous dans Help > SSL Proxying > Save Charles root certificate, sauvegardez le certificat quelque part, puis importez-le dans le trousseau.

Ensuite, exportez le certificat importé dans le trousseau au format .cer, et tapez la commande suivante pour l’ajouter en tant que certificat vérifié :

sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" /chemin/vers/mon/certificat.cer

Modifier les requêtes vers l’iTunes Store

Lancez un téléchargement d’application quelconque depuis iTunes. Vous devriez observer l’apparition d’une ligne vers un serveur dont le nom de domaine est formatté ainsi : ***-buy.itunes.apple.com. Faites un clic droit dessus puis sélectionnez Enable SSL Proxying. Cela va faire en sorte à ce que les communications SSL soient interceptées.

Lancez à nouveau un téléchargement d’application depuis iTunes. Dépliez l’arbre du serveur ***-buy.itunes.apple.com (WebObjects > MZBuy.woa > wa > buyProduct) et faites un clic droit sur buyProduct pour sélectionner Breakpoints. Cela va avoir pour effet de mettre en attente chaque requête vers buyProduct, pour pouvoir modifier son contenu.

Lancez à présent le téléchargement d’une application de la suite iWork, par exemple Pages. Charles va s’activer et vous proposer de modifier la requête. Cliquez sur l’onglet XML Text, et modifiez la valeur de appExtVrsId. Vous devez utiliser les valeurs suivantes :

  • Pages 1.7.2 : 14498879
  • Numbers 1.7.3 : 16806622
  • Keynote 1.7.2 : 14498877

Cliquez ensuite sur Execute, cela vous sera demandé plusieurs fois. Le téléchargement de l’application devrait commencer, et vous pourrez devriez vous retrouver avec l’application souhaitée dans vos téléchargements iTunes.

[Astuce] Accès distant avec OpenVPN

0

En voulant configurer un serveur d’accès distant avec OpenVPN, je suis tombé dans quelques petits pièges. Aussi, pour que mon expérience puisse servir à d’autres, autant vous en faire part.

Contexte

C’est très simple, presque bateau : un serveur, avec OpenVPN, des clients, avec OpenVPN également et quelques petites subtilités côté serveur. Les clients se connectent au serveur et accèdent à des ressources locales au serveur mais aussi à l’infrastructure qui se trouve derrière. Imaginez que l’infrastructure est importante et que le serveur serve de bordure à un protocole de routage dynamique.

Première astuce : les types de tunnels

D’abord, j’ai fait l’erreur de laisser les clients se connecter via un VPN TAP. Bien que ça fonctionne, ce n’est pas vraiment adapté en pratique. Sommairement, les tunnels de type TAP sont principalement conçus pour des connexions de site à site, et les tunnels de type TUN servent aux accès distant pour un terminal (ordinateur, téléphone, tablette…). Bref, on repasse en TUN pour le cas qui m’intéresse, c’est-à-dire de l’accès en itinérance de terminaux.

Deuxième astuce : la topologie des tunnels de type TUN

Les interfaces de type TUN fonctionnent au niveau 3 du modèle OSI, mais en fait c’est un montage un peu complexe quand on y regarde de très près mais qui fonctionne très bien. Sauf bien évidemment quand on utilise déjà des astuces de routage ou de pare-feu, ce qui était le cas sur mon serveur.

Regardons justement plus en détail. Sur une extrémité de tunnel TAP, on trouve une interface réseau virtuelle, possédant son adresse IP et son masque, et un pair en face. On est donc pas bien loin du tunnel GRE si on enlève le chiffrement qui va autour, dans le principe bien sûr.

Pour une extrémité TUN, il faut tenir compte de la notion de topologie. Par défaut, un serveur TUN démarre avec une topologie dite « net30 », soit assignation d’un sous-réseau /30 (2 IP possibles, le serveur et le client). Et pour que le client communique avec le serveur (au sens applicatif, par exemple un serveur Web abrité derrière la connexion VPN), il faut que le noyau puisse recevoir les paquets, et il n’y a qu’une seule interface virtuelle qui est montée. Dans ce cas, on va tomber sur une interface TUN déclarée dans le noyau avec une adresse IP /32, une route injectée « manuellement » par OpenVPN pour tout le sous-réseau, et un routage strictement interne à OpenVPN entre les clients. Obscur hein ! Décryptons avec un dessin.

Ce schéma représente le principe de fonctionnement d’une topologie Net30. Le serveur réel (le noyau du système d’exploitation) voit une unique adresse IP en 192.168.90.1/32, tout le reste étant masqué par le processus OpenVPN. Chaque client voit sa propre adresse IP dans un sous-réseau dédié par OpenVPN. Par exemple le client ayant l’adresse 192.168.90.6/30 discutera avec le serveur via l’adresse 192.168.90.5/30 et ne pourra pas communiquer avec le reste du monde, sauf à lui « pousser » des routes.

Il faut bien comprendre qui va tenir le rôle de routeur : est-ce le serveur OpenVPN ou est-ce le noyau de l’OS ? La réponse dépend de la configuration : avec l’option « client-to-client », c’est OpenVPN qui s’occupera du routage, sinon c’est le noyau.

Avec un Net30 et une plage réduite dans la configuration d’OpenVPN, disons 192.168.90.0/29, on peut avoir un serveur et un client (et un seul), et instancier autant de processus OpenVPN que nécessaire, et donc autant d’interfaces dans le noyau. Ca peut éventuellement servir pour appliquer des règles de pare-feu très fines entre clients ou différentes d’un client à l’autre.

Mais c’est peut-être un peu beaucoup… Et c’est pas tout à fait ça que je cherchais. Tout simplement parce que l’interface déclarée en tant que 192.168.90.1/32 crée du souci à mon protocole de routage, même avec la route « manuelle » évoquée plus haut qui serait ici 192.168.90.0/24. Dans mon cas, le protocole choisit le masque le plus restreint plutôt que la route statique, même en lui forçant la main.

Et c’est là qu’entre en jeu le paramètre « topology ». Moyennant de lui indiquer le mode « subnet », on retombe sur le même principe de fonctionnement que les interfaces TAP, et le noyau verra de nouveau l’interface virtuelle en tant que 192.168.90.1/24. Et voilà que mon routage s’est remis d’aplomb presque instantanément !

Troisième astuce : tout ça pour le client OpenVPN sur Android

Le client OpenVPN pour Android ne supporte pas les tunnels TAP ! C’est de là que tout est parti. Quand, lorsque j’ai bêtement converti mon serveur de TAP vers TUN, j’ai vu surgir tous ces problèmes de topologie mais aussi de routes et de DNS !

Parce que malgré un « ip route » sur un teminal Android (7.1.2), impossible de voir les routes poussées par le serveur dans le noyau Linux de l’Android. Même en root. Alors qu’elles sont bien présentes et bien inscrites par OpenVPN. Bref, que faut-il alors faire pour que ça fonctionne ?

Sur le serveur, il faut pousser les routes et éventuellement si c’est nécessaire (comme dans mon cas) les serveurs DNS. On placera donc les éléments suivants, que vous aurez bien évidemment pris soin d’adapter à votre cas, dans la configuration côté serveur :

push "route 10.0.0.0 255.0.0.0"
push "dhcp-option DOMAIN labcellar.com"
push "dhcp-option DNS 10.0.0.10"
push "dhcp-option DNS 10.0.0.11"

Je ne veux rediriger que le trafic interne dans le tunnel, c’est pouquoi je ne fais que pousser la route adaptée. Vous trouverez sur Internet pléthore de sites vous expliquant comment rediriger l’intégralité du trafic dans le tunnel. Ici, c’est l’accès aux outils internes qui m’intéresse, et la résolution des noms. Côté client Android, il faut bien penser à laisser l’option « pull » activée afin que soient pris en compte tous ces paramètres « pushés » par le serveur. Et n’oubliez pas dans les versions récentes d’Android d’aller régler les « Applications autorisées », soit en mode « liste blanche » (seulement les applications cochées), soit en mode « liste noire » (interdire les applications cochées).

En fait, au delà de l’astuce de configuration, il faut savoir que le seul moyen d’avoir des informations de débogage consiste à augmenter la « verbosité » du logiciel OpenVPN et à faire confiance au fait qu’il affiche ou non des erreurs à chacune de ses actions. Demander ces informations directement au noyau Android aboutit à n’avoir que des informations erronées ou incomplètes si l’on tente de procéder comme sur un ordinateur classique.

Références

Il y a une petite coquille dans cet article (qui n’est pas liée à la syntaxe ou à la grammaire mais bien sur le sujet de fond), et qui n’a pas d’impact sur toutes les explications données, ni sur la solution mise en œuvre. Je l’ai laissée (presque) exprès. Saurez-vous la retrouver ? J’éditerai cet article dans un mois environ pour indiquer la solution.

Edit du 09/04/2018 : si vous avez bien suivi les explications sur la topologie Net30, vous avez peut-être remarqué qu’il y a une incohérence dans le schéma que j’ai proposé. En effet si le pseudo-serveur qui émule le switch interne qui relie les tunnels entre eux s’attribue d’abord une adresse avant d’en attribuer une à son client, ça signifie que la patte en haut à gauche qui représente la machine physique ne contient pas les bonnes adresses. Côté switch, c’est l’adresse .1 et côté serveur physique, c’est .2. Et c’est effectivement le cas : l’adresse visible avec un « ifconfig » ou un « ip address » est bien une valeur paire, et généralement .2 pour un subnet /24 divisés en morceaux de /30.

[Palm] Emettre des codes infrarouge « Pronto » avec un Palm

0

Une histoire rocambolesque : j’avais besoin de tester une prise antenne dans un logement, et pour cela me suis muni d’un décodeur TNT. Pour lancer une recherche de canaux télévisuels, il faut une télécommande. Je n’avais pas à ma disposition de piles adéquates pour mettre dans la télécommande, et ai donc dû improviser avec un Palm TX…

Dans cet article, nous allons donc émuler une télécommande infra-rouge à l’aide d’un Palm en se servant de codes pour télécommande Philips Pronto en hexadécimal. Dans mon cas, il proviennent de la fabuleuse base de données irdb.tk.

Il n’existe pas (à ma connaissance) de méthode permettant d’entrer directement des codes infrarouges dans une application Palm pour les émettre. Nous allons donc bidouiller avec plusieurs logiciels pour parvenir à notre objectif.

(suite…)

[Mémo] Démarrer des instances OpenVPN avec systemd

0

Remarque préliminaire : cet article traite du démarrage d’instances d’OpenVPN sur un système Linux, ici une Debian Stretch, avec systemd. Il ne traite pas de la manière dont on configure une instance OpenVPN (paramètres et clés).

Avec SysV, un démon maître était lancé et chaque instance à démarrer automatiquement se faisait par configuration dans le fichier « /etc/default/openvpn » (du moins sur les Debian-like).

systemd est conçu pour gérer nativement ces problématiques de multi-instances, alors autant en profiter.

Contexte

Supposons que votre ordinateur portable nécessite d’être raccordé à trois infrastructures distantes via VPN, dont une de manière permanente. Imaginez que vous êtes un prestataire qui prend le contrôle à distance chez ses clients, tout en gardant en permanence un lien vers son serveur NAS à la maison,

On a donc 3 configurations différentes que nous appellerons « maison », « client-a » et « client-b ». Ces trois configurations et tous les fichiers nécessaires (notamment les clés) se placent dans leurs dossiers respectifs. Ce qui donne :

$ ls /etc/openvpn
client   client-a   client-b   maison   server

Cela dit, on remarque la présence de deux dossiers supplémentaires appelés « client » et « server ». Ils sont liés au fonctionnement prédéfini par les gabarits d’unités systemd pour OpenVPN 2.4.

Mise en œuvre

Pour chaque dossier créé, on trouve un certain nombre d’éléments, dont le fichier de configuration. Voici un exemple :

$ ls /etc/openvpn/maison
maison.conf   shared.key

Remarque : on pourrait tout bourrer comme des sagoins dans le dossier « client », mais je ne trouve pas ça très propre et très maintenable si les tunnels se multiplient.

Cependant, c’est bien le dossier « client » qui va faire foi dans un premier temps, vu la manière dont le gabarit est construit. Un simple lien symbolique suffit :

# ln -s /etc/openvpn/maison/maison.conf /etc/openvpn/client/maison.conf

Le gabarit n’est pas amorçable directement, il faut nommer explicitement une instance. Ici le fichier s’appelle « maison.conf ». Inscrire l’instance « maison » (qui ira bien chercher « maison.conf » dans le dossier « client ») est enfantin :

# systemctl enable openvpn-client@maison
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-client@maison.service → /lib/systemd/system/openvpn-server@.service.

Désormais, le VPN vers la maison se lance automatiquement au démarrage du système !

Et pour lancer les autres instances, pas besoin de les inscrire, systemd se débrouille à partir du nom indiqué pour retrouver ses petits.

# systemctl start openvpn-client@client-a

Remarques

Le paquet OpenVPN exploite donc désormais les services systemd, et non plus les scripts de type UNIX System V. Pour bien décortiquer l’affaire, il faut donc comprendre le fonctionnement des « unités » systemd. La petite bête réside dans ce paragraphe (en langue de Shakespeare) :

Optionally, units may be instantiated from a template file at runtime. This allows creation of multiple units from a single configuration file. If systemd looks for a unit configuration file, it will first search for the literal unit name in the file system. If that yields no success and the unit name contains an « @ » character, systemd will look for a unit template that shares the same name but with the instance string (i.e. the part between the « @ » character and the suffix) removed. Example: if a service getty@tty3.service is requested and no file by that name is found, systemd will look for getty@.service and instantiate a service from that configuration file if it is found.

Soit en gros : il détecte la présence d’un arobase, donc il suppose une instanciation. Il extrait le nom de l’instance entre le ‘@’ et le ‘.’, et lance le gabarit (reconnaissable au ‘@.service’) avec en paramètre le nom de l’instance.

Le paquet lui-même installe ces fichiers :

# ls -l /lib/systemd/system/openvpn*
-rw-r--r-- 1 root root 707 juil. 18 22:15 /lib/systemd/system/openvpn-client@.service
-rw-r--r-- 1 root root 780 juil. 18 22:15 /lib/systemd/system/openvpn-server@.service
-rw-r--r-- 1 root root 320 juil. 18 22:15 /lib/systemd/system/openvpn.service
-rw-r--r-- 1 root root 894 juil. 18 22:15 /lib/systemd/system/openvpn@.service

Dans le fichier « openvpn-client@.service », on trouve ces directives (parmi d’autres) :

WorkingDirectory=/etc/openvpn/client
[...]
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf

Et voilà grosso modo comment systemd s’y retrouve pour lancer des instances différentes à partir d’un même fichier. Même principe pour le gabarit « openvpn-server ».

Et les deux derniers ? Ce sont les versions pour OpenVPN 2.3, que je recommande d’abandonner si vous le pouvez. Ces instances cherchent leur configuration dans le dossier « /etc/openvpn » et sont lancées de manière significativement différentes. Si vous n’êtes pas un expert OpenVPN, ou ne recherchant pas explicitement ces détails de lancement, vous pouvez les abandonner sans regret. Sachez qu’un OpenVPN 2.4 peut parfaitement discuter avec un OpenVPN 2.3 moyennant de les laisser s’entendre sur les algorithmes et certains paramètres nouvellement introduits : c’est testé et approuvé !

systemd, faut en manger ! C’est bon ! (Mais des fois ça croque un peu sous la dent…)

[Debian] Basculer la mise en réseau de System V à systemd

1

Depuis Debian Jessie (8.X), systemd se fait de plus en plus présent dans la distribution, et permet d’effectuer une migration en douceur au fil des versions. Parmi celles à noter, je voudrais vous faire découvrir la partie mise en réseau élémentaire.

L’objectif est de remplacer la gestion classique avec l’ensemble ifupdown et le client DHCP de l’ISC. On pourra même supprimer les paquets à la fin de la migration. Pour corser les choses, je vais appliquer ce cas d’usage à un VPS 2016 chez OVH, dont la gestion manuelle révèle quelques surprises.

Testez vos configurations dans une machine virtuelle ! Ça vous évitera des surprises en production. Et lisez cet article en entier avant de vous lancer : systemd est super, mais aussi super chiant parfois…

Configurer systemd

La configuration des éléments réseau de systemd se fait dans le dossier /etc/systemd/network. Pour ce qui nous concerne, on va créer un fichier avec en préfixe un nombre quelconque, par exemple « 30 » puis un nom représentatif pour vous, je prendrai « wired » pour mes liens filaires, et l’extension « .network ». Dans cet exemple, ca me donne donc « 30-wired.network ».

(suite…)

[Terminaux Windows CE] Cleanboot sur Motorola MC70

0

Préambule

Pour interagir avec notre IBM i, nous utilisons majoritairement des sessions de type 5250 (les fameux écrans verts). Des grilles écrans issues de différents programmes s’affichent sur ses sessions et nous permettent d’interagir efficacement et directement avec la machine. Si habituellement nous accédons à la machine grâce à une console IBM, ou l’IBM i Access (qui émule un terminal 5250) sur nos PC, nous avons prévu l’utilisation de terminaux mobiles, notamment pour mouvementer les stock.

A l’heure où j’écris ces lignes, nous avons une ébauche de master pour nos trackers et je travaille sur ce sujet pour permettre une utilisation fluide.

Sur les terminaux équipés de Windows CE, il peut s’avérer utile de procéder parfois à une mise à blanc du système afin de lui restaurer son état d’origine. Cette opération peut être effectuée de plusieurs manières (bouton reset accessible avec une pointe, combinaison de touches, etc.) notamment par l’installation de fichiers spécifiques.

Nous allons voir dans ce billet comment procéder à cette mise à blanc sur nos terminaux, les Motorola Symbol MC7094, mais ceci est valable pour une large variété de terminaux. Cette mise à blanc s’appelle le cleanboot. Il ne s’agit de pas grand chose de plus que la traduction de la documentation fournie. (suite…)

[Windows] Dépendances de mises à jour sur Windows 7 SP1

0

Cet article est en fait un mémo pour rapidement mettre à jour les composants fondamentaux d’un Windows 7 SP1.

Exigences initiales

Mon problème est de bénéficier de la dernière version de PowerShell (5.1 au moment où je rédige cet article, 6.0 en cours de finalisation par Microsoft), de la dernière version du framework .NET (4.7.1), et de la dernière version d’Internet Explorer (11). De plus, ces logiciels doivent s’installer sans connexion à Internet.

Mise à jour d’Internet Explorer

Dans un premier temps, on s’occupera d’Internet Explorer. Windows 7 est livré par défaut avec Internet Explorer 8, lequel est obsolète depuis un bon moment, tant par l’arrivée de nouvelles versions et de fonctionnalités, que par l’arrêt progressif du support par Microsoft. Officiellement, l’éditeur ne le supporte plus depuis le 12 janvier 2016 (mais des correctifs sortent encore aujourd’hui…) Bref, il est grandement temps de le mettre à jour. (suite…)

Go to Top