hierarchie des fichiers Linux

Recherche :

Dernière réponse

Sujet : Debat : gestion RH du /tmp -> RAMDISK -> hierarchie des fichiers Linux

PinG

Sly Angel a écrit a écrit :

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 )

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 :de 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...

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

PinG

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.

PinG

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...

Zzozo

ping a écrit a écrit :

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...

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 ... ;) ...

Sly Angel

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 :)

Sly Angel

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é.

Sly Angel

trictrac_ban a écrit a écrit :

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é

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

houplaboom42

ping a écrit a écrit :

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?

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 )

PinG

Sly Angel a écrit a écrit :

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...

Sly Angel

ping a écrit a écrit :

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é...

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...

Sly Angel

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.

Zzozo

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 > ok merci :) mais j ai pas de nux pour tester la :cry:

trictrac_ban

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

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 :

globule:/tmp# echo tralala > pwetpwet
globule:/tmp# ls -la pwetpwet
-rw------- 1 root root 8 Aug 14 19:13 pwetpwet

pendant ce temps :

.-(/tmp)---------------------------------------------------------(ping@globule)-
`--> ls -la pwetpwet
-rw------- 1 root root 8 Aug 14 19:13 pwetpwet
.-(/tmp)---------------------------------------------------------(ping@globule)-
`--> cat pwetpwet
cat: pwetpwet: Permission denied
.-(/tmp)---------------------------------------------------------(ping@globule)-
`--> rm pwetpwet
rm: remove write-protected regular file `pwetpwet'? y
.-(/tmp)---------------------------------------------------------(ping@globule)-
`-->

maintenant, le root :

globule:/tmp# ls -la pwetpwet
ls: pwetpwet: No such file or directory
globule:/tmp#

tu peux tester ;)

sinon :

globule:/tmp# chmod +t /tmp
globule:/tmp# echo tralala > pwetpwet
globule:/tmp# ls -la pwetpwet
-rw------- 1 root root 8 Aug 14 19:16 pwetpwet
globule:/tmp#

.-(/tmp)---------------------------------------------------------(ping@globule)-
`--> ls -la pwetpwet
-rw------- 1 root root 8 Aug 14 19:16 pwetpwet
.-(/tmp)---------------------------------------------------------(ping@globule)-
`--> cat pwetpwet
cat: pwetpwet: Permission denied
.-(/tmp)---------------------------------------------------------(ping@globule)-
`--> rm pwetpwet
rm: remove write-protected regular file `pwetpwet'? y
rm: cannot remove `pwetpwet': Operation not permitted
.-(/tmp)---------------------------------------------------------(ping@globule)-
`-->

vala

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 ?

asphro

ping a écrit a écrit :

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...

.....

...

..

.

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 !?

houplaboom42

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

PinG

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...

PinG

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é...