close Warning: Can't synchronize with repository "keplertools" (/srv/svn/keplertools does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#888 closed Verbesserung (erledigt)

Satz von IP-Adressen für die USB-Livesysteme / IPs der LtspServer

Reported by: Rüdiger Kupper Owned by: Rüdiger Kupper
Priority: bald erledigen Milestone: Schuljahr 2012/13
Component: Server: LTSP-Setup-Skript Severity: beeinträchtigt den Unterricht einiger Lehrer
Keywords: Cc: bau

Description

Wir haben derzeit vier USB-Live-Systeme zum Aufsetzen der LtspServer in Betrieb. Es wäre hilfreich, wenn diese vier Livesysteme fest vergebene IP-Adressen hätten. Diese IP-Adressen sollten im Bereich liegen, der auf den paedml zugreifen kann.

Vorteile
  • Wenn ssh-Zugriff auf den paedml möglich ist, kann man auf das svn-Repository zugreifen.
  • Wenn die Live-Systeme individuelle IPs haben, kann man sich von außen auf das Livesystem einloggen und das Aufsetzen steuern.

=> Ich hätte gerne vier freie IPs, die ich unseren vier USB-Livesystemen verpassen kann. Die IPs müssen für den ssh-Zugriff auf den paedml feigegeben sein.

Change History (23)

comment:1 by bau, 14 years ago

Bitte die IP des jeweiligen Servers verwenden ansonsten müssten wir die IP's in der Firewall freischalten.

comment:2 by Rüdiger Kupper, 14 years ago

Probleme:

  • Spätestens beim Aufsetzen eines neuen (zusätzlichen) Servers braucht man eine eigene IP, weil ja alle existierenden Server dabei weiterlaufen.
  • Ich fürchte, dass wir damit IP-Konflikte heraufbeschwören. So habe ich ja gestern die IP des ltsp3 in den Network-Manager des verwendeten USB-Sticks eingetragen. Sollte ich vergessen, das von Hand wieder rückgängig zu machen, so würde das Livesystem beim nächsten Boot von diesem Stick wieder mit der IP von ltsp3 ins Netz gehen, was keine gute Idee ist.

Das würde man vermeiden, wenn die vier Live-Systeme der USB-Sticks eigene IPs bekämen.

comment:3 by bau, 14 years ago

OK, ist einleuchtend.
Vielleicht vergeben wir dann den ltsp auch mal irgendwie sinnvollere IP's,
Wir könnten für die Server den Bereich 10.32.2.X verwenden:

ltspX bekäme dann 10.32.2.X
die Sticks könnten 10.32.2.[201-204] haben

Das alles sollte dann /etc/init.d/linuxmuster-base eingetragen werden (habe ich schonmal proforma eingetragen - du kannst es also auf den ltsp testen).

comment:4 by Rüdiger Kupper, 14 years ago

Super!

comment:5 by Rüdiger Kupper, 14 years ago

Es sollte ja genügen, auf den LtspServern in der /etc/network/interfaces die neuen IPs einzutragen, oder?

comment:6 by bau, 14 years ago

Das ist der eine Ort.
Auf dem paedml ist aber mindestens in der dhcpd.conf der andere Bootserver einzutragen.
Du kannst es ja mal an einem ltsp-Server probehalber eintragen.

comment:7 by Rüdiger Kupper, 14 years ago

Ah, stimmt, danke.
Ich würde in dem Zug dann auch die /etc/hostname so ändern, dass die Rechner wirklich ltsp1-7 heißen. Die alten Bezeichnungen (ltsp118, LTServer128a, etc) können wir dann abschaffen.

comment:8 by bau, 14 years ago

Habe den Stick grade zum Plattmachen einer Festplatte in einem alten ltsp gebootet. Werde diesem Stick jetzt die IP 10.32.2.201 verpassen und draufschreiben.

comment:9 by Rüdiger Kupper, 14 years ago

Gut. Ich verfahre mit den anderen drei Sticks auch so (habe ich hier zuhause).

comment:10 by Rüdiger Kupper, 13 years ago

Status: new → accepted

comment:11 by Rüdiger Kupper, 13 years ago

Die LtspServer haben per changeset:533/keplertools jetzt die einheitlichen Hostnamen ltsp{1,2,3,4,5,6}.
Auch die include-Files wurden entsprechend umbenannt.

comment:12 by Rüdiger Kupper, 13 years ago

So, jetzt stimmen die "router" und "next-server"-Einträge auch :-) changeset:536/keplertools.

comment:13 by Rüdiger Kupper, 13 years ago

Resolution: → erledigt
Status: accepted → closed

Die LtspServer haben nun die IPs 10.32.2.{1,2,3,4,5,6,7}.

comment:14 by Rüdiger Kupper, 13 years ago

Summary: Satz von IP-Adressen für die USB-Livesysteme → Satz von IP-Adressen für die USB-Livesysteme / IPs der LtspServer

comment:15 by Rüdiger Kupper, 13 years ago

Nagios weiß noch nicht über die neuen IPs bescheid.

comment:16 by Rüdiger Kupper, 13 years ago

Nagios-Konfig geändert per [542/keplertools].

comment:17 by bau, 13 years ago

Ich habe noch die Konfiguration der .ssh/config angepasst und altes rausgeschmissen.

comment:18 by Rüdiger Kupper, 13 years ago

Wozu wird denn das identity-File "auto_dsa" benötigt (erstellt für Nutzer root@paedml)? Das gab es früher nicht, oder?

comment:19 by bau, 13 years ago

Das habe ich mal erstellt, um ohne Passwort vom paedml auf die anderen Hosts zu kommen.
Ich finde das kein Manko, da ich zuerst mal auf den paedml kommen muss, und das geht nur mit einem gültigen Schlüssel und nur für root, bau, kup und kau. Wenn man drauf ist, dann kommt man auch auf die anderen Server.

Wir könnten mit Umstieg auf die linuxmuster.net dann mal neue Schlüssel erzeugen und diese dann eindeutig verwenden, also einen für root, mit dem der dann überall hinkommt, einen für bau, kau, kup.

ToDo: auf die ltsp-Server kann man sich per Passwort einloggen, kann man das für root und linadmin verbieten (für die anderen User muss das ja so sein, sonst können die sich nicht mehr einloggen)

in reply to:  19 comment:20 by Rüdiger Kupper, 13 years ago

Replying to bau:

Das habe ich mal erstellt, um ohne Passwort vom paedml auf die anderen Hosts zu kommen.
Ich finde das kein Manko, da ich zuerst mal auf den paedml kommen muss, und das geht nur mit einem gültigen Schlüssel und nur für root, bau, kup und kau. Wenn man drauf ist, dann kommt man auch auf die anderen Server.

Das heißt, dieser Schlüssel hat eine leere Passphrase? Sowas vermeide ich eigentlich prinzipiell. Es unterläuft ja eins der Sicherheitsfeatures von SSH. Zwar hast Du Recht, dass man erst einmal auf dem paedml sein muss, um den Schlüssel nutzen zu können. Aber dann kannst Du auch gleich den "richtigen" root-Schlüssel nehmen, und lieber den ssh-agent verwenden, um die Passphrase zu cachen. Das ist immer noch sicherer, als ein Schlüssel ganz ohne Passphrase.

in reply to:  19 comment:21 by Rüdiger Kupper, 13 years ago

Replying to bau:

Wir könnten mit Umstieg auf die linuxmuster.net dann mal neue Schlüssel erzeugen und diese dann eindeutig verwenden, also einen für root, mit dem der dann überall hinkommt, einen für bau, kau, kup.

Ich verwende bereits einen einzigen ssh-Schlüssel, der mich als Person eineindeutig identifiziert. Überall, wo ich mich per ssh einloggen will, ist dieser eine Schlüssel hinterlegt.
Für jeden Nutzer sollte es genau einen Schlüssel geben.

in reply to:  19 comment:22 by Rüdiger Kupper, 13 years ago

Replying to bau:

ToDo: auf die ltsp-Server kann man sich per Passwort einloggen, kann man das für root und linadmin verbieten (für die anderen User muss das ja so sein, sonst können die sich nicht mehr einloggen)

Kling sinnvoll. Das kann man sicher in der ssh.conf der Maschine festlegen, oder?

comment:23 by bau, 13 years ago

OK, Denkfehler: linadmin soll sich ja auch an den Terminals anmelden können!
Ich habe dann gefunden unter ​http://www.leetperium.de/2012/06/ssh-mit-public-key-authentication-sichern/:

Für einzelne Benutzer-Accounts kann die Passwort-Authentifizierung auch einfach deaktiviert werden:

passwd -l [username]

Dann geht halt der Befehl su auch nicht mehr und wir müssten, wenn wir als linadmin drin sind wieder sudo verwenden (Ist das nicht dasselbe, wie wenn man root wie unter Ubuntu eingestellt gar kein Passwort gibt?)

Ah jetzt: unter ​http://serverfault.com/questions/109768/sshd-restriction-per-user-basis finden sich Einstellmöglichkeiten für den sshd:

   PermitRootLogin without-password

Damit kann sich root nur noch mit key einloggen (Eine gute Quelle ist auch man sshd_config) :-)

Ich setze das gleich mal um - prima, das klappt (root erhält nun nach Passworteingabe: permission denied) -> erledigt!

Note: See TracTickets for help on using tickets.