GuiGui's Show

« CVE-2015-8688: Gajim doesn’t verify the origin of roster pushes thus allowing third parties to modify the roster. »

Pour les personnes qui aiment taper sur la team Debian Security, vous avez là un exemple : correction par les dev Gajim fin décembre (https://trac.gajim.org/changeset/af78b7c068904d78c5dfb802826aae99f26a8947/ ), DSA fin février. :)

Via b4n (http://ban.netlib.re/shaarli/)

Nous avons déjà étudié un cas d'ingénierie de trafic BGP, voir http://shaarli.guiguishow.info/?9sfiXw . Aujourd'hui, nous allons étudier un autre cas réel plus compliqué. :)

Chez ARN, on a 3 transitaires pour nous connecter au reste des réseaux qui composent Internet :
    * Cogent
    * Interoute
    * Hurricane Electric dit HE (IPv6 uniquement)

L'interconnexion avec HE consiste en 2 tunnels 6in4 (car nous avons deux routeurs), un avec le PoP (Point of Presence, endroit/datacenter dans lequel un opérateur/hébergeur est présent) de HE à Francfort, l'autre avec le PoP de HE à Londres. Voir http://shaarli.guiguishow.info/?X_2rrQ . Londres et Francfort, c'est pour éviter les pannes locales (qui concerne un seul PoP) côté HE qui arrivent bien plus souvent qu'on ne le croit.

Ces tunnels 6in4 étaient pleinement justifiés avant la mise en production de notre deuxième transitaire, Interoute puisque HE et Cogent sont en guéguerre commerciale depuis plus de 5 ans et qu'il est donc impossible de joindre le réseau HE (et tous les "abonnés" 6in4 qu'HE a...) depuis Cogent...

Depuis qu'Interoute est tombé en marche, nous faisons de l'ingénierie de trafic sur les sessions BGP que nous avons avec HE :
    * On sort par HE uniquement si l'on n'a pas le choix c'est-à-dire si ni Cogent ni Interoute n'ont une route équivalente même si elle est moins optimale en terme de nombre de réseaux traversés. Pour ce faire, on diminue la local preference des préfixes IP qui nous arrivent via HE.

    * On conseille aux autres réseaux d'Internet d'utiliser HE pour nous joindre uniquement en dernier secours, s'ils n'ont pas une route équivalente via Cogent/Interoute. Pour ce faire, on utilise la technique de l'AS-prepending pour rallonger l'AS_PATH en insérant 2 fois supplémentaires notre ASN dans celui-ci. Ce conseil peut être parfaitement ignoré par les réseaux qui peuvent utiliser la localpref ou un poids (weight) pour forcer leurs routeurs à passer par HE malgré nos recommandations.




Depuis la mise en production de notre deuxième transitaire, nous observons de sévères pertes de paquets régulières (plusieurs fois par jour, vraiment beaucoup trop) en IPv6. C'est très pénible car ça casse les sessions SSH et ça fait hurler notre monitoring externe (monitoring en dehors de notre AS pour vérifier que les services que nous proposons sont bien accessibles depuis l'extérieur de notre réseau ce qui permet de vérifier qu'on n'a pas fait une erreur de config' et qu'on a bien ouvert le pare-feu,...).

En faisant des recherches, on s'aperçoit que les réseaux impactés sont ceux qui utilisent HE pour communiquer avec nous. Nous utilisons bien Cogent ou Interoute pour leur livrer le trafic mais eux nous répondent via HE. Oui, le trafic n'est pas forcément symétrique sur Internet et c'est même plutôt l'inverse.

Vu que cela se produit depuis la mise en production de notre 2e transitaire, on peut s'interroger :
    * Et si le problème venait du prestataire via lequel notre tunnel 6in4 est monté ? Nos routeurs choisissent Interoute pour communiquer avec HE en IPv4 car c'est le chemin le plus court. HE choisi Interoute car il n'a rien d'autre. Forcer le trafic IPv4 à destination d'HE à passer par Cogent ne changerait pas grand'chose puisque HE nous répondrait par Interoute donc s'il y a un embouteillage sur Interoute, on ne le contournerait pas.

    * Néanmoins, un mtr (traceroute dynamique utilisant ICMP au lieu de paquets TCP) semble indiquer que la perte de paquets a lieu au PoP de HE à Francfort. Je dis « semble » car on ne peut avoir de certitude : mtr utilise ICMP qui est un protocole auquel les routeurs prêtent moins d'attention (car il nécessite d'être traité de manière logicielle là où le transfert de paquets IP se fait de manière matérielle), surtout quand ils ont du taff à faire. Autrement dit : une perte de paquets ICMP ne signifie pas une perte de paquets IP.




Revenons donc à IPv6, au dessus du tunnel 6in4. Prenons l'un des réseaux qui choisissent d'échanger avec nous via HE, Tetaneutral.net et regardons les choix de leur routeur (via leur looking glass : http://lg.tetaneutral.net ) :

2a00:5881:8100::/40 via 2001:7f8:54::10 on eth0.4032 [FRANCEIX_RS1_6 2016-02-09 22:34:51 from 2001:7f8:54::250] * (370) [AS60630i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 6939 60630 60630 60630
BGP.next_hop: 2001:7f8:54::10 fe80::224:38ff:fe7e:7100
BGP.med: 1
BGP.local_pref: 100
BGP.community: (51706,64601) (51706,64650)
                   via 2001:7f8:54::10 on eth0.4032 [FRANCEIX_RS2_6 2016-02-09 22:34:51 from 2001:7f8:54::251] (369) [AS60630i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 6939 60630 60630 60630
BGP.next_hop: 2001:7f8:54::10 fe80::224:38ff:fe7e:7100
BGP.med: 1
BGP.local_pref: 100
BGP.community: (51706,64602) (51706,64650)
                   via 2001:7f8:54::10 on eth0.4032 [HE_FRANCEIX_6 2016-02-09 22:34:51] (360) [AS60630i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 6939 60630 60630 60630
BGP.next_hop: 2001:7f8:54::10 fe80::224:38ff:fe7e:7100
BGP.local_pref: 100
                   via 2a01:6600:3000:1::1 on eth0.2301 [FULLSAVE_TLS00_6 2016-02-02 17:31:01] (350) [AS60630i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 39405 3215 5511 8928 60630
BGP.next_hop: 2a01:6600:3000:1::1 fe80::f6b5:2f08:fdd7:7954
BGP.med: 0
BGP.local_pref: 100
BGP.community: (39405,22001) (39405,31000) (39405,31104)
                   via 2001:978:2:68::8:1 on eth4 [COGENT_TLS00_6 2016-02-02 08:19:20] (350) [AS60630i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 174 60630
BGP.next_hop: 2001:978:2:68::8:1 fe80::aa0c:dff:fe5e:c0df
BGP.med: 30051
BGP.local_pref: 100
BGP.community: (174,21101) (174,22008)

Verdict : Tetaneutral choisit bien de passer par HE (on repère la route sélectionnée car elle a une petite étoile « * »). Pourtant l'AS_PATH, donc le nombre de réseaux traversés est plus long ! Pour forcer une route même si la longueur de l'AS_PATH est défavorable, il faut utiliser la localpref. Mais ici la localpref est identique ! Il y a autre chose. Il faut regarder le nombre entre parenthèses vers la fin de chaque première ligne : 370 369, 360, 350.

Il s'agit d'un poids, soit ce qui a le plus de valeur dans l'algorithme de sélection d'une route en BGP : il passe devant la localpref qui elle-même passe avant la longueur de l'AS_PATH... Différence entre poids et préférence locale ? Le poids n'est pas propagé en iBGP. Le poids vaut 0 par défaut, le plus élevé est préféré.

Pour faire de même avec Quagga, il faut utiliser « neighbor 2001:db8::1 weight <poids> ». Pour faire de même avec BIRD : « protocol <nom> { preference <poids>; } ». Avec BIRD, je trouve que cette notion de préférence est un mélange confus entre un poids et une distance administrative (qui sert à déterminer quel protocole de routage (static, BGP, OSPF) l'emporte quand plusieurs ont sélectionné une route pour un même préfixe, voir https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html) chez Cisco...

Quel est l'objectif que Tetaneutral.net cherche à atteindre en faisant cela ? Privilégier les points d'échanges et les interconnexions privées directes (PNI), les deux composantes du peering, au transit. C'est un comportement des plus respectable : Internet devrait être uniquement du peering, c'est-à-dire de l'échange réciproque de trafic qui s'annule (en terme de débit consommé) sans rémunération. De plus, le peering offre souvent une meilleure qualité (latence et absence de perte de paquets) que le transit). Néanmoins, dans notre cas, ça entre en conflit avec notre volonté de ne pas utiliser un tunnel 6in4 tout crade (ça favorise la concentration du trafic chez un petit nombre d'acteurs donc centralisation dangereuse, surveillance & co et ça permet de maintenir le statu quo du non-déploiement d'IPv6) tout en sécurisant une route vers HE.




Que faire ? On veut que les réseaux utilisent Interoute ou Cogent pour échanger avec nous mais, si Interoute tombe en panne (ou maintenance programmée), on veut pouvoir encore communiquer avec HE (ce que Cogent ne permet pas, pour rappel ;) ). Réfléchissons :

    * On ne peut pas forcer les réseaux à choisir un autre chemin qu'HE car le poids et la localpref ont plus d'impact que les critères sur lesquels nous pouvons influer.

    * On pourrait couper nos sessions BGP avec HE et les monter uniquement quand Interoute est en panne. C'est très contestable : 1) les admins ARN n'auront pas le temps de réagir aux coupures courtes. 2) C'est le propre même d'utiliser un protocole de routage dynamique que de n'avoir rien à faire à la mano. 3) En associatif, ça consomme du temps libre que l'on n'a pas.

    * On pourrait découper notre allocation IPv6 en blocs plus petits et les annoncer tous un à un uniquement sur Interoute et Cogent. Cela tient d'un concept fort du routage IP : on sélectionne la route la plus spécifique, la plus précise, celle qui porte sur le moins d'adresses (un bloc /25 (128 adresses) est plus précis qu'un /22 (1024 adresses), par exemple). Si l'on annonce des préfixes plus spécifiques uniquement sur Interoute et Cogent, alors le trafic arrivera forcément par là, +/- ce qu'on nomme le trafic résiduel qui provient de réseaux qui ne reçoivent pas ces annonces plus spécifiques pour diverses raisons...
    Désagréger son allocation en sous-blocs dans le seul but de faire de l'ingénierie de trafic, ce n'est pas top du tout car ça contribue à ajouter des entrées inutiles dans la table de routage mondiale et donc à la faire grossir inutilement. Les cartes installées dans les routeurs qui transfèrent les paquets IP ont un nombre limité d'entrées dans leur mémoire TCAM et lorsqu'elle est saturée, le transfert des paquets s'effectue de manière logicielle donc plus lentement.
    On constate aussi que les opérateurs configurent leurs routeurs qui ont trop peu de mémoire pour supporter toute la table IPv4 de manière à rogner sur le nombre d'entrées IPv6 possibles (voir https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html ) dans le but de prolonger leur durée d'exploitation.
    Avec le plan d'adressage que nous avons choisi (voir https://wiki.arn-fai.net/technique:adressage#public ), nous utilisons partiellement 2 * /44 et 3 * /48. Donc il faudrait rajouter au moins 2 entrées dans la table de routage mondiale. No way !

    * En fait, ce que l'on voudrait c'est qu'HE ait une route vers nous, même si Interoute tombe mais qu'il ne la communique à personne. Cela existe et se nomme communauté no-export.
    Une communauté est un tag que l'on place sur un ensemble de préfixes IP. Ce tag permet de déclencher une action qu'un pair BGP a programmée à l'avance comme ne pas réannoncer ces préfixes, les réannoncer en faisant de l'AS-prepending, les réannoncer mais uniquement aux peers européens,....
    Plusieurs communautés sont normalisées à l'IETF (https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml ) dont la fameuse « no-export » qui demande à ce que l'annonce ne soit pas relayée en dehors du réseau du pair.




C'est cette dernière méthode que nous allons choisir : nous allons définir une localpref défavorable pour que nos routeurs n'utilisent pas HE pour sortir sauf si c'est la seule possibilité restante et nous allons positionner la communauté no-export sur notre session avec HE pour qu'HE puisse communiquer avec nous, même si Interoute tombe et sans faire fuiter cette information.

Nous allons aussi ignorer les préfixes qui ne sont pas annoncés par HE. Ça se justifie dans un seul cas : si Interoute tombe en panne, alors on utilisera HE pour joindre le réseau HE. Cogent prendra la main sur tout le reste (grâce à la localpref ;) ). Et si Cogent IPv6 tombe en même temps ? Nos routeurs vont vouloir sortir par HE pour joindre le reste de l'Internet IPv6. HE va bien transmettre nos paquets à la destination... qui ne pourra pas nous répondre puisqu'aucune route ne sera disponible (on a dit a HE de ne pas dire qu'il a une route vers nous ;) ).


Avec BIRD (limité au strict minimum) :
filter bgp_filter_hurricane_electric_in
{
    if bgp_path.last = 6939 then
    {
        bgp_local_pref = 90;
        accept;
    }

    reject;
}

# "_ou" = "_out" mais nom trop long pour BIRD
filter bgp_filter_hurricane_electric_ou
{
    # AS-prepending
    bgp_path.prepend(60630);
    bgp_path.prepend(60630);

    # Ajout de la communaute no-export
    bgp_community.add((65535,65281));

    accept;
}

protocol bgp bgp_hurricane_electric
{
    local as 60630;

    neighbor 2001:470:12:74::1 as 6939;
    source address 2001:470:12:74::2;

    import filter bgp_filter_hurricane_electric_in;

    export filter bgp_filter_hurricane_electric_ou;
}



Avec Quagga (limité au strict minimum) :
conf t

ip as-path access-list HE-asn permit _6939$

route-map disgrace-HE-in permit 5
    match as-path HE-asn
    set local-preference 90
route-map disgrace-HE-in deny 10

route-map disgrace-HE-out permit 5
    set as-path prepend 60630 60630
    set community additive no-export

router bgp 60630
    neighbor 2001:470:12:74::1 remote-as 6939
    no neighbor 2001:470:12:74::1 activate
    neighbor 2001:470:12:74::1 interface he-ipv6
    neighbor 2001:470:12:74::1 update-source 2001:470:12:74::2

    address-family ipv6
        neighbor 2001:470:12:74::1 activate
        neighbor 2001:470:12:74::1 route-map disgrace-HE-in in
        neighbor 2001:470:12:74::1 route-map disgrace-HE-out out
    exit-address-family




On peut ensuite vérifier :
    * Tetaneutral.net ne nous voit plus via HE : http://lg.tetaneutral.net/prefix_detail/h7/ipv6?q=web.arn-fai.net

    * Même chose à plus large échelle : http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv6?q=web.arn-fai.net

    * HE dispose bien de deux routes directes vers nous (une par PoP où nous sommes interconnectés) qu'il conserve pour son usage propre : http://lg.he.net/ (cocher « BGP Route » et saisir « 2a00:5881:8100::/40 » dans « IP/Hostname »).

    * Cette méthode a résolu notre problème de perte de paquets. \o/


Les esprits taquins remarqueront qu'HE utilisera toujours les tunnels 6in4 pour échanger avec nous... Même quand une route via Interoute est disponible... C'est moche pour les raisons éthiques évoquées plus haut mais aussi parce qu'on peut présumer que le problème de paquets va persister entre nous.

Que pouvons-nous y faire ? HE positionne une localpref = 140 sur nos interconnexions directes alors qu'elle est de 100 (valeur par défaut) sur la route qu'il reçoit via Interoute... On ne peut rien y faire à distance puisque la localpref est prioritaire sur les critères sur lesquels nous pouvons influer.

On peut leur demander de faire une exception pour nous puisqu'Internet est avant tout une construction humaine de gens qui communiquent. Notre demande a été refusée. Et c'est parfaitement compréhensible : vu la taille (nombre de PoP et donc de routeurs à travers le monde) du réseau HE et les services proposés, des automates ont été programmés et des templates/peer-groups doivent être utilisés sur les routeurs, laissant peu de place à la bidouille au profit d'un seul réseau.

Les seules solutions restantes sont : couper nos sessions BGP avec HE et les monter seulement quand Interoute tombe en panne ou désagréger notre allocation IPv6... J'ai déjà expliqué ci-dessus pourquoi nous ne ferons pas ça.


On notera un dernier défaut à cette manière de faire : dans une config' à un seul transitaire restant (donc dans une situation de panne), on fait l'hypothèse que le prestataire restant aura au moins une route vers tous les réseaux IPv6 qui composent Internet. Le seul défaut peut se situer sur HE (puisqu'on est connecté avec eux aussi longtemps qu'on a une liaison IPv4).

« Le FBI qui réclame en justice l’aide d’Apple pour débloquer le téléphone de l’auteur de la tuerie de San Bernardino a-t-il lui-même ruiné la possibilité d’obtenir une copie en clair des informations qui y sont stockées ? C’est ce que laisse entendre Apple dans la réponse qu’il adresse au juge pour justifier son opposition à fournir un moyen de contourner la mesure de sécurité imposée sur l’iPhone 5C du tueur.

[...]

À cette occasion, on découvre surtout qu’Apple avait peut-être le moyen d’obtenir une copie partielle des données stockées sur le téléphone, en rusant. Par défaut, les iPhone sont en effet configurés pour synchroniser avec iCloud les données liées aux applications Apple (contacts, documents, photos, vidéos, notes, historique de navigation Safari…). Tout est copié en permanence vers les serveurs d’Apple, mais à la condition d’utiliser un réseau Wi-Fi reconnu par l’iPhone. »

Note : même les messages échangés avec iMessage sont sauvegardés sur le cloud d'Apple... Voir : http://sebsauvage.net/links/?GnnBuw

Ho, Apple, la grande militante pour le chiffrement fort (lol) aurait en fait un moyen détourné d'accéder aux données d'un appareil Apple sans casser le chiffrement. Surprise, on ne s'en doutait pas du tout (ironie, hein). C'est tout le jeu des GAFA depuis les révélations Snowden : rassurer le grand public (pour ne pas perdre d'audience et donc de chiffre d'affaires émanant de la publicité) avec des mesures de sécurité bidons qui sont seulement des illusions d'optique. Ne leur faîtes pas confiance ! Vos données persos, ça se stocke chez vous ou dans une asso locale sur une infrastructure en logiciel libre communautaire en utilisant du chiffrement dont vous seul avez la clé. Même chose lorsqu'il s'agit de les faire transiter : logiciel libre + communauté + chiffrement de bout en bout.

« Sometimes, it is a good idea to scrub EXIF metadata from photos before sharing them, and there is no better tool for the job than exiftool »

exiftool -all= foo.jpg
exiftool -all= *.jpg

Malgré ce qu'affirme le dev' de gns3 dans le thread, il n'est effectivement pas possible d'utiliser qinq avec un switch dans gns3 : le paquet est bien doublement taggé mais avec le même VLAN ID alors que l'outer tag, défini par le provider peut justement être différent de l'inner tag, défini par le client. Essayez sa maquette en plaçant un hub entre les deux switchs puis en effectuant une capture réseau à partir d'un routeur connecté à ce même hub : l'outer tag n'est pas le bon (répétition de l'inner tag alors qu'on veut 999 en outer tag).

Après plusieurs heures de recherche, il me semble qu'il n'est pas possible d'utiliser qinq avec gns3/dynamips sans avoir recours à un switch physique externe (aucun IOS supporté par gns3/dynamips ne supporte dot1q-tunnel et gns3 fail cf paragraphe précédent).

John McAfee qui fait de l'esbroufe, ce n'est pas un scoop. L'info clé est plutôt celle-ci àmha :

« Des précédents de déchiffrement acceptés par Apple

Autre point de vue décalé par rapport à la position rigide d’Apple sur le non déchiffrement de ses produits, The Daily Beast qui déterre un procès similaire datant de 2015, au cours duquel Cupertino a reconnu être en mesure d’extraire les données chiffrées d’un iPhone. Selon le procureur, qui officiait alors au sein de cette juridiction new-yorkaise, Apple est même rompu à cet exercice : il aurait aidé les autorités à accéder aux données de ses terminaux plus de 70 fois depuis 2008.

Certes, dans le cas de l’iPhone de New York, il s’agissait d’un terminal sous iOS 7, moins sécurisé que la version 9 de l’OS qui anime l’iPhone 5c que le FBI a entre les mains dans l’affaire de la tuerie de San Bernardino. Mais les experts interrogés par nos confrères assurent qu’Apple est tout aussi capable de contourner les sécurités d’iOS 9 que celles d’iOS 7. »

Une faille SQL injection (mais il faut être authentifié) dans ttrss depuis le 29/01/2016.

Merci à Blusky pour l'info.

J'utilise OSMAnd~ sur mon ordiphone Android pour avoir de la navigation GPS et plus (création de tracés, par exemple) en utilisant les ressources du projet de cartographie libre et collaborative Open Street Map .

Le 9 février dernier, je souhaite récupérer des photos prises avec mon ordiphone en utilisant, comme d'habitude, gmtp. Sauf que, par fausse manip', je clique sur le bouton « Supprimer » au lieu du bouton « Télécharger ». Et gmtp ne demande aucune confirmation... Adieu photos. Forcément, je démonte la carte SD de mon ordiphone, je la retire physiquement de l'ordiphone, je l'insère dans mon laptop et je lance photorec qui me récupère toutes les photos supprimées par erreur.

Le week-end dernier, j'ai besoin d'OSMAnd~ pour trouver mon chemin... Et là, l'appli crashe une fois sur deux avec le message « l'application s'est arrêtée ». Quand elle démarre, deux messages d'erreur s'affichent : « Erreur lors de l'affichage de la zone sélectionnée » puis « Rendu natif non supporté par cet appareil. ». L'appli utilise le module GPS pour me localiser mais il n'y a aucun fond de carte, rien. OSMAnd~ peut toujours chercher un lieu ou bien encore calculer un itinéraire mais plus de fond de carte...

On se doute bien qu'un fichier d'OSMAnd~ a été corrompu sur la carte SD...

Lire le fichier « exception.log » produit par OSMAnd~ n'est pas bien utile : il manque des crashs...

Si l'on recherche le message d'erreur sur un moteur de recherche web, on trouve que c'est la traduction française de « rendering_exception ».

Dans le dossier OSM sur la carte SD, cherchons les fichiers modifiés ces 31 derniers jours (find . -mtime -31 ). Dans mon cas, les fichiers et dossiers suivants ont été modifiés le 9 février (tiens tiens ;) ) :
./regions.ocbf
./voice
./voice/en-tts
./voice/en-tts/_ttsconfig.p
./voice/fr-tts
./voice/fr-tts/_ttsconfig.p
./rendering
./rendering/default.render.xml
./poi_types.xml
./fonts
./fonts/OpenSans-Italic.ttf
./fonts/OpenSans-Regular.ttf
./fonts/OpenSans-Semibold.ttf
./fonts/OpenSans-SemiboldItalic.ttf
./roads
./backup

Le seul fichier qui ait un vague rapport de nom avec une « rendering_exception » est rendering/default.render.xml. Sauvegardons une copie et supprimons ce fichier.

On démonte la carte SD, on l'insère dans l'ordiphone, on lance OSMAnd~ et... it works \o/

Pour que votre âge soit automatiquement calculé (et donc automatiquement actualisé) lors de la compilation de votre CV. Ça permet d'éviter les oublis, de se simplifier la vie,...

« \usepackage{ifthen}
\newcounter{myage}
\setcounter{myage}{\the\year}
\addtocounter{myage}{-YYYY}
\ifthenelse{\the\month<MM}{\addtocounter{myage}{-1}}{}
\ifthenelse{\the\month=MM}{
  \ifthenelse{\the\day < DD}{\addtocounter{myage}{-1}}{}
}{}

then \themyage{} can be used to show your age. »


Je rappelle néanmoins que l'âge fait partie des informations discriminantes (cas d'un sénior ou d'une jeune femme >= 28 ans (que le/la recruteur-euse présumera vouloir devenir mère donc congés à gogo blablabla), si si si, ce genre de raisonnements existe encore en 2016) et qu'il n'est donc ni obligatoire ni toujours opportun de l'indiquer sur votre CV.

Merci à Johndescs (http://jonathan.michalon.eu/) pour le tuyau.

Chez ARN, FAI associatif en Alsace, nos machines physiques ont une BMC c'est-à-dire un contrôleur permettant le management à distance (accès console, reboot, monitoring bas niveau,...) de la bécane (voir https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller). Super utile en cas de panne, fausse manip' qui évite de bouger au datacenter où elles sont hébergées.

La BMC de notre HP ProLiant, un truc ILO 2 est perfectible : elle peut continuer à ping mais ne plus présenter son interface web... et devenir ainsi inutile. Le seul moyen est de rebooter totalement (éteindre + couper les arrivées électriques) la machine. Pas cool de découvrir ça quand on a besoin de la BMC car on a foiré une manip'...

On a mis en place un check de monitoring (voir http://shaarli.guiguishow.info/?wehQjg ) supplémentaire qui vérifie, en plus d'un ping que l'interface web répond toujours. La question est : on ne va quand même pas rebooter intégralement la machine à chaque fois que le check remonte une erreur car, même si l'infra est redondée, ça fait une intervention humaine et on sait tous et toutes que le temps bénévole est rare. Pourtant, ne pas le faire, c'est s'exposer à un adminsys qui oublie que la BMC est HS avant de faire une manip' risquée ainsi qu'à une panne que la BMC permettrait de corriger.

Quelles sont nos options ?
    * « impitool mc reset warn » n'est pas reconnue par la BMC, « reset cold » ne fonctionne pas ;

    * On peut utiliser la console accessible via SSH pour reboot uniquement la BMC (voir http://www.thevirtualway.it/2014/05/hp-ilo-how-to-reset-from-command-line/ ) mais vu qu'aucune communication réseau n'est possible au-delà de la couche 4, ça ne marchera pas ;

    * HP propose un outil « Standalone Remote Console » (voir http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=5228286&swLangOid=8&swEnvOid=4053 )... C'est du soft proprio disponible uniquement sous winwin et Red Hat ou en appli mobile (oui, LOL, je fais de la maintenance sérieuse avec mon ordiphone cracra mais bien sûr :- ) donc c'est mort de base. Ensuite, vu qu'aucune communication réseau avec la BMC n'est possible, c'est réglé.

    * Johndescs, qui a ses marques sur Dell/iDRAC, me dit qu'il y a un logiciel que tu mets sur le serveur lui-même et qui cause en local à la BMC du nom de racadm et qu'il doit bien y avoir un équivalent HP. Oui, ça existe, ça se nomme hponcfg (voir http://blog.adminrezo.fr/2015/09/hp-ilo-sous-linux/ ) et on peut rebooter seulement la BMC avec (voir http://community.hpe.com/t5/ProLiant-Servers-Netservers/Reboot-ILO-with-hponcfg/m-p/6413048#M20349 ).

        Le problème, c'est d'installer c'te truc. HP fournit un dépôt apt (ou yum ;) ) : http://downloads.linux.hpe.com/SDR/repo/mcp/debian/pool/non-free/  mais hponcfg impose l'installation de hp-health qui fout des initscripts et plein de merdes. NO. FUCKING. WAY.

        On va extraire les binaires et les libs du package hponcfg :
            * wget http://downloads.linux.hpe.com/SDR/repo/mcp/debian/pool/non-free/hponcfg_4.4.0.8-2._amd64.deb

            * dpkg -x hponcfg_4.4.0.8-2._amd64.deb hponcfg

            * sudo mv hponcfg/usr/sbin/hponcfg /usr/sbin/

            * sudo mv hponcfg/usr/lib/libhponcfg64.so /usr/lib/

            * En effectuant un strace, on remarque que le binaire tente de charger une lib libcpqci64.so et qu'il n'échoue pas s'il ne la trouve pas. En fait, elle est un doublon de libhponcfg64.so comme l'indique le message d'erreur de hponcfg quand on n'a aucun des deux libs : « Error Loading the library libcpqci.so or libhponcfg.so ». Si jamais ça peut servir : la libcpqci64.so est fournie avec hp-health.

            * On charge le module hpilo (fournit par Debian) dont le rôle est de faire la liaison avec la BMC en créant des fichiers /dev/hpilo/* dans lesquels il suffit de read() et write() pour communiquer avec la BMC : « sudo modprobe hpilo » .

        On exécute hponcfg : « sudo hponcfg » ... et là, c'est le drame :
            « ERROR: CpqCiCreateFunc() 0 time failed.
              Driver Error Code:(1,1h).
              Driver Error Message: CPQCIDRV driver is not loaded.

              ERROR: A general system error occurred while detecting Management Processor.
              ACTION REQUIRED: Check if iLO and iLO driver are up and running. »

            Vérifiez bien que vous avez chargé le module hpilo car les messages d'erreur entre "BMC viandée" et "absence du module hpilo" sont quasi identique, seul le message à la fin (« ERROR: [...] » change !

            Si vous regardez /var/log/kern.log, vous aurez quelques messages identiques à chaque essai de hponcfg : « [3890626.816095] hpilo 0000:01:04.2: Open could not dequeue a packet ».

            Si l'on regarde le code du module hpilo, on se rend compte que ça ne présage rien de bon : « * make sure iLO is really handling requests */ »

            On joue quand même le jeu : puisque hpilo crée des fichiers dans lesquels on peut lire et écrire pour causer à la BMC, faisons le :
              $ echo "areUinlife?" | sudo tee /dev/hpilo/d0ccb15
              Device or resource busy
              lol
            Et on retrouve le même message dans kern.log...

            On pourrait vouloir utiliser d'autres outils userspace pour écrire dans les /dev/hpilo/* mais on se souvient alors que la communication avec la BMC est dans un langage propriétaire et que personne ne semble avoir souhaité passer son temps à reverse ça (et ce n'est pas un reproche). Même python-hpilo utilise une communication réseau ou parse hponcfg.

        Après un reboot électrique du HP, il est parfaitement possible d'écrire dans les /dev/hpilo/* et d'utiliser hponcfg :
          « sudo hponcfg -get_hostinfo
            HP Lights-Out Online Configuration utility
            Version 4.4.0 Date 06/13/2014 (c) Hewlett-Packard Company, 2014
            Firmware Revision = <censure> Device type = iLO 2 Driver name = hpilo
            Host Information:
                                 Server Name: <censure>
                                 Server Number: 000000000 »


Qu'est-ce que tout cela signifie ? Que quand une BMC HP ILO est viandée, il n'y a pas d'autres moyens de la reboot que d'effectuer un reboot électrique complet de toute la machine ! C'est franchement super pratique... :'(

ÉDIT DU 05/06/2017 À 16H10 :  en mettant à jour le firmware de la BMC à la dernière version disponible à ce jour (la 2,29 du 7 octobre 2015), l'interface web de la BMC ne se viande plus. Tuto pour la màj : http://shaarli.guiguishow.info/?bfiXRg . FIN DE L'ÉDIT.