Linuxmuster 7 Neuinstallation

Server Firewall
1

Hallo zusammen,

ich bin neu hier, im Forum sowie auch in der Nutzergemeinschaft der linuxmuster.net.
Toll, was hier für open source geleistet wird. Vielen Dank.

An der Grundschule meiner Frau (Bayreuth, BY) kümmere ich mich um die Systemadmin. Als Serverlösung habe ich mich nach einiger Recherche für linuxmuster entschieden.

Nachdem es eine kplt. Neuinstallation wird, fiel die Wahl gleich auf die 7er Version.

Mittlerweile hat sich doch ein großer Fragenberg aufgetan, auch und vor allem weil wir auch in Bayreuth (Gruß nach Hamburg :wink: ) an eine TimeForKids-Vorgabe gebunden sind.

Mein anfängliches Vorhaben, die vorgegebenen IP-Bereiche an unsere bisherige Installation anzupassen, habe ich schon wieder etwas aufgegeben. Mal sehen, ob’s mir noch gelingt.

Im Moment muss/soll erstmal die Standardversion laufen. Allerdings bereitet mir hier die opnsense große Probleme.
Das Setup sieht folgendermaßen aus (Netz steht alles auf Standard):
Virtualisierer XCP-ng Version 8.0 (Verwaltungs-IP 192.168.1.201)
Als *.xva importiert:
lmn7-server
lmn7-opnsense
lmn7-opsi
lmn7-docker

Pings und Zugriff soweit über Konsole etc. alles möglich.
Allerdings startet/bootet mir die opnsense völlig unreproduzierbar ständig neu - mal unmittelbar, nachdem sie gebootet hat, mal nach 2 Minuten, mal nach 15 Minuten.
Ich kriege somit nichtmal die Updates der anderen VMs durch.

Was liegt da im argen? Wer würde bzw. könnte mir mit einem Lösungsansatz weiterhelfen.
Oder ist die gepackte xva fehlerhaft?
Ich habe die VM schon mehrmals gelöscht und wieder importiert, die Reboots sind auch völlig unabhängig von jeglichem Konfigurationszustand.

Freue mich auf Antwort und mögliche Hilfe.
Eigentlich kann ich erst weitermachen, wenn ich opnsense stabil bekommen habe.

Viele Grüße aus Bayreuth
und schonmal tausend Dank vorab,

Andreas (Dietel)

2

Hallo Andreas,

hier ist Hamburg :wink:

Wenn Ihr wie wir die Tfk-Box verwenden müsst, heißt das ja nicht, dass
man Euch wie uns auch noch vorschreibt, welche(s) IP-Segment(e) die
Schnittstelle GRUEN bekommt. !92.168.1.x deutet darauf hin, dass Du
GRUEN auf 10.0.0.254 ändern dürftest. Danach müsstest Du natürlich alle
Firewallregeln prüfen.
Wenn Du keinen Zugriff auf die Box haben solltest, macht die Umstellung
eventuell der Time for Kids Support für Euch?

OpenSense musst Du nicht unbedingt mit installieren. Bei
linuxmuster-setup kannst Du angeben, ob die Firewall mit konfiguriert
werden soll oder nicht. Was nicht oder nicht gut funktioniert: Die
TfK-Box und OpenSense kaskadieren. Du verlierst natürlich einige
Features der lmn, wie z. B. die Internetfreigabe, wenn kein
administrativer Durchgriff auf die Firewall besteht.

Falls Du weiterhin den Adressbereich 192.168.1.0/24 verwenden willst
oder musst, schicke ich Dir gern per PN meine Mitschrift, was ich in
lmn6.x alles ändern musste. Daran hat sich mit lmn7 (leider) kaum etwas
geändert. Testen konnte ich das bislang allerdings nur zu Hause mit
meinem „TfK-Box-Nachbau“ ipfire …

Gruß Jürgen

3

Hallo a_dietel,

Grüße in den Süden! :slight_smile:

Mit dem Befehl shasum -c lmn7-opnsense-*.ova.sha kannst du schauen, ob das xva korrekt ist.

Wenn die VMs unmotiviert rebooten (apropos: welche Virtualisierung nutzt du?), würde ich mal schaun, was die log-files so sagen. In /var/log/system.log auf der opnsense sollte ein wenig darüber stehen, warum die herunterfahren. Bei mir steht bei einem ordentlichen reboot:

Dec 20 09:39:55 firewall shutdown: reboot by root:  
Dec 20 09:39:56 firewall syslogd: exiting on signal 15
...

Das Booten beginnt mit ein paar Copyright-Meldungen:

Dec 20 10:45:56 firewall kernel: Copyright (c) 2013-2018 The HardenedBSD Project
.
Dec 20 10:45:56 firewall kernel: Copyright (c) 1992-2018 The FreeBSD Project.
Dec 20 10:45:56 firewall kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
...

Sollten die auftauchen, ohne dass irgendwie ein ordentliches shutdown gelogged wurde, wurde die VM wohl von aussen ausgeschaltet oder resettet. Dann kannst du im Host-System schauen, ob da Hinweise in /var/log/syslog oder (für die KVM Virtualisierung) in /var/log/libvirtlibvirtd.log zu finden sind.

4

Hallo Jürgen, hallo mdt,

ich wollte nicht unhöflich sein und entschuldige mich dafür, dass ich erst jetzt wieder ein Lebenszeichen von mir gebe. Aber es war die Woche einiges los und die restlichen Stunden hat mich linuxmuster beschäftigt … :wink:

Vielen Dank für eure schnellen Antworten vergangene Woche. Leider waren sie trotzdem nicht zielführend - die opnsense macht immer noch, was sie will.

Wegen der Prüfsummen - die hatte ich schon geprüft. Ich wollte eher mal anfragen, ob die basierende Installation, aus der die VM erstellt wurde, vielleicht nicht ganz korrekt ist. In den Log-Dateien findet sich nichts - zumindest nichts, was mir ins Auge sticht.
Fehlermeldungen oder -hinweise betreffen das DVD-Laufwerk, wiederholen sich im Sekundentakt. Deshalb habe ich dann danach gegoogelt und diverse Berichte zu Problemen des zugrundeliegenden FreeBSD mit AMD-Plattformen gefunden. Aber keinen konkreten Lösungsansatz.

Kann es trotzdem daran liegen? Welche Serverhardware verwendet ihr? Mein System war ein Gigabyte GA-3CESL mit Quad-Core AMD Opteron 2373 (was eine defekte CPU kommentarlos durchgeschleppt hat). Mittlerweile habe ich auf ein Supermicro H8DME gewechselt mit ansonsten identischer, aber funktionierender Ausstattung. Gleiche Probleme. Allerdings bootet sie mittlerweile nach einigen Änderungen hin und her im BIOS (meist) in einem Rutsch durch, vorher nahm sie ja 3 bis 5 Bootanläufe, bis sie überhaupt mal auf die Login-Seite kam (vorher Abbruch bei Initialisierung OpenSSL, webGUI, etc.). Längste Standzeit war vorgestern 1h 40min. - dann wieder Reboot. Ich habe unzählige Male neu installiert oder die VMs importiert und weiß langsam nicht mehr weiter.

Nun gut, heute wieder Erstkonfiguration unter ‚skip Firewall‘, Netzwerk habe ich komplett an die Vorgabe 10.0.0.0/16 angepasst und TFK auf die IP 10.0.0.254 (Firewall) konfiguriert.
Soweit läuft alles. Jetzt habe ich vorhin nur schnell noch versucht, einen Client via Linbo PXE-Boot hochzuziehen. Scheitert allerdings an der Stelle, wo er Konfigurationsdaten von 10.0.0.254 (also der Firewall) nachladen will.
Was muss ich denn diesbezüglich in TFK einstellen bzw. ändern?
Oder benötige ich für Linbo zwingend die opnsense - dann muss ich die Konfiguration halt nochmal mit dieser durchgehen und hoffen, dass sie eine Stunde erreichbar bleibt.
Allerdings ist sie bei mir weit von einem produktiven Einsatz entfernt.

Puh, langer Text. Freue mich aber wieder über jede Antwort.

Viele Grüße aus Bayreuth

Andreas

5

Ich hatte nach Hardwarewechsel auch unangemeldete Reboots. Die Dinger sind einfach gestorben, weil kein Speicher mehr da war. Habe einfach ein großes Swapfile im Host erzeugt und nun laufen sie durch.

6

Hallo mdt,

danke für die Rückmeldung.

Daran kann’s aber leider nicht liegen. Die Reboots hatte bzw. habe ich ja von Anfang an, also schon unter der Installation auf dem Gigabyte-Board (nur noch viel schlimmer, als momentan - da dauerte ja der Bootvorgang schon ewig und die Firewall war maximal 15min. up, dann sofort wieder reboot).
Dann Wechsel auf das Supermicro-Board, da klappte schon der Systemstart als solcher nicht - dadurch habe ich die defekte CPU gefunden - die hat das Gigabyte-Board überhaupt nicht gestört oder bemerkt!?! Ich hatte mich nur gewundert, dass alles so langsam und zäh vonstatten ging.

Also XCP-ng neu auf dem Supermicro installiert, opnsense-VM importiert, bootet glatt durch - ich dachte schon, ich wäre am Ziel. Aber auch jetzt immer wieder Reboots mit den gleichen Einträgen in system.log, etc. Nur erfolgen die Reboots jetzt etwas später (sie ist meistens eine halbe Stunde bis bisher maximal 1h40min. up) und meistens laufen sie glatt durch - war vorher ja auch komplett anders.

AMD? Keine Ahnung.
Ich sitze grade zuhause und installiere auf einer Intel-Basis - ist nur ein PC mit Core2Duo, aber zum Test reichts, denke ich. Bin mal gespannt.

Zum Linbo-PXE-Boot:
gestern, unterwegs auf der Autobahn, kam mir plötzlich die start.conf wieder in den Sinn. Da werde ich nachher nochmal alles durchforsten, woran der nicht funktionierende Start liegen kann.
Nur eine Frage schnell noch vorab:
Ich habe in irgendeinem anderen Beitrag gelesen, die Clients dürfen über Linbo-PXE zunächst nur eine andere IP bekommen, als dann das tatsächliche System nutzen soll.
Richtig so? Und gibt es da eine Vorgabe, welche IPs in Linbo das sein sollen?

Gruß

Andreas

7

Hallo zusammen,

gleich noch ein Nachtrag.

Testweise habe ich opnsense jetzt bei mir zuhause unter XCP-ng auf einem Intel-Rechner installiert. Software also wie in der Schule.

Firewall bootet glatt durch, Login, Update (Menü 12) gemacht - erster großer Unterschied: das Update hat sofort auf die aktuelle Version 19.7.9_1 aktualisiert. In der Schule nie, da blieb die Version auf 19.7.1 stehen, obwohl Pakete heruntergeladen und installiert wurden. Das Upgrade musste ich händisch per bootstrap machen.

Jetzt muss ich zur Vergewisserung nochmal fragen:
hat jemand das Ganze auch auf einer AMD-Plattform laufen und funkioniert dort alles einwandfrei? Oder sind hier nur Intel-Server am Start?

Wenn AMD, dann kann die ganze Problematik doch nur mit dem TFK zusammenhängen, oder? Dann blockt der doch irgendwie schon das Update/Upgrade.
Ich habe den TFK hierfür aber auf Vollzugriff laufen, Filterregeln alle angepasst.
Dann muss ich den testweise - habe ich noch nicht versucht - komplett umgehen und mich mal direkt aufs Modem klinken.

Irgendwie muss dem doch beizukommen sein.

Gruß Andreas

8

Hallo,

Also XCP-ng neu auf dem Supermicro installiert, opnsense-VM importiert,
bootet glatt durch - ich dachte schon, ich wäre am Ziel. Aber auch jetzt
immer wieder Reboots mit den gleichen Einträgen in system.log, etc. Nur
erfolgen die Reboots jetzt etwas später (sie ist meistens eine halbe
Stunde bis bisher maximal 1h40min. up) und meistens laufen sie glatt
durch - war vorher ja auch komplett anders.

offensichtlich ist in deinem Server nciht nur eine CPU defekt gewesen.
Ich tippe zuerst auf den Speicher und sekundär auf die Platten.
Defekte CPU ist schon selten genug: da würde ich an einen
Überspannungsschaden denken.
Vielleicht haben ja auch die Netzteile einen Schlag.

AMD? Keine Ahnung.

es liegt nicht an AMD: dafür verwende ich deren Hardware schon zu lange.
6 Jahre lang Bulldozer Server mit kvm und jetzt seit einem halben Jahr
ein ryzen Server.

Zum Linbo-PXE-Boot:
gestern, unterwegs auf der Autobahn, kam mir plötzlich die start.conf
wieder in den Sinn. Da werde ich nachher nochmal alles durchforsten,
woran der nicht funktionierende Start liegen kann.
Nur eine Frage schnell noch vorab:
Ich habe in irgendeinem anderen Beitrag gelesen, die Clients dürfen über
Linbo-PXE zunächst nur eine andere IP bekommen, als dann das
tatsächliche System nutzen soll.
Richtig so? Und gibt es da eine Vorgabe, welche IPs in Linbo das sein
sollen?

ist ein Client dem server unbekannt bekommt er eine IP aus dem DHCP
Lease: also im Default eine aus 10.0.0.100-200
Der Bereich dient zur Rechneraufnahme.
Ist er registriert bekommt er unter linbo und im Zielbetriebsystem
natürlich imemr die selbe IP Adresse: die MAC Adresse ändert sich ja
nciht, nur weil ein anderes Betriebsystem läuft.

Es ist aber nicht so sinnvoll Bootprobleme am Client zu untersuchen,
wenn der Server nicht sauber läuft.

Wenn du die Bootprobleme untersuchen willst, dann mach einen neuen
Thread auf und beschreib möglichst genau welche Probleme du hast.

LG

Holger

9

Hallo,

Jetzt muss ich zur Vergewisserung nochmal fragen:
hat jemand das Ganze auch auf einer AMD-Plattform laufen und funkioniert
dort alles einwandfrei? Oder sind hier nur Intel-Server am Start?

ja: ich.
Die lmn7 läuft auf einem ryzen Rechner mit ASUS Mainboard.
16kerne 16GB RAM.
Seit den Sommerferien ist es eine lmn7 mit OPNsense.

Es liegt nicht an AMD, es liegt an deinem Server: und bei dem
Updateproblem eher noch an der Firewall davor.

LG

Holger

10

Hallo Holger,

vielen Dank auch für deine Antworten.

Vorausgesetzt, memtest ist verlässlich, dann ist der Speicher in Ordnung.
Überspannungsschaden schließe ich auch mal aus, ist jetzt auch ein Board drin, das schon Jahre bei mir Dienst in anderer Funktion getan hat, zuverlässig.
Und alles andere außer opnsense läuft ja auch stabil.

AMD also nicht, danke nochmal für die Bestätigung. Ich zweifelte so langsam schon an allem.

Dann richte ich meinen Fokus auf TFK.
Der fliegt jetzt aus der Konfiguration mal raus, Verbindung ins Net dann über meinen Draytek Vigor 165 oder eine andere FritzBox.
Bin mal gespannt, wie’s weitergeht.

Danke für die Hinweise zur IP-Vergabe von Linbo.
Sollte ich TFK beibehalten (muss ich ja wohl irgendwie, Vorgabe der Stadt), ist es also auch korrekt, wenn der DHCP dort auch 10.0.0.100-10.0.0.200 verwaltet.

Gruß Andreas

11

Hallo Andreas,

Vorausgesetzt, memtest ist verlässlich, dann ist der Speicher in Ordnung.

… In Ordnung kann man sagen, wenn memmtest mal über 12 Stunden
durchgelaufen ist: nicht nach einem Durchlauf.
Findet er bei einem Durchlauf Fehler, ist der Speicher hin.
Findet er keine, dann funktioniert er vielelicht …

Überspannungsschaden schließe ich auch mal aus, ist jetzt auch ein Board
drin, das schon Jahre bei mir Dienst in anderer Funktion getan hat,
zuverlässig.

… und das/die Netzteil(e)?

Danke für die Hinweise zur IP-Vergabe von Linbo.
Sollte ich TFK beibehalten (muss ich ja wohl irgendwie, Vorgabe der
Stadt), ist es also auch korrekt, wenn der DHCP dort auch
10.0.0.100-10.0.0.200 verwaltet.

das geht nicht!
Wenn du außen 10.0.0.0/24 hast, dann mußt du drinnen einen anderen
Bereich nehmen.
Lies die Doku hier:

Allein am IP Adressbereich kann es liegen, dass die OPNsense nicht raus
kam: wenn sie innen und außen den gleichen Bereich hat.

LG

Holger

12

Wieviel Speicher haben denn die beiden Boards?

13

Hallo Holger, hallo mdt,

vielen Dank für alle Hilfestellungen.
Hat lange gedauert, letztendlich ist es zumindest serverseitig gelöst.

Ich hatte ja alles durchgetestet mit immer gleichbleibendem Fehlerbild.
Letztendlich habe ich die kompletten Server zwischen Schule und zuhause getauscht, der Fehler blieb.
Einziger Unterschied war nunmehr die Revision des Supermicro-Boards H8DME-2 - Rev. 1.2 im Schulserver, Rev. 2.01 in meinem eigenen.
Ich habe nun günstig ein baugleiches Rev. 2.01 für die Schule kaufen können, nun funktioniert alles. Offensichtlich besteht zwischen den verschiedenen Revisionen ein kleiner Unterschied - Chipsatz, Bios ist aber zumindest nominell alles gleich.

Denn dass ein Hardwaredefekt am LAN vorliegt, kann ich eigentlich ausschließen, denke ich. Denn die grundsätzliche Funktionalität ist ja gegeben, getestet mit unzähligen Netzwerkdurchsätzen, verschiedensten Dateien (gepackt, verschlüsselt, Images mit Prüfsummen) - alles wird und wurde sauber übertragen.

Soweit so gut, dieses Problem ist gelöst.

Jetzt machen mir die Rechner im Computerraum Probleme - PXE-UEFI-Boot funktioniert nicht, offensichtlich ist das UEFI bei den Gigabyte-Boards B75M-D3V nicht sauber implementiert. Hätte gerne gpt und UEFI verwendet, mal sehen, ob ich noch eine Lösung finde. Eigenes Thema, falls nötig … :wink:

Viele Grüße

Andreas