Pierre Carrier a écrit 199 commentaires

Le service n'a besoin d'être disponible que quand tu veux changer ces informations, pas les lire… Les méthodes POSIX ne vont nulle part.

24h sur 24 ?? systemd et D-Bus proposent tous les deux l'activation de services à la volée. Voir http://www.freedesktop.org/wiki/IntroductionToDBus#Activation pour D-Bus.

À moins que tu ne parles du daemon dbus ? C'est dur d'utiliser un système de bureau moderne basé sur Gnome sans en 2012 avec tous les composants reposant dessus, et il est vraiment léger (il prend 2Mo de RAM sur mon système…).

Il y a un paquet d'alternatives à yaourt si tu veux automatiser autour d'AUR. J'utilise packer.

La solution exists passes en revue tous les user et pour chacun fait une requête sur la table email. Une sous-requête exist est difficile à optimiser, même dans les cas particuliers.

Comme tu l'as présenté, les solutions efficaces évitent exist :

select u.id from user u join email e on e.source_id = u.id or e.target_id = u.id

Parce que le site de campagne de barack obama sera visité dans le monde entier ?

— Réponse d'un résident français à un autre résident français, telle que lue par un résident suédois.

Par ailleurs, il faut se souvenir que les États-Unis c'est grand, et leurs architectures réseau sont relativement décentralisées. Si tu veux couvrir tout leur territoire avec des faibles latences et/ou bons débits, un CDN vaut le coup. http://www.datacentermap.com/ixps.html

Désolé, mais visiblement tu ne sais pas comment "ce genre d'entreprises" fonctionne en la matière.

Elles ont souvent des prestataires qui s'occupent de la maintenance, de gérer des listes de domaine, alerter pour l'arrivée de nouveaux TLDs, etc. La facture est peut-être gonflée par rapport à une gestion interne et des registars low cost, mais encore une fois les coûts sont ridicules par rapport au reste de la production, et les risques largement amoindris.

Même sans ça :
À ma connaissance tous les registars d'autorisent à acheter pour 5 ou 10 ans et à renouveller à l'avance. En achetant toujours pour 5 ans, tu peux faire une revue de ta liste tous les 2 ans et être tranquille. Pas exactement un problème difficile.

Même pratique chez mon employeur.

L'intérêt des noms de domaine de niveau 2 par rapport à un niveau 3 ou 4 comme tu le suggères est la vitesse de résolution par les serveurs de nom. Dans des cas particuliers cela permet aussi d'éviter de surcharger les serveurs de nom de l'entreprise (les changements dans les zones dédiées aux CDNs sont rares). Une autre énorme avancée est pour garder des réponses tenant dans UDP ; dès qu'il y a des CNAME et/ou du round robin sur enregistrement A, ou CNAME et/ou enregistrements SRV, on peut se retrouver avec ces noms reproduits plusieurs (dizaines de) fois et devoir utiliser TCP. L'effet du passage d'UDP à TCP sur la charge côté serveurs de noms et latence de la résolution côté client sont impressionnants. Il vaut mieux effectuer 2 requêtes DNS passant sur UDP qu'une sur TCP.

Utiliser un domaine de domaine court (quelques lettres) permet aussi de le réutiliser pour offrir des URLs courtes, ce qui peut alléger les pages, E-mails, parfois significativement.

Les en-têtes des requêtes HTTP sont aussi plus courts, ce qui est utile vu qu'ils ne sont jamais compressés et affectent significativement la latence (doivent être entièrement servis avant que quoi que ce soit ne revienne, souvent sur des connexions TCP fraîchement créées donc avec de petites fenêtres les rendant très sensibles au roundtrip des paquets IP).

L'effet réel est peut-être faible au final, mais vu que ça ne coûte pas plus cher d'avoir un nom court (ton journal est rigolo : le coût annuel d'un domaine est complètement ridicule pour ce genre d'entreprises), ce n'est pas vraiment la peine de trop y réfléchir.

Oui pardon, je perds l'habitude du franglais. Il faut définir un "high watermark" bas (d'où le "low") pour jeter les messages rapidement.

Quelques potentiels problèmes avec zeromq, sans avoir regardé le design exact autour de ton logiciel :

1 - zeromq ne peut communiquer qu'avec des pairs de confiance. Le code est rempli d'assertions et il est trivial de le faire crasher dans tous les sens.

2 - Tu sembles utiliser des sockets Req/Rep, qui sont fragiles et généralement une mauvaise idée. Chaque pair doit absolument alterner req et rep ou le socket "explose". Le modèle "je reçois des requêtes et renvoie une réponse par requête" est mieux implémenté avec des sockets utilisant des en-têtes (se référer à l'excellent zmq:guide pour des implémentations "solides").

3 - Il faut autant que possible définir une "low watermark" sur les sockets, si tu ne le fais pas déjà. Si les clients envoient des requêtes mais ne sont jamais là pour recevoir la réponse (client qui meurt prématurément ou est déconnecté, potentiellement un attaquant) les messages s'empilent au cas, où ils réapparaitraient plus tard. Sans "watermark", ils s'empilent indéfiniment et peuvent manger toute la mémoire.

Si tu as le temps, merci d'avance de m'indiquer l'état du code vis-à-vis de ces problèmes :)

Pour les décideurs pressés (qui utilisent x86_64 pour le moment, j'ai la flemme de construire un environnement de build i686), les paquets sont disponibles en ajoutant dans /etc/pacman.conf :

[poussin]
Server = http://arch.pouss.in/$arch

J'ai posé des paquets pour freelan-buildtools 1.0, libcryptoplus 1.3, libiconvplus 1.0, libfscp 1.0, libasiotap 1.0, libfreelan 1.0, freelan 1.0 sur https://aur.archlinux.org/

Je te fais signe si je démarre un dépôt binaire :)

Deux ans hors pays francophones et j'en perds mon lat^Wfrançais.

Le spectre électromagnétique n'est pas infini, on ne peut pas y faire passer autant de données que l'on souhaite à coups d'investissements.

Le gigabit à large échelle ne peut être que filaire jusqu'aux derniers 20 mètres avec les technologies actuelles et leurs (non r-)évolutions attendues. Le sans-fil c'est bien pratique, mais ça ne passera pas a l'échelle des flux vidéos HD pour tous en zones urbanisées.

(Physiciens de tous bords, de grâce, dites-moi que j'ai tord)

Contrairement à getent passwd, id(1) affiche la liste des groupes auxquels tu appartiens via getgroups(3) ou similaire.

Si tu utilises ldap pour les groupes, ça veut dire recherche de tous les groupes auxquels ton utilisateur appartient. La même recherche a lieu à l'ouverture de session (initgroups(3) ou identique qui fait appel à tous les backends définis pour group dans nsswitch.conf).

Vérifie comment la requête est configurée, et que ton serveur dispose d'index adaptés.

Normal, il faut ne rien mettre.

Tu arriveras sur l'un de ces serveurs :

% dig +short _jabber._tcp.google.com SRV
5 0 5269 xmpp-server.l.google.com.
20 0 5269 alt3.xmpp-server.l.google.com.
20 0 5269 alt4.xmpp-server.l.google.com.
20 0 5269 alt5.xmpp-server.l.google.com.
20 0 5269 alt6.xmpp-server.l.google.com.
5 0 5269 alt1.xmpp-server.l.google.com.
5 0 5269 alt2.xmpp-server.l.google.com.

Et même si ça reste du PDF, une mise en page adaptée aux liseuses électroniques est disponible via go_kindle.tex, compilée tous les jours avec la version principale et disponible sur [http://www.miek.nl/files/go/].

Pour Learning Go, tu peux profiter du fait que les sources LaTeX soient disponibles.

Je réalise que les PIDs n'augmentent pas "assez", que je ne vois pas immédiatement pourquoi, et que j'ai l'air bien con.

J'aime beaucoup systemd, et le boulot de Lennart Poettering en général (même si je conçois que beaucoup de ses projets ont été amenés à gêner pas mal de monde dans l'utilisation quotidienne de systèmes libres).

Ceci dit, je commence à en avoir ras-le-derrière de cet argument. Je cite : "Tout le système de démarrage SysVinit est basé sur des scripts qui lancent des commandes externes. D’après Lennart cette approche est condamnée à être lente.".

1) grep, awk, cut, sed, etc. pourraient (souvent) être remplacés par des primitives du shell, et on éviterait de lancer des processus. Si les primitives manquent au shell par défaut de la distro, c'est peut-être plus intelligent de l'implémenter (ou d'utiliser un langage dynamique plus puissant, genre Python/Perl/Ruby/votre lubie) que de faire pêter du C ?

2048 processus echo prennent 5 secondes :

bash-3.2$ time sh -c 'for id in {1..2048}; do /bin/echo $id; done > /dev/null'
real    0m5.453s
user    0m1.374s
sys     0m3.542s

2048 echo de Bash prennent 50ms :

bash-3.2$ time sh -c 'for id in {1..2048}; do echo $id; done > /dev/null'
real    0m0.051s
user    0m0.041s
sys     0m0.007s

2) J'ai écrit en 2 minutes un micro-benchmark (pourri, comme tout benchmark). Un processus qui crée un enfant puis attend qu'il termine. Cet enfant crée lui-même un enfant puis attend qu'il termine. Le tout récursif, 2048 fois (donc 0 parallélisation, et on se retrouve avec 2049 de ces processus en simultané...).

Dans une machine virtuelle sur un laptop avec processeur basse consommation, l'exécution prend un total de 11 ms.

$ grep ^Pid /proc/self/status; time ./forking; grep ^Pid /proc/self/status
Pid:    15451
real    0m0.011s
user    0m0.002s
sys     0m0.009s
Pid:    15548

Si vous doutez de ma capacité à écrire 10 lignes de code, vous pouvez vérifier sur [https://github.com/pcarrier/stuff/blob/master/fun/forking.c].

systemd apporte des fonctionnalités géniales, mais de grâce, arrêtons d'utiliser la performance comme argument pour l'introduction de larges binaires.

... et postfix ne chroot() pas par défaut.

Peut-être que ta distribution met ça en place, mais ce n'est pas le cas d'upstream.

Tu peux vérifier dans postfix 2.6.5 : ils fournissent les instructions de chroot dans examples/chroot-setup.

Red Hat Enterprise Linux 6 utilise postfix par défaut, bien que sendmail soit toujours disponible. Et RHEL5 utilise sendmail par défaut, mais postfix est disponible.

Une approche qui peut t'intéresser est l'utilisation du mode restreint de bash.

Voir RESTRICTED SHELL dans bash(1).

Pour l'utiliser comme shell de login, le plus simple est de créer un lien symbolique /bin/rbash pointant vers /bin/bash, l'autoriser dans /etc/shells et de définir /bin/rbash comme shell pour un utilisateur.

Attention, pas de cd du tout !

Si tu veux que l'emplacement par défaut n'affiche que www, il "suffit" de définir le répertoire utilisateur (HOME) dans /etc/passwd pour indiquer un répertoire relatif à la racine du chroot et contenant uniquement www.

Si tu veux empêcher l'utilisateur de remonter dans la hiérarchie, tu te retrouves avec un chroot dans un répertoire qui ne contient pas de binaires. Dans ce cas un shell interactif ne sera pas utilisable (même pas de ls), et il faut utiliser sftp. Ce type de configuration est couvert par http://www.minstrel.org.uk/papers/sftp/builtin/

Sous Linux, Samba pourra stocker les ACLs Windows sur des ACLs POSIX (donc ext3 par exemple), ou NFS.

Une section du Samba HOWTO couvre les bases pour le premier cas.

Voir *acl* sur source3/modules (git de samba) pour le code des différents "backends" (posix, zfs, nfs, etc.).

Déjà, je vois mal l'intérêt de réimplémenter libpcap, m'enfin...

Tu as envie de comprendre le chemin de code impliqué entre le syscall handler pour une opération sur un socket, jusqu'au driver Ethernet ? Il n'y en a pas. Tout ce qui se passe sur ta carte réseau "en vol" (en dehors de la configuration) sera pris en charge dans la gestion de ses interruptions, donc pas dans le contexte de la prise en charge de ton syscall (même si ton syscall est traité dans le même temps).

Les relations entre les deux sont déraisonnablement compliquées pour faire l'objet d'un commentaire...

Si tu veux comprendre ce qui se passe dans le noyau, je te conseille de jeter un œil à drivers/net/e1000/e1000_hw.c. Si tu es toujours motivé après cet exemple, on peut discuter :)

Des fichiers au sens où tu peux open() et obtenir un file descriptor, non.

Des données embarquées, oui, avec objcopy. Voir par exemple http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967