Il y a problablement un timeout au niveau du kernel. Ca arrive par exemple avec le NFS ... il faut identifier où, mais par forum interposé c'est très difficile.
Est-ce qu'il y a de l'activité disque pendant ces moments d'attente ?
Des services devenus lents au démarrage, ça peut être le signe d'un timeout, mais dans ton cas de figure, on dirait que quelque chose part dans une boucle infinie.
En général, un processus fou consomme 100% du CPU, mais ne ralentit pas le reste car il se fait préempter facilement. Si tout le reste est lent, il y a probablement quelque chose qui travaille sur le disque.
Essaie de faire un top dans une console pour voir ce qui pourrait bien être aussi gourmand ...
void f2()
{
Objet obj (); /* <- NE PAS METTRE DE PARENTHESES ! */
obj.print();
}
En tout cas, pas par défaut. De la même façon que tu vas faire un int x, tu va faire un Object obj;. Type et nom de variable.
Le fait que tu puisse mettre des parenthèses te permet de choisir le constructeur qui doit être appelé, quand il y en a plusieurs.
Quand tu crées une variable en C, il reserve de la place dans la pile, en plus de ce qu'il y met déjà (sauvegarde des registres, adresse de retour et paramètres de la fonction). Eventuellement, il peut affecter une valeur par défaut à la place réservée.C'est d'ailleurs pour cette raison que C t'impose de déclarer toutes tes variables en début de bloc : spécialement parce que ce n'est PAS dynamique, mais déterminé au moment de la compilation (ce qui, en soi, est génial).
D'ailleurs, message perso aux afficionados de la qualité du code : il y a certains chefs de projets qui mettent un point d'honneur à vérifier que toutes les boucles et opérations conditionnelles (if while etc ...) soit bien encadrées dans des accolades. On leur répondra que 1) Si le langage permet certaines facilités, c'est pour des raisons précises 2) les accolades en C sont pratiquement toujours synonymes d'ouverture d'un nouveau cadre de pile et que la plupart des gens ne le savent plus 3) laissez les coders faire leur boulot :-)
La réservation de cette place ce fait d'ailleurs simplement en décalant le pointeur de pile de n octets. En C++, il faudra peut-être appeler une fonction plus sophistiquée pour mettre ton objet au propre : le constructeur. Celui-ci est donc appelé automatiquement en lui passant l'adresse de la mémoire fraîchement allouée.
Lorsque ta fonction se termine, en C, pour libérer la mémoire dans la pile, il suffit de faire remonter le pointeur de pile et de laisser tout le reste en l'état. En C++, il y a aura peut-être des ressources internes à libérer, donc les destructeurs seront appelés automatiquement aussi, mais fondamentalement, la mémoire allouée est la même qu'en C.
new et delete maintenant, c'est exactement la même chose que malloc et free en C. Ca sert à faire une allocation explicite d'un objet, et ne le libérer que lorsque le programmeur le décide explicitement. Et la, ça fonctionne aussi comme en C : une zone mémoire réservée, distincte de la pile, avec un tas, une table d'allocation, et une fragmentation mémoire.
Posté par Obsidian .
En réponse au message String.h.
Évalué à 1.
- Pas de majuscule à String (ce n'est pas du Java).
- Pas de ".h" au bout des noms des fichiers d'entêtes dans le code en C++ (même si la recommandation précise que ça doit marche quand même) ...
Surtout qu'ici, "string.h", c'est toujours le fichier de déclaration des fonctions C.
Ensuite, le namespace que va bien, effectivement ...
En réalité ce n'était pas vraiment un bug. En fait, le bâtiment ne tombait en panne systématiquement, mais facilement au deuxième ou troisième tir. C'était surtout une erreur de dosage ...
En réalité, je ne crois pas avoir un jour fini une campagne de Blue War. Trop long. Le temps passait plus lentement à cette époque.
Avec le sous-marin qui affichait une avarie chaque fois que l'on tirait une torpille ! :-)
Du coup, je ne sais pas si j'ai pu finir une mission, mais je me suis quand même bien amusé à explorer les sources, le jeu étant écrit en basic sur Thomson, à l'époque ...
99 fois sur cent, mot de passe commun est exactement synonyme d'erreur de conception. Un mot de passe est propre à un compte.
Si tu as l'intention de distribuer ton mot de passe à une liste de personnes de confiance, c'est à toi d'intégrer la liste des comptes desdites personnes dans ta configuration. Dès lors, le fait d'être identifié leur suffira à accéder à ton partage.
su, ça veut dire substitute user. C'est fait pour changer d'identité. On s'en sert pour lancer un programme (par défaut, un shell) sous une identité donnée (par défaut, root). L'option -c permet d'exécuter une commande spécifiée plutôt que le shell. Autant que je sache, su ne fait même pas partie du standard Unix de l'Open Group, mais il est conçu comme il faut, et extrêmement pratique.
sudo, c'est un bricolage qui étend ce principe. Il pallie certains manques et est de fait très utilisé. Mais comme il est en général très mal configuré, il est généralement très facile à contourner. En gros, tout le monde s'en sert pour redéfinir le rôle "administrateur" des utilisateurs Windows. Au feu.
Le principal intérêt est de te faire utiliser ton propre mot de passe, voire même un mot de passe dédié, pour te faire accéder à des commandes bien définies sous une identité bien définie elle-aussi, et de garder une trace des commandes effectuées. Ca sert aussi à respecter le principe de confidentialité des mots de passe (à considérer comme des codes de carte bleue)/
C'est bien là tout le problème, d'ailleurs : ouvrir une session de cinq minutes où l'on peut saisir des commandes sans mot de passe et depuis son propre compte, c'est déjà dégueu, mais c'est toujours mieux que de laisser une console root ouverte sans délai d'expiration ni trace des opérations effectuées.
La meilleure chose, donc, consiste encore à ne pas avoir à utiliser root à tout bout de champ, donc à configurer son système proprement une fois pour toute. Et, là encore, il ne s'agit pas de le faire en supprimant les barrières ! Il faut s'arranger pour repérer toutes les opérations réversibles, et les rendre leur exécution possibles aux utilisateurs ordinaires membres des groupes idoines.
Surtout, si ce n'est pas clair, dis-le tout de suite.
S'il faut développer un peu plus, je veux bien le faire ici, car cela servira à tout le monde, et formera une trace écrite, qui plus est référencée par Google :-)
En fait c'est la fleme de taper mon passe a chaque fois que je veux utiliser synaptec pour installer un ptit logiciel ou ouvrir mon serveur gproftpd alors que je suis le seul utilisateur de mon PC.
Les meilleurs pratiques consistent à identifier le problème avant d'essayer de trouver une solution pour le contourner. Les garde-fous ne sont pas là pour embêter l'utilisateur exprès.
Pour synaptic, tu ne devrais pas avoir à l'employer à tour de bras systématiquement. Si toutefois c'est le cas, utilise plutôt sudo apt-get install pour récupérer un truc identifié et ponctuel. Au moins, si tu rappelle la commande par accident, ou si un utilisateur le fait quand tu as le dos tourné, tu ne risqueras pas d'installer quelque chose d'imprévu.
Pour proFTPd, on peut lire sur Wikipédia :
Ses supporters disent que ProFTPd est bien documenté et que la pluspart des configurations seront proches de celles des exemples fournis avec le logiciel. Son unique fichier de configuration, proftpd.conf, utilise une syntaxe similaire à celle d'Apache permettant ainsi d'homogénéiser les fichiers de configuration.
Ce qui signifie que :
- Tu aurais largement plus vite fait d'éditer directement le fichier de conf plutôt que de passer par l'interface graphique à chaque fois.
- Cette interface (gproftpd) se contente, en coulisses, d'éditer ce fichier et éventuellement d'envoyer un signal à proftpd pour lui demander de le relire.
Donc, si tu fais ls -l /etc/proftp.conf tu verras que le fichier appartient, comme tous les autres, à un groupe. Il te suffit de te placer dans ce groupe pour que tu puisses, toi et personne d'autre à priori, éditer ce fichier directement sans jamais avoir à changer d'identité !
Mieux que ça, comme tu peux naturellement éditer le fichier, gproftpd le pourra aussi et il n'a donc plus besoin non plus d'être lancé par le super-utilisateur. Au lieu de ça, on parlait de lancer automatiquement, en root et sans mot de passe une application s'appuyant sur une infrastructure GNOME et ouvrant une connexion vers X-Window. Il suffit que n'importe quelle autre appli ouvre une connexion vers le serveur pour pouvoir taper "à ta place".
En poussant le raisonnement au maximum, même proftpd n'a pas besoin d'être root. Il peut fonctionner sous sa propre identité dans un environnement chrooté. Comme çà, même en cas de faille de sécurité, un utilisateur extérieur ne pourra jamais aller plus loin que ce que le système permet. La seule raison de démarrer le daemon FTP en root est pour lui permettre de réclamer le port 21 et çà, il suffit de demander à xinetd de le faire pour lui.
Bref, dans un serveur UNIX proprement administré, au bout d'un moment, on ne devrait plus avoir à passer root plus d'une fois par mois. Alors en arriver à vouloir virer le mot de passe ...
Enfin - et le ne le fais pas non plus si ce n'est pas nécessaire -, si tu a vraiment besoin de lancer fréquement des commandes en root, tu peux en préciser la liste dans /etc/sudoers et affecter NOPASSWD uniquement sur celles-ci.
C'est vraiment dommage parce qu'il suffit de savoir mettre des droits sur un fichier pour commencer à gérer la sécurité efficacement sous UNIX, c'est presque trivial. Evidemment, sous Windows, ce n'est même pas la peine d'y penser, et tous les utilisateurs exportent - bien plus que des mauvaises habitudes - des schémas de pensée entiers et calamiteux.
Ne fais pas çà. C'est suicidaire si tu es relié directement à Internet, et ce n'est de toute façon pas une habitude à prendre.
Si tu as besoin d'effectuer des commandes super-utilisateur à l'occassion, utilise sudo, c'est à çà que ça sert. Cette commande t'ouvre une session qui expire après cinq minutes d'inactivité. Donc, tu tapes ton propre mot de passe (et pas celui du superchef) une seule fois, et tu fais tout ton boulot sans être emmerdé.
Si vraiment c'est trop compliqué, tu peux ajouter la directive NOPASSWD dans /etc/sudoers pour que les irresponsables utilisateurs de confiance puissent directement lancer leurs commandes. La sécurité reste proche de zéro, mais au moins on limite les probabilités d'exécution de commandes en root par accident.
Ca dépend aussi beaucoup de l'âge de ta machine et, par extension, de celui de ton BIOS.
Les fabricants ont mis beaucoup de temps à implémenter partout une ACPI propre, par exemple, et celle-ci est mutuellement exclusive avec APM dans le noyau Linux par exemple.
Donc, vois déjà lequel de ces deux systèmes tu utilises, ensuite, il y a parfois des " sous-modules " à charger pour les différents cas de figure.
Ca fait longtemps que cela n'était pas arrivé mais pendant un moment ce fut vraiment la plaie. Sur 3 machines (ré)installées, 2 ne séteignaient pas correctement et j'ai passé des heures à recompiler le noyau avec les bonnes options simplement pour régler ce détail.
Si tu te perds, c'est parce que tu essaies de résorber les symptômes plutôt que de résoudre le problème de fond.
D'abord, comme tous les programmes, ton application et le mplayer que tu lances derrière héritent tout deux de la console de ton terminal X.
Ensuite, mplayer, en plus d'être doté d'un jeu de handlers fichier stdout,stdin, stderr comme tout le monde, ouvre une connexion vers le serveur X, qui est complètement indépendante de sa console, et qui peut très bien atteindre une machine distincte. Et c'est depuis les événements X que mplayer traite les commandes de navigation de l'utilisateur, pas depuis stdin.
Avec cela, en environnement graphique, l'application qui reçoit les événements de la console, c'est le serveur X lui-même (et en fait ce n'est même plus tout-à-fait vrai car Xorg ou Xfree86 gèrent eux-même le clavier et les périphs d'entrées). C'est aussi eux qui les traduisent en événements dans l'envrionnement graphique et qui les distribuent aux applications concernées (en fonction du focus et avec la complicité du WM).
D'autre part, à priori, ta douchette est vue comme un clavier, et est gérée comme tel par le système lui-même. C'est ce qui fait que tu n'a rien à configurer lorsque tu branches un clavier USB supplémentaire. Donc, au départ, tes applications ne savent pas du tout que tu es en train d'utiliser une douchette.
Ton problème, donc, c'est qu'il te faudrait deux focus. L'un provenant du clavier et ciblant la fenêtre vidéo de mplayer et l'autre, provenant de la douchette, sur la fenêtre du x-term qui fait tourner ton programme.
En conséquence, ton premier souci consiste à être parfaitement sûr de ce que tu veux faire :
- Soit tu souhaites conserver le fonctionnement normal de tes applications. Dans ce cas, c'est à toi de cliquer manuellement sur la fenêtre du X-term lorsque tu veux utiliser la douchette et sur celle de mplayer quand tu veux naviguer. C'est très fastidieux, mais c'est ce que tu ferais naturellement quand même si tu rentrais tes codes barre à la main ... Ca te permet également d'aller balancer la sortie de ta douchette dans un notepad au besoin, sans qu'elle soit interceptée par ton application ...
Tu peux aussi rentrer en mode slave pour ne pas avoir à faire du ping/pong mais cela t'oblige à réimplémenter TOUTES les commandes clavier de mplayer et à jouer avec termios pour récupérer l'état des touches avant d'appuyer sur return, quand c'est possible.
- Soit tu cherches à faire en sorte que la douchette ne serve qu'à zapper les vidéos lorsqu'elles tournent et dans ce cas, cela signifie implicitement qu'aucun autre programme ne doit recevoir ses caractères pendant que ton application tourne. Et dans ce cas, il y a donc une formalité à accomplir au préalable. Demander au système l'exclusivité sur la douchette.
Ca se gère donc au niveau de la gestion des HID par le noyau Linux. C'est normal que cela se trouve à ce niveau, d'ailleurs : il existe d'autres douchettes qui se branchent "en série" sur le cordon PS/2 en s'insérant entre le clavier et l'unité centrale. Dans un tel cas de figure, il t'est impossible de distinguer la douchette du clavier.
Dès lors, la meilleure solution consiste à écrire un daemon qui surveille silencieusement l'activité du clavier et reconnaît les trames susceptibles d'être envoyées par la douchette et qui, le cas échéant, prévient les programmes concernés via un canal de communication propre (un signal, un segment de RAM partagée ou , de préférence, un socket UNIX).
[^] # Re: Ils sont gentils dans l'éducation
Posté par Obsidian . En réponse au journal Wikipedia encoe attaqué dans l'éducation. Évalué à 4.
Déclarer que " l'orthographe est la science du pauvre ", c'est se dédouaner un peu vite, je trouve.
[^] # Re: Ils sont gentils dans l'éducation
Posté par Obsidian . En réponse au journal Wikipedia encoe attaqué dans l'éducation. Évalué à 2.
Y en a :
http://www.priceminister.com/offer/buy/1245319/Duhamel-Jerom(...)
[^] # Re: Top + Timeout
Posté par Obsidian . En réponse au message Système lent après crash du à plus de batterie. Évalué à 2.
# Top + Timeout
Posté par Obsidian . En réponse au message Système lent après crash du à plus de batterie. Évalué à 2.
Des services devenus lents au démarrage, ça peut être le signe d'un timeout, mais dans ton cas de figure, on dirait que quelque chose part dans une boucle infinie.
En général, un processus fou consomme 100% du CPU, mais ne ralentit pas le reste car il se fait préempter facilement. Si tout le reste est lent, il y a probablement quelque chose qui travaille sur le disque.
Essaie de faire un top dans une console pour voir ce qui pourrait bien être aussi gourmand ...
[^] # Re: stty
Posté par Obsidian . En réponse au message Ctrl-c ne fonctionne pas. Évalué à 2.
# Faire l'inverse
Posté par Obsidian . En réponse au message expression rationnelle particuliere. Évalué à 2.
:%s/[^\\]*\(\\line\|\\par\)\?\|.*/\1/g
[^] # Re: la fonction f1 devrait s'écrire comme f2
Posté par Obsidian . En réponse au message Constructeur, destructeur, et autre.... Évalué à 3.
# Bien différencier C++ et Java !
Posté par Obsidian . En réponse au message Constructeur, destructeur, et autre.... Évalué à 3.
{
Objet obj (); /* <- NE PAS METTRE DE PARENTHESES ! */
obj.print();
}
En tout cas, pas par défaut. De la même façon que tu vas faire un int x, tu va faire un Object obj;. Type et nom de variable.
Le fait que tu puisse mettre des parenthèses te permet de choisir le constructeur qui doit être appelé, quand il y en a plusieurs.
Quand tu crées une variable en C, il reserve de la place dans la pile, en plus de ce qu'il y met déjà (sauvegarde des registres, adresse de retour et paramètres de la fonction). Eventuellement, il peut affecter une valeur par défaut à la place réservée.C'est d'ailleurs pour cette raison que C t'impose de déclarer toutes tes variables en début de bloc : spécialement parce que ce n'est PAS dynamique, mais déterminé au moment de la compilation (ce qui, en soi, est génial).
D'ailleurs, message perso aux afficionados de la qualité du code : il y a certains chefs de projets qui mettent un point d'honneur à vérifier que toutes les boucles et opérations conditionnelles (if while etc ...) soit bien encadrées dans des accolades. On leur répondra que 1) Si le langage permet certaines facilités, c'est pour des raisons précises 2) les accolades en C sont pratiquement toujours synonymes d'ouverture d'un nouveau cadre de pile et que la plupart des gens ne le savent plus 3) laissez les coders faire leur boulot :-)
La réservation de cette place ce fait d'ailleurs simplement en décalant le pointeur de pile de n octets. En C++, il faudra peut-être appeler une fonction plus sophistiquée pour mettre ton objet au propre : le constructeur. Celui-ci est donc appelé automatiquement en lui passant l'adresse de la mémoire fraîchement allouée.
Lorsque ta fonction se termine, en C, pour libérer la mémoire dans la pile, il suffit de faire remonter le pointeur de pile et de laisser tout le reste en l'état. En C++, il y a aura peut-être des ressources internes à libérer, donc les destructeurs seront appelés automatiquement aussi, mais fondamentalement, la mémoire allouée est la même qu'en C.
new et delete maintenant, c'est exactement la même chose que malloc et free en C. Ca sert à faire une allocation explicite d'un objet, et ne le libérer que lorsque le programmeur le décide explicitement. Et la, ça fonctionne aussi comme en C : une zone mémoire réservée, distincte de la pile, avec un tas, une table d'allocation, et une fragmentation mémoire.
[^] # Re: re
Posté par Obsidian . En réponse au message String.h. Évalué à 1.
- Pas de ".h" au bout des noms des fichiers d'entêtes dans le code en C++ (même si la recommandation précise que ça doit marche quand même) ...
Surtout qu'ici, "string.h", c'est toujours le fichier de déclaration des fonctions C.
Ensuite, le namespace que va bien, effectivement ...
[^] # Re: Des bons souvenirs, ça ...
Posté par Obsidian . En réponse à la dépêche Danger from the Deep : version 0.3.0 disponible. Évalué à 3.
En fait, les émulateurs Thomson existent depuis belle lurette :
http://membres.lycos.fr/jth/emuto8.html
Blue War doit même être disponible, tiens ...
[^] # Re: Des bons souvenirs, ça ...
Posté par Obsidian . En réponse à la dépêche Danger from the Deep : version 0.3.0 disponible. Évalué à 1.
En réalité ce n'était pas vraiment un bug. En fait, le bâtiment ne tombait en panne systématiquement, mais facilement au deuxième ou troisième tir. C'était surtout une erreur de dosage ...
En réalité, je ne crois pas avoir un jour fini une campagne de Blue War. Trop long. Le temps passait plus lentement à cette époque.
[^] # Re: Des bons souvenirs, ça ...
Posté par Obsidian . En réponse à la dépêche Danger from the Deep : version 0.3.0 disponible. Évalué à 2.
Avec le sous-marin qui affichait une avarie chaque fois que l'on tirait une torpille ! :-)
Du coup, je ne sais pas si j'ai pu finir une mission, mais je me suis quand même bien amusé à explorer les sources, le jeu étant écrit en basic sur Thomson, à l'époque ...
# Des bons souvenirs, ça ...
Posté par Obsidian . En réponse à la dépêche Danger from the Deep : version 0.3.0 disponible. Évalué à 1.
[^] # Re: et $? ?
Posté par Obsidian . En réponse au message une erreur sur while [ `grep $uid /etc/passwd` ]. Évalué à 2.
# Mot de passe commun ?
Posté par Obsidian . En réponse au message Demande de conseil SAMBA. Évalué à 7.
99 fois sur cent, mot de passe commun est exactement synonyme d'erreur de conception. Un mot de passe est propre à un compte.
Si tu as l'intention de distribuer ton mot de passe à une liste de personnes de confiance, c'est à toi d'intégrer la liste des comptes desdites personnes dans ta configuration. Dès lors, le fait d'être identifié leur suffira à accéder à ton partage.
# Boot floppy
Posté par Obsidian . En réponse au message Redimensionner une partion racine sans la démonter. Évalué à 3.
- Créer une disquette de démarrage
- S'en servir pour lancer un CD.
Franchement, c'est quand même beaucoup plus confortable.
[^] # Re: re
Posté par Obsidian . En réponse au message supprimer mot de passe root. Évalué à 2.
sudo, c'est un bricolage qui étend ce principe. Il pallie certains manques et est de fait très utilisé. Mais comme il est en général très mal configuré, il est généralement très facile à contourner. En gros, tout le monde s'en sert pour redéfinir le rôle "administrateur" des utilisateurs Windows. Au feu.
Le principal intérêt est de te faire utiliser ton propre mot de passe, voire même un mot de passe dédié, pour te faire accéder à des commandes bien définies sous une identité bien définie elle-aussi, et de garder une trace des commandes effectuées. Ca sert aussi à respecter le principe de confidentialité des mots de passe (à considérer comme des codes de carte bleue)/
C'est bien là tout le problème, d'ailleurs : ouvrir une session de cinq minutes où l'on peut saisir des commandes sans mot de passe et depuis son propre compte, c'est déjà dégueu, mais c'est toujours mieux que de laisser une console root ouverte sans délai d'expiration ni trace des opérations effectuées.
La meilleure chose, donc, consiste encore à ne pas avoir à utiliser root à tout bout de champ, donc à configurer son système proprement une fois pour toute. Et, là encore, il ne s'agit pas de le faire en supprimant les barrières ! Il faut s'arranger pour repérer toutes les opérations réversibles, et les rendre leur exécution possibles aux utilisateurs ordinaires membres des groupes idoines.
Surtout, si ce n'est pas clair, dis-le tout de suite.
S'il faut développer un peu plus, je veux bien le faire ici, car cela servira à tout le monde, et formera une trace écrite, qui plus est référencée par Google :-)
[^] # Re: Je regrette, Dave ...
Posté par Obsidian . En réponse au message supprimer mot de passe root. Évalué à 4.
Les meilleurs pratiques consistent à identifier le problème avant d'essayer de trouver une solution pour le contourner. Les garde-fous ne sont pas là pour embêter l'utilisateur exprès.
Pour synaptic, tu ne devrais pas avoir à l'employer à tour de bras systématiquement. Si toutefois c'est le cas, utilise plutôt sudo apt-get install pour récupérer un truc identifié et ponctuel. Au moins, si tu rappelle la commande par accident, ou si un utilisateur le fait quand tu as le dos tourné, tu ne risqueras pas d'installer quelque chose d'imprévu.
Pour proFTPd, on peut lire sur Wikipédia :
Ce qui signifie que :
- Tu aurais largement plus vite fait d'éditer directement le fichier de conf plutôt que de passer par l'interface graphique à chaque fois.
- Cette interface (gproftpd) se contente, en coulisses, d'éditer ce fichier et éventuellement d'envoyer un signal à proftpd pour lui demander de le relire.
Donc, si tu fais ls -l /etc/proftp.conf tu verras que le fichier appartient, comme tous les autres, à un groupe. Il te suffit de te placer dans ce groupe pour que tu puisses, toi et personne d'autre à priori, éditer ce fichier directement sans jamais avoir à changer d'identité !
Mieux que ça, comme tu peux naturellement éditer le fichier, gproftpd le pourra aussi et il n'a donc plus besoin non plus d'être lancé par le super-utilisateur. Au lieu de ça, on parlait de lancer automatiquement, en root et sans mot de passe une application s'appuyant sur une infrastructure GNOME et ouvrant une connexion vers X-Window. Il suffit que n'importe quelle autre appli ouvre une connexion vers le serveur pour pouvoir taper "à ta place".
En poussant le raisonnement au maximum, même proftpd n'a pas besoin d'être root. Il peut fonctionner sous sa propre identité dans un environnement chrooté. Comme çà, même en cas de faille de sécurité, un utilisateur extérieur ne pourra jamais aller plus loin que ce que le système permet. La seule raison de démarrer le daemon FTP en root est pour lui permettre de réclamer le port 21 et çà, il suffit de demander à xinetd de le faire pour lui.
Bref, dans un serveur UNIX proprement administré, au bout d'un moment, on ne devrait plus avoir à passer root plus d'une fois par mois. Alors en arriver à vouloir virer le mot de passe ...
Enfin - et le ne le fais pas non plus si ce n'est pas nécessaire -, si tu a vraiment besoin de lancer fréquement des commandes en root, tu peux en préciser la liste dans /etc/sudoers et affecter NOPASSWD uniquement sur celles-ci.
C'est vraiment dommage parce qu'il suffit de savoir mettre des droits sur un fichier pour commencer à gérer la sécurité efficacement sous UNIX, c'est presque trivial. Evidemment, sous Windows, ce n'est même pas la peine d'y penser, et tous les utilisateurs exportent - bien plus que des mauvaises habitudes - des schémas de pensée entiers et calamiteux.
# Je regrette, Dave ...
Posté par Obsidian . En réponse au message supprimer mot de passe root. Évalué à 5.
Si tu as besoin d'effectuer des commandes super-utilisateur à l'occassion, utilise sudo, c'est à çà que ça sert. Cette commande t'ouvre une session qui expire après cinq minutes d'inactivité. Donc, tu tapes ton propre mot de passe (et pas celui du superchef) une seule fois, et tu fais tout ton boulot sans être emmerdé.
Si vraiment c'est trop compliqué, tu peux ajouter la directive NOPASSWD dans /etc/sudoers pour que les irresponsables utilisateurs de confiance puissent directement lancer leurs commandes. La sécurité reste proche de zéro, mais au moins on limite les probabilités d'exécution de commandes en root par accident.
Pour le reste, voir ici :
http://linuxfr.org/comments/801182.html#801182
[^] # Re: C'est mal, mais bon, puisque tu y tiens...
Posté par Obsidian . En réponse au message supprimer mot de passe root. Évalué à 3.
[^] # Re: Ca me rappelle quelque chose...
Posté par Obsidian . En réponse au journal Nouveau jeu libre : irrlamb. Évalué à 3.
# Avertissement productivité
Posté par Obsidian . En réponse au journal Galcon, jeu shareware rapide et prenant. Évalué à 2.
# ACPI , APM, toussa ...
Posté par Obsidian . En réponse au message Impossible d'arreter completement la machine. Évalué à 2.
Les fabricants ont mis beaucoup de temps à implémenter partout une ACPI propre, par exemple, et celle-ci est mutuellement exclusive avec APM dans le noyau Linux par exemple.
Donc, vois déjà lequel de ces deux systèmes tu utilises, ensuite, il y a parfois des " sous-modules " à charger pour les différents cas de figure.
Ca fait longtemps que cela n'était pas arrivé mais pendant un moment ce fut vraiment la plaie. Sur 3 machines (ré)installées, 2 ne séteignaient pas correctement et j'ai passé des heures à recompiler le noyau avec les bonnes options simplement pour régler ce détail.
# Sémantique, architecture, toussa ...
Posté par Obsidian . En réponse au message Gestion STDIN + pilotage Mplayer. Évalué à 4.
D'abord, comme tous les programmes, ton application et le mplayer que tu lances derrière héritent tout deux de la console de ton terminal X.
Ensuite, mplayer, en plus d'être doté d'un jeu de handlers fichier stdout,stdin, stderr comme tout le monde, ouvre une connexion vers le serveur X, qui est complètement indépendante de sa console, et qui peut très bien atteindre une machine distincte. Et c'est depuis les événements X que mplayer traite les commandes de navigation de l'utilisateur, pas depuis stdin.
Avec cela, en environnement graphique, l'application qui reçoit les événements de la console, c'est le serveur X lui-même (et en fait ce n'est même plus tout-à-fait vrai car Xorg ou Xfree86 gèrent eux-même le clavier et les périphs d'entrées). C'est aussi eux qui les traduisent en événements dans l'envrionnement graphique et qui les distribuent aux applications concernées (en fonction du focus et avec la complicité du WM).
D'autre part, à priori, ta douchette est vue comme un clavier, et est gérée comme tel par le système lui-même. C'est ce qui fait que tu n'a rien à configurer lorsque tu branches un clavier USB supplémentaire. Donc, au départ, tes applications ne savent pas du tout que tu es en train d'utiliser une douchette.
Ton problème, donc, c'est qu'il te faudrait deux focus. L'un provenant du clavier et ciblant la fenêtre vidéo de mplayer et l'autre, provenant de la douchette, sur la fenêtre du x-term qui fait tourner ton programme.
En conséquence, ton premier souci consiste à être parfaitement sûr de ce que tu veux faire :
- Soit tu souhaites conserver le fonctionnement normal de tes applications. Dans ce cas, c'est à toi de cliquer manuellement sur la fenêtre du X-term lorsque tu veux utiliser la douchette et sur celle de mplayer quand tu veux naviguer. C'est très fastidieux, mais c'est ce que tu ferais naturellement quand même si tu rentrais tes codes barre à la main ... Ca te permet également d'aller balancer la sortie de ta douchette dans un notepad au besoin, sans qu'elle soit interceptée par ton application ...
Tu peux aussi rentrer en mode slave pour ne pas avoir à faire du ping/pong mais cela t'oblige à réimplémenter TOUTES les commandes clavier de mplayer et à jouer avec termios pour récupérer l'état des touches avant d'appuyer sur return, quand c'est possible.
- Soit tu cherches à faire en sorte que la douchette ne serve qu'à zapper les vidéos lorsqu'elles tournent et dans ce cas, cela signifie implicitement qu'aucun autre programme ne doit recevoir ses caractères pendant que ton application tourne. Et dans ce cas, il y a donc une formalité à accomplir au préalable. Demander au système l'exclusivité sur la douchette.
Ca se gère donc au niveau de la gestion des HID par le noyau Linux. C'est normal que cela se trouve à ce niveau, d'ailleurs : il existe d'autres douchettes qui se branchent "en série" sur le cordon PS/2 en s'insérant entre le clavier et l'unité centrale. Dans un tel cas de figure, il t'est impossible de distinguer la douchette du clavier.
Dès lors, la meilleure solution consiste à écrire un daemon qui surveille silencieusement l'activité du clavier et reconnaît les trames susceptibles d'être envoyées par la douchette et qui, le cas échéant, prévient les programmes concernés via un canal de communication propre (un signal, un segment de RAM partagée ou , de préférence, un socket UNIX).
# Voir du coté des fonctions réseau
Posté par Obsidian . En réponse au message types (float, int) indépendant de l'architecture?. Évalué à 2.
htonl, htons, ntohl, ntohs