Liebe Mitstreiter,
zusammen mit einem Kollegen versuche ich (später unter den Hamburger Bedingungen …) lmn 7 zu installieren. Wir haben zwei XCP-ng Hosts installiert. Auf beiden konnten wir alle VMs zu irgendeinem Zeitpunkt aktualisieren. Mit dem XCP-ng selbst geht dies in unseren beiden Umgebungen nicht mehr.
Bei mir kann ich vom XCP-ng Host aus nur noch ein ping auf Adressen in 10.0.0.0/16 absetzen, nicht jedoch auf 10.0.0.254. Demzufolge läuft yum update nicht mehr. server kann dagegen raus und apt update läuft. Mein Admin-PC mit 10.0.0.10 hat ebenfalls Internetzugang.
Desweiteren bekommt ein Client zwar per PXE eine/die richtige IP, linbo (2.3.49-0) jedoch keine. Deshalb habe ich noch keinen Client.
Ich konnte opsi und docker bei derErstinstallation von server einbinden.
Beim Kollegen läuft linbo hingegen einwandfrei, jedoch kommt sein Client nicht ins Internet.
Er konnte weder docker noch opsi bei der Erstinstallation von server einbinden.
Meine erste Idee wäre ein oder mehrere Tippfehler irgendwo bei Gateway oder Subnetzmaske. Habe aber noch keinen gefunden.
Any Ideas?
Gruß Jürgen
Hallo Jürgen,
Desweiteren bekommt ein Client zwar per PXE eine/die richtige IP, linbo
(2.3.49-0) jedoch keine. Deshalb habe ich noch keinen Client.
setz mal dhcpretry hoch: ich würd mal mit 7 anfangen.
Beim Kollegen läuft linbo hingegen einwandfrei, jedoch kommt sein Client
nicht ins Internet.
Per Default ist der WebProxy auf der OPNsense an und funktioniert
mittels SSO: also kommen nur an der Domäne angemeldete Nutzer raus (also
nicht der lokale admin).
Willst du, z.B. zum Installieren/updaten, auch mit dem lokalen Admin
raus, mußt du in OPNsense erst mal die vorgefertigte Regel „alle dürfen
Raus LAN“ aktivieren.
Das geht unter Firewall/Rules/LAN
Nach dem aktivieren noch die Firewall reloaden (es erscheint ein Knopf
oben).
Er konnte weder docker noch opsi bei der Erstinstallation von server
einbinden.
wie sah das „konnte nicht“ den aus?
Haben sie die richtigen IPs gehabt? Konnten sie Server/Firewall anpingen?
LG
Holger
Ob das was bringt, teste ich ggf. später. Der “Übeltäter” war mein
nagelneuer Gigabit Smart Switch! Mit einem alten Fast Ethernet
WLAN-Router als Switch geht es.
Mal sehen, ob die (bald ebenfalls durch Gigabit-Technik zu
ersetzenden …) Cisco Switches in der Schule später auch solchen
Stress verursachen. Während lmn 6.2 in meiner alten Schule noch in
Betrieb war, hab ich so was jedenfalls nicht gesehen und mit IServ
auch nicht.
Das hatten wir beim Kollegen mit der ersten Regel gemacht. Aber
vielleicht nicht (erfolgreich) übernommen …
Dazu hat mich das Webinterface aufgefordert. yum update geht bei mir
mit den beiden deaktivierten und aktivierten Regeln jetzt wieder.
Die Regeln wurden demnach bei der Erstinstallation gesetzt, denn
zuerst ging es ja?
Ganz merkwürdig. Wenn beide eingerichtet werden sollten scheiterte
der Schlüsseltausch mit 10.0.0.3, wenn nur opsi, dann der mit
10.0.0.2. Ping war zu beiden möglich.