Définir le nom d'une application vu par le système
16 réponses
Elby
Une question plus de forme que de fond pour ce vendredi soir.
J'ai un executable python appel=E9 f-linux
Quand je le lance et que je regarde les process en cours je vois :
> ps ux=20
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00
python /tmp/test/f-linux
Y a-t-il moyen de dire =E0 l'OS d'utiliser un nom de commande particulier
et non "python chemin/du/script" ?
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00 python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier et non "python chemin/du/script" ?
A part renommer l'exécutable ou mettre un lien (ln /usr/bin/python toto), je ne vois rien de généralement utilisé. Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement fan de php ? (solution: ln /usr/bin/python php) Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
jm
Bonsoir
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00
python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier
et non "python chemin/du/script" ?
A part renommer l'exécutable ou mettre un lien
(ln /usr/bin/python toto), je ne vois rien de généralement utilisé.
Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement
fan de php ? (solution: ln /usr/bin/python php)
Il faut quand même savoir que si l'admin du serveur est un tant soit peu
rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00 python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier et non "python chemin/du/script" ?
A part renommer l'exécutable ou mettre un lien (ln /usr/bin/python toto), je ne vois rien de généralement utilisé. Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement fan de php ? (solution: ln /usr/bin/python php) Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
jm
hg
jean-michel bain-cornu wrote:
Bonsoir
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00 python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier et non "python chemin/du/script" ?
A part renommer l'exécutable ou mettre un lien (ln /usr/bin/python toto), je ne vois rien de généralement utilisé. Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement fan de php ? (solution: ln /usr/bin/python php) Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
jm
Je ne sais pas ce que tu verra si tu crée un mini programme en C qui fait le "system "python ..... " qu'il faut, mais ça vaut le coup d'essayer.
hg
jean-michel bain-cornu wrote:
Bonsoir
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00
python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier
et non "python chemin/du/script" ?
A part renommer l'exécutable ou mettre un lien
(ln /usr/bin/python toto), je ne vois rien de généralement utilisé.
Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement
fan de php ? (solution: ln /usr/bin/python php)
Il faut quand même savoir que si l'admin du serveur est un tant soit peu
rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
jm
Je ne sais pas ce que tu verra si tu crée un mini programme en C qui fait
le "system "python ..... " qu'il faut, mais ça vaut le coup d'essayer.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00 python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier et non "python chemin/du/script" ?
A part renommer l'exécutable ou mettre un lien (ln /usr/bin/python toto), je ne vois rien de généralement utilisé. Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement fan de php ? (solution: ln /usr/bin/python php) Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
jm
Je ne sais pas ce que tu verra si tu crée un mini programme en C qui fait le "system "python ..... " qu'il faut, mais ça vaut le coup d'essayer.
hg
Mihamina (R12y) Rakotomandimby
jean-michel bain-cornu - <46607ac6$0$21150$ :
Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Pour quelle raison un lien symbolique peut-il etre une raison de renvoi? Surtout si je fait un $HOME/bin/interpreteur -> /usr/bin/python, et que j'invoque la "convenance personnelle", je vois vraiment mal comment et pourquoi...
Il faut quand même savoir que si l'admin du serveur est un tant soit peu
rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Pour quelle raison un lien symbolique peut-il etre une raison de renvoi?
Surtout si je fait un $HOME/bin/interpreteur -> /usr/bin/python, et que
j'invoque la "convenance personnelle", je vois vraiment mal comment et
pourquoi...
Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Pour quelle raison un lien symbolique peut-il etre une raison de renvoi? Surtout si je fait un $HOME/bin/interpreteur -> /usr/bin/python, et que j'invoque la "convenance personnelle", je vois vraiment mal comment et pourquoi...
jean-michel bain-cornu
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00 python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier et non "python chemin/du/script" ? A part renommer l'exécutable ou mettre un lien
(ln /usr/bin/python toto), je ne vois rien de généralement utilisé. Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement fan de php ? (solution: ln /usr/bin/python php) Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Je ne sais pas ce que tu verra si tu crée un mini programme en C qui fait
le "system "python ..... " qu'il faut, mais ça vaut le coup d'essayer.
Tu verras le nom de l'exécutable que tu as lancé, plus celui que la
fonction system a elle même lancé.
Exemple : si tu génère hello à partir de : #include <stdio.h> #include <stdlib.h> int main (int argc, char *argv[]) {system ("/usr/bin/python tst.py"); exit (0);}
Tu verras "hello", et "/usr/bin/python"
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00
python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier
et non "python chemin/du/script" ?
A part renommer l'exécutable ou mettre un lien
(ln /usr/bin/python toto), je ne vois rien de généralement utilisé.
Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement
fan de php ? (solution: ln /usr/bin/python php)
Il faut quand même savoir que si l'admin du serveur est un tant soit peu
rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Je ne sais pas ce que tu verra si tu crée un mini programme en C qui fait
le "system "python ..... " qu'il faut, mais ça vaut le coup d'essayer.
Tu verras le nom de l'exécutable que tu as lancé, plus celui que la
fonction system a elle même lancé.
Exemple : si tu génère hello à partir de :
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char *argv[])
{system ("/usr/bin/python tst.py");
exit (0);}
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND elby 4308 0.0 0.2 5336 2320 pts/0 S+ 20:25 0:00 python /tmp/test/f-linux
Y a-t-il moyen de dire à l'OS d'utiliser un nom de commande particulier et non "python chemin/du/script" ? A part renommer l'exécutable ou mettre un lien
(ln /usr/bin/python toto), je ne vois rien de généralement utilisé. Et d'ailleurs, quel est l'intérêt ? Tu as un boss qui est exclusivement fan de php ? (solution: ln /usr/bin/python php) Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Je ne sais pas ce que tu verra si tu crée un mini programme en C qui fait
le "system "python ..... " qu'il faut, mais ça vaut le coup d'essayer.
Tu verras le nom de l'exécutable que tu as lancé, plus celui que la
fonction system a elle même lancé.
Exemple : si tu génère hello à partir de : #include <stdio.h> #include <stdlib.h> int main (int argc, char *argv[]) {system ("/usr/bin/python tst.py"); exit (0);}
Tu verras "hello", et "/usr/bin/python"
jean-michel bain-cornu
Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Pour quelle raison un lien symbolique peut-il etre une raison de renvoi? Surtout si je fait un $HOME/bin/interpreteur -> /usr/bin/python, et que j'invoque la "convenance personnelle", je vois vraiment mal comment et pourquoi...
Ce n'est pas le lien (symbolique ou pas) en lui-même qui pose problème, c'est le fait de masquer le nom de l'exécutable que tu appelles. En tant qu'admin unix, si j'estime que le lien ne se justifie pas, et comme je suis d'une nature parano et que je surveille mes process, je vais me demander pourquoi python est masqué, je ne vais pas trouver de réponse valable, et je vais avoir tendance à échafauder tout un tas de scénari mettant en cause la sécurité. J'aurais sûrement tort au final, mais ça va me gonfler, et se terminer par un kill -9 et un blocage du comte jusqu'à plus ample explication. En fait, la vrai question est celle-là : pourquoi changer le nom de l'exécutable ? C'est déjà suffisament difficile de maîtriser un système, si en plus les process sont masqués...
Mais bon, je ne suis pas l'admin unix non plus ;-)
jm
Il faut quand même savoir que si l'admin du serveur est un tant soit peu
rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Pour quelle raison un lien symbolique peut-il etre une raison de renvoi?
Surtout si je fait un $HOME/bin/interpreteur -> /usr/bin/python, et que
j'invoque la "convenance personnelle", je vois vraiment mal comment et
pourquoi...
Ce n'est pas le lien (symbolique ou pas) en lui-même qui pose problème,
c'est le fait de masquer le nom de l'exécutable que tu appelles.
En tant qu'admin unix, si j'estime que le lien ne se justifie pas, et
comme je suis d'une nature parano et que je surveille mes process, je
vais me demander pourquoi python est masqué, je ne vais pas trouver de
réponse valable, et je vais avoir tendance à échafauder tout un tas de
scénari mettant en cause la sécurité.
J'aurais sûrement tort au final, mais ça va me gonfler, et se terminer
par un kill -9 et un blocage du comte jusqu'à plus ample explication.
En fait, la vrai question est celle-là : pourquoi changer le nom de
l'exécutable ?
C'est déjà suffisament difficile de maîtriser un système, si en plus les
process sont masqués...
Mais bon, je ne suis pas l'admin unix non plus ;-)
Il faut quand même savoir que si l'admin du serveur est un tant soit peu rigoureux et qu'il s'en aperçoit, c'est la porte tout de suite...
Pour quelle raison un lien symbolique peut-il etre une raison de renvoi? Surtout si je fait un $HOME/bin/interpreteur -> /usr/bin/python, et que j'invoque la "convenance personnelle", je vois vraiment mal comment et pourquoi...
Ce n'est pas le lien (symbolique ou pas) en lui-même qui pose problème, c'est le fait de masquer le nom de l'exécutable que tu appelles. En tant qu'admin unix, si j'estime que le lien ne se justifie pas, et comme je suis d'une nature parano et que je surveille mes process, je vais me demander pourquoi python est masqué, je ne vais pas trouver de réponse valable, et je vais avoir tendance à échafauder tout un tas de scénari mettant en cause la sécurité. J'aurais sûrement tort au final, mais ça va me gonfler, et se terminer par un kill -9 et un blocage du comte jusqu'à plus ample explication. En fait, la vrai question est celle-là : pourquoi changer le nom de l'exécutable ? C'est déjà suffisament difficile de maîtriser un système, si en plus les process sont masqués...
Mais bon, je ne suis pas l'admin unix non plus ;-)
jm
Méta-MCI
Bonjour !
Je me demande si ce n'est pas toi qui aurait servi de modèle au dessinateur Cointe, pour Maurel, son personnage administrateur-système.
Tu sais, celui qui, passant un soir dans les bureaux, trouve un lecteur de disquettes géant, non référencé dans le système. Du coup, il le rend inopérant, en le bourrant de morceaux de papiers, collés au typex.
Le lendemain, les utilisateurs se demandent pourquoi il a bousillé leur grille-pain...
Je me demande si ce n'est pas toi qui aurait servi de modèle au dessinateur
Cointe, pour Maurel, son personnage administrateur-système.
Tu sais, celui qui, passant un soir dans les bureaux, trouve un lecteur de
disquettes géant, non référencé dans le système. Du coup, il le rend
inopérant, en le bourrant de morceaux de papiers, collés au typex.
Le lendemain, les utilisateurs se demandent pourquoi il a bousillé leur
grille-pain...
Je me demande si ce n'est pas toi qui aurait servi de modèle au dessinateur Cointe, pour Maurel, son personnage administrateur-système.
Tu sais, celui qui, passant un soir dans les bureaux, trouve un lecteur de disquettes géant, non référencé dans le système. Du coup, il le rend inopérant, en le bourrant de morceaux de papiers, collés au typex.
Le lendemain, les utilisateurs se demandent pourquoi il a bousillé leur grille-pain...
Je me demande si ce n'est pas toi qui aurait servi de modèle au dessinateur Cointe, pour Maurel, son personnage administrateur-système.
Tu sais, celui qui, passant un soir dans les bureaux, trouve un lecteur de disquettes géant, non référencé dans le système. Du coup, il le rend inopérant, en le bourrant de morceaux de papiers, collés au typex.
Le lendemain, les utilisateurs se demandent pourquoi il a bousillé leur grille-pain...
Cette agression caractérisée, insupportable en dehors du vendredi, m'est intolérable. Je me venge immédiatement à coup de "init 6" et autres "halt" "reboot" sur la totalité des machines dont j'ai la responsabilité. J'envisage également de fonder la SPP (Société Protectrice des Process) qui entreprendra, dès après les élections, des actions dans le but d'empêcher les renommages sauvages et non dûment autorisés.
Non mais.
Je me demande si ce n'est pas toi qui aurait servi de modèle au
dessinateur Cointe, pour Maurel, son personnage administrateur-système.
Tu sais, celui qui, passant un soir dans les bureaux, trouve un lecteur
de disquettes géant, non référencé dans le système. Du coup, il le rend
inopérant, en le bourrant de morceaux de papiers, collés au typex.
Le lendemain, les utilisateurs se demandent pourquoi il a bousillé leur
grille-pain...
Cette agression caractérisée, insupportable en dehors du vendredi, m'est
intolérable. Je me venge immédiatement à coup de "init 6" et autres
"halt" "reboot" sur la totalité des machines dont j'ai la responsabilité.
J'envisage également de fonder la SPP (Société Protectrice des Process)
qui entreprendra, dès après les élections, des actions dans le but
d'empêcher les renommages sauvages et non dûment autorisés.
Je me demande si ce n'est pas toi qui aurait servi de modèle au dessinateur Cointe, pour Maurel, son personnage administrateur-système.
Tu sais, celui qui, passant un soir dans les bureaux, trouve un lecteur de disquettes géant, non référencé dans le système. Du coup, il le rend inopérant, en le bourrant de morceaux de papiers, collés au typex.
Le lendemain, les utilisateurs se demandent pourquoi il a bousillé leur grille-pain...
Cette agression caractérisée, insupportable en dehors du vendredi, m'est intolérable. Je me venge immédiatement à coup de "init 6" et autres "halt" "reboot" sur la totalité des machines dont j'ai la responsabilité. J'envisage également de fonder la SPP (Société Protectrice des Process) qui entreprendra, dès après les élections, des actions dans le but d'empêcher les renommages sauvages et non dûment autorisés.