Hi,
im Syncthing ebenfalls unter Technics/Serverplanung/ liegt jetzt ein Entwurf für eine Servicekarte. Ich hoffe das ist in etwas das was ihr euch vorgestellt habt.
Grundsätzlich ist die Planung so ausgelegt, dass wir mittelfristig erstmal keine Anwenungen mehr auf den Servern hin- und herschieben müssen sondern grundsätzlich Luft für Performanceengpässe haben.
* Datenbanken: da ändert sich nichts * Backup: hierfür ist ein eigener Server vorgesehen, welche Dienste darauf laufen sollen haben wir aber glaube ich noch nicht besprochen * Monitoring: für Munin und Nagios gibts eine eigene Kiste auf die auch noch der Meshviewer rauf kann damit der nicht auf der selben Kiste wie Netmon liegt (falls eines der beiden ausfällt). Diese Kiste braucht ne Anbindung ans Mesh * Web1: hier liegt der Mailkram sowie PHP+Nginx Web-Anwendungen, diese Kiste braucht ne Anbindung ans Mesh * Web2: hier liegt XMPP sowie Python und andere Web-Anwendungen
Es gibt noch 4 Dienste die ich so nicht zuordnen konnte. Grundlage für die Planung ist https://pad.freifunk.net/p/ffnw-admin-dienste
Was meint ihr dazu?
LG Clemens
Zitat von Clemens John clemens.john@floh1111.de:
- Datenbanken: da ändert sich nichts
+1
- Backup: hierfür ist ein eigener Server vorgesehen, welche Dienste darauf
laufen sollen haben wir aber glaube ich noch nicht besprochen
rsnapshot zieht sich die daten, aber das sollten wir im detail noch besprechen.
- Monitoring: für Munin und Nagios gibts eine eigene Kiste auf die auch noch
der Meshviewer rauf kann damit der nicht auf der selben Kiste wie Netmon liegt (falls eines der beiden ausfällt). Diese Kiste braucht ne Anbindung ans Mesh
+1
- Web1: hier liegt der Mailkram sowie PHP+Nginx Web-Anwendungen, diese Kiste
braucht ne Anbindung ans Mesh
bist du sicher das netmon mit dem ganzen anderen auf srv01? benötigt netmon nicht viel leitung?
- Web2: hier liegt XMPP sowie Python und andere Web-Anwendungen
Es gibt noch 4 Dienste die ich so nicht zuordnen konnte. Grundlage für die Planung ist https://pad.freifunk.net/p/ffnw-admin-dienste
Was meint ihr dazu?
webalizer_NG, srv01 (web1) (läuft z.b alle stunde) shellinabox , srv01 (web1) (ssh notlösung wenn kein ssh zur hand mit passwort zugang über browser) bnc (znc), srv05 (web2) (brauch ca. >=400MB RAM und nicht viel CPU zeit
puppet mit auf srv14 (backup)? am besten noch mit felix sprechen.
*** NOCH VERGESSEN mosh parallel zu sshd auf jeden server *** https://mosh.mit.edu/
Hi,
- Monitoring: für Munin und Nagios gibts eine eigene Kiste auf die
auch noch der Meshviewer rauf kann damit der nicht auf der selben Kiste wie Netmon liegt (falls eines der beiden ausfällt). Diese Kiste braucht ne Anbindung ans Mesh
+1
Ich würde nagios und Munin evtl. auch noch mal auf zwei getrenten Maschinen laufen lassen.
- Web1: hier liegt der Mailkram sowie PHP+Nginx Web-Anwendungen, diese
Kiste braucht ne Anbindung ans Mesh
bist du sicher das netmon mit dem ganzen anderen auf srv01? benötigt netmon nicht viel leitung?
könnte man mal ausprobieren.
- Web2: hier liegt XMPP sowie Python und andere Web-Anwendungen
Es gibt noch 4 Dienste die ich so nicht zuordnen konnte. Grundlage für die Planung ist https://pad.freifunk.net/p/ffnw-admin-dienste
Was meint ihr dazu?
webalizer_NG, srv01 (web1) (läuft z.b alle stunde)
Wollen wir da nicht lieber Piwik nehmen ?
shellinabox , srv01 (web1) (ssh notlösung wenn kein ssh zur hand mit passwort zugang über browser)
Finde ich generrel ne schlechte idee da ich persönlich lieber von passwörtern weg will.
besser wären keys, Certivicate, 2 Factor autentifizirung oder anstelle der 2 Factor autentifizirung besser sogar One time Passwörter.
bnc (znc), srv05 (web2) (brauch ca. >=400MB RAM und nicht viel CPU zeit
puppet mit auf srv14 (backup)? am besten noch mit felix sprechen.
+1
*** NOCH VERGESSEN mosh parallel zu sshd auf jeden server *** https://mosh.mit.edu/
Da bin ich eher vorsichtig das ich administattions tools eher niedrig halten würde. Um angriffe sowie potentielle sicherheitslücken zu meiden.
LG Tarek
Zitat von Jan-Tarek Butt tarek@ring0.de:
- Monitoring: für Munin und Nagios gibts eine eigene Kiste auf die
auch noch der Meshviewer rauf kann damit der nicht auf der selben Kiste wie Netmon liegt (falls eines der beiden ausfällt). Diese Kiste braucht ne Anbindung ans Mesh
+1
Ich würde nagios und Munin evtl. auch noch mal auf zwei getrenten Maschinen laufen lassen.
wenn wir das sowviel hw haben sehr gerne ++1
- Web1: hier liegt der Mailkram sowie PHP+Nginx Web-Anwendungen, diese
Kiste braucht ne Anbindung ans Mesh
bist du sicher das netmon mit dem ganzen anderen auf srv01? benötigt netmon nicht viel leitung?
könnte man mal ausprobieren.
+1
- Web2: hier liegt XMPP sowie Python und andere Web-Anwendungen
Es gibt noch 4 Dienste die ich so nicht zuordnen konnte. Grundlage für die Planung ist https://pad.freifunk.net/p/ffnw-admin-dienste
Was meint ihr dazu?
webalizer_NG, srv01 (web1) (läuft z.b alle stunde)
Wollen wir da nicht lieber Piwik nehmen ?
wir können gerne nur piwik nutzen ++1 (hat den vorteil das piwik auf srv01 nicht viel last macht und eher die DB quält)
shellinabox , srv01 (web1) (ssh notlösung wenn kein ssh zur hand mit passwort zugang über browser)
Finde ich generrel ne schlechte idee da ich persönlich lieber von passwörtern weg will.
okay, kann ich nachvollziehen ++1
besser wären keys, Certivicate, 2 Factor autentifizirung oder anstelle der 2 Factor autentifizirung besser sogar One time Passwörter.
hast du dazu eine lösung wie man sowas baut? yubikey, sowas würde mich interessieren ++1
*** NOCH VERGESSEN mosh parallel zu sshd auf jeden server *** https://mosh.mit.edu/
Da bin ich eher vorsichtig das ich administattions tools eher niedrig halten würde. Um angriffe sowie potentielle sicherheitslücken zu meiden.
mosh soll ja grade deswegen auf jeden srv wo der sshd läuft. https://mosh.mit.edu/#techinfo aber mosh können wir lassen, ich dachte an die geplagten, mit instabiler anbindung (zug, mobilfunk usw...)
Am Donnerstag, 9. Juli 2015, 21:42:48 schrieb Jan-Tarek Butt:
Ich würde nagios und Munin evtl. auch noch mal auf zwei getrenten Maschinen laufen lassen.
Würde ich nicht machen weil uns das nicht mehr Sicherheit bringt. Wenn eine Produktivmaschine ausfällt auf der gleichzeitig ein Monitoringtool läuft (und das wäre ja die Konsequenz), haben wir ein Problem. Wenn uns aber nur das Monitoring wegbricht (selbst wenn es beide Tools gleichzeitig sind), passiert gar nichts. Mehr Sicherheit können wir nur gewinnen indem wir Nagios und Munin auf zwei getrennte Hosts packen auf denen sonst nichts anderes läuft. Das wäre aber glaube ich echt Overkill^^
bist du sicher das netmon mit dem ganzen anderen auf srv01? benötigt netmon nicht viel leitung?
könnte man mal ausprobieren.
Das Netmon zieht vorallem an der Datenbank und die haben wir extra deswegen ausgelagert. Von daher sehe ich da nicht so ein großes Risiko.
Zu den restlichen Punkten kann ich nur ganz allgemein Anmerken, dass jedes zusätzliche Tool und jeder mechanismus Arbeit mit sich bringt die wir irgendwie wuppen müssen. Von daher vllt. einmal drüber meditieren obs wirklich notwendig oder einfach nur nice2have wäre.
LG Clemens
Am 09.07.2015 um 22:03 schrieb Clemens John:
Am Donnerstag, 9. Juli 2015, 21:42:48 schrieb Jan-Tarek Butt:
Ich würde nagios und Munin evtl. auch noch mal auf zwei getrenten Maschinen laufen lassen.
Würde ich nicht machen weil uns das nicht mehr Sicherheit bringt. Wenn eine Produktivmaschine ausfällt auf der gleichzeitig ein Monitoringtool läuft (und das wäre ja die Konsequenz), haben wir ein Problem. Wenn uns aber nur das Monitoring wegbricht (selbst wenn es beide Tools gleichzeitig sind), passiert gar nichts. Mehr Sicherheit können wir nur gewinnen indem wir Nagios und Munin auf zwei getrennte Hosts packen auf denen sonst nichts anderes läuft. Das wäre aber glaube ich echt Overkill^^
das ist ein argument.
Zu den restlichen Punkten kann ich nur ganz allgemein Anmerken, dass jedes zusätzliche Tool und jeder mechanismus Arbeit mit sich bringt die wir irgendwie wuppen müssen. Von daher vllt. einmal drüber meditieren obs wirklich notwendig oder einfach nur nice2have wäre.
also hier noch mal drüber geschlafen schellinabox und webalizer ***lassen wir weg***
bnc (znc), srv05 (web2) (brauch ca. >=400MB RAM und nicht viel CPU zeit puppet mit auf srv14 (backup).
TODO: mosh *diskusion*
Am 10.07.2015 um 08:40 schrieb Jan-Tarek Butt:
bnc (znc), srv05 (web2) (brauch ca. >=400MB RAM und nicht viel CPU zeit puppet mit auf srv14 (backup).
wir können für den puppet auch einen separaten container erstellen sowie der bnc
macht es sinn für ALLES EINEN eigenen lxc container zu erstellen?
Am 10.07.2015 um 08:42 schrieb picard:
Am 10.07.2015 um 08:40 schrieb Jan-Tarek Butt:
bnc (znc), srv05 (web2) (brauch ca. >=400MB RAM und nicht viel CPU zeit puppet mit auf srv14 (backup).
wir können für den puppet auch einen separaten container erstellen sowie der bnc
macht es sinn für ALLES EINEN eigenen lxc container zu erstellen?
Ne ich hab mal eine servicekarte_v1 erstellt wo ich ein paar Änderungen vorgenommen hab.
Also puppet und puppet-web frontend würde ich in einen containter packen.
Backup würde ich nur für Backup foo lassen.
und bnc würde ich mit xmpp zusammen in ein container packen da das thematisch besser zusammen passt.
LG Tarek
Eine VM für unseren OS Kram brauchen wir noch. Dafür machen wir unseren LXC Host frei.
Am 10. Juli 2015 09:29:14 MESZ, schrieb Jan-Tarek Butt tarek@ring0.de:
Am 10.07.2015 um 08:42 schrieb picard:
Am 10.07.2015 um 08:40 schrieb Jan-Tarek Butt:
bnc (znc), srv05 (web2) (brauch ca. >=400MB RAM und nicht viel CPU
zeit
puppet mit auf srv14 (backup).
wir können für den puppet auch einen separaten container erstellen
sowie
der bnc
macht es sinn für ALLES EINEN eigenen lxc container zu erstellen?
Ne ich hab mal eine servicekarte_v1 erstellt wo ich ein paar Änderungen vorgenommen hab.
Also puppet und puppet-web frontend würde ich in einen containter packen.
Backup würde ich nur für Backup foo lassen.
und bnc würde ich mit xmpp zusammen in ein container packen da das thematisch besser zusammen passt.
LG Tarek
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Klar.
* WordPress * Mail * DNS
SQL über 07
Am 10. Juli 2015 09:35:31 MESZ, schrieb Jan-Tarek Butt tarek@ring0.de:
Am 10.07.2015 um 09:33 schrieb Stefan:
Eine VM für unseren OS Kram brauchen wir noch. Dafür machen wir
unseren LXC Host frei.
Magst du kurz auflisten was für Dienste ihr da habt ?
Wordpress etc.
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Am 10.07.2015 um 10:06 schrieb Stefan || Freifunk Osnabrück:
Am 10.07.2015 um 09:56 schrieb Bjoern Franke:
Das lässt sich ja alles ineinander migrieren mit unseren Diensten. Also gut, web, mail und dns sollte man trennen.
Könnten wir DNS bei euch unterbringen?
Sollte kein Problem sein wir haben ja sogar schon ein dns Server für interne domains. Warum hatte ihr da eigentlich nen eigenen :D ?
LG Tarek
Weil das irgendwie vor dem zustoßen zu NordWest so gekommen ist. Welcher DNS ist das? Bind?
Sofern ein Webinterface da ist, könnte ich einen Zugang bekommen? Dann switche ich das als erstes mal um!
Am 10.07.2015 um 10:14 schrieb Jan-Tarek Butt:
Warum hatte ihr da eigentlich nen eigenen :D ?
Am 10.07.2015 um 10:17 schrieb Stefan || Freifunk Osnabrück:
Weil das irgendwie vor dem zustoßen zu NordWest so gekommen ist. Welcher DNS ist das? Bind?
Sofern ein Webinterface da ist, könnte ich einen Zugang bekommen? Dann switche ich das als erstes mal um!
Klar meiner seist wäre das überhaupt kein Thema.
Mail und WP könnte man mit auf srv01 integrieren.
DNS würde ich auf srv08 schieben da eine mesh Anbindung notwendig ist.
P.S. Ich hab servicekarte_v1 mal ergänzt
LG Tarek
Zitat von Jan-Tarek Butt tarek@ring0.de:
P.S. Ich hab servicekarte_v1 mal ergänzt
was ist wordpress os auf srv01
Am Freitag, den 10.07.2015, 10:14 +0200 schrieb Jan-Tarek Butt:
Am 10.07.2015 um 10:06 schrieb Stefan || Freifunk Osnabrück:
Am 10.07.2015 um 09:56 schrieb Bjoern Franke:
Das lässt sich ja alles ineinander migrieren mit unseren Diensten. Also gut, web, mail und dns sollte man trennen.
Könnten wir DNS bei euch unterbringen?
Sollte kein Problem sein wir haben ja sogar schon ein dns Server für interne domains. Warum hatte ihr da eigentlich nen eigenen :D ?
Der interne ist momentan dnsmasq, der taugt nicht als normaler DNS-Server für externe Domains.
-- xmpp bjo@schafweide.org
Könnten wir DNS bei euch unterbringen?
Sollte kein Problem sein wir haben ja sogar schon ein dns Server für interne domains. Warum hatte ihr da eigentlich nen eigenen :D ?
Der interne ist momentan dnsmasq, der taugt nicht als normaler DNS-Server für externe Domains.
wollten wir doch sowie so auf bind ändern damit wir dafür ein gescheites web frontend haben.
LG Tarek
Am Freitag, den 10.07.2015, 10:20 +0200 schrieb Jan-Tarek Butt:
Könnten wir DNS bei euch unterbringen?
Sollte kein Problem sein wir haben ja sogar schon ein dns Server für interne domains. Warum hatte ihr da eigentlich nen eigenen :D ?
Der interne ist momentan dnsmasq, der taugt nicht als normaler DNS -Server für externe Domains.
wollten wir doch sowie so auf bind ändern damit wir dafür ein gescheites web frontend haben.
Für Bind gibt's gescheite Webfrontends? Wir hatten doch mal PowerDNS mit Poweradmin angedacht.
Powerdns könnten wir ja kurzfristig auf ein System schmeißen. Die Frage wäre nur, wohin soll dass? srv08 ist ja momentan noch als GW eingesetzt
Am Freitag, 10. Juli 2015, 08:42:41 schrieb picard:
macht es sinn für ALLES EINEN eigenen lxc container zu erstellen?
Hi,
nein das macht vom Aufwand her keinen Sinn und so viele IP-Adressen haben wir auch nicht denke ich. Wir müssen ein sicheres System erstellen, aber nicht das sicherste System der Welt. Sicherheitsmaßnahmen müssen verhältnismäßig sein denke ich.
LG Clemens
Das sehe ich wie Clemens. Wir könnten das Nagios z.b auf unserem LXC, dann wäre es von den Bytemine Kisten unabhängig.
Vorschlag für unseren LXC: * Nagios VM * Backup VM * evtl. Mailserver + postfixAdmin (bjo beachte mich auf die Idee) * testing VM
Damit sollte der Host doch klarkommen
Am 10. Juli 2015 09:40:55 MESZ, schrieb Clemens John clemens.john@floh1111.de:
Am Freitag, 10. Juli 2015, 08:42:41 schrieb picard:
macht es sinn für ALLES EINEN eigenen lxc container zu erstellen?
Hi,
nein das macht vom Aufwand her keinen Sinn und so viele IP-Adressen haben wir auch nicht denke ich. Wir müssen ein sicheres System erstellen, aber nicht das sicherste System der Welt. Sicherheitsmaßnahmen müssen verhältnismäßig sein denke ich.
LG Clemens
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Am 10.07.2015 um 09:47 schrieb Stefan:
Das sehe ich wie Clemens. Wir könnten das Nagios z.b auf unserem LXC, dann wäre es von den Bytemine Kisten unabhängig.
Genau das hab ich doch gesagt ?
Vorschlag für unseren LXC:
- Nagios VM
- Backup VM
- evtl. Mailserver + postfixAdmin (bjo beachte mich auf die Idee)
- testing VM
Was ist euer LXC ? srv13 ?
LG Tarek
Zitat von Stefan stefan@osnabrueck.freifunk.net:
Das sehe ich wie Clemens. Wir könnten das Nagios z.b auf unserem LXC, dann wäre es von den Bytemine Kisten unabhängig.
Vorschlag für unseren LXC:
- Nagios VM
- Backup VM
- evtl. Mailserver + postfixAdmin (bjo beachte mich auf die Idee)
- testing VM
Damit sollte der Host doch klarkommen
auf jedenfall sollten wir OS und FFNW vereinen. gleiche doppelte services vermeiden.
wollte es nur noch mal sagen ;-)
Am Freitag, 10. Juli 2015, 13:27:38 schrieb picard:
auf jedenfall sollten wir OS und FFNW vereinen. gleiche doppelte services vermeiden.
Ja und nein. Lokale Gruppen in unserem Netzwerk konnten sich immer ein Stück weit unabhängig entfalten indem sie bspw. eine eigene Webseite betreiben um lokalen Gegebenheiten gerecht zu werden und eine eigene Dynamik zu entwickeln.
Natürlich macht das Aufwand, ich kann dieses Bedürfnis aber nachvollziehen. Ich weiß jetzt nicht um welche Anwendungen es genau geht, aber ich würde dafür plädieren diesen Punkt mit etwas Vorsicht anzufassen.
LG Clemens
Zitat von Clemens John clemens.john@floh1111.de:
Am Freitag, 10. Juli 2015, 13:27:38 schrieb picard:
auf jedenfall sollten wir OS und FFNW vereinen. gleiche doppelte services vermeiden.
Ja und nein. Lokale Gruppen in unserem Netzwerk konnten sich immer ein Stück weit unabhängig entfalten indem sie bspw. eine eigene Webseite betreiben um lokalen Gegebenheiten gerecht zu werden und eine eigene Dynamik zu entwickeln.
ich drücke mich deutlicher aus, entschuldigt. ich spreche von kern services wie Supernodes, DNS, MAIL, HTTP und auch die fw DEV. tickets so weit es geht zusammen bearbeiten.
FRONTENDS wie webseite(n), sozial media (twitter, facebook) und treffen sollten natürlich lokal möglich sein und sogar gemacht werden.
aber eine gemeinsame kern basis schaffen und das wenns geht dezentral vom verein (wenn genug hw von extern vorhanden ist)
Hier stimme ich Clemens auch zu! DNS, Mail etc können wir zusammen legen.
Am 10.07.2015 um 13:35 schrieb Clemens John:
Ja und nein. Lokale Gruppen in unserem Netzwerk konnten sich immer ein Stück weit unabhängig entfalten indem sie bspw. eine eigene Webseite betreiben um lokalen Gegebenheiten gerecht zu werden und eine eigene Dynamik zu entwickeln.
Natürlich macht das Aufwand, ich kann dieses Bedürfnis aber nachvollziehen. Ich weiß jetzt nicht um welche Anwendungen es genau geht, aber ich würde dafür plädieren diesen Punkt mit etwas Vorsicht anzufassen.
Am 09.07.2015 um 22:03 schrieb Clemens John:
Am Donnerstag, 9. Juli 2015, 21:42:48 schrieb Jan-Tarek Butt:
Ich würde nagios und Munin evtl. auch noch mal auf zwei getrenten Maschinen laufen lassen.
Würde ich nicht machen weil uns das nicht mehr Sicherheit bringt. Wenn eine Produktivmaschine ausfällt auf der gleichzeitig ein Monitoringtool läuft (und das wäre ja die Konsequenz), haben wir ein Problem. Wenn uns aber nur das Monitoring wegbricht (selbst wenn es beide Tools gleichzeitig sind), passiert gar nichts. Mehr Sicherheit können wir nur gewinnen indem wir Nagios und Munin auf zwei getrennte Hosts packen auf denen sonst nichts anderes läuft. Das wäre aber glaube ich echt Overkill^^
Ja, Munin da lassen wo es jetzt geplant ist also srv08 und nagios bzw icinga auf srv13 in ein lxc schmeißen.
bist du sicher das netmon mit dem ganzen anderen auf srv01? benötigt netmon nicht viel leitung?
könnte man mal ausprobieren.
Das Netmon zieht vorallem an der Datenbank und die haben wir extra deswegen ausgelagert. Von daher sehe ich da nicht so ein großes Risiko.
dito.
Zu den restlichen Punkten kann ich nur ganz allgemein Anmerken, dass jedes zusätzliche Tool und jeder mechanismus Arbeit mit sich bringt die wir irgendwie wuppen müssen. Von daher vllt. einmal drüber meditieren obs wirklich notwendig oder einfach nur nice2have wäre.
+1
LG Tarek
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
picard -
Stefan -
Stefan || Freifunk Osnabrück