Comment chu trop un sage

Tags:
1 Comment »

Voila un week end BIEN productif ! Comme je ne m’étais pas replongé dans IPv6 depuis la glorieuse époque isdnet, je me suis dit qu’il était grand temps de me rafraîchir la mémoire; j’ai donc été au bout de la certification IPv6 de HE qui va de la simple déclaration d’un tunnel v4/v6 à l’enregistrement d’une zone DNS IPv6 parfaitement fonctionnelle en passant par un MX et un desktop double pile aux petits oignons. Et ça fait du bien !
Compte tenu de la situation, je ne saurais trop vous encourager à faire de même, et de ramener ce savoir dans vos boulots, c’est pas comme si le grand mouvement avait lieu demain, mais compte tenu de l’ampleur de la tâche, il est pas trop tot…
Allez, jme la pête au laser: .

mmmmm les bons spaghettis

Tags: , , , , ,
1 Comment »

Ça commence à sentir le vieux sac de lacets sur ma routing box.
Pour rappel, j’utilise un domU NetBSD hébergé quelque part pour différencier mon traffic sortant. Ce domU est controllé par un dom0 Debian Squeeze, et a ceci de particulier que sa route par défaut part vers la suède. Seuls quelques services répondent directement sur l’IP publique “réelle”, sur laquelle j’opère du SNAT et du DNAT.

Tout ceci manquait cruellement d’un soupçon d’IPv6. Ainsi, après m’être frotté à SixXs et son système de crédits aussi ingénieux que pénible, j’ai finalement opté pour Hurricane Electric qui a en plus le bon goût de posséder un endpoint à Paris.

Si la configuration d’un tunnel v4/v6 se réalise le plus simplement du monde depuis plus de 10 ans via des tunnels gif, l’opération n’est pas complètement triviale lorsque le endpoint se trouve être NATté et qu’en plus ce dernier utilise une route par défaut différente de l’IP publique officielle du dom0.

Ainsi, après avoir souscrit à un endpoint IPv6 chez HE, quelques opérations sont nécessaires au bon fonctionnement du routage. Nous considèrerons que l’ip du endpoint gif IPv4 chez Hurricane est 1.2.3.4 et que notre IPv4 publique, sur le dom0 donc, est 5.6.7.8.

La première chose à faire sur notre dom0 est de rediriger tout le traffic en provenance de HE vers notre domU, dont nous considèrerons que l’IPv4 privée est 192.168.0.1.

# iptables -t nat -A PREROUTING -i eth0 -s 1.2.3.4 -j DNAT --to-destination 192.168.0.1

Il faudra évidemment, si cela n’est pas déjà fait, appliquer du SNAT afin que votre domU puisse “sortir” et se présenter avec notre IPv4 publique au monde. Par exemple:

# iptables -t nat -A POSTROUTING -s 192.168.0.1/32 -o eth0 -j SNAT --to-source 5.6.7.8

C’est l’unique configuration à effectuer sur le dom0. Jusqu’ici tout va bien.

Sur notre domU NetBSD, nous créons l’interface de tunneling comme ceci:

# ifconfig gif0 create
# ifconfig gif0 tunnel 192.168.0.1 1.2.3.4
# ifconfig gif0 inet6 2001:470:1e31:b2c::2 2001:470:1e31:b2c::1 prefixlen 128

Notez que c’est bien l’IPv4 privée que nous utilisons pour monter le tunnel gif, le SNAT du dom0 s’occuppera de transformer cette IP au vol.
Cette seule configuration, compte tenu du routage particulier de notre domU, ne suffira pas au bon fonctionnement du tunnel. Deux opérations sont nécessaires:

  • Ajouter une route explicite vers le endpoint HE
  • Forcer la sortie vers l’interface réelle du dom0 lorsqu’on essaye de joindre une adresse IPv6

Execution:

# route add -host 1.2.3.4 192.168.0.254

Ici, 192.168.0.254 est l’adresse passerelle du dom0.

# grep he_tunnel /etc/pf.conf-ovpn
he_tunnel="1.2.3.4/32"
pass out quick route-to ($real_if $gateway) from any to $he_tunnel

$real_if représente l’interface xennet0, et $gateway l’adresse de notre passerelle coté dom0, à savoir 192.168.0.254.
Reste à appliquer une route par défaut pour les adresses IPv6:

route -n add -inet6 default 2001:470:1e31:b2c::1

Et nous y sommes. Enfin, il faut evidemment automatiser toutes ces manipulations afin de retrouver notre état fonctionnel à chaque reboot, cela est réalisé en créant le fichier /etc/ifconfig.gif0 avec ce contenu:

create
tunnel 192.168.0.1 1.2.3.4
inet6 2001:470:1e31:b2c::2 2001:470:1e31:b2c::1 prefixlen 128
!route add -host 1.2.3.4 192.168.0.254
!route -n add -inet6 default 2001:470:1e31:b2c::1

And voila, Danse petite tortue, danse !

Tu te CALMES le dom0

Tags: , ,
1 Comment »

Voici ce que crachait l’un de mes dom0 Debian/Squeeze sous Xen 4.0:

Nov 10 05:32:22 yavin kernel: [838380.839883] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
Nov 10 05:32:22 yavin kernel: [838380.839883] Modules linked in: dummy xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_physdev iptable_filter ip_tables x_tables xen_evtchn xenfs bridge stp ext2 w83627hf w83793 hwmon_vid loop snd_pcm snd_timer snd radeon soundcore snd_page_alloc ttm drm_kms_helper parport_pc drm parport pcspkr evdev i2c_i801 i2c_algo_bit rng_core serio_raw i2c_core container shpchp pci_hotplug i3000_edac button processor edac_core acpi_processor ext3 jbd mbcache dm_mod raid1 md_mod sd_mod crc_t10dif ata_generic uhci_hcd ata_piix libata thermal floppy ehci_hcd scsi_mod thermal_sys usbcore nls_base e1000e [last unloaded: dummy]

Le tout saupoudré de quelques stack traces du meilleur effet:

Nov 11 19:52:20 yavin kernel: [976376.042974]    [] ? xen_swiotlb_unmap_page+0x0/0x5
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_force_evtchn_callback+0x9/0xa
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? check_events+0x12/0x20
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_swiotlb_unmap_page+0x0/0x5
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_restore_fl_direct_end+0x0/0x1
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? kfree+0xc6/0xcb
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? skb_release_head_state+0xb4/0xc8
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? __kfree_skb+0x9/0x7d
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_put_txbuf+0x5a/0x6c [e1000e]
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_clean_tx_irq+0x9d/0x21e [e1000e]
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_clean+0x5c/0x235 [e1000e]

Et j’en passe. Bref, ça pue.

Après m’être documenté quelque peu sur les erreurs constatées, deux actions semblent avoir stabilisé la situation. Premièrement, plusieurs posts dans quelques forums indiquent que l’installation de intel-microcode et microcode.ctl permet de “réparer” certains bugs embarqués dans les processeurs Intel. Je m’execute:

# apt-get install intel-microcode microcode.ctl

Deuxièmement, comme le conseille la section Best Practices de Xen.org, il est de bon ton de:

  • Fixer la quantité de mémoire du dom0 afin d’éviter le ballooning
  • Attacher un core (“cpu pinning”) au dom0

Ainsi, j’ajoute la ligne suivante au fichier /etc/default/grub:

GRUB_CMDLINE_XEN="dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin"

Et précise dans /etc/xen/xend-config.sxp:

(dom0-min-mem 1024)

Ne disposant, sur cette machine, que de deux cores, je n’exclurai pas le CPU0 de la configuration des domU, mais fais confiance à l’hyperviseur pour équilibrer les ressources efficacement, sachant que désormais le CPU0 est “pinné” au dom0. Reste alors à régénérer la configuration de grub:

# update-grub

Et, malheureusement, de rebooter. Pas le choix ici.

Moyennant ces ajustements, mon dom0 ne semble plus souffir, alors que ses domUs compilent à tour de bras.

SMTP AUTH sous NetBSD, vite fait

Tags: , , ,
No Comments »

Heureux possesseur d’un téléphone Android, j’utilise comme bon nombre de mes compères le logiciel K9-mail, probablement le meilleur MUA disponible sur cette plateforme, et qui a le bon goût d’être Libre, au contraire des centaines de milliers d’applis merdiques à 0.99€.
Jusqu’à présent, je n’utilisais K9 que pour lire mon mail, essentiellement dans le metro, “on the go”. Et puis finalement, je suis dit qu’il serait fort convivial de pouvoir utiliser mon serveur mail perso depuis un peu partout.
Mon serveur mail, est-il besoin de le préciser, est un domU NetBSD sur lequel sont executés Sendmail et dovecot.
Il y a un certain temps de cela, j’avais documenté la méthode pour FreeBSD, et assez étrangement, jamais pour NetBSD. Je vais donc corriger le tir de ce pas.

La première chose à faire est de préciser que nous souhaitons bénéficier du support TLS et SASL dans sendmail. Ceci est réalisé dans le fichier /etc/mk.conf:

PKG_OPTIONS.sendmail=   tls sasl

Je ne sais pas si cela est lié au fait que la machine sur laquelle j’ai mené l’opération est “encore” en 5.0.2, mais la compilation de cyrus-sasl a misérablement échoué dans sa configuration par défaut. Ceci:

db_ndbm.c: In function '_sasldb_getdata':
db_ndbm.c:95: warning: passing argument 3 of 'utils->getcallback' from incompatible pointer type

M’a mis sur la voie, et j’ai donc ajouté dans mon /etc/mk.conf la ligne suivante:

SASL_DBTYPE=            berkeley

Un make update clean plus loin, tout était installé. Il est à noter que, par défaut, cyrus-sasl ne fournit aucun plugin, aussi, il sera nécessaire d’en installer au moins un, par exemple:

# cd /usr/pkgsrc/security/cy2-login
# make install clean

Qui nous permettra d’utiliser le couple login/password de notre système. Deux étapes sont nécessaires pour utiliser cette méthode, tout d’abord, il faut installer le démon saslauthd, en charge des échange d’authentification plain text:

# cd /usr/pkgsrc/security/cyrus-saslauthd/
# make install clean
# cp /usr/pkg/share/examples/rc.d/saslauthd /etc/rc.d
# echo "saslauthd=YES" >> /etc/rc.conf
# /etc/rc.d/saslauthd start

Puis de préciser au plugin SASL qu’il devra utiliser le démon saslauthd pour l’authentification en provenance de sendmail.

# cat /usr/pkg/lib/sasl2/Sendmail.conf
pwcheck_method:saslauthd

Nous ajoutons maintenant à sendmail la gestion de ces deux nouvelles fonctionnalités:

# cd /usr/pkg/share/sendmail/cf
# cat monserveur.mc
[...]
dnl ### SMTP AUTH
define(`confAUTH_MECHANISMS', `LOGIN')dnl
TRUST_AUTH_MECH(`LOGIN')dnl
dnl ### STARTTLS
dnl ### Ces sertificats sont en provenance de CACert.org. Il ne s'agit pas de certificats auto-signés
define(`confCACERT_PATH',`/etc/mail/certs/')dnl
define(`confCACERT', `/etc/mail/certs/cacert.crt')
define(`confSERVER_CERT',`/etc/mail/certs/certificat_serveur.pem')dnl
define(`confSERVER_KEY',`/etc/mail/certs/certificat_privatekey.pem')dnl
[...]

Puis nous compilons et installons la nouvelle configuration:

# make install-cf CF=monserveur
rm -f monserveur.cf
m4 ../m4/cf.m4 monserveur.mc > monserveur.cf || ( rm -f monserveur.cf && exit 1 )
echo "### monserveur.mc ###" >>monserveur.cf
sed -e 's/^/# /' monserveur.mc >>monserveur.cf
chmod 444 monserveur.cf
/usr/bin/install -c -o root -g wheel -m 0444 monserveur.cf /etc/mail/sendmail.cf
/usr/bin/install -c -o root -g wheel -m 0444 monserveur.cf /etc/mail/submit.cf

À l’issue d’un /etc/rc.d/sendmail restart, nous devrions constater les choses suivantes:

# sendmail -d0.1 -bv root | grep SASL
                SASLv2 SCANF SOCKETMAP STARTTLS TCPWRAPPERS USERDB XDEBUG

Et également:

# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220monserveur ESMTP Sendmail 8.14.5/8.14.5; Fri, 11 Nov 2011 13:13:17 +0100 (CET)
ehlo localhost
250-monserveur Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE 5000000
250-DSN
250-ETRN
250-AUTH LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP

Ne reste alors qu’à configurer votre MUA pour qu’il utilise votre serveur SMTP sur le port 587 en TLS avec la méthode LOGIN, avec les login/passwd de l’utilisateur souhaité.

Enjoy.

MIX ALL THE SOURCES!!!

Tags: , ,
3 Comments »

Ce matin, j’ai mis à jour le dom0 Debian d’une de mes machines. Passionnant me direz-vous. L’opération a consisté en la migration de Lenny vers Squeeze. De plus en plus interessant hein ? L’upgrade s’est effectué sans trop de peine, après quelques apt-get -f install et autres réinstallations de packages ayant sauté dans la bataille, rien de palpitant. Me voici donc avec un kernel 2.6.35-2 sur un Xen 4 flambant neuf.

Ce dom0 accueille des domU NetBSD. Des NetBSD 5.0.2 pour être précis. Et c’est le drame: Le PR 44743 indique en effet:

Subject: Network doesn’t work on DomU NetBSD 5.1 which is run on Debian Squeeze Dom0 (Xen 4)

Ce à quoi Dieu^WManuel Bouyer répond:

No, copy mode support was added to the backend (dom0) before 5.1, but
it was added to the frontend (domU) after 5.1 was released. So you need
something newer from the netbsd-5 branch.

Vous voyez poindre le bordel ? “Mais migre, bigre de couillon” me direz-vous, et vous aurez raison, seulement cette machine construit des packages (via bulk build, voir le post précédent) pour un certain nombre d’autres machines, elles aussi en 5.0.2. Bref, rien n’est simple. J’ai donc adopté une méthode “alternative” (aussi appelée la méthode *rhon* *rhon* *huiiiiii*): patcher le noyau 5.0.2 avec les bits and pieces nécessaires en provenance de netbsd-5. Finalement, cela n’a pas été si compliqué. Il suffit de cvs up -rnetbsd-5 -dP dans src/sys/arch/xen et src/sys/arch/x86 puis de relancer un config, make depend, make pour obtenir un noyau domU 5.0.2 muni du support copy mode.

“All went better than expected”.

Aiguille, fil, trou

Tags: , ,
No Comments »

Pour une partie de mon parc de machines, je fais mon propre bulk build. Ce dernier ne construit pas l’ensemble des packages, mais un petit subset (environ 600 packages) avec mes propres préférences. Parmi elles, il en est une qui fout un merdier sans nom dans le build, converters/libiconv. Comme je l’expliquais ici il y a quelques temps, j’ai besoin de construire converters/php-iconv avec la version pkgsrc de la libiconv. Cet impératif a un impact non négligeable dans la configuration de mon /etc/mk.conf, aussi je vous livre ce dernier, final et fonctionnel:

.ifdef BSD_PKG_MK

# no base X11
MKX11=no
X11_TYPE=modular
# clean dependencies when the "clean" target is called
CLEANDEPENDS=yes
# everybody likes vim
ACCEPTABLE_LICENSES+=vim-license

USE_BUILTIN.iconv=      no
# A built-in gettext is always going to use a built-in iconv.
USE_BUILTIN.gettext=    no

PKG_RCD_SCRIPTS=        yes

PKG_OPTIONS.irssi=      perl inet6
PKG_OPTIONS.mplayer=    oss

DSPAM_STORAGE_DRIVER=   mysql
PKG_OPTIONS.dspam+=     graphs
MYSQL_VERSION_DEFAULT=  50
PHP_VERSION_DEFAULT=    52
PKG_OPTIONS.php=        -cgi fastcgi

PKG_OPTIONS.rtorrent=           xmlrpc

UPDATE_TARGET=package-install
DEPENDS_TARGET=         bulk-install
BATCH=                  yes

ACCEPTABLE_LICENSES+= socks5-license
ACCEPTABLE_LICENSES+= sendmail-license
ACCEPTABLE_LICENSES+= openmotif-license
ACCEPTABLE_LICENSES+= idea-license

PKG_OPTIONS.dovecot=    ssl ldap dovecot-sieve dovecot-managesieve
PKG_OPTIONS.nagios-nrpe = ssl tcpwrappers

PKGCHK_CONF?=   /usr/pkgsrc/pkgchk.conf
BULK_PREREQ+=   converters/libiconv
#
# Parse pkgchk.conf and supply list of packages for the bulk build framework.
#
.if defined(SPECIFIC_PKGS)
PKGLIST!=               awk '{print $$1}' ${PKGCHK_CONF}
.  for _pkg_ in ${PKGLIST}
HOST_SPECIFIC_PKGS+=    ${_pkg_}
.  endfor
.endif

.endif # BSD_PKG_MK

À noter, donc, les particularités suivantes:

  • Xorg modular pour les dépendances relatives à X11
  • libiconv en provenance de pkgsrc, il est impératif de faire de même pour gettext
  • irssi est compilé avec le support perl et IPv6
  • storage MySQL pour dspam
  • MySQL 5.0
  • PHP 5.2
  • Options ssl ldap dovecot-sieve et dovecot-managesieve pour dovecot
  • Options ssl et tcpwrappers pour nagios-nrpe
  • On ajoute libiconv comme pré-requis pour la construction bulk

J’utilise, pour générer tout ce petit monde, l’excellent script du sieur orgrim, disponible ici, avec sa note explicative.

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in
Performance Optimization WordPress Plugins by W3 EDGE