Pour faire un remplacement dans une “visual selection (Ctrl+v)”, notamment pour restreindre un remplacement à une sélection dans une longue ligne :
:'<,'>s/\%Vfoo/bar/
Pour faire un remplacement dans une “visual selection (Ctrl+v)”, notamment pour restreindre un remplacement à une sélection dans une longue ligne :
:'<,'>s/\%Vfoo/bar/
ldapvi is so wonderful. No Java/Python/PHP for “browsing” LDAP trees and the power of vi for LDAP administration. Nevertheless, today I had difficulty for deleting a facsimileTelephoneNumber attribute:
$ ldapvi Action? [yYqQvVebB*rsf+?] y ldap_modify: Inappropriate matching (18) additional info: modify/delete: facsimileTelephoneNumber: no equality matching rule
Here is the LDIF change tried by ldapvi:
dn: uid=foo,ou=people,dc=evolix,dc=net changetype: modify delete: facsimileTelephoneNumber facsimileTelephoneNumber: 0000
After a little search on the web, I find the reason on openldap-bugs list archives:
Since the schema definition of facsimileTelephoneNumber has no matching rule defined, the only modifications you can make are Replace or Delete w/ no values.
facsimileTelephone attribute actually doesn’t have SYNTAX definition. See in core.ldif file:
Number olcAttributeTypes: ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' ) DESC 'RFC2256: Facsimile (Fax) Telephone Number' SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
By default, ldapvi tries to delete a specific value (even if there is only one value) for an attribute. But according documentation, it’s impossible to delete only one of values for facsimileTelephoneNumber attribute!
Note: for deleting all values of facsimileTelephoneNumber attribute, the LDIF change must be:
dn: uid=foo,ou=people,dc=evolix,dc=net changetype: modify delete: facsimileTelephoneNumber
Il est important de fermer complètement son Bind, à savoir mettre dans son named.conf :
allow-query { localhost;}; allow-recursion { localhost; }; allow-transfer { none; };
Cela provoque un statut REFUSED pour toutes les requêtes non autorisées. Si refuser les transferts (requêtes AXFR dévoilant toute votre zone) est sage et refuser les requêtes récursives est logique (vous ne voulez pas être serveur DNS pour le monde entier), il faut également refuser toutes les requêtes par défaut afin d’éviter de potentiels dénis de service.
Vous noterez que les directives ci-dessus autorisent les requêtes classiques de la part de localhost dans la mesure où il est fréquent que votre machine se serve de son propre Bind. Si ce n’est pas le cas, mettre toutes les directives à none.
Un moyen simple de vérifier qu’un serveur DNS refuse bien toutes les requêtes :
dig google.fr @<serveur DNS>
Vous ne devez pas obtenir la(les) réponse(s), ni même obtenir la liste des ROOT SERVERS. Vous devez obtenir status: REFUSED (ou alors un timeout…).
J’ai souvent eu du mal à expliquer pourquoi il fallait fermer complètement son Bind, car la menace des attaques DOS restait un peu vague. Ce n’est désormais plus le cas depuis quelques semaines où chaque administrateur d’un Bind assiste (dans ses logs ;-) aux multiples requêtes “. NS IN” générées par des robots/virus :
client 76.9.16.171#39068: query (cache) './NS/IN' denied client 69.64.87.156#42646: query (cache) './NS/IN' denied
On déplore même des victimes de ces attaques DDOS de grande ampleur, notamment NetworkSolutions qui l’explique sur son blog. Pour contrer cela, on peut refuser les paquets en amont : voici un fameux paquet (format PCAP). On voit donc que l’on peut interdire les paquets comportant une requête DNS récursive (flags = 0x0100). Sur une machine Linux, on peut le faire avec iptables et le module u32 (attention, il semble y avoir des bugs avec certaines versions) :
iptables -A INPUT -p udp --dport domain -m u32 --u32 "0>>22&0x3C@10=0x01000001" -j DROP
SI vous ne voulez pas interdire toutes les requêtes récursives, j’ai trouvé sur Internet une règle plus précise qui matche sur le “. NS IN” (voir commentaires de ce post) :
iptables -A INPUT -j DROP -p udp --dport domain -m u32 --u32 \ "0>>22&0x3C@12>>16=1&&0>>22&0x3C@20>>24=0&&0>>22&0x3C@21=0x00020001"
Enfin, sur l’excellent blog de Stéphane Bortzmeyer, vous trouverez plus de détails et des outils pour mesurer le nombre d’attaques sur votre serveur.
Que ça soit pour des raisons de performance, de sécurité ou de simplicité, il est assez commun de ne pas avoir de module CGI sur un serveur (installer du CGI avec nginx est fastidieux par exemple). Or, l’outil de stats mailgraph n’est prévu que pour tourner en CGI. Voici un petit script qui permet de s’en affranchir et de générer les graphes mailgraph sans CGI :
#!/bin/sh MAILGRAPH_PATH=/usr/lib/cgi-bin/mailgraph.cgi # Debian #MAILGRAPH_PATH=/usr/local/www/cgi-bin/mailgraph.cgi # FreeBSD #MAILGRAPH_PATH=/usr/local/lib/mailgraph/mailgraph.cgi # OpenBSD MAILGRAPH_DIR=/var/www/mailgraph umask 022 mkdir -p $MAILGRAPH_DIR $MAILGRAPH_PATH | sed '1,2d ; s/mailgraph.cgi?//' > $MAILGRAPH_DIR/index.html for i in 0-n 0-e 1-n 1-e 2-n 2-e 3-n 3-e; do QUERY_STRING=$i $MAILGRAPH_PATH | sed '1,3d' > $MAILGRAPH_DIR/$i done
Il peut être placé en crontab, ce qui permet une sauvegarde régulière des graphes générés. Testé sous Debian, FreeBSD et OpenBSD (variable MAILGRAPH_PATH à adapter).
I have a Xen dom0 with nat-mode and IPv6 enabled. Set up IPv6 in Xen domU is like a classical IPv6 network: add IPv6 addresses on vif interfaces on dom0 and IPv6 addresses on domU (manually or with radvd on dom0). The only tip is how adding IPv6 addresses on vif interfaces which are dynamically created by Xen. Here is my dirty hack to do it on /etc/xen/scripts/vif-nat file:
[ "$dhcp" != 'no' ] && dhcp_up +# Add IPv6 addresses +[ "$vif_ip" = '192.168.0.1' ] && ifconfig "$vif" add 2001:6f8:143d:1::101:1234/64 +[ "$vif_ip" = '192.168.0.2' ] && ifconfig "$vif" add 2001:6f8:143d:2::101:1234/64 ;; offline)
Where $vif_ip is the IP address from domU configuration : vif=[‘ip=192.168.0.1].
I think the best solution is adding ipv6 option to domU configuration. I will consider to open a wishlist bug for that.
Un joli manteau neigeux a recouvert Marseille, pour le bonheur des enfants, un peu moins pour les automobilistes. Ci-dessous, le Jarret (une des artères principales de Marseille) bloqué par le neige :
Ou encore le Pôle Média Belle de Mai, où se trouvent les bureaux d’Evolix :
Edit : toutes mes excuses aux lecteurs de Planet-Libre et Planet-Debian-Fr/Planet-Debian-Fr-Users, j’ai mis ce post dans une mauvaise catégorie ! Le ciel m’est vraiment tombé sur la tête ce mercredi…
Depuis plusieurs semaines, on a assisté à une déferlante médiatique à propos de la crise. À tel point qu’un grand nombre de français a désormais pris l’habitude de mentionner cette fameuse crise à tout bout de champ : “à cause de la crise”, “malgré la crise”, etc. Or, il faut vraiment souligner que l’origine de cette crise est boursière. Je me permets de rappeler ce qu’est la bourse (en tous cas, ce que j’en ai compris) : c’est un lieu d’échange de titres qui sont des estimations virtuelles de la valeur d’une entreprise. Et ces estimations fluctuent chaque jour en fonction d’élements divers : annonces de résultats, rumeurs, situations géopolitiques, météo, etc. Bref, une somme d’élements qui laisse une bonne part d’interprétations, voire de hasard, et souvent annoncés par les médias. C’est donc un cercle vicieux : à partir du moment où l’on médiatise les évènements boursiers… qui dépendent fortement des médias. Et l’on est en plein dans ce cercle vicieux. L’élément déclencheur, l’écroulement d’un château de cartes faites de paris américains trop risqués, est bien loin. Les bourses se trouvent dépendantes du contexte médiatique morose, et peinent à rebondir véritablement. Mais pire, les conséquences vont au-delà de la bourse, les acteurs économiques ralentissent leurs investissements en fonction de ce contexte… ce qui influe directement sur tout le système économique : les fournisseurs et sous-traitants se trouvent également ralentis, cela débouche sur moins d’embauches, voir des licenciement et des fermetures. Impactés ou non, les citoyens adoptent un comportement similaire, et l’économie dans son ensemble menace d’être ralentie.
Plus l’on parle de la crise, plus elle progresse. Anticiper la crise, c’est l’accélérer.
En conséquence, il est du devoir des acteurs économiques et de chacun d’adopter un comportement pragmatique : il ne s’agit pas de faire de la méthode Coué en l’occultant complètement, mais il s’agit de ne pas faire d’exagération et de s’en tenir aux conséquences factuelles. Il est notamment un peu facile d’attribuer à la crise le ralentissement du marché automobile : pour des raisons écologiques et économiques (le prix de l’essence augmentant inexorablement depuis des dizaines d’années), le marché est amené à se renouveler et la crise semble davantage être un bon prétexte. Le danger se situe aussi à ce niveau, car la surmédiatisation de la crise offre une excuse en or à de nombreux acteurs pour faire passer des plans de licenciement, délocalisations, etc. Elle offre même une excuse pour tout évènement négatif… À l’inverse, on pourrait mettre en avant les effets positifs à la crise : le prix de l’essence a baissé (le baril de pétrole est passé de 150 $ à 50 $), l’envolée des prix de l’immobilier s’est arrêtée, des aides à l’embauche ont été mises en place pour les petites entreprises, les taux d’intérêts des prêts baissent, et même le prix de la vie est en baisse, le marché de l’offre devant s’adapter au marché de la demande désormais … frileux ! Bref, pas de quoi tomber dans la morosité ambiante.
Pour conclure, la surmédiatisation de la crise est dangereuse pour l’économie. Afin de revenir à une situation plus raisonnable, les médias, les entreprises et les individus devrait prendre la bonne résolution d’éviter de parler de la crise à tort et à travers, mais de s’en tenir aux faits. Par exemple, beaucoup d’entreprises sont en pleine progression. C’est le cas d’Evolix, PME en constante croissance, et qui va sortir un beau bilan 2008 avec un chiffre d’affaires entre 200.000 et 250.000 EUR. Et qu’on ne me dise plus qu’Evolix ne connaît pas la crise, je vous répondrais : “La crise ? quelle crise ?”
– Dis papa, je dois écrire ton métier pour l’école. C’est quoi ton métier ?
– Ba, tu peux mettre “gérant de la société Evolix“.
– Et, papa, c’est quoi gérant ?
– Heu… en quelques mots, être gérant dans une PME, c’est être à la fois :
- Administrateur système et réseau
- Analyste
- Avocat
- Chargé de communication
- Chasseur de tête
- Chauffeur/livreur
- Chef de chantier
- Chef de projet
- Chercheur
- Commercial
- Comptable
- Consultant informatique
- DBA (DataBase Administrator)
- Déménageur
- Développeur informatique
- Directeur administratif et financier
- Directeur de marketing
- DRH (Directeur des Ressources Humaines)
- DSI (Directeur du système d’information)
- Électricien
- Femme de ménage
- Formateur
- Imprimeur
- Infographiste
- Ingénieur
- Intégrateur
- Journaliste
- Opérateur
- Photographe
- Professeur
- Psychologue
- Relecteur
- Reponsable informatique
- Responsable de la sécurité
- Responsable éditorial
- Responsable qualité
- Secrétaire
- Standardiste
- Taxi
- Technicien
- Traducteur
- Trésorier
- Vendeur
- Web-designer
- Webmaster
- etc. !
À l’occasion du salon Synergie NTIC à Marseille, je suis intervenu environ 20 minutes dans une conférence à propos de la sécurité et l’Open Source. En résumé, j’ai parlé de la façon dont on doit se préoccuper de la sécurité quand on travaille avec des distributions ou logiciels Open Source. Notamment, j’ai parlé :
Vous pouvez télécharger les slides utilisés pour cette présentation (soyez indulgent, je les ai fait rapidement).
Avec un ordinateur portable sous Debian Lenny i386, depuis quelques semaines j’avais d’étranges problèmes de rendu qui se produisaient sur plusieurs sites. Par exemple, une barre verticale constituée d’images répétées verticalement se retrouvait en plein milieu d’une page au lieu de rester sur les côtés : voici un exemple typique du bug avec le site http://www.evolix.fr/
Le problème est désormais identifié et fixé grâce à glandium (Mike Hommey), mainteneur Debian d’Iceweasel/xulrunner/libxml2/xebkit/etc. Il s’agit d’un problème entre xulrunner et cairo, et l’installation d’un paquet xulrunner-1.9 modifié, ou mieux, libcairo2 modifié, corrige le problème pour mon ordinateur portable (carte Intel, xorg.conf minimal avec uniquement une entrée spécifique pour la disposition du clavier). Merci glandium !