HOAB

History of a bug

PEER_DNS=no on debian or how to prevent a specific DHCP interface to update the DNS

Rédigé par gorki Aucun commentaire

Problem :

On Debian, do not update resolv.conf (DNS) when we have multiple DHCP network interfaces.

Solution :

A first link : Never update resolv.conf with DHCP client

But we don't want to never update, but sometimes update...

On Redhat families it's simple (see the previous link) : PEERDNS=NO on the right interfaces

On Debian families.... let's use the hook as suggested :

Create hook to avoid /etc/resolv.conf file update

You need to create /etc/dhcp3/dhclient-enter-hooks.d/nodnsupdate file under Debian / Ubuntu Linux:
# vi /etc/dhcp3/dhclient-enter-hooks.d/nodnsupdate
Append following code:

#!/bin/sh
make_resolv_conf()
{ : }

OK, but the hook prevent ALL interfaces to update resolv.conf, the idea :

  1. in the hook test the interface name
  2. if one authorized, call the original make_resolv_conf
  3. otherwise to nothing

In bash it's not easy to have multiple function with the same name, but thanks stackoverlow !:

#!/bin/bash


# copies function named $1 to name $2
copy_function() {
    declare -F $1 > /dev/null || return 1
    eval "$(echo "${2}()"; declare -f ${1} | tail -n +2)"
}

# Import the original make_resolv_conf
# Normally useless, hooks are called after make_resolv_conf declaration
# . /sbin/dhclient-script

copy_function make_resolv_conf orignal_make_resolv_conf

make_resolv_conf() {
        if [ ${interface} = "auhtorizedInterface" ] ; then
                original_make_resolv_conf
        fi
}

Update :

The previous solution is not working...  declare is not known by sh/dash and the script is run by sh/dash. So the copy function is not possible.

Ideas :

  • copy make_resolv_conf in this file under original_make_resolv_conf : it works, but ugly due to security patch not handled
  • use 2 hooks : one enter : save resolv.conf, one on exit : restore resolv.conf if ${interface} is not authorized
  • try to extract make_resolv_conf from /sbin/dhclient-script : not so easy...

Best solution, the two hooks, it's a pity :) I like the copy_functions :) :

# vi /etc/dhcp3/dhclient-enter-hooks.d/selectdns-enter

#!/bin/sh

cp /etc/resolv.conf /tmp/resolv.conf.${interface}

# vi /etc/dhcp3/dhclient-exit-hooks.d/selectdns-exit

#/bin/sh

if [ ${interface} = "auhtorizedInterface" ] ; then
       echo "${interface} not authorized"
       cp /tmp/resolv.conf.${interface} /etc/resolv.conf
fi

 

Bash and SSH completion with Include directive

Rédigé par gorki Aucun commentaire

Problem :

I use bash as shell and usually the autocompletion (with bash-completion) works well.

Until I create some Include files...

Solution :

Not a final one for every one, but a quick workaround is :

  1. put your Include file in a directory, for example : ~/ssh/config.d
  2. add those config file in bash_completion configuration.
sudo vi /usr/share/bash-completion/bash_completion

// Add your directory in the config file list

for i in /etc/ssh/ssh_config ~/.ssh/config ~/.ssh/config.d/* ~/.ssh2/config; do
    [[ -r $i ]] && config+=( "$i" )
done

That's all folks.

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

 

Fil RSS des articles