daggett a écrit 533 commentaires

En plus des contraintes du filesystem déjà évoquées, prends aussi en compte que les "4.7GB" sur la pochette du DVD sont des gigas décimaux, ce qui correspond à seulement 4.3 "vrais" Gigas d'informaticien... donc tu ne pourras pas dépasser énormément des 4G de toute façon

Ruby on Rails aurait été bien plus judicieux.

Je suppose qu'avec les bonnes options de find tu peux t'en sortir.
Il existe les prédicats -ctime et -mtime pour obtenir les fichiers modifiés depuis {exactement/moins/plus} de "n" jours; mais si c'est pour trouver ce qui a changé entre deux appels quelconques, "-newer" est utile car il compare avec la date d'un fichier de référence.

Un script qui ferait ce que tu veux se baserait donc sur:

#!/bin/sh

DATE_REFERENCE=/var/tmp/reference_pour_find
if [ -e $DATE_REFERENCE ]; then
find $1 -newer $DATE_REFERENCE
else
echo >&2 "Premier appel, creation du fichier timestamp"
fi
touch $DATE_REFERENCE

Non, sérieusement, qu'est-ce qui vous fait prendre une carte-son de ce prix?

Probablement la même raison que l'existence d'ampli à lampe et des connecteurs "or". Ooops...

En fait, en 32bits, Linux est capable de gérer un total de 64G, mais chaque processus ne pourra adresser que 4G à la fois: après tout, les registres qui servent de pointeurs sont toujours en 32 bits.
C'est pour pouvoir adresser d'un coup toute la plage de 64G qu'il faut être en 64bits natif.

Ou alors vraiment le coup de bol, les machines se connectent en IPv6 avec auto-configuration:
http://www-uxsup.csx.cam.ac.uk/courses/ipv6_basics/x13.html#(...)

C'est un peu comme dire "oh allez, c'était juste une armoire" laquelle contenait toutes tes archives, tes photos, ton courrier personnel...

Moi ce qui me ferait le plus flipper dans ces conditions, c'est tous les trucs (dont je n'ai pas forcément bien consciences) qui peuvent être trouvés sur mon disque dur et qui sont utilisables.
On se doute que ceux qui volent s'attachent plus à la valeur du matériel, et ne sauront rien faire sous linux, mais peut-être qu'ils ont des filières parallèles spécialisées pour, par exemple, fouiller dans tes mails et récupérer un mot de passe Paypal / eBay / banque en ligne/....

pardon, "chiffré". Pour mon home et /etc/, pas pour le système.

Donc, un disque externe portable, certes plus cher qu'un simple disque externe de bureau, mais que justement je peux trimbaler facilement pour éventuellement copier le backup sur une machine familiale distante (pas encore fait, c'est vrai que pour l'instant le PC et le backup sont au même endroit).
Comme j'ai l'intention de m'en servir aussi comme disque portable à usage multiple, et qu'il est donc potentiellement volé / égaré, la partition dédiée au backup est chiffrée (md-crypt, cryptsetup).

Enfin pour la synchro en elle-même, je prends rsnapshot qui est facile d'utilisation, avec sauvegardes différentielles (par semaine, par mois) à base de liens durs pour partager les fichiers identiques.
La récupération est a priori facile puisqu'après avoir monté la partition, il suffit d'aller chercher sous backup/weekly.0 ou weekly.n l'arborescence de fichiers comme sur l'original. Une sauvegarde sur bandes ou d'innombrables CD/DVD me rendrait fou.

Au final, je passe à rsnapshot une liste de fichiers/sous-répertoires qui n'ont pas besoin d'être sauvegardés (trucs sans réelle importances ou facilement récupérables) pour réduire un peu la taille du backup.

Apparemment il y a une piste qui consiste justement à conserver toute l'information au cours des calculs (au lieu d'effacer des trucs au fur et à mesure) de façon à être réversible. Cette réversibilité s'appliquant aussi bien au processus physique sous-jacent qu'au niveau logique, la déperdition de chaleur/énergie (ou l'accroissement d'entropie) pourrait être aussi petite que l'on veut.

http://en.wikipedia.org/wiki/Reversible_computing
http://trappist.elis.ugent.be/~aldevos/projects/computer.htm(...)

À noter justement que les ordinateurs quantiques doivent avoir cette propriété: http://fr.wikipedia.org/wiki/Ordinateur_quantique#Contrainte(...)

Ma remarque finale n'est peut-être pas adaptée selon la façon dont tu architectures tes maître/esclaves. Est-ce que c'est les esclaves qui se connectent une fois pour toute au maître, ou bien ils envoient un message initial (via une socket quelconque) et le maitre les recontacte plus tard sur leur socket ouverte par le bind(0) ?
Dans le 1er cas, tu n'as pas besoin du tout de faire un bind, juste un socket() puis un connect() vers le maitre. Dans le 2eme cas, continue comme tu l'expliques, mais c'est bizarrement foutu.

Je te conseille de lire "Beej's Guide to Network Programming" http://www.beej.us/guide/bgnet/ qui illustre de façon très claire les bases d'un client/serveur.

Au lieu de transmettre à bind() ton port testé en boucle via my_addr.sin_port = htons(port++), il te suffit de mettre sin_port à 0 : bind() t'allouera automatiquement un port libre.

Pour récupérer le port ainsi alloué à ta socket "sockfd" , utilise getsockname:

struct sockaddr_in name;
int namelen;

namelen = sizeof(name);
err = getsockname(sockfd, &name, &namelen);
printf(" err = %d, port alloué = %d\n", err, ntohs(name.sin_port));



Cependant, sache que tu n'as pas besoin de communiquer explicitement ton port via un protocole à toi au maître : du moment que tu fais une connexion à sa socket (via un connect() ou un sendto()), le maitre récupère automatiquement l'identifiant (IP, port) de l'appelant (man getpeername). Tu peux donc te contenter de fournir juste l'UID.

J'espère que tu es conscient que le "nombre de lignes" n'est pas une métrique particulièrement pertinente... entre le programmeur qui fait des dizaines de copier-coller inutiles, et celui qui factorise efficacement du code, elle est même à l'envers.

Je viens de voir (en cherchant "cron public key" dans google-linux ;) ) que la restriction sur les fils de ssh-agent est en fait facilement contournable, si on exporte les bonnes variables d'environnement.
Il suffirait de fournir à ton script cron, les $SSH_AGENT_PID et $SSH_AUTH_SOCK de ta session, pour qu'il puisse se connecter à l'agent. Par contre je viens d'essayer chez moi ça ne marche pas, peut-être que ça dépend des versions/distribs.

puis ssh-add pour mettre la clé.
Ben je crois que tu as donné toi-même la réponse à ton problème !..

Forcément , dans le cron , personne n'a entré ta passphrase, donc aucune authentification par clef ne peux marcher.
(Pour rappel, ssh-agent ne donne accès à ta clef qu'à ses fils et leur descendance (donc X, ton environnement de bureau, ton shell), pas aux autres (donc, pas cron))

Maintenant pour régler ça, il te faut sûrement une autre clef, qui ne soit pas protégée par passphrase.

Les variables d'environnement sont une piste.
Un autre truc fourbe est aussi les file-descriptors standards (stdin, stdout, stderr) qui, s'ils existent et renvoient vers ton xterm quand tu le lances à la main, sont généralement inexistants quand on les hérite de init et des scripts de démarrage. Un message de démarrage par printf peut alors se terminer en échec. Au début de ton programme, ouvre /dev/null pour remplacer les fds 0, 1 et 2 s'ils n'existent pas.

Pour débuggue plus généralement, tu peux remplacer "ton_prog" dans le script de démarrage par "strace -o /tmp/trace.log ton_prog" pour avoir la liste des appels systèmes effectués, avec leur code de retour. La cause de sortie devrait se trouver dans les derniers...

Quand getsockname() foire, que dis un bon vieux perror() ?.. Je pense que ça mettrait déjà sur une piste...

Sinon un strace ou ltrace de ton programme donne en général de bons indices (je suppose que ces outils ou équivalents existent sous ce système)

... on pourra bientôt dire BSD/Linux au lieu d'être obligé de dire GNU/Linux !

C'est vrai qu'une charge de 17, c'est pas mal ;)
Soit tu as effectivement des processus qui bouffent tout, soit c'est plus subtil: si le serveur reste réactif, regarde s'il y a des processus en état "D" dans la colonne "Status" de top ou de ps. C'est en gros un process bloqué en attente d'un retour d'appel système qui ne rendra jamais la main, mais qui en pratique ne consomme absolument pas de CPU.
J'ai déja eu ça par exemple pour un ls sur un CD-rom vérolé (bon, là ça peut consommer si le kernel recommence continuellement), ou sur un montage NFS "cassé". Ça peut aussi arriver sur des drivers buggués.

Tu as peut-être remarqué que ce qui est renvoyé par SNMP est visiblement exactement 100 fois ce que te renvoie top...
/usr/share/snmp/mibs/UCD-SNMP-MIB.txt:
laLoadInt OBJECT-TYPE
"The 1,5 and 10 minute load averages as an integer.
This is computed by taking the floating point
loadaverage value and multiplying by 100"

Donc apparemment c'est le comportement attendu. Tu n'as plus qu'à gérer tes unités en fonction de cette échelle.

Maintenant pourquoi les autres serveurs ne sont pas pareils ? Peut-être qu'ils utilisent une autre MIB avec une autre sémantique ? Ou juste qu'ils ne sont pas chargés du tout et donc ça ne se voit pas même multiplié par 100 ?

Pas vraiment sûr que ça vienne de là (l'erreur serait "bad interpreter: Aucun fichier ou répertoire de ce type"), mais au cas où: il n'y a pas de caractère invisible qui viendrait polluer le nom de l'interpréteur ? fait un "od -c" sur ton script, tu devrait avoir exactement ça:

$ od -c tt.sh
0000000 # ! / b i n / s h \n e c h o "
0000020 S H f o n c t i o n n e " \n
0000037

Si tu as un \r\n au lieu d'un \n à la fin du /bin/sh par contre, c'est un saut de ligne MS-DOS et le \r est interprété comme faisant partie du nom du shell, qui n'existe alors pas.

Google "grep formfeed", 1er résultat:
http://www.redhat.com/archives/guinness-list/2002-January/ms(...)
try: grep '^L' file
where that's typed: g r e p space ' ctrl-v ctrl-l ' space f i l e

Tu peux regarder dans ~/.xsession-errors qui est le fichier ou est censé être redirigé le stderr de tout les programmes lancés par le gestionnaire de fenêtre/bureau.

Attention, iperf donne le résultat en Mega "décimaux" et non pas "puissance de 2" pour le débit en bits (mais pas pour les Bytes).
917 Mebibits = 961 Megabits

Mono-core mais peut-être avec Hyper-Threading, ce qui sera vu comme un presque quadri-proc par linux.
Dans top, appuie sur "1" pour changer la ligne Cpu(s) globale en une ligne pour chaque CPU individuels; tu verras s'il t'en affiche 2 ou 4. (Selon la version de top, c'est peut-être une autre touche.)

Quand à la différence de débit, peut-être que "n'importe quel outil" (lequel ?) mesure le débit "data", alors que iperf compte aussi l'overhead du protocole (les en-tête IP, TCP)

Il faut bien te rendre compte que ton programme, à lui tout seul, est parfaitement linéaire et mono-tâche: Si tu lui demandes de lire la prochaine ligne de l'entrée standard, il bloquera effectivement jusqu'à ce qu'une ligne arrive. Tout ce qui concerne la gestion de l'interface graphique est dans d'autres routines qui ne pourront être appelées que quand getline rendra la main.

Pour pouvoir faire plusieurs choses à la fois, tu as en gros le choix entre deux choses:
- Rendre ton programme multitheadé, chaque thread étant un process indépendant qui fait son truc (c'est alors Linux qui les fera s'exécuter en parallèle). Il faudra malgrès tout pouvoir les faire communiquer pour justement transmettre ce getline()... Et le multithread c'est pas forcément le plus facile quand on débute :)
- Utiliser une boucle d'événement.
Ce dernier point est le classique de tout programme devant gérer plusieurs choses à la fois, et de tout truc ayant une interface graphique. L'idée est d'avoir une boucle while(1) centrale qui attend un "événement" quelconque pouvant arriver de plusieurs sources différentes; une fois celui-ci identifié, on appelle alors la routine qui traitera les données en attente pour cet événement.

Je ne sais pas quel toolkit graphique tu utilises, mais il te donne forcément des points d'entrée pour sa boucle d'événement. Tu devrais avoir le moyen de donner par exemple un couple (descripteur de fichier + fonction), pour que la boucle d'évenement appelle ta fonction dès qu'il y a des données à lire sur ce descripteur (dans ton cas, l'entrée standard), sans avoir à bloquer dessus.

Sinon au pire tu peux le faire gruik toi-même, en testant continuellement dans ta boucle while:
if "quelque chose à lire" cin.getline(); else rendre_la_main_au_GUI();
(mais sache que ton prog prendra alors 100% de CPU).
Je ne connais rien en C++, donc je ne sais pas comment on fait la partie "if quelque chose à lire"...