La traduction française du livre blanc officiel du SEI contient tout ce qu’il faut pour comprendre CMMI-DEV, même en n’ayant aucune notion en méthodologie d’amélioration des processus, et les annexes sont bien fournies.

Description: simple debconf wrapper for OpenSSL
This package enables unattended installs of packages that
need to create SSL certificates.
.
It is a simple wrapper for OpenSSL’s certificate request utility that
feeds it with the correct user variables.
Tag: interface::commandline, protocol::ssl, role::program, scope::utility

Il suffit alors de lancer un
$ make-ssl-cert generate-default-snakeoil

Pour obtenir une clé et un certificat:
/etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/ssl/private/ssl-cert-snakeoil.key

La configuration par défaut est aisément modifiable (voir l’aide de make-ssl-cert)

Par exemple, pour récupérer les messages contenant “iptables: ” uniquement dans le fichier /var/log/iptables, les règles suivantes semblent valides:

:msg, contains, "iptables: " -/var/log/iptables
:msg, contains, "iptables: " ~

• 1ère ligne: En se basant sur le contenu du message (msg), s’il contient (contains) la chaîne de caractère “iptables: ” alors écrire dans le fichier /var/log/iptables sans bufferiser (-)
• 2ème ligne: avec les mêmes critères que précédemment, supprimer le message. (~)

Or, sur une Debian Squeeze (rsyslog 4.6.4-2) avec une configuration rsyslog basique, les messages ne sont pas supprimés, et se retrouvent  dans /var/log/messages et dans la console.

Le souci ? Un bug dans rsyslog, corrigé dans la version  5.7.8 et backporté dans la branche stable à partir de la version 5.6.5

Contenu de ~/.offlineimaprc

[general]
accounts = Gmail
maxsyncaccounts = 1
ui = Noninteractive.Basic

[Account Gmail]
localrepository = Local
remoterepository = Remote

[Repository Local]
type = Maildir
localfolders = /home/loic/gmail.backup

[Repository Remote]
type = Gmail
readonly = true
remotehost = imap.gmail.com
remoteuser = login@gmail.com
remotepass = password
ssl = yes
maxconnections = 1
realdelete = no
spamfolder = '[Gmail]/Spam]'
trashfolder = '[Gmail]/Corbeille]'
folderfilter = lambda foldername: foldername not in ['[Gmail]/Tous les messages']
nametrans = lambda foldername: re.sub('\[Gmail\]/Messages envoy.*', '[Gmail]/Messages_envoyes', foldername)

Détails

Pas vraiment de subtilités, le fichier exemple par défaut étant très complet, inutile de recopier les explications ici.

folderfilter me permet d’éviter de sauvegarder “Tous les messages”, qui évite de perdre de la place et du temps avec une copie intégrale de la boîte.

nametrans  corrige la curieuse interprétation qu’a OfflineIMAP de l’accent du mot “envoyés”, en renommant en local ce répertoire en “Messages_envoyes”

C’est peut-être un bug, à voir.

Au final, un OfflineIMAP régulièrement lancé couplé à une sauvegarde me garanti une copie complète de tous mes messages Gmail, parant à toute éventuelle perte de données

Ce port met à disposition les  commandes suivantes facilitant le travail avec des queues de type AMQP (RabbitMQ, Qpid, …)

amqp-deleteq     
amqp-dequeue     
amqp-enqueue     
amqp-peek     
amqp-pop     
amqp-purge     
amqp-spy     
amqp-statq     
amqp-unbind

Il est ainsi très facile de récupérer un message dans une queue, vider une queue, compter à distance le nombre de messages, etc,  sans avoir à écrire un script pour attaquer le serveur de queue.

maj 06/10/2011: la version 0.5.0 apporte des nouveautés:  amqp-delexch et amqp-exchange

Ce post peut peut-être vous aider

La carte mère ASUSTeK M4A785TD-M EVO embarquant cette puce a servi de système de test:

# lspci |grep Realtek
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

Symptômes

Les symptômes que j’ai rencontrés (Ubuntu 10.04.1  x86_64,  noyau 2.6.32-27-generic) et qui se manifestent plus ou moins aléatoirement sont:

-pertes de paquets de l’ordre de 20% (ping depuis un autre pc sur un switch)

-importantes fluctuations de débit montant et descendant

Je ne suis pas le seul à rencontrer ce problème, connu depuis 2008 !

https://bugs.launchpad.net/linux/+bug/347711

http://forum.ubuntu-fr.org/viewtopic.php?id=334030

De plus un collègue a eu le même problème sur un portable Dell Vostro équipé du même chipset (avec comme  bonus la carte qui n’était quelque fois pas activable sous Linux à la suite un démarrage sous Windows puis reboot à chaud)

Solution

Elle a fonctionné à la fois pour la carte mère ASUSTeK et le portable Dell.

Elle consiste à ne plus utiliser le module par défaut du noyau Linux r8169, mais celui  fourni par Realtek r8168, la compilation du module noyau ainsi que quelques manipulations sont nécessaires. (attention lors des mises à jour du noyau !)

Cette procédure étant très bien expliquée pour Ubuntu ici, je ne vais pas la recopier.

Pour info le code source du module écrit par Realtek est disponible sur leur site (ou realtek.com ->Downloads > Communications Network ICs > Network Interface Controllers > 10/100/1000M Gigabit Ethernet > PCI Express > Software)

Même si quelques sites relatifs à Linux/Ubuntu  signalent cette carte comme fonctionnant “out of the box”, c’est vraiment très lié au sens que l’on donne à “fonctionner”.

Certes, cette carte permet de se connecter à un AP en wpa, jusque là tout va bien, ça “fonctionne”.

En revanche, j’ai rencontré des problèmes avec certains outils comme network-manager et wicd (impossibilité de se connecter avec du wpa, déconnexions, …) et surtout un problème de débit vraiment bloquant: le débit tombe parfois à 1Mbps au lieu de 54Mbps théoriques.

Je ne suis pas le seul, c’est un problème connu depuis bientôt 3 ans pour Ubuntu et le noyau Linux et toujours non résolu. Il existe des bidouilles à base de iwconfig pour forcer le débit, mais cela reste inefficace sur la durée, sur mon poste cela marche tant qu’il y a peu de connexions tcp, mais dès qu’il y a plus de connexions ou un peu plus de traffic, on retombe à un débit anémique.

Pourquoi est-ce qu’au bout de 3 ans ce n’est toujours pas résolu ?

C’est simple. Ralink avait libéré les spécifications de certains de leur chipsets wifi, donc cela aurait dû faciliter le travail des développeurs.

En fait, seules certains familles de chipset ont une documentation disponible, à l’époque de ce post sur le forum du projet rt2x00 (ce sont eux qui travaillent à faire fonctionner sous Linux les chipsets Ralink)  la documentation était publique pour les chipsets rt61 et rt73.

Les spécifications pour les chipsets plus anciens comme le rt2500 sont uniquement disponibles pour les développeurs du projet rt2x00.

J’avais remonté cette info sur le rapport de bug Ubuntu et un développeur du projet rt2x00 a donné plus d’informations : expliquant que le problème n’est pas spécifique au rt2500, et que vu le faible nombre de développeurs sur ce projet, les ressources sont forcément limitées et ils préfèrent se consacrer aux chipsets plus récents, ce qui est tout à fait compréhensible.

Je suis sûr que ce problème sera corrigé prochainement vu le travail titanesque déjà accompli par ce projet, et je  souhaite bon courage aux développeurs.

En attendant, à part si vous souhaitez contribuer à ce projet, je vous conseillerai plutôt d’acheter une autre carte.

Mais laquelle ? Quelle carte pci/usb fonctionne “out-of-the-box”, en wpa, avec n’importe quel outil de gestion réseau, sans passer par un ignoble ndiswrapper ? Après plusieurs soirées de recherche, je n’ai pas trouvé de réponse à cette question, et j’ai fini par installer des modules CPL.

Si quelqu’un connait une carte wifi pci à 100% fonctionnelle, je suis preneur !

Avec un peu de temps et d’acharnement, j’ai finalement réussi à trouver la source du problème et à proposer un patch dans le bug tracker de FreeBSD

J’espère qu’il sera accepté, et que personne n’en rira

Pour modifier ce comportement, il faut utiliser la propriété rankdir

Exemple concret :

digraph G {
  "init" -> "0";
  "0" -> "1" [label="a"];
  "1" -> "2" [label="b"];
  "2" -> "6" [label="b"];
  "2" -> "3" [label="c"];
  "2" -> "5" [label="a"];
  "3" -> "4" [label="d"];
  "5" -> "4" [label="a"];
  "6" -> "4" [label="e"];
  "4" -> "7" [label="b"];
  "7" -> "8" [label="a"];
  "8" [shape="doublecircle"];
  "init" [shape="none", label=""];
}

Et maintenant le même graphe, cette fois-ci orienté LR (Left-Right)

digraph G {
  rankdir=LR;
  "init" -> "0";
  "0" -> "1" [label="a"];
  "1" -> "2" [label="b"];
  "2" -> "6" [label="b"];
  "2" -> "3" [label="c"];
  "2" -> "5" [label="a"];
  "3" -> "4" [label="d"];
  "5" -> "4" [label="a"];
  "6" -> "4" [label="e"];
  "4" -> "7" [label="b"];
  "7" -> "8" [label="a"];
  "8" [shape="doublecircle"];
  "init" [shape="none", label=""];
}