Frédéric Perrin a écrit 207 commentaires

Lorsque sudo est invoqué, il execute 'cd' qui est un programme tout à fait valide et accessible via PATH.

Quel est ce programme ? Et comment un programme invoqué par sudo pourrait-il changer le $PWD du shell courant ?

girafe:~% for p in ${path}; do ls -l ${p}/cd; done     
/bin/ls: impossible d'accéder à /usr/local/bin/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /usr/bin/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /bin/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /usr/local/sbin/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /usr/sbin/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /sbin/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /usr/bin/vendor_perl/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /usr/lib/perl5/vendor_perl/bin/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /usr/bin/core_perl/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /opt/qt/bin/cd: Aucun fichier ou dossier de ce type
/bin/ls: impossible d'accéder à /home/fred/bin/cd: Aucun fichier ou dossier de ce type

Parce que /var n'est pas disponible au boot.

D'autant que ce qui était dans /dev/.<xxx>, soit sur un montage tmpfs, donc en mémoire, va se retrouver désormais écrit dans le système de fichiers racine avec tous les risques inhérents à ce genre de pratique (des données volatiles dans /).

C'est pour ça que dans son mail, Poettering explique que /run est un tmpfs.

gagner quelques millièmes de secondes au boot ? Rester permissif dans la gestion des dépendances des rc.d ?

Ni l'un ni l'autre, mais se débarrasser de dossiers /cachés/ dans /dev.

Histoire de fusionner trois FS (/dev/.<xxx>, /etc, /lib/rw) en un, on rend plus vulnérable /. Je ne vois pas où est l'intérêt.

Je ne vois de /lib/rw ni sous Arch, ni sous Debian que j'ai sous la main, ni dans le mail de Poettering. Je ne sais donc pas exactement à quoi tu fais référence. /run a effectivement pour but de remplacer tous les /dev/.xxx, le /lib/init/rw qui est une Debiannerie qui a le même but que le /run proposé, et les choses crades qui écrivent dans /etc (d'ailleurs, je n'ai pas d'exemple en tête de scripts au démarrage qui font ceci... tu as un coupable en tête ?).

En quoi /run rend / vulnérable ?

ça reste redondant avec /var/run

C'est justement pour ça quand dans son mail, Poettering explique que /var/run sera un symlink vers /run.

sauf à cliquer sur "suivant" sans jamais lire ce que dit la fenêtre !

Bravo, tu viens de découvrir le comportement de 80% des utilisateurs devant un ordinateur.

Tres amusant vu la nouvelle du piratage de Bercy annonce la semaine derniere...

Ils ont depense 7.5 millions d'euros pour ... rien!

Qu'est-ce qui te fait dire que l'architecture mise en place n'a déjà repoussé dix attaques par jour depuis sa mise en place ? Le lectorat de DLFP devrait pourtant savoir que les seuls systèmes informatiques dont on parle sont ceux qui tombent en panne, même (surtout !) lorsque c'est exceptionnel.

Pour ce nombre de user je voulais me baser sur de l'archi virtuel ? déja est ce une bonne idée ? Apres si j'ai le choix dois je utiliser plusieurs serveurs pour les perfs ou avec 50==> 100 users je peu tout mettre sur le même ?

Pour 100 utilisateurs, une brouette sous-dimensionnée sera suffisante... Pour info, notre serveur mail ici (qui fait bien plus gestion de mailing lists que distribution de courrier aux utilisateurs finaux, mais bref) fait passer 11000 mails/jour sur une VM de 750Mo de RAM avec une consommation CPU ridicule. Ce qui consomme le plus de RAM est la chasse au spam, dont tu n'as pas besoin dans une messagerie interne uniquement.

Mais c'est rigolo ça.

Qu'est-ce qui se passe si on n'a pas de chance et qu'il y a un saut de ligne juste entre la première moitié et la seconde ?

girafe:~# nmap -sU -6 ::1
Sorry -- IPv6 support is currently only available for connect() scan (-sT), ping scan (-sP), and list scan (-sL). OS detection, random targets and decoys are also not supported with IPv6. Further support is under consideration.

Donc oui, nmap sait parler un peu ip6, mais bien moins bien qu'ip4. (nmap 5.21 ici, mais un grep très rapide sur IPv6 dans le ChangeLog ne montre pas de changements).

Il y a le site « de référence », gopher://gopher.quux.org/1/ qui a plein de ressources sur gopher, et des liens vers d'autres site gopher.

Et bien sûr, le système de commentaires de DLFP ne reconnaît pas gopher:// comme un protocole avec lequel il peut faire des liens :).

J'approuve : le comportement normal de la commande rm est de supprimer des fichiers. Si dans son comportement normal une commande pose plein de questions à l'utilisateur, il y a un souci...

Par contre, dans le cas de mv ou cp, écraser un fichier de destination n'est pas le comportement normal ; dans ce cas, poser la question à l'utilisateur si c'est OK de continuer est raisonnable.

les hommes viriles

Euh, tu es sûr du e ?

En l'état, la commande d'Obsidian n'est pas portable non plus :

% ps aux|grep em[a]cs
zsh: no matches found: em[a]cs

Ce qui bien sûr se corrige par l'utilisation de guillemets.

Ceci dit, pgrep (et son copain pkill) existe sous Linux, FreeBSD, OpenBSD, NetBSD, Solaris, etc. Il reste des OS dignes d'être utilisés qui n'ont pas pgrep ?

Tu peux dire à l'admin sys "hey, j'ai un fichier bizarre dans /home/toto/blah/, tu peux regarder ?". Bien sûr, auparavant, tu auras mis dans ce dossier un fichier exécutable du nom de `ls', qui par exemple fait un "usermod -ou 0 toto" ou toute autre joyeuseté.

Et depuis, on a appris à utiliser pgrep.

Chez moi, ni GNU netcat ni OpenBSD netcat n'ont d'options -q ou -b. Que permettent de faire ces options ? Avec quelle version de netcat ?

Aussi, pourquoi as-tu besoin de préciser le port local à utiliser avec -p ? (du moins, aussi bien GNU nc qu'OpenBSD nc utilisent cette option comme définissant le port local ; comme tu ne sembles pas utiliser ces versions, cette option a peut-être une autre signification chez toi.)

Tu peux créer un service de webmail gratuit chiffré et sécurisé fait de telle sorte que même l'admin ne peut pas savoir quels sont les mails qui transitent sur son serveur.

Justement, il n'y a pas longtemps, la question avait été posée sur la liste de diffusion d'OpenBSD d'une implémentation de PGP en Javascript. L'idée est que le {dé,}chiffrement des mails se fait côté client, et que donc les clefs peuvent rester sur le poste client. Bien sûr, il y a quelques petits détails à régler du style, comment est-ce que le client est sûr qu'il a la bonne version du code JS, et est-ce que la nouvelle version qui vient de m'être envoyée n'envoie pas dans le même temps une copie de ma clef à quelqu'un d'autre ?

Ceci dit, si l'utilisateur utilise un webmail, alors il fait déjà vachement confiance au propriétaire du webmail...

http://marc.info/?l=openbsd-misc&m=129217819603705&w(...) (il y a pas mal de bruit dans la discussion)

Et justement, plus important que l'uptime, il y a le taux de disponibilité et l'efficacité du service rendu. Parce que bon, un uptime remontant à plusieurs années c'est bien, mais si la machine est inutilisable 50% du temps parce qu'elle a une charge trop élevée, bof bof...

Euh, ce sont bien les gens au nom desquels le serveur français de Wikileaks a été loué ?

C'est drôle, moi j'aurais beaucoup joué là-dessus dans l'annonce...

http://demo.ovh.net/download/7a0c424d996a153e176ae3ce5355a28(...)

det ?

Dans le même ordre d'idées : est-ce que le fait que certaines applications soient swappées est un problème ? Est-ce que tu constates des ralentissements dans ta charge de travail normale ? Tu dis que quand tu es en charge, l'utilisation de la mémoire atteint les 4Go, tu as donc largement de la marge pour faire un swapoff. Est-ce que tu constates un changement dans les performances dans ce cas ?

Ici, git gui affiche le diff dans la fenêtre principale, avec les hunks colorés, il n'appelle pas un diff dans un xterm à côté...

Sinon, il y a également gitk, qui est plus orienté vers la navigation de l'historique. Quand tu cliques-droit sur un fichier, il y a une option "Diff externe". Le programme utilisé pour le diff externe est à régler dans Éditer > Préférences.

xdg-open a été conçu exactement pour faire cela, avec son compagnon xdg-mime pour choisir les applications associées à tel ou tel type de fichier. Désolé de casser ton enthousiasme comme cela :-).

Est-ce que tu utilises une locale autre que C ?

Hey, est-ce que tu as compris la commande de François ?

date +"%b %d" renvoie la date sous le format donné (voir man strftime pour les %x possibles). `data +"%b %d"` est remplacé par la date avant l'appel à grep, qui devient donc grep "^mmm. JJ" < fichier.log.

Avec une locale française, la date renvoyée est "nov. 28" pour aujourd'hui parce que c'est l'abréviation de novembre en Français. Les logs contiennent Nov parce que c'est l'abréviation de November en Anglais. Il faut donc donner à date la locale correcte.

Si tu n'as qu'une seule commande dans ce cas, je dirais quelque chose du genre :

grep "^$(env LANG=C date +'%b %d')" < fichier.log

Si tu as plusieurs commandes dans ce style, un petit export LANG=C au début du script sera probablement plus simple.