Hobgoblin's Master

APT, Proxy-Auto-Detect et proxy.pac ou wpad.dat

Landry MINOZA — Thu, 25 Sep 2014 19:31:13 GMT

The option Acquire::http::Proxy-Auto-Detect already exists for some time. It was intended to be used with the package squid-deb-proxy-client which is a helper for the APT http method to discover proxies that publish their service as _apt_proxy._tcp. It was justed upgraded (version 1.0.8) and now add the URL as a paramater. It is now possible to discover a common proxy through a proxy.pac script.

My proposed solution uses the package libproxy-tools and is a shell script wrapper.

Packages to install

The following packages are needed:

libproxy-tools brings the proxy command.
libproxy1-plugin-mozjs or libproxy1-plugin-webkit to evaluate wpad.dat or proxy.pac files.
Optionally libproxy1-plugin-networkmanager, libproxy1-plugin-gsettings or libproxy1-plugin-kconfig to read proxy configuration from Network Manager, Gnome or KDE.

Configuring APT

Create a new file in /etc/apt/apt.conf.d/ (for example /etc/apt/apt.conf.d/02proxy):

Acquire::http::Proxy-Auto-Detect "/usr/local/bin/apt-autoproxy.sh";

It say to APT to launch the given script for earch domain during downloads.

Shell script wrapper

/usr/local/bin/apt-autoproxy.sh

     #!/bin/sh

     export http_proxy=wpad://
     echo "$*" | proxy | awk '{ print $1 }'

Line 2 is optional, it allows to force search of an automatic proxy for the root user when it does not have KDE or Gnome proxy setting (or plugins networkmanager, gsettings or kconfig are not installed).
Filtering with awk allows to provide one proxy to APT (indeed, several proxies may be returned by the proxy command (and proxy.pac files).
The wrapper can be tested with the following commands:

/usr/local/bin/apt-autoproxy.sh http://ftp.debian.org
sudo /usr/local/bin/apt-autoproxy.sh http://ftp.debian.org

These commands must return a string with no spaces like: http://proxy.example.com:3128 in the presence of a proxy or direct:// if none is usable for this URL.

Aptitude cheat sheet

Landry MINOZA — Wed, 15 Jan 2014 14:05:42 GMT

Here are some aptitude commands I use regularly but not often enough to remember each time…

List of manually installed packages. Usefull to clone an installation:

aptitude search -F%p ~i\!~M

-F set a format string.
%p is replaced by the package name.
~i select all installed packages.
!~M excludes automaticaly installed packages.

With actually installed versions (usefull if some packages comes from backports or external repositories:

aptitude search --disable-columns -F%p=%v ~i\!~M

--disable-columns unset displaying in columns and taking all terminal width.
%v replaced by the version of the package.

Example: to clone a host (after copying all sources.list files):

aptitude install $(ssh machine_modele aptitude search --disable-columns -F%p=%v ~i\!~M |tr '\n' ' ')

Find updates available in backports or experimental:

aptitude versions '~W(~Awheezy-backports(~W(~i!~M)))'
aptitude versions '~W(~Aexperimental(~W(~i!~M)))'

~W ignores the version selected by another filter.
~Axxx select packages from archive xxx.

Lists upgradable packages:

aptitude search ~U

With version numbers:

aptitude search --disable-columns -F'%p     %v      %V' ~U

Lists modified configuration files:

sudo debsums -ce

Backup debconf configurations:

sudo debconf-get-selections > /tmp/conf-paquets.txt

To import as this befor installing packages:

sudo debconf-set-selections < /tmp/conf-paquets.txt

To be continued…

Mise à jour Nikola V6

Landry MINOZA — Tue, 07 Jan 2014 23:09:51 GMT

La version Debian de Nikola a été mise à jour en V6 il y a quelques temps. Ça a été l’occasion d’essayer d’optimiser un peu la configuration du blog et de supprimer les modifications en dur qui me permettaient d’afficher le bouton Flattr.

Les premiers tests après la mise à jour du paquet m’ont fait utiliser le theme oldfashioned, ce qui m’a permis de conserver exactement la même apparence avec mon thème « personnalisé ». Mais j’avait encore pas mal de Warnings à la construction du site.

La seconde étape à donc été de mettre à jour le fichier conf.py de Nikola afin de l’adapter à la nouvelle version. J’ai généré un fichier de conf « propre » en créant un nouveau site, puis j’y ai incorporé toutes les modifications nécessaires, puis j’ai écrasé l’ancien. J’en ai profité pour tester l’interface en français (ça ne fonctionnait pas avec l’ancienne version). J’ai ensuite choisi le thème bootstrap (bootstrap3-gradients me plait bien, mais il semblerait que le paquet Debian ne soir pas prêt pour les thèmes bootstrap3).

J’ai ensuite ajouté les bouton « saociaux », à la lecture de la page dédiée, j’ai décidé d’utiliser SocialSharePrivacy parce qu’il me permet d’utilser Flattr, qu’il reste discret, et surtout qu’il semble par défaut ne pas traquer les visiteurs de ce blog que ne le voudrait pas. J’avoue que j’ai ensuite un peu galéré pour l’intégrer correctement dans la page afin que le placement soit « harmonieux ».

Dernière modification, l’ajout via le paramètre EXTRA_HEAD_DATA d’une css custom dans laquelle je vais pouvoir faire quelques modifications su style par défaut – à commencer par la justification du texte des articles parce que l’alignement à droite, je trouve ça vraiment moche…

Voilà, après un bon mois de procrastination et de tergiversations, je suis satisfait du résultat, je vais pouvoir pousser tout ça en production et me consacrer pleinement aux prochains articles techniques.

check_by_ssh_wrapper

Landry MINOZA — Sun, 27 Oct 2013 17:00:00 GMT

Trying to mutualise Nagios services (or Shinken in my case) and NRPE configuration, sometimes a check returns to many data for NRPE or a host in DMZ don't have NRPE port accessible.

On one infrastructure I monitor, while my NRPE configuration can check free disk space on local file systems (among other), I have a NAS in one DMZ with a lot of file systems (one LVM volume by share). The size of returned data, with Nagios perf data was above NRPE limit (1 kB). Rather than moving NRPE command line in Shinken services configuration and having to handle character escaping, rights and complexify Shinken configuration, I wrote this little script which use via check_by_ssh the same parameters than check_nrpe and read NRPE configuration one the client host to validate the command and execute it.

The code

It is a simple bash script, hosted on GitHub. At time of writing this post, the code is:

#!/bin/bash
#
# check_by_ssh_wrapper
#
# This script provides access to commands declared in nrpe to check_by_ssh
# Please set the nrpeconf variable to the right value
# You must generate a ssh key on the nagios server, copy it in .ssh/authorized_keys
# in nagios (or nrpe) user home directory on distant server, then add this at
# the begining of the line juste before the key:
# no-pty,no-port-forwarding,command="/usr/local/bin/check_by_ssh_wrapper $SSH_ORIGINAL_COMMAND"
#
# You can the use $USER1$/check_by_ssh -H <distant host> -l nagios -C 'check_cmd [args]'
#
# Freely inspired by nagios_ssh_framework. Can be used when nrpe port can't be accessed
# or check_command returns to many text for nrpe and you want to keep facilities of nrpe
# config files.
#
# Changes an Modifications:
# 2011-10-12 - Landry MINOZA - V 1.0
# Created because check_disks returns to many lines for nrpe with one of my servers
#
# Copyright: Telbase Formation Conseil, MUSEE D'ORSAY 2011
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

# Set main nrpe.cfg file
nrpeconf=/etc/nagios/nrpe.cfg

# Get cmdname
cmdname=$1
if [ -z "$cmdname" ] ; then
        echo "WARNING, no command name provided"
        exit 1
fi
shift
# Get optionnal args
cmdargs=$@

# Declare an array of commands
declare -A command

# find all nrpe conf files
include=$(sed -ne '/^include=/ s/^.*=// p' $nrpeconf)
include_dir=$(sed -ne '/^include_dir=/ s/^.*=// p' $nrpeconf)

# Parse all nrpe conf files for command[*]= arguments
for cfgfile in $(echo -e "$nrpeconf\n${include}\n${include_dir}*.cfg") ;do
        eval $(sed -ne '/^command\[/ s/=\(.*\)$/="\1"/ p' $cfgfile)
done

# Check if command[$cmdname] exists
if [ -z "${command[$cmdname]}" ] ; then
        echo "WARNING, command $cmdname does not exist"
        exit 1
fi

# Launch check
exec ${command[$cmdname]} $cmdargs
exit

The code can be divided in 8 parts:

Line 38, to customize, this is the path of NRPE configuration file (for Debian stable here).
Line 40 to 48, command line parameters validation.
Line 51, explicit (and mandatory) declaration of an associative array of commands, it is used to store for each command named in NRPE configuration the related command line.
Line 54 and 55, retrieval of include and include_dir statement in nrpe.conf file to take into account the referenced files. Take care, this include files research is not yet recusive, the statements are only analyzed in the main configuration file.
Line 58 and 60, loop on list on found files.
Line 59, this line is the core of the script, this is a trick base on NRPE configuration syntax, indeed, to declare a command in NRPE, one writes: command[command_name]=command_line options. Lines simply have to be extracted and the command line part (after “=”) have to be quoted, then this have to be executed via eval to fill the array command declared before.
Line 63, testing if a command whith the name given as parameter to the script exists.
At last, line 69, execution of the specified command with his parameters. The explicit exit at the end, ensure that the exit state of the script is the same that the one of the executed command, and so transmited to Nagios.

Installation

This script have to be installed on the monitored host, not on the monitoring server, for instance in /usr/local/bin. The user executing NRPe daemon (on Debian, it is named nagios) must have execution rights on the script. By default, this user have no password set, and we do not want to set one. Anyway, this is generaly a bad idea to have passwords in Nagios configuration files. First, generate a SSH key pair on the monitoring server using the command ssh_keygen as the monitoring daemon user. By default, this commande generates a RSA key, stores the private key in $HOME/.ssh/id_rsa and the public one in $HOME/.ssh/id_rsa.pub. This last is the one we want.

On the monitored host, create in the $HOME of the NRPE daemon user (/var/lib/nagios on Debian) a directory named .ssh whith unix rights rwx------

mkdir /var/lib/nagios/.ssh
chown nagios:nagios /var/lib/nagios/.ssh
chmod u=rwx,go= /var/lib/nagios/.ssh

In the folder, create a file named authorized_keys containing the following line:

no-pty,no-port-forwarding,command="/usr/local/bin/check_by_ssh_wrapper $SSH_ORIGINAL_COMMAND" ssh-rsa AAAA… user@server

Replace AAAA… user@server with the content of the file id_rsa.pub generated on the server. This line [1] permits to allow only the command chaeck_by_ssh_wrapper (only place here an absolute path) to be executed when connectiong with this SSH key and forbid ports forwarding and pseudo-tty allocation. The original command passed to ssh will be provided as parameter to our script via the variable $SSH_ORIGINAL_COMMAND.

Using

In Nagios configuration, just create a new command object:

define command{
        command_name check_by_ssh
        command_line $USER1$/check_by_ssh -H $HOSTADDRESS$ -t 60 -l nagios -C '$ARG1$ $ARG2$'
}

This can be used the same way than check_nrpe in services definitions:

define service{
        use                     base-service
        service_description     check_disks
        display_name            Check Disks
        check_command           check_by_ssh!check_disks
}

Conclusion

This is not perfect, it does not handle recusrive inclusions, but it work as I want since 2 years and permited me to simplify a lot the use of check_by_ssh plugin, securing it as only commands declared in NRPE configuration are usable.

[1]	I'm preparing a more complete post on ssh (and PuTTY).

Debian on HP ENVY dv7, installation

Landry MINOZA — Thu, 10 Oct 2013 14:48:19 GMT

J’ai fait l’acquisition de cette nouvelle machine suite à l’autodestruction de mon ancien portable – un Dell XPS 15 qui n’était pourtant pas si vieux. Je devais bien entendu y installer ma distribution favorite, à savoir Debian (Sid parce que pour un desktop, c’est la meilleure version quand on connait un peu).

Vu que je l’utilise de temps en temps, je désirais conserver l’OS Microsoft™ (version 8) pré-installé gentiment par HP, donc ce sera une installation multiboot (du coup pas de tout repos).

Le matériel

lshw -short -sanitize -numeric
Chemin matériel  Périphérique  Classe         Description
============================================================
                                  system         HP ENVY dv7 Notebook PC (E3C85EA#ABF)
/0                                bus            181D
/0/0                              memory         6GiB Mémoire Système
/0/0/0                            memory         2GiB SODIMM DDR3 Synchrone 1600 MHz (0,6 ns)
/0/0/1                            memory         4GiB SODIMM DDR3 Synchrone 1600 MHz (0,6 ns)
/0/c                              memory         128KiB BIOS
/0/38                             processor      Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz
/0/38/3a                          memory         32KiB L1 cache
/0/38/3b                          memory         256KiB L2 cache
/0/38/3c                          memory         6MiB L3 cache
/0/39                             memory         32KiB L1 cache
/0/100                            bridge         3rd Gen Core processor DRAM Controller [8086:154]
/0/100/1                          bridge         Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:151]
/0/100/1/0                        display        GF108M [GeForce GT 635M] [10DE:DE3]
/0/100/2                          display        3rd Gen Core processor Graphics Controller [8086:166]
/0/100/14                         bus            7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1E31]
/0/100/16                         communication  7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1E3A]
/0/100/1a                         bus            7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1E2D]
/0/100/1b                         multimedia     7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1E20]
/0/100/1c                         bridge         7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1E10]
/0/100/1c.1                       bridge         7 Series/C210 Series Chipset Family PCI Express Root Port 2 [8086:1E12]
/0/100/1c.1/0                     generic        RTS5229 PCI Express Card Reader [10EC:5229]
/0/100/1c.3                       bridge         7 Series/C210 Series Chipset Family PCI Express Root Port 4 [8086:1E16]
/0/100/1c.3/0     wlan0           network        RT3290 Wireless 802.11n 1T/1R PCIe [1814:3290]
/0/100/1c.3/0.1                   generic        RT3290 Bluetooth [1814:3298]
/0/100/1c.5                       bridge         7 Series/C210 Series Chipset Family PCI Express Root Port 6 [8086:1E1A]
/0/100/1c.5/0     eth0            network        RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10EC:8168]
/0/100/1d                         bus            7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1E26]
/0/100/1f                         bridge         HM77 Express Chipset LPC Controller [8086:1E57]
/0/100/1f.2                       storage        82801 Mobile SATA Controller [RAID mode] [8086:282A]
/0/100/1f.3                       bus            7 Series/C210 Series Chipset Family SMBus Controller [8086:1E22]
/0/1              scsi0           storage
/0/1/0.0.0        /dev/sda        disk           1TB HGST HTS541010A9
/0/1/0.0.0/1      /dev/sda1       volume         399MiB Windows NTFS volume
/0/1/0.0.0/2      /dev/sda2       volume         259MiB Windows FAT volume
/0/1/0.0.0/3      /dev/sda3       volume         127MiB reserved partition
/0/1/0.0.0/4      /dev/sda4       volume         146GiB Windows NTFS volume
/0/1/0.0.0/5      /dev/sda5       volume         28GiB Windows NTFS volume
/0/1/0.0.0/6      /dev/sda6       volume         755GiB LVM Physical Volume
/0/2              scsi4           storage
/0/2/0.0.0        /dev/cdrom      disk           DVD A  DS8A9SH
/1                                power          MO06062
/2                                power          OEM_Define5

Comme je pense la plupart des machines récentes, l’antique BIOS a été remplacé par UEFI. Il y a également 2 cartes graphiques, la carte Intel intégrée et une GeForce Nvidia, le tout saupoudré de technologie Optimus. Les cartes réseaux nécessitent des micrologiciels propriétaires, les paquets suivants devront donc être installés :

firmware-ralink
firmware-realtek

Préparation

Afin d’avoir ces micrologiciels dès l’installation, j’ai choisi d’utiliser le média d’installation alternatif comme indiqué sur le wiki Debian

Il faut également de la place pour installer Debian sur le disque, j’ai choisi la facilité : réduire la taille de la partition Windows™ avec gparted en démarrant sur un SystemRescueCd.

Je ne m’amuse plus à graver de CD depuis un moment, donc autant pour SystemRescueCd que pour Debian, le démarrage aura lieu sur une clé USB. Pour SystemRescueCd, c’est bien expliqué sur le site officiel, pour l’ISO netinstall de Debian, c’est simple, il suffit d’utiliser la commande dd.

Concernant Secure Boot, je n’ai pas eu envie de chercher, je l’ai juste désactivé pour le moment.

Installation

L’installation est très classique pour qui a déjà installé une Debian, il est même possible de lancer le téléchargement des paquets en Wi-Fi, attention cependant, à ce jour, la configuration Wi-Fi n’est pas conservée dans le fichier /etc/network/interfaces donc pas de réseau au premier boot…

Afin d’éviter les surprises, et réinstaller tout ce que j’avais sur l’ancienne machine, j’ai réalisé une installation minimale puis j’ai réinstallé tous les paquets installés manuellement dont je récupère la liste grâce à la commande suivante :

aptitude search -F%p ~i\!~M

Il y a ensuite plusieurs façons d’installer cette liste de paquets, j’ai choisi la suivante :

cat installed |xargs aptitude -s install
cat installed |xargs aptitude -y install

Pour récupérer mes données, j’ai commencé par éditer /etc/passwd et /etc/group pour recréer mon login avec les mêmes valeurs, un coup de passwd pour inscrire mon mot de passe dans /etc/shadow. Puis un rsync de mon /home depuis le disque de l’ancien portable vers le nouveau.

UEFI HP et dual-boot

Le sélecteur de démarrage est bogué, il ne retient pas l’ordre indiqué par efibootmgr ou son équivalent sous Windows™, j’ai essayé diverses solutions glanées sur le net et testé rEFInd, rien à faire, le démarrage par défaut se fait toujours sous Windows™. Et rEFInd finalement fait double emploi avec GRUB. J’ai donc opté pour une solution manuelle :

Tout d’abord, il faut récupérer la configuration générée par GRUB pour démarrer Windows™ dans /boot/grub/grub.cfg, ça va nous servir :

menuentry "Windows Boot Manager (UEFI on /dev/sda2)" --class windows --class os {
      insmod part_gpt
      insmod fat
      set root='(hd0,gpt2)'
      search --no-floppy --fs-uuid --set=root 3EE5-0D31
      chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

Ensuite, on neutralise la configuration par défaut en déplaçant le fichier /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi (je l’ai mis dans le répertoire /boot/efi/EFI/Microsoft) et en renommant le fichier /boot/efi/EFI/Boot/bootx64.efi (qui n’est q’une copie du premier) en .old par exemple.
À ce stade, je me suis retrouvé avec grub comme boot par défaut, si d’autres installations existent et entrent en conflit, il faudrait copier le fichier grubx64.efi correspondant en /boot/efi/Boot/bootx64.efi (j’ai préféré ne pas le faire pour m’éviter d’oublier cette opération manuelle à la prochaine mise à jour de GRUB). Je me retrouve donc avec la liste d’éléments bootables suivante :

sudo efibootmgr
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 3002,0003,0004,2001,2002,2003
Boot0002* debian
Boot0003* Network Adapter (IPv4 UEFI)
Boot0004* Network Adapter (IPv6 UEFI)
Boot2001* USB Drive (UEFI)
Boot2002* Internal CD/DVD ROM Drive (UEFI)
Boot3002* Internal Hard Disk or Solid State Disk

Le Windows™ n’est plus bootable, et le générateur de configuration GRUB ne le trouve plus non plus, il faut l’ajouter manuellement en copiant la configuration récupérée précédemment à la fin du fichier /etc/grub.d/40_custom, ajuster les chemins en fonction de l’endroit où on a déplacé le fichier bootmgfw.efi. Enfin il faut mettre à jour la configuration de GRUB (sudo update-grub).

Conclusion

Tout fonctionne à peut près correctement, kdm se lance sans toucher à la configuration de xorg (franchement, je ne m’y attendais pas), même si je ne sais pas quelle carte graphique est utilisée, le fichier de log xorg montre le chargement des pilotes intel et nouveau (je pense essayer Bumblebee bientôt). Le bluetooth intégré à la carte Wi-Fi ne fonctionne pas, d’après ce que j’ai lu rapidement, un pilote existe sur le site du constructeur, mais il ne compilerait pas sur un noyau plus récent que le 3.2. Je mettrais un billet si j’arrive à en sortir quelque chose.