Reprise du message précédent :
hummm... sinon, le coup de la DB de plusieurs Go en ram, c mauvais plan, parceque même avec un onduleur qui t'alertes 5 minutes avant la perte de batterie... tu as le temps de copier/rsync la DB, plus le sync sur le HD, plus le halt propre? c'est quoi tes HDD?
 
sinon, faudrait intercepter le signal pf (power fail) dès le début du problème, copier la DB sur le HD, sync le cache HD, puis si le pn (powerfail now) surviens, tu halt proprement, sinon, si tu te prends un po (power ok), tu refout tou en ram? trops risqué...
 

asphro a écrit a écrit :     moi c /chroot/apache/usr/local/apache/       /chroot/web <-- les fichier web   /chroot/libexec/libapache <-- les modules apache     apres y mysql   /chroot/myysql/usr/local/mysql /chroot/home/mysql <-- les db   apres postfix courrier imap meme principe   apres bind meme principe   car je m y retrouve mieux et c pour moi

beurk!
bind...
 
même chrooté, quand ton bind il se suicide parcequ'il comprends pas ce qui se passe, tu est bien sans service DNS... hop, un DOS super facile...
 
prends un vrai serveur DNS, pas cette merde...

 
euuuh un truc qui commence par djb , avec une licence un peu bizarre ?  

 
.....
 
...
 
..
 
.
 
 
IL a fait c preuve pas les autres a+
 
 
dans ce cas fini apache c une merde vu les toru de secu qu il a eu en juin
 
de meme pour openssh je retourne sur telnet
 
de meme pour openbsd ...
 
meme linux, meme windows vais prendre koi !?

je ne comprend pas ce que sont les sticky bits  
c un fichier permettant de definir des droits ? (a la facon d un chmod) ou je me plante completement ?

houplaboom42 > à peut près, même si on n'as pas la même définition de bizare... ce qui n'est pas gpl *strict* est bizare pour toi?
 
asphro > non, faut pas pousser, mais Bind, c une atrocitée ce truc, ne serais-ce que par sa conception...
 
gug > perdu! Sur un répertoire, ca veut dire que personne sauf le créateur d'un fichier ne peut le supprimer... exemple :

 
pendant ce temps :

maintenant, le root :

 
tu peux tester  
 
 
 
sinon :

 
vala

mais je crois que CT juste pour un bench.. en prod il le font pas, c'est juste pour prendre des part de marché!
Comme bugati avec la veyron qui pour des probleme de cout va mettre des pneu "normaux" et des reglage typiques, mais qui, si tu veux tapper dedans, te propose de faire venir des mecanos chez toi pour te changer les reglage le temps de la deconne et tout remettre d'origine ensuite: tu tappe une grosse pointe en condition extremes histoire de dire que ta voiture elle bourrinne, mais en temps normal, elle bourrine pas tant que ca, ùmais ca, une fois que c'est vendu, tu t'en fou, t'as gagner le marché

ping > ok merci mais j ai pas de nux pour tester la

Ben ... non .. en prod ils le font ... sur des Enterprise 6000 et même sur des Sun Fire 15K ... mais l'onduleur ... cé un morceau aussi  ... y'a aussi un groupe electrogène ... et une équip de prod et de supervision qui bichonne toutes ces bestioles ...
Et ca marche du feu de dieu ...
Des bases avec plusieurs millions d'enregistrements ... en transactionnel .... mais en décisionnel aussi ...

ping a écrit a écrit : hum... j'ai lu le thread en diagonale, alors je réponds juste à Sly, même si j'ai vu des énormitées dans un ou deux posts...   */ concernant le vidage auto de /tmp, ENORMEMENT d'Unix font ca... ils se basent sur le atime en général, mais certains sont un peut plus malins que ca. C'est normal. /tmp, comme son nom l'indique est pour les fichiers temporaires, donc ... _volatiles_ */ déjas, /tmp, c une atrocitée... Entre les race conditions, et autres... Donc dans un premier temps, avis à la populasse, foutez moi un bit sticky sur /tmp, et tous les reps de ce genre (/var/run, ...). De toute facon, le mieux c'est que le tmp de chaque user soit séparré de celui des autres (~/tmp par exemple) et surtout que /tmp ne serve pas à un programme/daemon/script/cequevousvoullez à créer des fichiers... */ hum... /tmp en ram, c'est bourin, tout le monde à les droits sur /tmp, je peux te saturer ta ram (en accès, pas en taille) même si tu m'as foutu des limitations (setrlimit par exemple...) asser facilement... */ fouttre un truc en ram, ca sert juste si tu accède souvent à des fichiers du disque... Si c'est des binaires, anyway quand ils sont lancés ils sont chargés en ram.   Mon conseil :   */ si c'est pour toi, pour des fichiers -> tu te créé un ~/ram_tralala_pwetpwet chargé en ram, tu fout tes fichiers dedans... */ si c'est un daemon ou une appli lancée continuelement -> ca sert à rien */ si c'est une appli lancée fréquement -> **/ si tu en est l'auteur -> tu créé une sorte de daemon qui reste en mémoire et qui contiens/charge/map la majorité des chaoses **/ sinon bah tu la fout dans un ramdisk, monté de préférence dans ~/ram/foo_bar       Pour tout le monde : */ fouttez des sticky bits dans les reps où tout le monde à les droits d'écriture */ utilisez ~/tmp au lieu de /tmp (caca) sauf pour l'échange de fichiers, et encore... */ si vous codez faites gaffes si votre appli doit gérer des fichiers temp... pour vous en convaincre, jettez un oeuil sur eliott par exemple...     vala, ct le coup de geule du mec qu'en a marre que tout le monde fasse n'importe quoi.

 
- Machine complétement dédiée à ce qui est utilisé dans le /tmp donc pas de problème, un seul user réel existe sur la machine
- Ce ne sont pas des binaries, effectivement aucun intérêt de mettre un binaire en RAM, ce sont plutôt des fichiers accédés comme des bases par exemple
- ~tmp c'est bien beau mais sachant que comme je l'ai dis plus haut il n'y a pas qu'un daemon qui utilise cet espace, c'est un peu lourd, dans les cas un ~ est pas gérable dans mon cas de figure ( je veux justement que cet espace soit partagé à tous les fichiers de tous les daemons potentiellement )
- Il faut voir que déjà au départ beaucoup d'applis utilisent /tmp pour mettre leurs fichiers de travail ( notamment mon premier exemple en tête sera Zend Accelerator ), partant de là je préfère ajouter des choses en /tmp qui me sont utilise dans un but assez similaire par rapport à ce que Zend fait et mettre le /tmp en RAM plutot que de modifier la config de Zend Accelerator ou tout autre programme du même genre à chaque fois que j'en installe un.  
 
Enfin c'est des choses que j'avais déjà précisé mais bon
 
J'ai aussi dis il me semble que je ne prétendais pas faire quelque chose de super normal en utilisant /tmp pour ça.

 
Tu fais un sync de temps en temps en CRON et généralement ce ne sont pas des bases sensibles ou souvent modifiées, du moins c'est en général ce dont on parlait.
 
P.S. : En 5 min on peut transférer des Go ( 6 Go à 20 Mo/s par exemple ) et de toute manière tu vas surement pas souvent mettre 5 Go ou + en RAM non plus...

heu... tu veux dire une syncho de la ram vers le hd, pas un (1) sync ?
sinon, oui, mais je trouve ca risqué quand même...
si c'est des fichiers en lecture seul ou temporaires, ca vas, mais des fichiers/bases dans lesquels tu écrit...

 
non c est pas du free software ou compatible tout simplement ( mais je ne remet pas du tout en cause la qualité de djbdns hein   )
 
http://www.gnu.org/licenses/licens [...] areLicense
 
sinon les sticky bit sur le /tmp il est pas par default sur la plupart des distros ? ( en tout cas il l est pour la mienne )

 
Les moteurs de recherche comme google font ça en prod. Le cout est bien moindre et les perfs bien meilleures...

 
un rsync du répertoire en utilisation si tu préfères
 
Effectivement c'est délicat pour des bases, au pire par contre c'est par contre possible de faire un LOCK TABLES + BACKUP TABLES sous MySQL par exemple de temps en temps, sachant qu'on a toujours dit le faire sur des bases TRES PEU MODIFIEES, dans ce cas le risque est minime...
 
C'est une question de choix, c'est un choix sur des fichiers qui ne nécessitent pas une absolue stabilité.  
 
 

houplaboom42 a écrit a écrit :     non c est pas du free software ou compatible tout simplement ( mais je ne remet pas du tout en cause la qualité de djbdns hein   )   http://www.gnu.org/licenses/licens [...] areLicense   sinon les sticky bit sur le /tmp il est pas par default sur la plupart des distros ? ( en tout cas il l est pour la mienne )

 
Perso j'aime bien djbdns, mais par contre il a tout de même moins de suivi que named et c'est dommage. L'avantage aussi de prendre un serveur DNS différent du standard named, c'est que les "méchants pabos" qui veulent la peau de ton serveur supposent par défaut que tu utilises named, les gens qui cherchent des exploits le font également sur ce produit puisque le plus répandu sur les distribs. La célébrité a ses revers... ( je pense que si djbdns était le standard, il y aurait un peu plus d'exploit trouvés pour lui également )
 
Par défaut normalement il y a le sticky bit oui

On n'a pas dit de mettre dans un fs en RAM les fichiers/bases dans lesquels tu écris souvent ... ... cé kler que c'est dangereux e que c'est chercher les emmerdes que de le faire sur qqchose qui est susceptible d'être modifié à tout moment ... par contre, y' a un truc qui est pas mal pour les SGBDR en général, cé de mettre leur base temporaire (celle qui est utilisé pour créer les tables temporaires et autres "objets" que le SGBDR créé/détruit pour son fonctionnement interne) dans un fs en RAM ... ca les aide bien, et les risque en cas de crash sont très limités ... surtout pour les SGBDR qui "journalisent" (les transactions quoi ...) systématiquement (i.e. : faites bien attention au type de table avec MySQL  )  ...
Mais bon, je le répète, on ne se lance dans ce genre d'optim qu'après ANALYSE  (du système en place, des goulots d'étranglement, des risque, etc ...) et une fois que son système est stable (on fait ca sur les serveur en général, donc peu de "vrais" users existent sur la machine ...) ... mais je crois que qqun l'a déjà précisé ca ... ...

houplaboom42 a écrit a écrit :     non c est pas du free software ou compatible tout simplement ( mais je ne remet pas du tout en cause la qualité de djbdns hein   )   http://www.gnu.org/licenses/licens [...] areLicense   sinon les sticky bit sur le /tmp il est pas par default sur la plupart des distros ? ( en tout cas il l est pour la mienne )

DJB>
bah, DJ a ses raisons, clairement expliquées, que je respecte (parcequ'elle tiennent debout). Arrétez de vouloir imposer une licence virale à tout le monde, DJ est l'auteur de son soft, il a le droit de le placer sous la licence qu'il veut, non? C'est open source, et libre d'utilisation/modifications/distribution, non? Oui, bon bah c'est tout ce que je demandes aujourd'hui à un soft.
 
sticky> ca l'est de plus en plus, la debian l'as, mais toutes ne l'ont pas...

Sly Angel a écrit a écrit :     un rsync du répertoire en utilisation si tu préfères   Effectivement c'est délicat pour des bases, au pire par contre c'est par contre possible de faire un LOCK TABLES + BACKUP TABLES sous MySQL par exemple de temps en temps, sachant qu'on a toujours dit le faire sur des bases TRES PEU MODIFIEES, dans ce cas le risque est minime...   C'est une question de choix, c'est un choix sur des fichiers qui ne nécessitent pas une absolue stabilité.

ouep, on est d'accord. Dans le cas de Google, si je me souviens bien, seuls les bases qui contiennent les mots -> sites sont en ram, les bases dans lesquels ils écrivent sont en hard drive.

Suivi : bah disont qu'aujourd'hui DJB est stable, a toutes les options que l'on peut espérer, donc les maj sont éventuellement des bug fixes.
standart e toute facon, le gros problème viens du fondement des deux programmes, et du protocole DNS. Bind est mal penssé, sur plusieurs points. DJ a essayé de réfléchir à la secu et au service DNS avant de coder. Ajoute à  cela que c'est un très bon codeur (quand il code, il se préminise des buffer overflows, il rends toutes les allocations dès qu'il n'en a plus besoin, il utilise snprintf et non sprintf, ...)... Et puis de toutes facon, le proto DNS a pleins de trous (master spoofing, zone overwriting, ...), ainsi qu'IPv4 (spoofing, ...)...
 
Et puis, en dernir lieu, djb est plus simple d'utilisation... (même si je n'aime pas trops svscan) et offre plus d'options...