-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV103YAAoJEIu3uYB6vkH46VsQAIQMXN+pv/wCmuSq107lAJWs 9Zad4cOl309pXobwa+Y7OfFznORs30EoTSm1n7QlFhO60D/C39KkJX6nyPfI7jSV SgZPU9H60Rn3TaRBFmTzR0LeRmWCuq/9nCG1IaatXTWKdW/AzOBAeMCSOrJLmn9m 1lX+KXvxV5FThWHU9DDhRVWrynISmwDVLERVY+kQJUoYzBRKh5AAeM9ln2Fl6Uil OO3CAnegZUAN0884eigNfOxg1Z56qkvTDbTirvAWItD6vU9gKEEFspSHtJqftUnv w2nrJKgCKXsfpJ+hIWuZWEAgoyndTpN8Oax+UboqsvTHUpLC579gTFcbIx1+t9ZQ suw6hhszCLUIkM+biSIGxJRimn8D6GbH2PTK3J8/4+gCHT33LZEfz6UEO9PL5eTo OxyuTSYtrxdWfpsyyVlaDfvwLBWn3vNvgv+LXjWsIayFWaGeZuN9RqaPQ0FYuWsK hC9r+nrS/IWdip7Ns1DyY1c0WLHEWfZJHQ53mCPnhUj/vVNDzlC8aSJlCzWdFsTF yAj1nXHzvQAymYmFg/yBcXC0lwEATIT8vdaV9QGl0Y2O8uF698PFIebn+TIImJ50 RvwnpIeI906AnxwVsgJbJXZKmX/JpM8CSWLA/olZblClD8lDIZerC24KMvj8RBbQ yB0LopT9zsUTQv7WmgGC =+EPP -----END PGP SIGNATURE-----
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. -- gruß pic @ME https://wiki.nordwest.freifunk.net/picard
-----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.
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
"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... 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJV2wcHAAoJEIu3uYB6vkH4C/4P/2tpxAGjq8fyVz0nhFhBLVxr CWlrx8W/lh80HFpCaogLEnvyvqhSMLcTsLvUvy2ZAVhgpKef1mrxhnAxeaFhe3MB Ze35oZ9DA+rLyMf3Eh/ak2IVbTe4okfDPsFV/3/qWFsTWiYKvz4tOBWMOez/IUlK BQRP2ioqWbcNpt3OoCx6+1FTmcwRwSN4P8HNr16P30X4XzUKfMtTLU8eulzR7+Qu WLbvbTeoymRUdXUMWWcAiLbnNrQ5fOy7JS0OMnhn9LyFIjLvFJMvUIM7Yb5q/Fqa 02hJoWyM8rF2iv0VzWkignhzIiOKEVcOERR8hsu2B1++TV18q0Eu8Y2SVlQKfgd5 +YKqJ66oFM6Y+4Bd0XaquUImoho5k8a/REeNPiAFMePY4BvqgiZdplPScBEu4NE+ qq8Bh1iaYE52jMTYosyTiSK1KQlSnzCXeU1KujEH9L73rdnHDJ//uAHzz+35Cr2c QKJVv5+9eEXMDLzf56OsRbjjtMS5bvOvg36JK4GSYehcccTsGwIMKX22I6loGxSV w6YrEp8v5vI3V9B7xxPhB4Z0zr0WlpDyi37mQlsQye5NL6rJuoDc3Qn7gbw5FECj V9Qr68SIxCfFmTnKuzyC9ByiI51g56aRejVwHfWWOu+PV4OQNQD02a8Ug3jMOSGz flzxVy8/2urPyd0zqOSk =fGKs -----END PGP SIGNATURE-----
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? -- gruß pic @ME https://wiki.nordwest.freifunk.net/picard
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?
-- Viele Grüße, Stefan
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/ -- gruß pic @ME https://wiki.nordwest.freifunk.net/picard
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. -- xmpp bjo@schafweide.org
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.
-- Viele Grüße, Stefan
-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV3HrqAAoJEIu3uYB6vkH4WbkQAIPdetHO8vl/WB+QQ62npj8q 7+G+dt7OKur3GrGBAWHtAbDpiCmTvrUnNqNg0n2nK9TiTzinLYGesP6AGyUtqKQ5 Xq9YCwMTvO/TT8JBq8s1P040fiIdU4R7FjU0rxEm1qRT77eqOETyDfo/PuwNw1b/ eb2mKjN+6EjuLv3CcljOfR3P3RepnfFQPPh4H16VUfHPCX0UiJnHonF/84tAECgF uuhaJdv0SLca2fj1E4ZCXMb+HU9HhE0cs3U2aqKbGy27sRH1gJ88gtdiDPsR0CjQ w2sLOLuRfRZIaLbPmh6l/Pp8s7BI8VlXFsLqnd3X/w6v0j2Sth2ys9fM/k9/FKyT n+awY+YsXv6OhmwOf4Xq+tcJ4FaDkA4kgg3TS274h+7nHB1XkXOLHnxXKWLSxVw1 aX+6xSVyEn0/+7iycrPr6+arov7CF/DzUfBjf0utafuTKv9bqU3d/X0hpzfB59P1 ypBdvUW8mZYaZPGW5DEIXcl15q6MsPoTaOaSUZIWivW4KIQX75rXnn6MhcdS6P5l n2Hgo05BKkPKLVv8nnGRaapkAVtiEgl5SVqVvQQzG9SiIJKG4q29HTWdUjQJ99ql jREzeqfWT8oaoN5psE9YqLOjF7iaQno78WDxcpbzIEbkRmqGJ315FZd5FI6IUuc5 YMELqUO/AmsZKLkWPgkZ =aKoB -----END PGP SIGNATURE-----
participants (5)
-
Bjoern Franke -
Eike Baran -
Eike Baran -
picard -
Stefan