Hey,
En ce beau mardi d'août, je vous propose un petit brainstorming ! Je souhaite développer un petit applicatif Web pour gérer mon serveur dédié. L'applicatif en question serait hébergé sur ce même serveur sous Squeeze.
La question que je souhaite vous poser, c'est concernant l'aspect technique. J'ai de bonnes compétences en administration de serveurs sous Linux et en PHP, mais uniquement les bases en Python et en Perl.
Comment gérer l'interaction entre l'applicatif Web et la modification de ma configuration d'Apache par exemple ?
J'ai pensé à plusieurs choses :
Je pourrais développer un démon en Bash qui attend les instructions et qui fait ce que je lui dit, éditer un fichier de conf, relancer Apache, …
J'ai pensé aussi à SSH pour PHP, mais niveau sécurité, c'est hors de question de laisser traîner le mot de passe root ou équivalent en clair dans mon code.
Du perl pur, mais dans tous les cas, il faudrait que www-data ai accès aux fichiers de conf que je veux modifier, et qu'il puisse par exemple relancer Apache2…
Bref, je suis à cours d'idée, comment feriez-vous ? J'ai essayé de décortiquer un peu les solutions actuelles, mais elles sont tellement "usine à gaz", que je ne m'y retrouve pas. Dans l'état actuel des choses, j'aurais aimé faire un applicatif simple : édition des VirtualHosts d'Apache, consultation des logs, …
Quelques idées ?
Merci d'avance
# script shell/perl/python whatever et sudo ?
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 1.
tu pourrais lancer des commandes en tant que www-data mais avec sudo pour avoir les bons droits.
J'ai pas mieux en tête mais bonne question
[^] # Re: script shell/perl/python whatever et sudo ?
Posté par Clement33 . Évalué à 3.
Du coup, n'importe quelle page Web sur mon serveur pourrait faire du sudo… Niveau sécurité, c'est pas le top du top =/.
[^] # Re: script shell/perl/python whatever et sudo ?
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 1.
Techniquement tu peux autoriser l'exécution d'un seul programme qui lui même peut vérifier que l'appelle vient bien des pages que tu veux et uniquement celles-là… Donc niveau sécu je ne vois pas le problème. Mais je trouve pas ça beau comme solution et je m'attend à plus simple dans les prochains commentaires :p
# Pourquoi réinventer la roue ?
Posté par goofy . Évalué à 2.
Je commencerai par regarder comment font les autres :
http://isp-control.net/
[^] # Re: Pourquoi réinventer la roue ?
Posté par Clement33 . Évalué à 2.
J'ai pas parlé de réinventer la roue, mais je veux juste me développer MON panel d'admin car je trouve les autres trop lourds… C'est en se fixant quelques projets et défis que l'on progresse, donc je veux tenter ma chance ;).
Si tu as lu plus haut goofy, tu sauras que j'ai essayé de me plonger dans le code de certaines applis, mais c'est tellement complet que je ne sais même pas ou chercher…
# AlternC
Posté par napster2core . Évalué à 1.
Et pourquoi pas AlternC ???
Tu le trouve trop lourd ?
https://www.alternc.org/
http://framabook.org/9-alternc-comme-si-vous-y-etiez
Librement
Si tu ne sais pas demande, si tu sais partage !
[^] # Re: AlternC
Posté par Clement33 . Évalué à 0.
Le soucis n'est pas de trouver ou de ne pas trouver AlternC lourd… Mais pour répondre à ta question, il y a bien 50 % des fonctionnalités dont je ne me sers pas…
Mais, en lisant le site d'AlternC, je suis tombé sur SUexec, qui permet d'exécuter des scripts CGI en tant qu'un autre utilisateur que celui qui exécute le serveur Web, à savoir www-data pour moi.
Du coup, je pourrais partir sur l'optique suivante :
Je modifie ma conf Apache pour avoir un second fichier de conf qui regroupe mes VirtualHosts et tout, et j'autorise un utilisateur précis seulement à modifier ce fichier. Du coup, via SUexec, je peux faire l'interaction entre le PHP qui va parser mes VHosts, et CGI qui modifiera mes fichiers de conf.
Le soucis majeur reste le fait de relancer Apache, car www-data n'a pas le droit de le faire…
[^] # Re: AlternC
Posté par napster2core . Évalué à 1.
Alors je te préviens tout de suite, suexec c'est vraiment pas facile de le faire fonctionner correctement (j'ai passé plus d'une semaine à essayer de faire fonctionner un service git avec suexec, une belle prise de tête).
C'est pas le module le plus simple de apache…
Pour ce qui est de suexec, tu peux redémarrer apache avec (en étant un autre utilisateur justement).
Par contre c'est toujours dangereux de faire redémarrer un service par un utilisateur qui a un accès web.
Bon courage !
Si tu ne sais pas demande, si tu sais partage !
# des robots
Posté par BAud (site web personnel) . Évalué à 3.
Tu peux regarder http://vhffs.org (VHFFS) : cela est fait avec des robots (bon il n'y a pas besoin de modifier le httpd.conf vu que pour de l'hébergement de masse les arrêt-relance ce serait un peu lourd, mais bon). Ces robots se déclenchent via le cron, vérifient s'il y a quelque chose à traiter en base (selon les statuts) et le font. cf. http://www.vhffs.org/doc:installationguide:basic-robots
# Comment gérer l'interaction entre l'applicatif Web et la modification de ma configuration d'Apache?
Posté par lay . Évalué à 1.
Pour que ce soit plus pratique tu peux déjà créer un dossier avec les droits de ton applicatif contenant un fichier de conf par virtualhost, chaque fichier de conf serait généré par ton applicatif.
Tu n'as plus qu'a inclure ce dossier depuis ton httpd.conf avec par exemple "Include virtualhosts/*.conf".
Pour relancer apache tu peux faire un script avec le bit Suid positionné, en faisant bien gaffe aux droits d’écriture sur le script. Cela permet de lancer le script en root si le script appartient à root.
Sinon pour faire un truc tip-top de la mort qui tue, je partirai personnellement vers des webservices qui font les actions de bases sur le système (par exemple un petit webserver en python), et une interface en php qui fait uniquement appel aux webservices pour faire le travail. Ainsi tu pourrais déployer les webservices sur plusieurs dédiés et avec une interface sur un seul dédié pour les centraliser.
Pour le risque de plantage au redémarrage d'apache qui entrainerai une perte de l'interface, une solution serait de mettre un nginx en frontal, qui sur un virtualhost afficherait le panel d'admin, et qui ferait un reverse proxy vers ton vrai apache pour tout les autres virtualhosts.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.