Krunch a écrit 3959 commentaires

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.

> Est-ce que Debian a une offre de support avec engagement de délai de réparation (dans les dépôts) [...] ?

Tu connais des sociétés qui font ça pour un système d'exploitation complet « généraliste » ?

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

Non. C'est pour btrfs (non supporté dans RHEL pour le moment).

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

C'est ce à quoi on fait référence plus haut en parlant de SIMD.
http://en.wikipedia.org/wiki/SIMD

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

Si tu es français en Belgique, tu es censé respecter la loi belge (et inversement).

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

Les jeux qui sont joués plus de dix ans sont maintenus un minimum. Il fut un temps où les jeux utilisaient souvent IPX/SPX. De nos jours, je te défie de trouver quelqu'un qui utilise encore un de ces jeux.

Par contre, les applications d'entreprise qui sont utilisées sans mise à jour, c'est monnaie courante (pas d'argent/temps pour mettre à jour, on touche pas tant que ça marche, fournisseur qui a fait faillite,...).

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

A priori si c'est IMAP par dessus SSL/TLS, c'est bon (modulo vérification de certificats). Tu peux vérifier ce qui passe avec tcpdump/Wireshark. Après, les mails sortant utilisent un protocole complètement différent (SMTP).

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

> Enfin on sera d'accord qu'installer un serveur DNS juste pour un hôte c'est clairement excessif, non ?

Non.

Le hook de la glibc est certes plus amusant à mettre en place.

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

Pourquoi ne pas poser la question à Sam ? http://cyclim.se/

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

Alors c'est pas vraiment documenté mais le resolver de la glibc donne accès à des hooks pré et post-résolution. Dans res_send.c :

 503                                 res_sendhookact act;
 504 
 505                                 struct sockaddr_in *nsap4;
 506                                 nsap4 = (struct sockaddr_in *) nsap;
 507                                 act = (*statp->qhook)(&nsap4, &buf, &buflen,
 508                                                       ans, anssiz, &resplen);
 509                                 nsap = (struct sockaddr_in6 *) nsap4;
 510                                 switch (act) {
 511                                 case res_goahead:
 512                                         done = 1;
 513                                         break;
 514                                 case res_nextns:
 515                                         __res_iclose(statp, false);
 516                                         goto next_ns;
 517                                 case res_done:
 518                                         return (resplen);
 519                                 case res_modified:
 520                                         /* give the hook another try */
 521                                         if (++loops < 42) /*doug adams*/
 522                                                 break;
 523                                         /*FALLTHROUGH*/
 524                                 case res_error:
 525                                         /*FALLTHROUGH*/
 526                                 default:
 527                                         return (-1);
 528                                 }

Donc le truc c'est de placer le pointeur vers ta fonction qui va pouvoir faire un peu ce qu'elle veut, y compris décider d'utiliser l'un ou l'autre serveur de nom selon des critères arbitraires tels que le contenu de la requête. Soit tu va écrire dans _res.qhook directement, soit tu utilises res_send_setqhook() :

197 void
198 res_send_setqhook(res_send_qhook hook) {
199         _res.qhook = hook;
200 }

Pour la déclaration de la fonction que tu vas écrire, voir resolv.h :

 71 typedef enum { res_goahead, res_nextns, res_modified, res_done, res_error }
 72         res_sendhookact;
 73 
 74 typedef res_sendhookact (*res_send_qhook) (struct sockaddr_in * const *__ns,
 75                                            const u_char **__query,
 76                                            int *__querylen,
 77                                            u_char *__ans,
 78                                            int __anssiz,
 79                                            int *__resplen);
 ..
104 struct __res_state {
...
126         res_send_qhook qhook;           /* query hook */

Donc une fois que tu as écrit ton myresolvhook.so, tu peux l'injecter partout avec LD_PRELOAD. Une alternative sur un système qui dispose du patch utrace serait d'utiliser stap -g. Et si t'as rien compris, utilise juste un serveur DNS.

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

Nonon, il est correctement nommé à côté de screenshot2.docx.rar et screenshot3.docx.rar.

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

/me reçoit régulièrement des screenshot.docx.rar

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

Tu aurais gardé le dump complet de la fonction ainsi que l'adresse exacte du crash quelque part ?

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