Comprends pas tes raisons pour ne pas vouloir utiliser de cles. Un login par mot de passe ca se craque de plein de facons (dictionnaire, timing des paquets, shoulder-surfing, rien d'evident mais autant de vecteurs d'attaque possibles) alors qu'une cle a 1024 ou 2048 bits prendrait l'age de l'univers a craquer. Si tu proteges ton fichier cles avec un mot de passe bien choisi tu limites considerablement les attaques, et le resultat est le meme: tu ne peux pas utiliser la connection tant que tu ne connais pas le mot de passe. La seule difference est que dans un cas il est echange sur le reseau, dans l'autre il est utilise par un process en local pour debloquer des informations, et il reste disponible apres l'avoir tape une fois sans avoir a pondre un script maison.
ssh propose le login par cles precisement pour contourner les problemes de securite causes par le login via mot de passe, et ssh-agent est la pour te faciliter la vie dans cette voie. Le probleme du stockage du fichier de cles en local est egalement partiellement resolu si tu transportes ton fichier de cles dans... une cle USB.
Si tu connais Python, tu peux eventuellement regarder aussi 'paramiko', qui encapsule des liaisons ssh (donc scp) de facon relativement elegante, ce qui permet de scripter assez facilement des operations de transfert repetitives. On pourrait imaginer un script qui refuse de se declencher pour les copies tant qu'une cle USB n'a pas ete inseree sur le poste local, contenant un fichier de cles adequats pour le login sur tes machines distantes.
Bon enfin ce que j'en dis... Peut-etre que tu as d'autres contraintes sur les cles/mots de passe que tu voudrais exposer? Si ton souci principal est un souci de securite, fais attention par exemple au process expect que tu lances (un trojan est si vite installe...).
Pour se logger sur un hote distant via ssh en re-dirigeant tous les flux X11 vers sa machine locale, il faut effectivement autoriser X11Forwarding sur le serveur ssh, re-demarrer le serveur au besoin, puis simplement se connecter avec l'option -X (majuscule):
ssh -X host
ssh s'occupe tout seul de creer un display virtuel qu'il re-dirige vers ton display local. A l'inverse, pour etre sur de ne pas forwarder les flux X11, utilise l'option -x (minuscule).
xhost est a proscrire totalement pour autoriser les displays, c'est un trou de securite majeur qui a plus de 10 ans. Si tu veux temporairement donner un acces a une personne sur le reseau a ton serveur X, utilise plutot 'xauth'. La man page est une bonne source d'informations. Dans les deux cas, donner acces a son serveur X a une machine distante revient a une perte totale de securite de ta console. Il est facile de revoquer une autorisation d'acces avec xauth, c'est beaucoup plus difficile avec xhost.
ssh-agent garde en memoire les cles utilisees pour te logger sur tes diverses machines et les fournit tout seul a chaque fois que tu en as besoin. Si tu penses a mettre un mot de passe pour proteger tes cles, d'un point de vue utilisation ca revient exactement au cas que tu decris:
La session demarre, tu tapes ton mot de passe pour debloquer ton jeu de cles. A chaque login (ssh/scp), ssh-agent fournit la cle pour toi. En passant: pour scp, pense a enlever les bannieres et autres affichages de texte dans le .bash_login ou .bashrc, il n'aime pas ca du tout et plante avec une erreur incomprehensible.
ulimit est un reglage de parametres sous bash, c'est plutot du domaine du desktop. Sa valeur depend entierement de l'utilisateur qui lance l'application, alors que cette valeur devrait etre fixee par l'application elle-meme en accord avec les ressources disponibles. Ca peut resoudre le probleme pour un utilisateur desktop soucieux de ne pas planter sa machine par un memory leak au cours du developpement, c'est tres difficile a regler system-wide.
Quand malloc retourne NULL on peut faire encore beaucoup de choses comme par exemple mapper des espaces disque pour creer son propre swap. Une appli peut aussi avoir envie de profiter du maximum d'espace memoire disponible pour accelerer ses calculs le plus possible. Le probleme de l'overcommitment c'est qu'on ne peut pas compter sur le systeme pour nous dire a un instant T si la prochaine allocation pourra se faire ou bien si elle plantera le systeme.
Pour l'histoire: la discussion qui a precede l'existence de ce patch date de 98. Voir par exemple:
Dans mon experience, Linux est un systeme extremement peu fiable pour tout ce qui concerne la gestion de la memoire aux limites. Quand on a des processes qui ont besoin du maximum de RAM qu'ils peuvent allouer, les Unix standards nous ont habitue a utiliser malloc() et lui faire confiance pour retourner NULL quand il n'y a plus de ressources disponibles. Ce contrat n'est pas respecte sous Linux et ce n'est pas la faute de malloc(), mais bien celle du noyau.
Sur des programmes qui peuvent etre mission-critical (francais?), un tel comportement n'est pas acceptable. La seule facon de s'en sortir est de determiner soi-meme la quantite de memoire disponible a priori sur la machine locale, de surcharger les allocations memoire avec un compteur et d'arreter d'allouer quand le compteur indique une limite atteinte. Les nombreuses discussions qui ont eu lieu avec les developpeurs en charge de la gestion memoire sous Linux se sont terminees en queue de poisson.
Ceci dit, il est rare d'avoir a ecrire des programmes qui ont besoin forcement d'allouer le maximum de memoire disponible dans un environnement critique. Pour la quasi totalite des applications qui tournent sur des desktops, les points decrits ici ne s'appliquent pas. Dans le cas precisement evoque ici, le kernel s'est retrouve aux limites a cause d'une faute de programmation dans une appli Java. Pas de panique donc! Les gens qui ont l'habitude de pousser Linux a ses limites en gestion de memoire doivent juste etre conscients des limitations induites par l'overcommitment.
OOM killer (Out-Of-Memory Killer) est une fonctionnalite du kernel qui se declenche quand il n'y a plus aucune memoire disponible sur le systeme. Les operations d'allocation memoire ont sature la memoire physique, puis le swap, puis il ne reste plus de place pour allouer encore. A ce moment-la, le kernel prend son courage a deux mains et decide qu'il doit y avoir une application qui est decidement trop gourmande en memoire et qu'elle a ete donc forcement mal programmee et ne merite plus de vivre. Il observe les processes qui sont les plus gourmands en consommation memoire et les tue jusqu'a ce que le systeme recouvre assez de ressources pour continuer a fonctionner.
Dans ton cas, tu as sans doute une application qui est partie en vrille en allouant de nouveaux objets en pagaille sans les liberer. Avec les infos que tu donnes je pencherais pour un probleme Java (JBoss). En aucun cas un filesystem ne peut declencher directement l'intrepide OOM killer. Si tu as de la chance, OOM killer decidera de tuer precisement l'application qui pose des problemes, mais rien n'empeche OOM killer de dezinguer ton serveur X ou bien ta session eclipse dans laquelle tu travailles depuis 2 jours sans sauvegardes. C'est lui qui choisit, pas toi.
Dans le detail: OOM killer fait d'une machine Linux une veritable bombe a retardement pour toutes les applis qui ont besoin du maximum de memoire qu'elles peuvent allouer. Pour les applis desktop c'est encore acceptable mais pour du deploye industriellement c'est critiquement grave.
Linux est (a priori) le seul Unix qui vienne avec cet infame OOM killer. La raison profonde derriere ce patch est le fait que le kernel Linux s'amuse a promettre bien plus de memoire qu'il ne peut en offrir (memory overcommitment). Application: ecrire une boucle qui alloue des paquets de 1 Meg a la fois et regarder combien on peut en allouer (mon noyau me promet jusqu'a 4 Gb sur une machine qui possede 512 Mb de RAM + 512 Mb de swap). Deuxieme essai: allouer les blocs en boucle jusqu'a ce que malloc retourne NULL, puis remplir de zero les zones allouees une par une. La RAM se remplit, puis le swap, puis apres c'est le bonheur: soit le noyau plante, soit OOM killer intervient et (parfois) tue d'autres processes vitaux du systeme, ce qui finit en desastre complet.
Pourquoi le noyau s'amuse-t-il donc a promettre plus de memoire que ce dont il dispose? Apparemment c'est du a l'implementation de fork() qui commence par repliquer le process qui fait cet appel, incluant une copie complete de sa memoire, ce qui prend du temps. Generalement un process qui fork() fait immediatement un exec derriere, ce qui rend inutile la perte de temps de recopie de memoire. Le noyau prefere promettre a fork() de la memoire dont il ne se servira de toutes facons pas.
Si ce comportement vous inquiete vous pouvez desactiver le memory overcommitment en manipulant des flags dans /proc/sys/vm (suivant la version de kernel). Attention alors: le systeme ralentit considerablement.
Posté par malin .
En réponse à la dépêche Mythtv 0.20.
Évalué à 2.
MythTV utilise la majorité des fonctionnalités de MySQL.
Tu me sembles bien renseigne, peut-etre pourras-tu repondre a ces questions: quels sont les features de MySQL utilises dans MythTV qu'on ne trouve pas ailleurs? Quand tu affirmes que pres de 70% des fonctionnalites sont utilisees, c'est juste un sentiment ou bien un argument demontrable?
Peut-etre que tu confonds "les fonctionnalites des MySQL" avec "les fonctionnalites de SQL"?
suffisamment pour que la 0.19 soit impactée par un bug sur un JOIN spécial de MySQL
Voici exactement le genre de probleme auquel je faisais reference. MySQL est un volume de code important. En tant que tel il amene ses bugs, ses problemes de maintenance, de securite, ses dependances. Moins on amene de code dans l'equation, moins on prend ce genre de risques. Ca n'a rien de particulier avec MySQL.
N'importe quoi ! Tu as à autoriser ton user mythtv, fermer l'accès externe, en gros c'est tout.
Alors Grand-Mere: pour regarder la TV c'est pas complique. Tu downloades 90 megs de soft, ca vient avec un SGBDR qui t'installe un utilisateur de plus mais tu le desactives et tu fermes les ports qu'il va ouvrir, au besoin tu vas editer un fichier de conf et puis tu relances le daemon avec les droits qui vont bien et tu verifies avec nmap que t'es pas attaquable... Dis, tu dors Grand-Mere?
C'est une vraie caricature. Un truc ecrit par des geeks pour des geeks.
Ah si, tu peux mettre en cron la sauvegarde régulière d'un dump de ta base sur une autre machine.
A un moment il faudrait faire la difference entre un ingenieur systeme et un type qui veut juste regarder des films a la TV (avec des fonctionnalites sympas). Parfois ce sont deux personnes differentes, tu sais.
Tu devrais plus te renseigner sur ce qu'est une BDD et sur le fonctionnement de MySQL
Mes connaissances sur le sujet n'ont rien a voir avec la discussion, jeune Padawan. Attaque l'argument plutot que l'argumentateur.
Le fait que chez moi ça marche, avec l'install de base faite par un "make install" et une copie du default-my.cnf (ou un truc comme ça) ?
Si je l'ai vu marcher chez moi alors ca marche partout ailleurs. C'est cool ca! Il suffit de coder une fois sur ma machine pour que dans le reste du monde ca marche pareil!
Ohlala ! Encore une fois : zéro maintenance, et MySQL se compile tout seul. Avec une distro, rien à faire.
MySQL: la premiere (et seule) DB du monde qui se maintient toute seule! Et elle corrige ses bugs elle-meme, et se met a jour toute seule, meme sur un live-CD!
Si tu veux mon experience: j'ai apt-get installe MythTV sur une machine chez moi. Apres son long download et sa configuration ou il m'a parle de plein de parametres de config qui n'ont rien a voir avec regarder une video, il m'a profondement brise les coudes en me posant des questions sur l'installation de mon beau nouveau serveur MySQL. Je passe deja suffisamment de temps les mains dans les DBs dans la journee (MySQL, Postgres et Oracle) pour ne pas avoir envie de recommencer chez moi en rentrant. Laissez-moi voir mon media center et arretez de me pourrir la vie avec de la maintenance systeme! Je ne suis pas un numero! Je suis un homme liiiiibre! ;-)
J'ai essaye Freevo ca a l'air chouette. Point de vue dependances soft il ne depend que de players video/son et quelques libs Python. Pas encore regarde les fonctionnalites TV.
Bon enfin ce que j'en dis... Si ca marche bien pour toi et que tu te fais plaisir c'est ca qui compte.
D'autres filesystems supportent egalement les labels:
ext2/ext3:
% tune2fs -L Musique /dev/sdXX
xfs:
% xfs_admin -L Musique /dev/sdXX
...
Si Gnome est bien configure (e.g. Ubuntu) tu verras apparaitre une icone sur le desktop quand le disque est branche, du nom du label donne (ici: Musique). Les donnees sont accessibles sous /media/Musique par la suite.
Posté par malin .
En réponse à la dépêche Mythtv 0.20.
Évalué à 5.
Est-ce qu'on peut essayer de lister les utilisations qui sont faites de SQL dans MythTV? Est-ce qu'on peut mettre ca en regard du nombre de fonctionnalites offertes par MySQL? Si on utilise moins de 5% des capacites de MySQL on peut decemment sortir l'analogie de la centrale nucleaire et la lampe de poche. Sans forcement tout re-coder a la main (ca ne sera pas forcement mieux ecrit que dans MySQL), il existe d'autres librairies qui offrent un sous-ensemble reduit de fonctionnalites, dont MythTV pourrait profiter sans avoir a s'encombrer d'un SGBDR avec cloches et sifflets. Un stockage ad-hoc base sur des fichiers et des recherches via dictionnaires offrerait peut-etre les memes fonctionnalites? Ou sinon un moteur SQL minimaliste qui ne requiert pas de maintenance?
MySQL ne se maintient pas tout seul: comme tout moteur de DB il y a foultitude de parametres a regler. On peut sans doute se contenter des parametres par defaut mais l'install generique qui est faite e.g. dans Ubuntu n'a pas conscience qu'elle va etre utilisee pour MythTV. Qu'est-ce qui me garantit qu'une install par defaut est valide pour MythTV sur toutes les distribs? On peut aussi imaginer que j'utilise le daemon mysqld en local a d'autres fins et que mes reglages customises soient conflictuels avec MythTV.
On peut tres bien comprendre que les developpeurs aient voulu resoudre un probleme de developpeurs avec les outils qu'ils maitrisent, personne ne leur reproche. Par contre c'est imposer a ses utilisateurs (et donc a soi-meme) une charge supplementaire d'installation et de maintenance (fut-elle minimale) d'un soft non negligeable. Quand on importe un package comme MySQL on importe tous ses avantages et tous ses problemes (sans juger aucunement encore une fois de la valeur de MySQL qui est tres bien ecrit nous sommes d'accord). Est-ce que les developpeurs de MythTV sont prets a mettre en place un FAQ pour les utilisateurs qui ont une installation mal foutue de MySQL? Des trous de securite non patches (e.g. sur un live-CD donc pas patchable)? Un port malencontreusement ouvert a l'exterieur sur une machine publique? A confirmer: mysqld a besoin de creer un user dedie pour travailler, est-ce que toutes les installs par defaut interdisent le login a ce user? Est-ce qu'il y a moyen de s'assurer que toutes les installs de MySQL seront compatibles avec l'utilisation qui en est faite par MythTV, et sans apporter de trou de securite? Les developpeurs de MythTV ont sans doute suffisamment a faire avec leur soft pour en plus s'occuper de debugger les installs de MySQL chez leurs utilisateurs.
Ou alors ils s'en foutent et qqn qui n'arrive pas a faire tourner MySQL chez lui a interdiction d'utiliser MythTV.
Posté par malin .
En réponse à la dépêche Mythtv 0.20.
Évalué à 3.
Oops... Mon post precedent peut effectivement etre mal interprete.
Non MySQL n'a pas de raison de souffrir de plus de failles de securite que n'importe quel autre volume de code similaire! Ce commentaire etait generique et aurait pu s'entendre de la meme facon sur n'importe quel volume massif de code ajoute au tronc principal. (Chapeau bas aux developpeurs de MySQL en passant.)
Pour remplir une fonctionnalite de gestion de donnees relativement simple (tout est dans le "relatif"), je prefererais inclure une lib qui fait 2 Megs qu'une qui fait 20 Megs, ne serait-ce que parce que statistiquement j'aurai a priori 10 fois moins de problemes, sans presumer aucunement des talents des programmeurs de ce volume de code. Est-ce que les developpeurs de MythTV sont prets a supporter les problemes d'install, de securite, de maintenance, de dependances qui seront inevitablement poses a leurs utilisateurs par l'ajout de MySQL? Je ne doute pas que MySQL ait resolu leur probleme, c'est juste une addition qui me semble demesuree pour un soft destine a des end-users.
Bon, sans serveur X tu risques de ne pas aller tres loin pour afficher de la video sous Linux. Ca ne me semble pas aberrant de demander a ses utilisateurs d'installer la couche graphique la plus standard pour voir de la video ;-)
Posté par malin .
En réponse à la dépêche Mythtv 0.20.
Évalué à 6.
Le (potentiellement) large volume de donnees a gerer ne justifie pas en lui-meme l'utilisation de MySQL. D'accord par ailleurs sur ce point: si tu as beaucoup de requetes non-triviales a mener de facon specifique (e.g. programmes dont le nom commence par XYZ commencant apres 14h et ne contenant pas de pub, avec un presentateur chauve et des chansons), les capacites de selection de SQL seront appreciees (sans etre indispensables ceci dit).
Mon point etait plutot base sur la necessite d'avoir un mastodonte comme MySQL pour remplir un besoin qui est generalement bien desservi par des moteurs plus "lite" (voire sans SQL). SQLite est une suggestion, il y en a d'autres. Quid de la maintenance du daemon MySQL qui tourne sur ta machine? La masse de code importee avec MySQL vient avec son lot de bugs, de trous de securite, de dependances encore a d'autres packages, de taches de maintenance, etc. Je ne dis pas que MySQL est mal (c'est un excellent moteur de DB!) mais pour un utilisateur qui veut juste regarder la TV c'est un peu cher paye alors que VLC propose la meme chose en installation stand-alone. Disons qu'une gestion plus discrete des memes donnees serait appreciable.
Bon enfin ce que j'en dis... Apres tout l'essentiel est que les gens qui programment MythTV se fassent plaisir. Rien ne m'oblige a l'installer si je n'ai pas envie d'avoir un daemon SQL sur ma machine ;-)
Dernier point: 90 megs pour un soft c'est demesure. Ce n'est pas une question d'encombrement du disque, c'est une question de qualite de produit. Mais c'est une autre discussion...
Posté par malin .
En réponse à la dépêche Mythtv 0.20.
Évalué à 5.
Un peu facile la DB mysql... Juste pour stocker les programmes TV c'est la centrale nucleaire pour faire marcher une lampe de poche. Une install de base de mythtv sur Ubuntu (sans les 42017301 plugins) prend 90 megas, ca fait un peu cher d'espace disque, sans compter les ressources bouffees par un daemon MySQL qui tourne rien que pour ca, les trous de securite potentiels d'une DB qui tourne a temps plein, et la maintenance que ca ne manquera pas d'occasionner (qui s'occupera de purger la DB?).
Soyons critiques mais constructifs: pour stocker des enregistrements sur lesquels les seules operations sont add/delete/display, une DB est tres largement sous-utilisee. A priori des fichiers de donnees structurees suffiraient largement. Si vraiment les developpeurs se sentent le besoin insurmontable d'ecrire du code qui fait appel a des commandes SQL, on peut opter pour SQLite qui implemente la meme chose mais sans avoir besoin de lancer de process separe, sans ouvrir de ports, sans avoir a bouffer des tonnes de disque, du CPU, ni necessiter de maintenance delirante.
[^] # Re: ssh-agent
Posté par malin . En réponse au message SCP: sans password et surtout sans clé. Évalué à 4.
ssh propose le login par cles precisement pour contourner les problemes de securite causes par le login via mot de passe, et ssh-agent est la pour te faciliter la vie dans cette voie. Le probleme du stockage du fichier de cles en local est egalement partiellement resolu si tu transportes ton fichier de cles dans... une cle USB.
Si tu connais Python, tu peux eventuellement regarder aussi 'paramiko', qui encapsule des liaisons ssh (donc scp) de facon relativement elegante, ce qui permet de scripter assez facilement des operations de transfert repetitives. On pourrait imaginer un script qui refuse de se declencher pour les copies tant qu'une cle USB n'a pas ete inseree sur le poste local, contenant un fichier de cles adequats pour le login sur tes machines distantes.
Bon enfin ce que j'en dis... Peut-etre que tu as d'autres contraintes sur les cles/mots de passe que tu voudrais exposer? Si ton souci principal est un souci de securite, fais attention par exemple au process expect que tu lances (un trojan est si vite installe...).
# ssh -X host
Posté par malin . En réponse au message X11Forwarding - ssh. Évalué à 2.
ssh -X host
ssh s'occupe tout seul de creer un display virtuel qu'il re-dirige vers ton display local. A l'inverse, pour etre sur de ne pas forwarder les flux X11, utilise l'option -x (minuscule).
xhost est a proscrire totalement pour autoriser les displays, c'est un trou de securite majeur qui a plus de 10 ans. Si tu veux temporairement donner un acces a une personne sur le reseau a ton serveur X, utilise plutot 'xauth'. La man page est une bonne source d'informations. Dans les deux cas, donner acces a son serveur X a une machine distante revient a une perte totale de securite de ta console. Il est facile de revoquer une autorisation d'acces avec xauth, c'est beaucoup plus difficile avec xhost.
# ssh-agent
Posté par malin . En réponse au message SCP: sans password et surtout sans clé. Évalué à 5.
ssh-agent garde en memoire les cles utilisees pour te logger sur tes diverses machines et les fournit tout seul a chaque fois que tu en as besoin. Si tu penses a mettre un mot de passe pour proteger tes cles, d'un point de vue utilisation ca revient exactement au cas que tu decris:
La session demarre, tu tapes ton mot de passe pour debloquer ton jeu de cles. A chaque login (ssh/scp), ssh-agent fournit la cle pour toi. En passant: pour scp, pense a enlever les bannieres et autres affichages de texte dans le .bash_login ou .bashrc, il n'aime pas ca du tout et plante avec une erreur incomprehensible.
[^] # Re: La honte du noyau
Posté par malin . En réponse au message Raisons susceptibles du déclenchement d'OOM killer. Évalué à 1.
Quand malloc retourne NULL on peut faire encore beaucoup de choses comme par exemple mapper des espaces disque pour creer son propre swap. Une appli peut aussi avoir envie de profiter du maximum d'espace memoire disponible pour accelerer ses calculs le plus possible. Le probleme de l'overcommitment c'est qu'on ne peut pas compter sur le systeme pour nous dire a un instant T si la prochaine allocation pourra se faire ou bien si elle plantera le systeme.
Pour l'histoire: la discussion qui a precede l'existence de ce patch date de 98. Voir par exemple:
http://lkml.org/lkml/1998/8/14/77
[^] # Re: La honte du noyau
Posté par malin . En réponse au message Raisons susceptibles du déclenchement d'OOM killer. Évalué à 1.
Dans mon experience, Linux est un systeme extremement peu fiable pour tout ce qui concerne la gestion de la memoire aux limites. Quand on a des processes qui ont besoin du maximum de RAM qu'ils peuvent allouer, les Unix standards nous ont habitue a utiliser malloc() et lui faire confiance pour retourner NULL quand il n'y a plus de ressources disponibles. Ce contrat n'est pas respecte sous Linux et ce n'est pas la faute de malloc(), mais bien celle du noyau.
Sur des programmes qui peuvent etre mission-critical (francais?), un tel comportement n'est pas acceptable. La seule facon de s'en sortir est de determiner soi-meme la quantite de memoire disponible a priori sur la machine locale, de surcharger les allocations memoire avec un compteur et d'arreter d'allouer quand le compteur indique une limite atteinte. Les nombreuses discussions qui ont eu lieu avec les developpeurs en charge de la gestion memoire sous Linux se sont terminees en queue de poisson.
Ceci dit, il est rare d'avoir a ecrire des programmes qui ont besoin forcement d'allouer le maximum de memoire disponible dans un environnement critique. Pour la quasi totalite des applications qui tournent sur des desktops, les points decrits ici ne s'appliquent pas. Dans le cas precisement evoque ici, le kernel s'est retrouve aux limites a cause d'une faute de programmation dans une appli Java. Pas de panique donc! Les gens qui ont l'habitude de pousser Linux a ses limites en gestion de memoire doivent juste etre conscients des limitations induites par l'overcommitment.
# La honte du noyau
Posté par malin . En réponse au message Raisons susceptibles du déclenchement d'OOM killer. Évalué à 8.
Dans ton cas, tu as sans doute une application qui est partie en vrille en allouant de nouveaux objets en pagaille sans les liberer. Avec les infos que tu donnes je pencherais pour un probleme Java (JBoss). En aucun cas un filesystem ne peut declencher directement l'intrepide OOM killer. Si tu as de la chance, OOM killer decidera de tuer precisement l'application qui pose des problemes, mais rien n'empeche OOM killer de dezinguer ton serveur X ou bien ta session eclipse dans laquelle tu travailles depuis 2 jours sans sauvegardes. C'est lui qui choisit, pas toi.
Dans le detail: OOM killer fait d'une machine Linux une veritable bombe a retardement pour toutes les applis qui ont besoin du maximum de memoire qu'elles peuvent allouer. Pour les applis desktop c'est encore acceptable mais pour du deploye industriellement c'est critiquement grave.
Linux est (a priori) le seul Unix qui vienne avec cet infame OOM killer. La raison profonde derriere ce patch est le fait que le kernel Linux s'amuse a promettre bien plus de memoire qu'il ne peut en offrir (memory overcommitment). Application: ecrire une boucle qui alloue des paquets de 1 Meg a la fois et regarder combien on peut en allouer (mon noyau me promet jusqu'a 4 Gb sur une machine qui possede 512 Mb de RAM + 512 Mb de swap). Deuxieme essai: allouer les blocs en boucle jusqu'a ce que malloc retourne NULL, puis remplir de zero les zones allouees une par une. La RAM se remplit, puis le swap, puis apres c'est le bonheur: soit le noyau plante, soit OOM killer intervient et (parfois) tue d'autres processes vitaux du systeme, ce qui finit en desastre complet.
Pourquoi le noyau s'amuse-t-il donc a promettre plus de memoire que ce dont il dispose? Apparemment c'est du a l'implementation de fork() qui commence par repliquer le process qui fait cet appel, incluant une copie complete de sa memoire, ce qui prend du temps. Generalement un process qui fork() fait immediatement un exec derriere, ce qui rend inutile la perte de temps de recopie de memoire. Le noyau prefere promettre a fork() de la memoire dont il ne se servira de toutes facons pas.
Si ce comportement vous inquiete vous pouvez desactiver le memory overcommitment en manipulant des flags dans /proc/sys/vm (suivant la version de kernel). Attention alors: le systeme ralentit considerablement.
[^] # Re: mysql
Posté par malin . En réponse à la dépêche Mythtv 0.20. Évalué à 2.
Tu me sembles bien renseigne, peut-etre pourras-tu repondre a ces questions: quels sont les features de MySQL utilises dans MythTV qu'on ne trouve pas ailleurs? Quand tu affirmes que pres de 70% des fonctionnalites sont utilisees, c'est juste un sentiment ou bien un argument demontrable?
Peut-etre que tu confonds "les fonctionnalites des MySQL" avec "les fonctionnalites de SQL"?
suffisamment pour que la 0.19 soit impactée par un bug sur un JOIN spécial de MySQL
Voici exactement le genre de probleme auquel je faisais reference. MySQL est un volume de code important. En tant que tel il amene ses bugs, ses problemes de maintenance, de securite, ses dependances. Moins on amene de code dans l'equation, moins on prend ce genre de risques. Ca n'a rien de particulier avec MySQL.
N'importe quoi ! Tu as à autoriser ton user mythtv, fermer l'accès externe, en gros c'est tout.
Alors Grand-Mere: pour regarder la TV c'est pas complique. Tu downloades 90 megs de soft, ca vient avec un SGBDR qui t'installe un utilisateur de plus mais tu le desactives et tu fermes les ports qu'il va ouvrir, au besoin tu vas editer un fichier de conf et puis tu relances le daemon avec les droits qui vont bien et tu verifies avec nmap que t'es pas attaquable... Dis, tu dors Grand-Mere?
C'est une vraie caricature. Un truc ecrit par des geeks pour des geeks.
Ah si, tu peux mettre en cron la sauvegarde régulière d'un dump de ta base sur une autre machine.
A un moment il faudrait faire la difference entre un ingenieur systeme et un type qui veut juste regarder des films a la TV (avec des fonctionnalites sympas). Parfois ce sont deux personnes differentes, tu sais.
Tu devrais plus te renseigner sur ce qu'est une BDD et sur le fonctionnement de MySQL
Mes connaissances sur le sujet n'ont rien a voir avec la discussion, jeune Padawan. Attaque l'argument plutot que l'argumentateur.
Le fait que chez moi ça marche, avec l'install de base faite par un "make install" et une copie du default-my.cnf (ou un truc comme ça) ?
Si je l'ai vu marcher chez moi alors ca marche partout ailleurs. C'est cool ca! Il suffit de coder une fois sur ma machine pour que dans le reste du monde ca marche pareil!
Ohlala ! Encore une fois : zéro maintenance, et MySQL se compile tout seul. Avec une distro, rien à faire.
MySQL: la premiere (et seule) DB du monde qui se maintient toute seule! Et elle corrige ses bugs elle-meme, et se met a jour toute seule, meme sur un live-CD!
Si tu veux mon experience: j'ai apt-get installe MythTV sur une machine chez moi. Apres son long download et sa configuration ou il m'a parle de plein de parametres de config qui n'ont rien a voir avec regarder une video, il m'a profondement brise les coudes en me posant des questions sur l'installation de mon beau nouveau serveur MySQL. Je passe deja suffisamment de temps les mains dans les DBs dans la journee (MySQL, Postgres et Oracle) pour ne pas avoir envie de recommencer chez moi en rentrant. Laissez-moi voir mon media center et arretez de me pourrir la vie avec de la maintenance systeme! Je ne suis pas un numero! Je suis un homme liiiiibre! ;-)
J'ai essaye Freevo ca a l'air chouette. Point de vue dependances soft il ne depend que de players video/son et quelques libs Python. Pas encore regarde les fonctionnalites TV.
Bon enfin ce que j'en dis... Si ca marche bien pour toi et que tu te fais plaisir c'est ca qui compte.
[^] # Re: Pourquoi ne pas changer le label ?
Posté par malin . En réponse au message Monter un disque USB avec toujours le même nom?. Évalué à 2.
ext2/ext3:
% tune2fs -L Musique /dev/sdXX
xfs:
% xfs_admin -L Musique /dev/sdXX
...
Si Gnome est bien configure (e.g. Ubuntu) tu verras apparaitre une icone sur le desktop quand le disque est branche, du nom du label donne (ici: Musique). Les donnees sont accessibles sous /media/Musique par la suite.
[^] # Re: mysql
Posté par malin . En réponse à la dépêche Mythtv 0.20. Évalué à 5.
MySQL ne se maintient pas tout seul: comme tout moteur de DB il y a foultitude de parametres a regler. On peut sans doute se contenter des parametres par defaut mais l'install generique qui est faite e.g. dans Ubuntu n'a pas conscience qu'elle va etre utilisee pour MythTV. Qu'est-ce qui me garantit qu'une install par defaut est valide pour MythTV sur toutes les distribs? On peut aussi imaginer que j'utilise le daemon mysqld en local a d'autres fins et que mes reglages customises soient conflictuels avec MythTV.
On peut tres bien comprendre que les developpeurs aient voulu resoudre un probleme de developpeurs avec les outils qu'ils maitrisent, personne ne leur reproche. Par contre c'est imposer a ses utilisateurs (et donc a soi-meme) une charge supplementaire d'installation et de maintenance (fut-elle minimale) d'un soft non negligeable. Quand on importe un package comme MySQL on importe tous ses avantages et tous ses problemes (sans juger aucunement encore une fois de la valeur de MySQL qui est tres bien ecrit nous sommes d'accord). Est-ce que les developpeurs de MythTV sont prets a mettre en place un FAQ pour les utilisateurs qui ont une installation mal foutue de MySQL? Des trous de securite non patches (e.g. sur un live-CD donc pas patchable)? Un port malencontreusement ouvert a l'exterieur sur une machine publique? A confirmer: mysqld a besoin de creer un user dedie pour travailler, est-ce que toutes les installs par defaut interdisent le login a ce user? Est-ce qu'il y a moyen de s'assurer que toutes les installs de MySQL seront compatibles avec l'utilisation qui en est faite par MythTV, et sans apporter de trou de securite? Les developpeurs de MythTV ont sans doute suffisamment a faire avec leur soft pour en plus s'occuper de debugger les installs de MySQL chez leurs utilisateurs.
Ou alors ils s'en foutent et qqn qui n'arrive pas a faire tourner MySQL chez lui a interdiction d'utiliser MythTV.
[^] # Re: mysql
Posté par malin . En réponse à la dépêche Mythtv 0.20. Évalué à 3.
Non MySQL n'a pas de raison de souffrir de plus de failles de securite que n'importe quel autre volume de code similaire! Ce commentaire etait generique et aurait pu s'entendre de la meme facon sur n'importe quel volume massif de code ajoute au tronc principal. (Chapeau bas aux developpeurs de MySQL en passant.)
Pour remplir une fonctionnalite de gestion de donnees relativement simple (tout est dans le "relatif"), je prefererais inclure une lib qui fait 2 Megs qu'une qui fait 20 Megs, ne serait-ce que parce que statistiquement j'aurai a priori 10 fois moins de problemes, sans presumer aucunement des talents des programmeurs de ce volume de code. Est-ce que les developpeurs de MythTV sont prets a supporter les problemes d'install, de securite, de maintenance, de dependances qui seront inevitablement poses a leurs utilisateurs par l'ajout de MySQL? Je ne doute pas que MySQL ait resolu leur probleme, c'est juste une addition qui me semble demesuree pour un soft destine a des end-users.
Bon, sans serveur X tu risques de ne pas aller tres loin pour afficher de la video sous Linux. Ca ne me semble pas aberrant de demander a ses utilisateurs d'installer la couche graphique la plus standard pour voir de la video ;-)
[^] # Re: mysql
Posté par malin . En réponse à la dépêche Mythtv 0.20. Évalué à 6.
Mon point etait plutot base sur la necessite d'avoir un mastodonte comme MySQL pour remplir un besoin qui est generalement bien desservi par des moteurs plus "lite" (voire sans SQL). SQLite est une suggestion, il y en a d'autres. Quid de la maintenance du daemon MySQL qui tourne sur ta machine? La masse de code importee avec MySQL vient avec son lot de bugs, de trous de securite, de dependances encore a d'autres packages, de taches de maintenance, etc. Je ne dis pas que MySQL est mal (c'est un excellent moteur de DB!) mais pour un utilisateur qui veut juste regarder la TV c'est un peu cher paye alors que VLC propose la meme chose en installation stand-alone. Disons qu'une gestion plus discrete des memes donnees serait appreciable.
Bon enfin ce que j'en dis... Apres tout l'essentiel est que les gens qui programment MythTV se fassent plaisir. Rien ne m'oblige a l'installer si je n'ai pas envie d'avoir un daemon SQL sur ma machine ;-)
Dernier point: 90 megs pour un soft c'est demesure. Ce n'est pas une question d'encombrement du disque, c'est une question de qualite de produit. Mais c'est une autre discussion...
[^] # Re: mysql
Posté par malin . En réponse à la dépêche Mythtv 0.20. Évalué à 5.
Soyons critiques mais constructifs: pour stocker des enregistrements sur lesquels les seules operations sont add/delete/display, une DB est tres largement sous-utilisee. A priori des fichiers de donnees structurees suffiraient largement. Si vraiment les developpeurs se sentent le besoin insurmontable d'ecrire du code qui fait appel a des commandes SQL, on peut opter pour SQLite qui implemente la meme chose mais sans avoir besoin de lancer de process separe, sans ouvrir de ports, sans avoir a bouffer des tonnes de disque, du CPU, ni necessiter de maintenance delirante.
Bon enfin ce que j'en dis...
# Solutions possibles
Posté par malin . En réponse au message connaitre l'allocation mémoire en C++. Évalué à 1.
mtrace
valgrind
mudflap
purify (payant)
Autre possibilite: surchager new/delete pour les classes suspectees de fuites.