Krunch a écrit 4071 commentaires

Et ton compte.pl il tient compte de la fragmentation ? Des paquets qui arrivent dans le désordre ? Des paquets perdus et dupliqués ? Tcpflow serait déjà plus fiable. Si on veut faire ça correctement à ce niveau, on va plutôt utiliser libnids mais sinon en vrai on va chercher dans les logs du serveur applicatif (Sendmail, Apache,...).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> le MTU est généralement à 1500 en ethernet, le réduire à 1496
> permet souvent de le faire refonctionner lors d'un passage en ATM
> ou des équipements réseau défaillants... (quelques soucis avec des
> ajouts "involontaires" au header...).
> Je n'ai jamais trop compris, mais ça marche (il y a le même souci
> parfois avec le FreeWifi).

Je ne sais pas d'où tu sors le 1496 mais le problème typique que j'ai pu observer c'est le passage par PPPoE qui ajoute 8 octets d'en-tête et pour lequel il est donc utile de diminuer le MTU à 1492. Cela permet de réduire les risques de fragmentations et donc d'augmenter les performances. Sauf qu'avec certains équipement qui ne gèrent pas bien la fragmentation, ça fait perdre des paquets et cause donc des problèmes de connectivité (pas juste de performance) comme décrit par briaeros007.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et tu as regardé exactement ce qui se passe au niveau réseau (tcpdump est ton ami toussa) ou bien tu préfères juste troller en publique sans faire quoi que ce soit pour essayer de régler le problème ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> Selon Novell, les 2/3 des clients Fortune 100 utilisent SuSE Linux
> comme solution pour leur système d'information.

On pourrait aussi lire ça comme « 1/3 des clients Fortune 100 de Novell n'utilisent pas SuSE Linux ».

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

OK, admettons que le mail est un canular. C'est quoi le but ? Discréditer OpenBSD pour faire passer leurs clients vers la concurrence ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Security through obscurity. Ça marche bien tant que c'est pas ta seule protection. Si ton Apache n'annonce pas sa version exacte à tout le monde, tu as un peu plus de chances de pouvoir patcher à temps le jour où il y a un zero day.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Il faut aussi qu'il n'y ait pas prescription. C'était il y a 10 ans quand même.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> je ne fais évidemment pas confiance à du code fermé pour quoi que ce soit d'important

Tu utilises quoi comme BIOS libre ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> arriver à coller des bouts de code qui ont l'air de rien lors des relectures,
> qui ne sont pas obfusqués, mais qui supportent donc un certain type
> "d'appel" permettant de mettre en route des fonctionnalités cachées,
> ce n'est plus que du code, c'est du grand art.

C'est effectivement très joli à voir : http://underhanded.xcott.com/

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Le lien "Bref historique du retrait de l’algorithme de chiffrement A5/2 de GSM, par Harald Welte." est cassé.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

L'auteur de Ion, Tuomo Valkonen, a arrété le développement d'Ion après avoir critiqué la manière dont il était intégré dans les distributions : http://en.wikipedia.org/wiki/Ion_(window_manager)#Controvers(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

https://access.redhat.com/support/offerings/production/soc.h(...)
Production Support [does] not support System and network design

Après, s'il y a des questions précises sur l'utilisation d'un logiciel supporté, c'est autre chose.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

AFAIK, kexec va remettre l'uptime à 0. Avec ksplice par contre...

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> Maîtrise de l’hébergement LAMP (Linux,Apache,MySQL,Php) Si on maîtrise davantage
> B[NL][PS]P (BSD, Nginx / Lighttpd, PostgreSQL / SQLite, Perl / Python) peut-on toujours
> postuler ?

Tu peux même postuler si tu ne connais ni l'un ni l'autre. Après, c'est moins sûr d'avoir une réponse positive.

> Intérêt pour l’univers des logiciels libres et OpenSource ? Quel est l'intérêt,
> personnellement, je ne connais personne (dans mon entourage), qui a un intérêt pour
> les systèmes d'exploitation libres, l'hébergement Web, et se foutre complètement
> de l'univers des logiciels libres.

Perso, j'aimerais pas bosser avec des gens qui n'en n'ont vraiment rien à foutre (je l'ai fait mais ça a pas duré).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et les « réseaux/media sociaux » ne sont pas forcément mauvais non plus. Pour beaucoup de gens c'est un moyen bien pratique de rester en contact (même superficiel) avec des amis ou parents qu'il est difficile de voir régulièrement. Évidemment le problème c'est que ces plateformes sont fortement centralisées (d'un point de vue organisationnel, pas forcément technique) et qu'on voit donc une concentration de pouvoir sur des trucs pour lesquels ça aurait été difficile il y a quelques années.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

On peut argumenter que la programmation fonctionnelle est naturellement concurrente puisque l'interpréteur peut paralléliser plein de choses sans risque d'effet de bord.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Moi j'ai aussi vu des gens faire Red Hat -> Novell -> Red Hat. Je n'ai pas de référence publique par contre.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Hum sinon, il on peut patcher les applications qui ont besoin d'avoir leur mémoire en RAM pour utiliser mlock(). C'est sans doute pas une bonne idée en générale mais ça permet d'avoir un contrôle plus fin.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

kdump+sysrq-c (bis)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

La solution actuelle pour obtenir un vmcore c'est kdump. Pour analyser le dump, c'est crash(8).
Tu peux aussi obtenir des backtraces directement avec sysrq-t et sysrq-w (-w est seulement sur RHEL/Fedora je pense) mais si l'userland est freezé, ça va se retrouver sur la console (si elle fonctionne) mais pas dans les logs syslog (ou bien tu peux utiliser netconsole par exemple mais ça devient plus compliqué pour des résultats incertains).

Voire kdump/kdump.txt et sysrq.txt dans la documentation du noyal.
Pour crash(8) : http://people.redhat.com/anderson/crash_whitepaper/

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

On pourrait aussi faire un truc comme ceci :

$ cat findbadfiles.stp 
// findbadfiles.stp GOOD_UID BAD_UID

global good
global bad

probe syscall.open {
        if (execname() == "openshot") {
                if (uid() == $1) {
                        good[$filename] = 1
                }
                if (uid() == $2) {
                        bad[$filename] = 1
                }
        }
}

probe end {
        foreach (file in bad) {
                if (!good[file]) {
                        printf("%s\n", file)
                }
        }
}

Si le bon utilisateur a l'UID 1000 et le mauvais 1001, ça se lance comme ça :

# stap findbadfiles.stp 1000 1001

Après tu lances le programme avec le bon utilisateur et le mauvais. Une fois que c'est fait, tu interromps le script SystemTap et il va t'afficher les fichiers qui ont été ouvert dans le cas qui a merdé mais pas dans l'autre. J'ai absolument pas testé.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Il faut quand même préciser que cette notion de groupes était déjà là avant ce patch. Tout ce que ce patch fait c'est répartir les processus dans des groupes par tty. Ce qui explique pourquoi il est si court.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tiens mais si t'es dans le coin (PAN !), tu as peut être déjà été au MKLUG ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Il y a un balise "i" non fermée au début de cet article (« Cette dépêche est sous licence » ...).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> Si tu désires installer et utiliser un serveur RHEL, il te faudra une licence.

Non. Tu peux très bien utiliser RHEL sans licence autre que celles couvertes par le logiciel inclus dans la distribution (GPL, BSD,...). Par contre, si tu désires avoir accès aux mises à jour via Red Hat Network, à la base de connaissance et au support ou avoir une relation commerciale quelconque avec Red Hat, il te faut un « abonnement » (subscription) pour chacun des systèmes RHEL de ton organisation. Si tu as un système RHEL non couvert par la souscription, le contrat est rompu et Red Hat n'a plus d'obligation envers toi.

Disclaimeur : Ne croyez pas tout ce que vous lisez sur internet. Je suis pas juriste. Je peux me tromper ou m'exprimer de manière ambigüe. Les circonstances de chacun peuvent changer. Mais je travaille au support Red Hat. Si vous voulez être sûr, faites lire https://www.redhat.com/licenses/ à vos avocats.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.