Servers beheren vanuit 1 punt dmv app/service?

[gvdh81]

Aangezien /14 te boek staat als

Problemen met applicatieprogrammering of serversided scripting.

stel ik hier even mijn vraag voor een probleem waar ik mee aan het worstelen ben.

Momenteel heb ik 1 eigen server, maar dit gaan er binnenkort twee worden, en misschien in de toekomst nog wel meer, dat weet ik nog niet. Om nu al op dit feit voorbereid te zijn zit ik erover na te denken om een soort van management tool te gaan maken om bepaalde zaken op deze servers wat makkelijker te kunnen administreren.Er zijn op dit moment maar 5 zaken die ik wil automatiseren en dit zijn ze (in volgorde van belangrijkheid):
* Bind (domeinbeheer)
* Apache (domeinbeheer)
* MySQL (databasebeheer)
* Crontab
* Directory wijzigingen (gerelateerd aan het domeinbeheer).

Zoals ik er nu over denk (architecture) wil ik dit gaan maken door een (al dan niet encrypte) XML instructieset naar de server te sturen. Op deze server staat bijv. 1 CGI programma wat deze instructieset kan ontvangen, ergens opslaan en vervolgens een lokaal programma kan starten wat de instructieset parsed. Hier zit natuurlijk geen directe feedback op, en misschien wil ik het wel via een webservice gaan doen, maar heb geen ervaring opgedaan hoe ik dit soort zaken kan gaan opzetten.

Welke methode raden jullie mij aan en wat zijn de zaken (buiten de beveiliging) waar ik rekening mee moet gaan houden? Iedere input is welkom, dit is vooralsnog enkel een brainstorm topic, maar links naar tutorials zijn welkom.

[djc]

Misschien is het wel nuttig om een en ander via XMPP te doen (het Jabber-protocol).

Je zou dan iets met PubSub kunnen doen. Wellicht iets meer werk, maar wel een gaaf project.

[sariel]

MySQL: met behulp van phpmyadmin, kan je meerdere servers in zetten.
Bind, Apache2: configuratie data in database zetten, daarna beheren met phpmyadmin.
Crontab: Zo vaak hoef je niet iets in je crontab te wijzigen, toch? Doe dat met ssh.
Directory wijzigingen: deluser kan je met een parameter (--remove-home) de home dir verwijderen. zet gewoon alle webdirs in de home van de user.

[gvdh81]

ehmz, w0w, kun je bind en apache2 in mysql zetten? Dat zou een hoop werk schelen, maar dan nog blijf je het feit houden dat je servers remote moet kunnen reloaden ivm configuratiedata. Directory;s moet kunnen aanmaken, users moet kunnen aanmaken etc.
Iemand ervaring met soap::lite?

[ Voor 6% gewijzigd door gvdh81 op 16-10-2006 14:16 ]

[MTWZZ]

sariel schreef op maandag 16 oktober 2006 @ 14:07:
MySQL: met behulp van phpmyadmin, kan je meerdere servers in zetten.
Bind, Apache2: configuratie data in database zetten, daarna beheren met phpmyadmin.
Crontab: Zo vaak hoef je niet iets in je crontab te wijzigen, toch? Doe dat met ssh.
Directory wijzigingen: deluser kan je met een parameter (--remove-home) de home dir verwijderen. zet gewoon alle webdirs in de home van de user.

Bind wil je echt niet in MySQL zetten. Apache configuratie kan volgens mij niet eens in een database.
Een iets andere (en misschien verre van optimale) oplossing is een CVS/SVN repository te bouwen en je configuratie bestanden daar inchecken en dan via ssh op de andere servers de nieuwe versie te laten downloaden. Zo heb je iig automagisch versiebeheer van je configuratie files.

Je zou ook naar webmin kunnen kijken.

[ Voor 4% gewijzigd door MTWZZ op 16-10-2006 17:09 ]

[gvdh81]

Hey MTWZZ, webmin en andere CP's doe ik liever niet, aangezien deze nogal wat daemons hebben draaien op de achtergrond die je server onnodig traag maken. Ik wil dus wel de voordelen van deze systemen (remote admin van server gedeelten) maar het liever zelf bouwen. Iemand ervaring met de perl module SOAP::lite ?

[mocean]

Je kan ook je data in 1 centrale mysql database zetten, dus de gegevens over domeinen, server, crontab etc. Daarvoor kan je dan een mooie webinterface maken.

Op elke server moet dan een programma draaien die de data in de mysql database omzet naar de benodigde config files en evt de deamon restart. Dat inlezen van de nieuwe config data zou je vanuit de webinterface kunnen pushen; dus tegen de server zeggen: haal de nieuwe config data op.

[Gomez12]

Wat ik ooit eens heb gedaan is gewoon een simpel scriptje schrijven wat met rsync 1 mappenstructuur gelijk trekt over alle servers en daarna de mappen structuur lokaal gelijk trekt.

Dus elke server heeft in de root een map sync staan met daarin /etc, /pub, /var/log etc.
En dan wordt eerst /var/log gesynched met /sync/log/hostname/var/log
En dan wordt de map sync met rsync gesynchroniseerd over het netwerk heen.
Daarna wordt /sync/etc gekopieerd naar /etc en vanuit het script worden daarna enkele services herstart ( indien nodig ).

Voordeel hiervan vind ik dat ik overal backups rond heb zwerven overal van alle lokale servertjes. rsync zorgt voor een lage lijnbelasting. En als ik iets nieuws installeer kan ik zelf kiezen of ik het op alle servers wil hebben ( door in /sync/etc te gooien ) of alleen lokaal ( rechtstreeks in /etc ). Omdat alles met alles synched heb ik binnen 24 uur een software uitrol gedaan ( syncscript draait alleen in de nacht ) over 35 lokale servertjes.

Valt er eentje uit is er nog geen nood aan de man. Basisinstall doen en dan weer het syncscriptje draaien en hij krijgt alle data en configs weer terug.

Wat er bij ons bijv in /etc/sync staat zijn
dhcpd, bind, samba, crontab

Het voordeel hiervan vinden wij dat je niet 1 punt hebt waarop je beheer kan doen, maar je kan het vanuit elk punt doen zolang het maar niet vanaf 2 punten gelijktijdig gebeurt.

[gvdh81]

Ik vind het idee van Mocean wel erg leuk en haalbaar. Dit in gedachten houdende, zouden hier ook nog nadelen aan kunnen kleven, behalve dat alle servers in de config tabel moeten kunnen inloggen?

[mocean]

gvdh81 schreef op dinsdag 17 oktober 2006 @ 08:43:
Ik vind het idee van Mocean wel erg leuk en haalbaar. Dit in gedachten houdende, zouden hier ook nog nadelen aan kunnen kleven, behalve dat alle servers in de config tabel moeten kunnen inloggen?

Qua security moet je e.e.a. wel goed doordenken. De webinterface moet goed zijn dichtgetikt (restricted to IP?). Als mensen daar in kunnen komen, zijn al je servers te beinvloeden.

De Mysql DB kan je ook enkel accessible maken vanaf je eigen servers, met read-rechten. Maar ook hier oppassen dat als 1 van de servers is gehacked, ze niet bij de data van de andere servers kunnen.

Zaken als passwords die naar de servers moeten zou je e.v.t. kunnen encrypten met een key die per server anders is.

Maar al met al best haalbaar denk ik, ben benieuwd of anderen nog securtiy issues zien, of andere nadelen.

[Gomez12]

gvdh81 schreef op dinsdag 17 oktober 2006 @ 08:43:
Ik vind het idee van Mocean wel erg leuk en haalbaar. Dit in gedachten houdende, zouden hier ook nog nadelen aan kunnen kleven, behalve dat alle servers in de config tabel moeten kunnen inloggen?

Vraagje. Hoe zet je gegevens in de dbase??? Gewoon 1 memo veld per bestand met daarin de complete inhoud van het bestand of elke mogelijkheid als aparte rij opslaan?

1 memo veld zie ik weinig nut in. t.o.v. flat files.
per property een rij in je dbase en het daarna weer opbouwen op de client vereist volgens mij een berg onderhoud ( nieuwe versie, nieuwe property , het standaard commentaar in de flat files moet je ook nog ergens kwijt kunnen, het verschil in sommige config files ).
Volgens mij als je propertys los wilt opslaan kan je beter verschillende webbased configs gebruiken die door anderen onderhouden en bijgewerkt worden dan dat je alles zelf moet gaan zitten bouwen.

Het klinkt heel mooi, maar volgens mij vergis je je in het onderhoud wat je eraan gaat hebben.

[cytherea]

In essentie is zo'n systeem niet heel erg complex. Met een hele mooie webinterfaces en alles wordt het inderdaad wel moeilijker.

Ik ben ook een beetje aan het kijken naar zo'n soort systeem en ik ga waarschijnlijk voor een centrale opslag van de gegevens in een MySQL database. vanhieruit halen servers de benodigde configuratie enz.. en schrijven de configs lokaal weg en geven de deamons een slinger. Dit ga ik inzetten voor een webcluster oplossing. Zelf alles handmatig bijwerken is niet te doen en brengt ook risico's met zich mee vanwege typo's.

Zelf denk ik aan een centrale database met een interface, kan heel eenvoudig zijn voor intern gebruik.

Elke server leest de data uit, via SOAP ofzo. Eventueel door handmatig het scriptje op te starten vanaf SSH, zodat het niet extern te benaderen is. De machine maakt de configbestanden, maakt een backup van de oude en schrijft het weg. Restart van de services en klaar is kees.

In de database zou ik de data wel gemodelleerd opslaan zodat het makkelijker door de interface te verwerken is, en het parsen van configbestanden wil je eigenlijk voorkomen.

Just my 2 cents

[Verwijderd]

Webmin maakt je server traag

[gvdh81]

Tabel met servers
+ Tabel met domeinen op die server
++ Instellingen voor dit domein, per config idd 1 veld

Het grote voordeel van dit systeem t.o.v. config files is dat ik:
- remote een download kan laten doen, dus geen rechten hoef te geven aan het script wat op de main server draait om op iedere server waar dan ook bestanden weg te gaan schrijven (laat staan connecties e.d.)
- de config op 2 plaatsen heb

De reden dat ik het niet per property doe is idd ivm onderhoud en uitbreidbaarheid.

Ik heb dus (exact) hetzelfde idee als Cytherea hierboven, voor diegene die dat nog niet door hadden:

Ik ben ook een beetje aan het kijken naar zo'n soort systeem en ik ga waarschijnlijk voor een centrale opslag van de gegevens in een MySQL database. vanhieruit halen servers de benodigde configuratie enz.. en schrijven de configs lokaal weg en geven de deamons een slinger. Dit ga ik inzetten voor een webcluster oplossing. Zelf alles handmatig bijwerken is niet te doen en brengt ook risico's met zich mee vanwege typo's.

Zelf denk ik aan een centrale database met een interface, kan heel eenvoudig zijn voor intern gebruik.

Elke server leest de data uit, via SOAP ofzo. Eventueel door handmatig het scriptje op te starten vanaf SSH, zodat het niet extern te benaderen is. De machine maakt de configbestanden, maakt een backup van de oude en schrijft het weg. Restart van de services en klaar is kees.

In de database zou ik de data wel gemodelleerd opslaan zodat het makkelijker door de interface te verwerken is, en het parsen van configbestanden wil je eigenlijk voorkomen.

@RutgerM, webmin heb ik geen ervaring mee, maar wel Plesk, en dat wil ik nooit meer op mijn server(s) hebben als ik zie wat voor een vrijheid ik nu heb. Denk aan zelf een PHP versie kiezen, niet meer betalen voor open-source antivirus oplossingen, etc. etc.

[djc]

Slack is het systeem dat Google hiervoor gebruikt.

[cytherea]

gvdh81 schreef op woensdag 18 oktober 2006 @ 08:17:

@RutgerM, webmin heb ik geen ervaring mee, maar wel Plesk, en dat wil ik nooit meer op mijn server(s) hebben als ik zie wat voor een vrijheid ik nu heb. Denk aan zelf een PHP versie kiezen, niet meer betalen voor open-source antivirus oplossingen, etc. etc.

Eens, alleen voor puur shared webhosting toepassingen waarbij klanten van alles zelf willen wel handig. Heb zelf ook teveel geklooi met een Plesk server. Ik zal het niet zo snel gebruiken om puur eigen applicaties te hosten.

[gvdh81]

Klanten willen bij ook van alles, maar ik geef ze in het begin alleen toestemming om zelf email adressen te beheren (incl. autoreply). Daarna misschien subdomeinen maar daarna houd het al snel op.