-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hallo,
ich denke, wir sollten langsam mal sehen, dass wir mit den Puppet-Planungen vorankommen; Ich habe mich in den vergangenen wochen zumindest ansatzweise dort eingearbeitet und im /etc/puppet/environments/dev-Environment auf unserem puppet.ffnw.de erste Module angelegt: ffnwbase (user ffnw+ ssh-keys für admins), screen und sudo.
Um nun sinnvoll weiter zu machen, sollten wir uns überlegen, wie wir die konfiguration(en) managen und backupen. Der Vorschlag von Felix war ja - wenn ich mich recht entsinne, die dev-Umgebung zum eigentlichen entwickeln zu nutzen und bei Abschluss von Veränderungen die Änderungen in ein Git-repo und in die production-Umgebung zu pushen. Hab ich das so korrekt in Erinnerung und wollen wir es auch so machen?
Und: Welche Pakete und Einstellungen brauchen wir auf den Supernodes und wo unterscheiden sie sich zwischen den jeweiligen Nodes (Ip-adressen, hostnames, vpn-keys,...?)
Viele Grüße, Eike
Zitat von Eike Baran derbaranator@gmail.com:
ich denke, wir sollten langsam mal sehen, dass wir mit den Puppet-Planungen vorankommen; Ich habe mich in den vergangenen wochen zumindest ansatzweise dort eingearbeitet und im /etc/puppet/environments/dev-Environment auf unserem puppet.ffnw.de erste Module angelegt: ffnwbase (user ffnw+ ssh-keys für admins), screen und sudo.
das liest sich schon mal sehr gut.
user ffnw ist/soll ein generischer user sein auf allen hosts. user verwaltung fehlt dann noch, die admins sollen nicht alle ffnw user nutzen.
Um nun sinnvoll weiter zu machen, sollten wir uns überlegen, wie wir die konfiguration(en) managen und backupen. Der Vorschlag von Felix war ja - wenn ich mich recht entsinne, die dev-Umgebung zum eigentlichen entwickeln zu nutzen und bei Abschluss von Veränderungen die Änderungen in ein Git-repo und in die production-Umgebung zu pushen. Hab ich das so korrekt in Erinnerung und wollen wir es auch so machen?
wieso überlegen? wir hatten uns, wie wir beim treffen waren, auf git geeinigt. dies backupen wir mit rsnapshot.
Und: Welche Pakete und Einstellungen brauchen wir auf den Supernodes und wo unterscheiden sie sich zwischen den jeweiligen Nodes (Ip-adressen, hostnames, vpn-keys,...?)
wir benötigen eine gemeinsame ffnw OS host basis. und dann für die einzellnen einsatzsenarien module.
gibt es hier jemanden der in firewall fit? ist, wir müssen den puppet master server absichern!.
pad.ffnw.de <- brainstorming pad erstellen. feel free
ich habe noch nicht mit puppet angefangen.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
user verwaltung fehlt dann noch, die admins sollen nicht alle ffnw user nutzen.
sehe darin noch immer keinen echten vorteil für uns...
Um nun sinnvoll weiter zu machen, sollten wir uns überlegen, wie wir die konfiguration(en) managen und backupen. Der Vorschlag von Felix war ja - wenn ich mich recht entsinne, die dev-Umgebung zum eigentlichen entwickeln zu nutzen und bei Abschluss von Veränderungen die Änderungen in ein Git-repo und in die production-Umgebung zu pushen. Hab ich das so korrekt in Erinnerung und wollen wir es auch so machen?
wieso überlegen? wir hatten uns, wie wir beim treffen waren, auf git geeinigt. dies backupen wir mit rsnapshot.
"wir machen das mit git" ist aber auch noch nichts, was irgendwie eindeutig ist. Mir ging es eben darum, wie das im Detail organisiert werden soll, ob die production- direkt an die dev-umgebung beim commit gekoppelt werden soll, ob wir mehrere branches nutzen, die wir ggf entsprechend mergen und dann produktiv einsetzbare versionen taggen oder wie auch immer...
Und: Welche Pakete und Einstellungen brauchen wir auf den Supernodes und wo unterscheiden sie sich zwischen den jeweiligen Nodes (Ip-adressen, hostnames, vpn-keys,...?)
wir benötigen eine gemeinsame ffnw OS host basis.
dafür habe ich das ffnwbase-modul angelegt...
und dann für die einzellnen einsatzsenarien module.
...dafür könnte man dann ein z.B. ffnwsupernode-modul, welches dann im wesentlichen eine art meta-modul für die benötigten packages und configs ist, aufstellen...
gibt es hier jemanden der in firewall fit? ist, wir müssen den puppet master server absichern!.
sollte mittelfristig geschehen, da wir bisher aber noch keine private-keys und sonstigen sensiblen kram unbeschränkt "an alle" puppet-agents verteilen, brennt mir das jetzt nicht so unmittelbar den nägeln..
pad.ffnw.de <- brainstorming pad erstellen. feel free
okay: https://pad.ffnw.de/p/puppet
ich habe noch nicht mit puppet angefangen.
Zitat von Eike Baran eike.baran@uni-oldenburg.de:
user verwaltung fehlt dann noch, die admins sollen nicht alle ffnw user nutzen.
sehe darin noch immer keinen echten vorteil für uns...
ich verstehe nicht wieso du das immer wieder fragst?
um ein paar zu nennen + verschiedene arbeits umgebungen (programm configs) + verschiedene shells + eigene history + eigenes /home/foobar
Ein Mehrbenutzersystem oder Multiuser-System ist ein Betriebssystem, das die Fähigkeit hat, Arbeitsumgebungen für verschiedene Benutzer bereitstellen und voneinander abgrenzen zu können.
login als user und "sudo -i", was hindert dich?
Bin ich auf Eikes Seite, leider passieren seit dem Usersystem komische Dinge..
@srv06: zsh: corrupt history file /home/stefan/.zsh_history zsh: corrupt history file /home/ffnw/.zsh_history
Am 24.08.2015 um 16:28 schrieb picard:
ich verstehe nicht wieso du das immer wieder fragst?
Zitat von Stefan stefan@osnabrueck.freifunk.net:
Bin ich auf Eikes Seite, leider passieren seit dem Usersystem komische Dinge..
@srv06: zsh: corrupt history file /home/stefan/.zsh_history zsh: corrupt history file /home/ffnw/.zsh_history
du hast dein history file kapput gemacht, was hat das mit user verwaltung zu tun? schau mal mit einem edior in dein file ^^
hier eine der lösungen um das zu fixen http://marcparadise.com/blog/2013/09/21/how-to-fix-a-corrupt-history-file/
Am Montag, den 24.08.2015, 16:52 +0200 schrieb Stefan:
Bin ich auf Eikes Seite, leider passieren seit dem Usersystem komische Dinge..
@srv06: zsh: corrupt history file /home/stefan/.zsh_history zsh: corrupt history file /home/ffnw/.zsh_history
Das liegt an unsauberen Reboots.
Ah okay. Grade mal folgende Idee gehabt: Wie wäre es, wenn wir kurzfristig den 09 ans Netz anbinden und den mit in die FW aufnehmen? Hier mal nur 50 Peers drauf laufen lassen und schauen, wie sich die Kiste verhält?
04 mit 75 peers hat bspw. keine reboot Probleme..
Am 24.08.2015 um 18:14 schrieb Bjoern Franke:
Das liegt an unsauberen Reboots.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
- verschiedene arbeits umgebungen (programm configs)
das wäre in dem Fall auf der Shell vermutlich nur die Einstellung ob vim dir Zeilennummern anzeigt oder nicht?
- verschiedene shells
okay, kann sinnvoll sein, ist mir pers. aber recht wumpe, zur not tippe ich einmal bash oder zsh oder so ein, wenns mir auf die Nüsse geht
- eigene history
empfinde ich eher als Nachteil, wenn man mal zwecks Fehlerbehebung auf die Kiste guckt und sehen will, was vorher so gemacht worden ist.
- eigenes /home/foobar
für was?
Ein Mehrbenutzersystem oder Multiuser-System ist ein Betriebssystem, das die Fähigkeit hat, Arbeitsumgebungen für verschiedene Benutzer bereitstellen und voneinander abgrenzen zu können.
jo. Und das macht für mich vor allem dann Sinn, wenn man verschiedene reale Benutzer mit verschiedenen Use-Cases/Arbeitsabläufen. Find das hier einfach n bisschen unnötig und ich habe - das mag aber auch ne wissenslücke sein - keine ahnung, warum wir überhaupt nen anderen user als root benötigen? Ein unbeschränktes sudo hat doch quasi dieselben potenziellen Sicherheitsrisiken?! Kann mir das wer erklären?
Gruß, Eike
-
Bjoern Franke -
Eike Baran -
Eike Baran -
picard -
Stefan