HOAB

History of a bug

Copier une VM facilement sous ESX

Rédigé par gorki Aucun commentaire

Le problème :

Un petit souci de gestion de VM sous VMWare ESX 5.

Alors oui je sais, normalement on fait du Ansible, Stack, Puppet pour les anciens pas si anciens.

Mais dans mon cas, je duplique 1 VM par an et je n'ai pas forcément ces outils à disposition au moment de le faire.

Solution :

Assez simple à faire si la VM est bien pensée au départ (windows ou linux) :

  • un disque système
  • un disque par user (oracle, myuser,...)

Donc la marche à suivre :

  1. on se loggue en ssh sur l'ESX
  2. on va dans le répertoire des images : /vmfs/xxxx
  3. on duplique la VM en copiant le répertoire dans un nouveau (la VM a été préalablement arrêtée)
  4. dans le nouveau répertoire :
    1. on a les fichiers disques (*vmdk, *-flat.vmdk)
    2. on a le descripteur de VM (vmx, vmxf, vmxd, nvram)
    3. on renomme les fichiers descripteurs avec le nouveau nom
    4. on modifie dans les fichiers descripteurs les références à l'ancien nom
    5. on install la VM

Exemple de références :

// Fichier vmxf (référence au fichier vmx) : 

<vmxPathName type="string">oldvm.vmx</vmxPathName>


// Fichier vmx : 
// propriété qui peut-être supprimé : 
sched.swap.derivedName

// à modifier : 
extendedConfigFile="oldvm.vmxf"

// si les noms des disques sont en absolus, pensez-y, en relatif, pas de soucis

Dans l'exploration du stockage :

  1. sélectionner le fichier vmx
  2. installer
  3. ouvrir la console et lancer la VM
  4. cliquer sur "je l'ai copié"

 

Ensuite vu que c'est une VM copiée, modifer dans la VM (une fois lancée) :

  1. le hostname
  2. l'IP si pas de DHCP
    1. attention aux programmes qui peuvent utiliser l'IP externe (listener oracle par exemple)
  3. sous linux : le routage (/etc/hosts)
  4. sous linux : le montage des disques si l'UID a changé et qu'il n'est pas autodécté : (/etc/fstab)

 

 

Antivirus et transfert de fichiers bloqué

Rédigé par gorki Aucun commentaire

Le problème :

Quand on est chez le client, il arrive qu'on doive transférer des fichiers dans un environnement "sécurisé". Il existe parfois des solutions de transfert :

  • espace de partage sécurisé (permet de logguer les transferts)
  • clé usb chiffrée

Et puis de temps en temps c'est galère (la clé n'est pas là, le transfert n'est pas accessible, ...) et votre fichier doit arriver chez le client. Or les .sh, .jar, .zip, .exe, sont mal vu... Normal. Les dropbox wetransfer, et autre FTP bannis, le partage WIFI bloqué, les fichiers scannés...

Pour autant la plupart des sites sont autorisés pour le travail (normal aussi).
 

Solution :

Il vous faut :

  • une habilitation sur un poste client (sinon pourquoi voudriez-vous envoyer des fichiers ?)
  • un espace disponible sur internet

Utilisez ce petit programme :

  • côté pile : on rajoute du bruit avant le fichier à télécharger. On met ce fichier sur un espace internet
  • côté face : on télécharge le fichier depuis cet espace neutre, on enlève le bruit

Si c'est un vrai virus, l'antivirus le verra lors de l'écriture du fichier sans bruit (enfin, on peut l'espérer). LE fichier n'est pas exécutable sans le "unhide", donc il faut une action humaine pour ça, donc ça limite parfaitement les risques.

Ca limite les risques, parce que si vous arrivez à faire exécuter ça à quelqu'un (transfert, compilation, téléchargement, unhide, exécution) alors vous avez largement les moyens de faire autre chose de mieux au niveau piratage.... social hacking.

Quand à savoir pourquoi on ne peut pas télécharger un fichier mais quand même l'exécuter, ça....

Ca dépanne de temps en temps.

package com.hidefile;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.channels.Channels;
import java.nio.channels.ReadableByteChannel;

import static java.lang.System.exit;

public class Hider {
    private static final byte[] bytes = "unelongueclepourquelesantivirusenaitmarrederegarder".getBytes();

    public static void hide(String filename) {
        try {
            String destFilename = filename + ".mdfy";
            ReadableByteChannel rbc = Channels.newChannel(new FileInputStream(filename));
            FileOutputStream fos = new FileOutputStream(destFilename, false);
            fos.write(bytes);
            fos.getChannel().transferFrom(rbc, bytes.length, Long.MAX_VALUE);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void unhide(String filename) {
        try {
            String destFilename = filename.replace(".mdfy", "");
            FileInputStream fis = new FileInputStream(filename);
            ReadableByteChannel rbc = Channels.newChannel(fis);
            FileOutputStream fos = new FileOutputStream(destFilename, false);
            System.out.println("bytes.length = " + bytes.length);
            fis.skip(bytes.length);
            fos.getChannel().transferFrom(rbc, 0, Long.MAX_VALUE);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void main(String... args) {
        if (args.length != 2) {
            System.err.println("Bad arguments : --hide|-h|--unhide|-u ");
            exit(1);
        }

        if (args[0].equals("-u") || args[0].equals("--unhide") ) {
            unhide(args[1]);
        }
        else {
            hide(args[1]);
        }
    }


}

Astuce, les extensions sont importantes : .png passe mieux que .jar.mdfy

Au pire, le bruit peut être un header PNG :

private static final byte[] bytes = new byte[]{(byte) 137,80,78,71,13,10,26,10};

Bien sur c'est en total non-conformité avec la charte d'utilisation de votre poste en général.

Cannot process volume group "xxx" on boot

Rédigé par gorki Aucun commentaire

Le problème :

Je joue avec des VM en ce moment, copie, clone, etc... et lors de la mise au point je me suis amusé à modifier le nom des volumes groups.... Dont le volume group qui hébergait la partition "/" :)

Alors après ça ne démarre plus... curieusement...

failed to connect to lvmetad

volume group "xxx" not found

Cannot process volume group "xxx" on boot

On arrive à la fin sur le initramfs qui indique bien la cause probable : boot args, cat / proc/cmdline

Et en effet, dans ce cas, le boot_image pointe vers l'ancien nom du volume group. Quoi de plus normal.

Mais bon j'ai un peu galéré pour un truc super simple à corriger.

Solution :

J'ai cherché des disques de dépannage dont le supergrub2-iso qui ne m'a pas aidé (pas réussi à le faire booter celui-là).

Bref, la solution toute simple (parce que j'ai grub2 !), au démarrage :

  • booter une première fois jusqu'à avoir l'invite initramfs
  • lister les volumes logiques : ls /dev/mapper
  • repérer le nom du volume logique (qui contient -root en général)
  • reboot de la vm
  • lors du menu grub appuyer sur e pour éditer la configuration choisie
  • repérer la ligne qui contient /dev/mapper/<ancien nom du volume logique>
  • corriger le nom
  • ctrl-x

ça devrait booter.

Pour corriger complètement :

  1. Corriger le fichier /etc/fstab s'il contient encore la référence vers l'ancien volume logique
  2. Vérifier le disque initfsram :
update-initramfs -u

# Si des warnings sont affiché, vérifier la configuration dans : 
cd /etc/initramfs-tools
# particulièrement :
/etc/initramfs-tools/conf.d/resume
  1. Ensuite on demande à grub de se mettre à jour :
update-grub /dev/sda
grub-install /dev/sda

 

Spring Boot ne sert pas les ressources statiques

Rédigé par gorki 1 commentaire

Le problème :

Avec une stack JHipster, spring-boot n'affiche pas les ressources statiques en mode développement.

Ddonc par exemple pas de index.html...

Pour autant si on lance la commande avec le war serverless (cf spring-boot-maven-plugin), ça fonctionne.

Je suis sous Intellij, à l'évidence quelque chose manque dans le lancement de la tâche Intellij spring-boot

L'architecture est mavenisé donc le root contexte est sous : src/main/webapp

Cependant spring-boot semble chercher ses ressources ailleurs : cf la documentation

Par quelle magie spring-boot doit-il trouver ses ressources dans src/main/webapp ??

Solution :

Beaucoup de recherches, de debug et autre (il y a un peu de spring-secu dans le lot). Au final les services jhipster classiques (health, dump, etc...) fonctionnent mais toujours pas de ressources statiques.

Vérification :

  • de la tâche de lancement Intellij, elle semble correcte.
  • des classpaths (on met src/main/webapp dans le classpath, on l'enlève) 
  • des paramètres de lancement (profil Spring et autre)

Au final la mise en debug m'a permis de trouver un log perdu parmi les autres :

[DEBUG] org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory - None of the document roots [src/main/webapp, public, static] point to a directory and will be ignored.

Tiens donc le Tomcat embarqué de spring-boot a ses propres chemins de recherches... (pas tout à fait décrit dans la doc Spring ci-dessus).

Breakpoint, watch, et paf, le chemin vers src/main/webapp en absolu n'est pas le bon.

Tout ça parce que le répertoire de travail de ma tâche spring-boot sous Intellij n'était pas fixé. Comment Intellij détermine cette valeur ? Mystère. En mettant donc le répertoire de travail égal au répertoire qui contient le src/main/webapp, tout roule (ici le répertoire de travail serait : /home/user/projets/monprojet/webportal.

On retrouve le log :

[DEBUG] org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory - Document root: /home/user/projets/monprojet/webportal/src/main/webapp

Eclairé aussi par ce lien

 

Cinnamon and Gnome : org.cinnamon.SettingsDaemon

Rédigé par gorki Aucun commentaire

Problem :

After an update of my debian, I lost :

And when I tried to apply new screen configuration I had :

GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service

Many references on the net, many solutions :

  1. reinstall cinnamon
  2. remove configuration file
  3. start /usr/bin/cinnamon-settings-daemon
  4. ...

All tried, none work.

Solution :

Due to previous ressources and tests, I notice that when starting :

/usr/bin/cinnamon-settings-daemon

I had an error :

You can only run one xsettings manager at a time; exiting

After checking that is wasn't already started with :

ps -aef | grep cinnamon-settings-daemon

I perform a grep with :

ps -aef | grep settings

And I found that I had a gnome-settings-daemon running. Eurêka ! Gnome was my previous X manager.

So after a few checks :

sudo apt-get purge gnome-control-center gnome-settings-daemon gnome-control-center-data gnome-desktop3-data gnome-accessibility-themes

Restart, and all works.

 

 

 

 

Fil RSS des articles