Exile on Keyboard St. - Blog sur Linux et Debian

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 28 octobre 2018

Utiliser VirtualBox 5.2 sur Debian Jessie

Si vous utilisez Debian 8 (Jessie) et VirtualBox, vous avez sans doute remarqué que la version de VirtualBox du dépôt Debian date un peu, puisque c'est une version 4.3.40 qui date de l'été 2016.

On souhaitera donc installer la version maintenue de VirtualBox, la 5.2, comme indiqué sur le Wiki de VirtualBox.

Une fois cette version installée, si vous créez une machine virtuelle, par exemple avec Vagrant, vous obtiendrez certainement l'erreur suivante:

There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "b81392d9-6f90-4c80-87e0-91bd0d95ef56", "--type", "headless"]

Stderr: VBoxManage: error: The virtual machine 'test_vbox_52_default_1540707024933_47897' has terminated unexpectedly during startup with exit code 1 (0x1)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine

La machine virtuelle ne démarre pas !

La cause est la suivante: VirtualBox 5.2 essaie d'utiliser les "kernels modules" de la version 4.3 de VirtualBox et ce même si on a supprimé tous les paquets correspondants à cette version :-(

Il nous faut donc reconstruire ces modules par:

# sudo rcvboxdrv setup
vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.

Comme indiqué à la fin du paragraphe suivant.

Et la VM va maintenant démarrer.

D'ailleurs, si vous regardez bien, VirtualBox 5.2 ne comporte pas de paquet virtualbox-dkms comme c'était le cas auparavant. Un seul paquet est installé:

# dpkg --list | grep virtualbox
ii  virtualbox-5.2                        5.2.20-125813~Debian~jessie                amd64        Oracle VM VirtualBox

Voilà, vous pouvez utiliser la dernière version de VirtualBox et la version la plus récente de Vagrant sur Debian Jessie.

dimanche 14 octobre 2018

Vagrant: une VM Debian en Français avec GUI en 3mn

Vagrant est un outil open source qui permet de créer et de configurer des machines virtuelles très rapidement. Depuis l'arrivée de Docker, on parle beaucoup moins de Vagrant qui existe depuis 2010.

Comme Docker, on part d'une image de base pour construire sa propre image. La terminologie Vagrant parle de 'box'. Par défaut, Vagrant utilise VirtualBox pour créer les VMs.

Mais les 'box' de bases sont quasiment tout le temps:

  • Sans environnement graphique
  • Avec un clavier en Anglais

Le deuxième point n'étant génant que si l'on veut avoir le premier ! Dans le cas contraire, on se connecte à la box en SSH et le tour est joué.

Donc, pour disposer d'une machine virtuelle avec un environnement graphique, on va 'provisionner' notre VM comme suit:

Dans un premier temps, il faut indiquer à Vagrant d'afficher l'UI de VirtualBox:

  config.vm.provider "virtualbox" do |vb|
    vb.name = "Debian with Mate"
    vb.gui = true
    vb.memory = "4096"
  end

Sans cela, l'environnement graphique ne s'affichera tout simplement pas !

Puis on va installer quelques logiciels sur la VM:

  config.vm.provision "shell", inline: <<-SHELL
    apt-get --quiet update
    apt-get --assume-yes upgrade
    apt-get --assume-yes install lightdm mate-desktop-environment
    echo "autologin-user=vagrant" | tee --append /usr/share/lightdm/lightdm.conf.d/01_debian.conf
    sed --in-place s/us/fr/g /etc/default/keyboard
    systemctl reboot
  SHELL

On commence par mettre à jour le système, puis on installe Mate, plus léger que nombre d'autres environnements graphiques, ainsi qu'un 'Display Manager', lightdm sera très bien.

Il ne reste qu'à:

  • Activer la connexion automatique
  • Définir le clavier en Français

Je vois souvent plein d'instructions compliquées pour passer le clavier en Français, alors qu'il suffit de changer une ligne dans le fichier /etc/default/keyboard !!!

Vous noterez que je préfère les options longues des commandes. Je trouve que c'est plus lisible comme cela, on ne se souvient pas toujours de ce que fait l'option -i ou -q ...

Enfin, la dernière ligne des instructions de provisioning est requise:

systemctl reboot

et permet de:

  • Prendre en compte la configuration du clavier en Français
  • Se loguer automatiquement

Voilà, c'est fini, en 3mn, vous êtes sous Debian avec Mate et déjà connecté !

mercredi 10 octobre 2018

Des logs claires et utiles en Java

L'utilisateur final d'un logiciel est toujours heureux lorsque ce logiciel produit des logs claires et utiles.

Malheureusement, les développeurs ne font pas toujours suffisamment le nécessaire pour:

  • Ajouter des logs et traces là ou c'est utile
  • Mettre ces logs dans le bon niveau de log
  • Les mettre à jour quand besoin est
  • Faire en sorte que ces logs ne pénalisent pas trop les performances du logiciel

Et pourtant, la deuxième plus grande catégorie d'utilisateurs d'un logicel, c'est .... l'équipe de développement de ce logiciel !!!

On va donc faire un tour des erreurs les plus communément faites en matière de logs, et ce dans le but de s'amélirorer !

1. Pas de logs du tout

La première erreur que je vois trop souvent, c'est l'absence complète de logs dans une méthode ou même dans un composant tout entier. Il est donc impossible en cas de doute(s) sur le fonctionnement de ce code, de savoir ce qu'il se passe, à part se connecter en debug sur le serveur, ce qui n'est évidemment pas possible chez un client.

2. Des logs uniquement en TRACE ou en FINEST

Deuxième erreur trop souvent commise, on a des logs mais seulement dans le niveau de log maximum !

Comme en pratique, il est déconseillé de configurer un logiciel avec un niveau de log maximum, il en résulte que ces logs ne sortiront la plupart du temps pas chez les clients.

Ce cas arrive souvent quand le développeur veut mettre des logs mais il n'est pas certain du niveau de logs qu'il faut choisir. Et comme il développe avec un niveau de log en TRACE, ses logs s'affichent et il est content !

3. Des logs sans suffisamment de contexte

C'est moins fréquent, mais j'ai aussi vu des logs qui ressemblent à ça:

LOGGER.log(Level.INFO, "Creating user");

ou

LOGGER.log(Level.INFO, "Entering method 'needsRestart'");

Des logs comme celles-cis ne donnant aucun contexte, elles ne sont pas vraiment utiles.

Il s'agit en fait de traces utilisées lors du développement ou plus précisément du debug et qui auraient dù être enlevées ensuite.

4. Des logs avec une chaîne de formatage fausse

Le cas le plus courant de chaîne de formatage fausse est l'erreur sur le nombre de paramètres, par exemple:

LOGGER.info("Computing user: {} identifier: {}", user.getName());

Manifestement, il va nous manquer une information dans la log ...

Si à la place on avait:

LOGGER.info("Computing user: {} identifier: {}", getParam("user"), getParam("identifier"), getParam("extra"));

La méthode getParam serait appelée trois fois alors que le troisième paramètre n'est pas utilisé. Cela nous amènera à utiliser un Supplier et les méthodes lambdas avec Java 8.

5. Des logs faites par des anciens développeurs C

Dans les logs en Java, on trouve aussi le résultat de la programmation en C: le développeur Java qui met des String.format(...) partout !

LOGGER.info(String.format("Computing user: %s identifier: %s", getParam("user"), getParam("identifier")));

Ce qui va formater la chaîne même si le niveau de log ne permet pas que le message s'affiche. On en revient aux Suppliers.

Ensuite il est inutile de recourir à String.format(....) puisque Log4j ou java.util.logging formattent très bien le message en convertissant tout en chaînes de caractères.

Parfois le String.format(...) est tout simplement oublié:

LOGGER.info("Computing user: %s identifier: %s", getParam("user"), getParam("identifier"));

Ce qui affiche quelque chose comme:

06:48:36.094 main INFO org.grumpyf0x48.test.Log4j2Test - Computing user: %s identifier: %s

ce qui n'était probablement pas souhaité !

6. Des logs avec des passages de paramètres .... illisibles

On voit aussi des développeurs qui veulent logger beaucoup de choses dans le même message, et qui ont la hantise du plantage, et qui donc non content de passer 8 paramètres au message de log (et ce tout sur la même ligne temps qu'à faire), font une vérification pour chacun (ou presque) comme: (name == null) ? "no name supplied" : name.

C'est parfaitement inutile puisque dans ce cas Log4J affichera simplement "null" sans se planter. En outre ce genre de message compliqué est difficile à lire et à maintenir, donc à bannir.

Voilà, j'imagine qu'il y a des cas d'erreurs que j'oublie, n'hésitez pas à faire un commentaire si c'est le cas.

- page 1 de 54