Déjà je ne savais pas dans quelle catégorie mettre une telle question : j'ai pris le parti de Linux général. Si ça se trouve il va falloir faire un peu de Bash/Python/Perl (peu importe) pour faire ce que je cherche ou alors un logiciel fait déjà cela. En plus, le titre n'est pas forcément très précis mais je détaille par la suite
Situation : j'ai une frontale sous CentOS 6 sur laquelle les utilisateurs peuvent se connecter via SSH avec le X11 forwarding autorisé. Sur cette frontale, l'exécution des processus est limitée à 30 minutes (via limits.conf).
Information 1 : le X11 forwarding est autorisé pour pouvoir exécuter certaines applications qui ne consomment pas énormément de ressources tels que geany, nedit, evince… Le problème est que certains s'en servent pour lancer des applications bien plus consommatrices tels que paraview, vmd, molekel… Cela a pour problème de ralentir fortement la frontale. Pour lancer ces applications, il est possible de se connecter à une machine dédiée à la visualisation donc je souhaiterais que l'exécution sur la frontale soit tuée en envoyant un mail pour dire d'aller sur la machine de visualisation.
Information 2 : les utilisateurs pouvant compiler leurs propres codes dans leur /home, il n'est pas simplement possible de faire un chmod -x sur le dossier contenant l'exécutable.
Au final, il faudrait que je trouve/écrive un démon ou un script qui sache lister les processus en cours. Si celui-ci matche avec une certaine liste alors il le tue et prévient via un mail (sendmail de préférence). Donc, avant de me lancer dans l'écriture un tel script (qui doit pas être très gros) je me demande si par hasard quelqu'un ne l'aurait pas déjà écrit (forcément mieux que ce que je vais faire).
Merci d'avance !
# killall ou pkill
Posté par calandoa . Évalué à 2.
… pour tuer le proc ; pour le mail, peut être en se basant sur le code de retour de pkill?
[^] # Re: killall ou pkill
Posté par MarbolanGos (site web personnel) . Évalué à 1.
Ah oui, j'avais déjà réfléchi avec un ps puis un killall. Je vais étudier le pkill qui semble pouvoir faire le ps en même temps. Merci !
# mauvaise solution
Posté par fearan . Évalué à 3.
Moi je fais un petit renommage de firefox en nedit et hop je passe au travers ;)
Je monterai le home en noexec mais si j'ai bien compris les gens doivent pouvoir exécuter des programmes dans leur /home, ce qui fait que je vois pas trop comment faire proprement.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mauvaise solution
Posté par MarbolanGos (site web personnel) . Évalué à 1. Dernière modification le 22 mai 2013 à 11:36.
Oui le noexec n'est pas une solution car des petits scripts légers d'analyse ont tout à fait le droit d'être exécutés.
C'est vrai que c'est une mauvaise solution mais je suis un peu bloqué par le fait de devoir laisser libre une exécution pour analyser des sorties et pouvoir maîtriser les ressources qui ne sont pas infinies…
[^] # Re: mauvaise solution
Posté par fearan . Évalué à 2.
il me semble que noexec sur une partition ne bloque pas les scripts, que les binaires.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# SELinux
Posté par Xavier . Évalué à 0.
Bonjour, peut-être en regardant du côté de SELinux?
[^] # Re: SELinux
Posté par MarbolanGos (site web personnel) . Évalué à 1.
Il est vrai que SELinux pourrait être une solution mais il va falloir fouiller…
# Nice
Posté par needs . Évalué à 2. Dernière modification le 16 mai 2013 à 19:59.
Peut-être est-il possible que tout les processus lancé par un utilisateur aient une priorité plus faible que la normale (genre 10). Du coups ils devraient moins gêner le fonctionnement de la machine non ?
[^] # Re: Nice
Posté par MarbolanGos (site web personnel) . Évalué à 1.
En fait, actuellement, un utilisateur n'a le droit de n'utiliser que 50 % de la RAM et des CPU de la machine. Mais malgré cela dès qu'il y a plein d'IO et j'ai l'impression le serveur X ça provoque pas mal de ralentissements intempestifs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.