[Alg] Management via webserver

[JeRa]

Ik ben bezig met een webbased management systeem van twee samenwerkende servers. Om dit goed te laten werken heb ik de rechten nodig om gebruikers op de servers aan te maken, aangezien het Linux-servers zijn zal dit dus via de root moeten. Ik had bedacht dat ik de webserver bash-scriptjes met argumenten kon laten aanroepen waar met sudo gewerkt wordt om de root-rechten tijdelijk te verwerven om gebruikers aan te maken / te verwijderen.

Probleem hiervan is dat de webserver zo in de sudo'ers lijst moet komen te staan en aangezien het een gedeelde webserver is (ik host wat websites) lijkt me dit niet het allerslimste idee. Het management gebeurt vrijwel uitsluitend via MySQL, maar af en toe moeten er dus ook directories worden aangemaakt en bestanden worden gewijzigd waarvoor ik root-rechten nodig heb.

Iemand een idee hoe ik dit het best kan bewerkstelligen?

[Flard]

Mijn linux-kennis is vrij beperkt, maar is het wellicht geen idee om de 'opdrachten' ergens in een speciale tabel te zetten in de database, en dan een programmaatje schrijven dat je geregeld aanroept en dan alle 'opdrachten' uit de database aan te roepen?
Dat programma kan dan natuurlijk wel gewoon met root-rechten draaien?

[JeRa]

Flard schreef op zondag 18 december 2005 @ 17:49:
Mijn linux-kennis is vrij beperkt, maar is het wellicht geen idee om de 'opdrachten' ergens in een speciale tabel te zetten in de database, en dan een programmaatje schrijven dat je geregeld aanroept en dan alle 'opdrachten' uit de database aan te roepen?
Dat programma kan dan natuurlijk wel gewoon met root-rechten draaien?

Dat heb ik al, maar dat draait op de server als internet applicatie. Het idee is dat ik straks één webbased management app heb die zowel door normale gebruikers als de administrator (ik) kan worden gebruikt om de accounts te beheren. Hiervoor zijn rootrechten benodigd, maar ik ga die zeker niet permanent aan die webapp geven.

[ripexx]

Hiervoor zijn er al veel langer standaard producten zoals webmin, plesk etc. Daarmee kan je dus users aanmaken en nog vele meer. Dus kijk eens hoe zij dat regelen. Volgens mij is (een deel) open source.

[Janoz]

Wat flard bedoeld is dat je een soort queue maakt. Wanneer een gebruiker een actie uit wil voeren wordt deze in een lijstje gezet. Compleet los hiervan draait 1 scriptje met root rechten dat een specifiek aantal acties uit zou mogen voeren. Deze kijkt (dmv bv cron) elke zoveel minuten of er in dat lijstje nog acties staan en voert deze uit. Hierdoor hoef je de webapplicatie en de gebruikers zelf geen rechten te geven en je hebt exacte controle over welke acties uitgevoerd worden.

[JeRa]

Janoz schreef op zondag 18 december 2005 @ 18:28:
Wat flard bedoeld is dat je een soort queue maakt. Wanneer een gebruiker een actie uit wil voeren wordt deze in een lijstje gezet. Compleet los hiervan draait 1 scriptje met root rechten dat een specifiek aantal acties uit zou mogen voeren. Deze kijkt (dmv bv cron) elke zoveel minuten of er in dat lijstje nog acties staan en voert deze uit. Hierdoor hoef je de webapplicatie en de gebruikers zelf geen rechten te geven en je hebt exacte controle over welke acties uitgevoerd worden.

Nu snap ik 'm idd ook en dat is een erg goed idee. Toevallig heb ik al een scriptje dat met een kleine aanpassing precies geschikt is voor deze taak. Het enige nadeel aan deze methode is dus dat je vastzit aan de tijden waarop de cronjob wordt uitgevoerd.

[Verwijderd]

Je zou ook kunnen denken aan een XML-RPC applicatie, waarbij je commands kan versturen naar een wrapper die alles parsed en verwerkt.

[Verwijderd]

Wat je ook zou kunnen doen is in je applicatie een SSH verbinding maken (bijvoorbeeld met MindTerm) en op die manier je commando's doorgeven.

[JeRa]

Verwijderd schreef op maandag 19 december 2005 @ 13:47:
Wat je ook zou kunnen doen is in je applicatie een SSH verbinding maken (bijvoorbeeld met MindTerm) en op die manier je commando's doorgeven.

Bedankt voor de suggesties, maar ik ga het toch zoals boven beschreven doen met een soort journal dus. De hoofdreden hiervoor is dat ik geen cruciale wachtwoorden hoef op te slaan in een userspace (waar de websites, en dus ook het controlpanel, draaien).

[eamelink]

JeRa schreef op zondag 18 december 2005 @ 19:35:
[...]

Nu snap ik 'm idd ook en dat is een erg goed idee. Toevallig heb ik al een scriptje dat met een kleine aanpassing precies geschikt is voor deze taak. Het enige nadeel aan deze methode is dus dat je vastzit aan de tijden waarop de cronjob wordt uitgevoerd.

Je kan ook in de sudoers file zetten dat apache alléén dat scriptje uit mag voeren, dus gewoon process.sh ofzo. Dan kunnen users ook wel je opdrachten laten uitvoeren, maar als jij de enige bent die de queue kan invullen gebeurt er niets, en zit je toch niet meer vast aan cron

[JeRa]

eamelink schreef op maandag 19 december 2005 @ 23:02:
[...]


Je kan ook in de sudoers file zetten dat apache alléén dat scriptje uit mag voeren, dus gewoon process.sh ofzo. Dan kunnen users ook wel je opdrachten laten uitvoeren, maar als jij de enige bent die de queue kan invullen gebeurt er niets, en zit je toch niet meer vast aan cron

Wat bedoel je met 'maar als jij de enige bent die de queue kan invullen'?

Zoals ik het nu heb gerealiseerd is door een journal tabel te vullen met commando's die om de vijf minuten verwerkt worden. Dit is ook om te voorkomen dat als iemand veel subdomeinen gaat verwijderen of toevoegen er veel Apache reloads plaatsvinden. Dit is dan niet het geval als ik dat in een scriptje zet dat telkens opnieuw kan worden aangeroepen.

[JeRa]

Het was toch niet ideaal, mijn opzet

Ik had dus een journalfile die om de 5 minuten werd verwerkt, maar hier zaten wat nadelen aan. Nu laat ik om de 20 minuten een PHP-script (uitgevoerd door een cronjob) de huidige status uitlezen en waar nodig aanpassingen verrichten. Dat betekent dat gebruikers nu maximaal 20 minuten hoeven te wachten op aanpassingen van hun (sub)domeinen. Nu is dit op wat punten nog steeds niet wat ik wil:

1. Bij het aanmaken en verwijderen van databases moeten ze nu óók maximaal 20 minuten wachten, maar dit wil ik meteen laten gebeuren. Maar omdat ik de database-users rechten tot die database moet geven moet ik de db-account van dit webpanel zo'n beetje alle rechten geven.

2. De mailaccounts worden beheerd op een andere server. Omdat het inloggen niet werkt als de directory van de mailbox nog niet is aangemaakt, moet ik via SSH de directory alvast aanmaken. Dit zou inhouden dat ik de webserver vrije SSH-toegang tot de root van de andere server moet geven, en dat is natuurlijk een no-go.

3. Hetzelfde verhaal over de mailaccounts gaat op voor de SVN-repositories, ik wil de webserver absoluut die rechten niet geven maar tegelijkertijd wél de gebruiker directe controle over de repositories geven.

Iemand ideeën hierover?

[eamelink]

JeRa schreef op dinsdag 20 december 2005 @ 09:47:
[...]

Wat bedoel je met 'maar als jij de enige bent die de queue kan invullen'?

Zoals ik het nu heb gerealiseerd is door een journal tabel te vullen met commando's die om de vijf minuten verwerkt worden. Dit is ook om te voorkomen dat als iemand veel subdomeinen gaat verwijderen of toevoegen er veel Apache reloads plaatsvinden. Dit is dan niet het geval als ik dat in een scriptje zet dat telkens opnieuw kan worden aangeroepen.

Wat ik dus bedoelde een aantal maanden geleden was :

Je vult met je php applicatie een mysql database. Vervolgens maak je een progje/scriptje dat de acties uitvoert. Tenslotte geef je apache sudo access tot dat scriptje. Dus apache kan als root alléén dat ene scriptje uitvoeren. En dat ene scriptje doet niets anders dan direct de queue wegwerken.

Andere gebruikers van apache zouden, doordat ze ook dat scriptje als root kunnen uitvoeren weliswaar dat script runnen, maar zolang jij de enige bent die de specifieke mysql tabel met commando's kan vullen; gebeurt er niets wanneer andere gebruikers dat doen.

Daarmee zou je je problemen moeten kunnen oplossen.

[JeRa]

Dat klinkt goed, maar wat kan ik dan beter doen? Sudo-rechten aan Apache voor dat script geven of setuid op dat script waarvan Apache de eigenaar is?

[djluc]

Even tussendoor: waarom moet je voor subdomeinen apache rebooten? Kan je dat niet anders oplossen? Ik gebruik Typo3 als CMS en daarmee kan ik gewoon on the fly subdomeinen toevoegen. Kan je verder niet met een .htaccess anders die subdomeinen laten verwijzen? Die kan je ook gewoon aanpassen als Apache draait.

[JeRa]

djluc schreef op dinsdag 21 maart 2006 @ 13:31:
Even tussendoor: waarom moet je voor subdomeinen apache rebooten?

Omdat ik de subdomeinen instel in een include van de 'hoofd'config file in /etc/apache2/ die config file wordt niet herlezen totdat er een herstart plaatsvindt.

Kan je dat niet anders oplossen? Kan je verder niet met een .htaccess anders die subdomeinen laten verwijzen? Die kan je ook gewoon aanpassen als Apache draait.

Ik geloof dat je in een .htaccess niet zoveel kunt instellen m.b.t. VirtualHosts, maar als jij een idee hebt, laat het me horen verder is een .htaccess natuurlijk een lichte aanslag op de performance omdat dat bestand dan bij élke request gelezen moet worden.

Ik gebruik Typo3 als CMS en daarmee kan ik gewoon on the fly subdomeinen toevoegen.

Maakt Typo3 niet gebruik van een eigen webserver?

[djluc]

Nee, gewoon een standaard Apache/PHP/MySQL installatie. Dit is de standaard htaccess:

code:

order deny,allow
deny from all

RewriteEngine On

RewriteRule ^typo3$ - [L]

RewriteRule ^typo3/.*$ - [L]

 

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* index.php

[JeRa]

Nou ken ik Typo3 verder niet zo, maar is het niet gewoon zo dat die index.php alle subdomeinen afhandelt? En zo niet, hoe weet je dan zeker dat Typo3 de Apache webserver niet graceful herstart? (daar merk je niets van namelijk)

[djluc]

JeRa schreef op dinsdag 21 maart 2006 @ 23:35:
Nou ken ik Typo3 verder niet zo, maar is het niet gewoon zo dat die index.php alle subdomeinen afhandelt? En zo niet, hoe weet je dan zeker dat Typo3 de Apache webserver niet graceful herstart? (daar merk je niets van namelijk)

Die index handeld inderdaad alles af. Dat klopt. Daardoor kan je in Typo3 alle domeinen en subdomeinen behandelen. Je kunt er ook via een extension: realurl, mooie urls mee maken.

[JeRa]

djluc schreef op woensdag 22 maart 2006 @ 10:17:
[...]

Die index handeld inderdaad alles af. Dat klopt. Daardoor kan je in Typo3 alle domeinen en subdomeinen behandelen. Je kunt er ook via een extension: realurl, mooie urls mee maken.

Daar heb ik dus net niets aan, omdat mijn subdomeinen doorverwezen worden naar andere directories van andere users bedankt iig voor het meedenken.

[ Voor 4% gewijzigd door JeRa op 22-03-2006 19:46 ]

[djluc]

Dan zal een htaccess inderdaad de enige oplossing zijn.

[JeRa]

djluc schreef op woensdag 22 maart 2006 @ 20:13:
Dan zal een htaccess inderdaad de enige oplossing zijn.

Dat gaat niet werken. Een htaccess zal op de eerste plaats waarschijnlijk geen rechten hebben om een VirtualHost te declareren en op de tweede plek is het een logisch probleem. Een .htaccess wordt in een bepaalde directory geplaatst zodat het op die directory en alle onderliggende directories en files van toepassing is. Echter, die .htaccess wordt niet gelezen omdat ik de directories per VirtualHost declareer (hoe moet Apache anders weten waar ie bestanden moet vinden?). Maar die VirtualHosts zijn dus nog niet gedeclareerd, etc. Gaat niet werken

[JeRa]

JeRa schreef op zondag 19 maart 2006 @ 21:43:
Dat klinkt goed, maar wat kan ik dan beter doen? Sudo-rechten aan Apache voor dat script geven of setuid op dat script waarvan Apache de eigenaar is?

Kickje voor bovenstaande vraag