Beiträge von elk

Zitat von itsmee

Wobei ich für den PXE Node mit DHCP, HAProxy, DNS, etc.. auch ne ganze Weile gebraucht habe.

HAProxy? Wofür den denn?

Ansonsten mach ich das natürlich auch mit CoreOS, da läuft der Flohzirkus an Diensten in Podman Containern. Ich hab eine entsprechende Ignition zusammengebaut, das Terraform Projekt dazu findet man hier. Da fällt eine Ignition hinten raus, mit der man z.B. lokal ein qemu Image erzeugen kann. Das kann man dann bei Netcup hochladen und in einer VM verwenden, die an ein VLAN angehängt ist. Danach kann man diese Kiste benutzen um andere VMs über PXE zu bootstrappen. Das verwende ich auch für alle möglichen anderen Container-Anwendungen, und das sind bei mir mittlerweile die meisten.

Matchbox ist schon ne coole Sache... schade dass es nur mit Ignition so wirklich funktioniert, ich könnte es mir auch gut für andere PXE Boot Umgebungen vorstellen, Kickstart Profile o.ä.

Zitat von itsmee

Von RedHat gibt es jetzt einen "assisted installer" - da klickst Du dir auf der WebOberfläche online dein Cluster zusammen (clustername, domain, ..) und bekommst dann ein single iso zum anbooten der Maschinen.

Ja, wenn man OpenShift verwenden will, ist das schon nett. Kostet bisschen was, aber das ist dann letztendlich Kubernetes, so wie es Spass macht. Solange man es nicht selber bezahlen muss . Allerdings ist es leider äußerst ressourcenhungrig... und es bringt viel mit, was man nicht braucht.

Typhoon funktioniert ähnlich, nur eben mit Fedora CoreOS. Es bietet nicht alles out of the box, ist hier und da etwas frickelig, aber dafür kostet es nichts und man kann es auch auf sparsamer dimensionierten VMs laufen lassen. Für die Control Panes reichen ja z.B. auch 2GB RAM und 2 Cores. OpenShift will da auch immer gleich 4 vCPUs und 16GB RAM haben auf jedem Knoten. Plus die 2 extra Infra Knoten sind das schon 5 dicke Maschinen, die sich aufs Budget niederschlagen.

Zitat von H6G

Da würde sich ja eine API zum Erstellen von Servern und CloudInit anbieten.

Das war ja auch mal im Gespräch.

Ja, das würde ich auch gerne nehmen ;-).

Aber eine API ist natürlich nochmal viel aufwändiger zu realisieren und zu pflegen, als PXE Boot im VLAN praktikabel zu machen. Mit letzterem könnte Netcup mit relativ geringem Einsatz schnell eine große Wirkung erzielen… und nebenbei könnten sie ja immer noch in Ruhe an einer API feilen.

Zitat von itsmee

Themenfremd - aber vielleicht eine Anregung. Ich wollte mal mit Fedora spielen - dafür gab es kein Image. Wenn man sich lokal mit kvm ein qcow / raw image baut & das auf den FTP schiebt ist der Hauptaufwand geschehen.

Für 1-2 VMs geht das ja noch. Vorrausgesetzt man kriegt qemu lokal zum Laufen um das Image zu erzeugen, was auf neueren macOS oder Windows... zumindest frickelig ist.

Mein konkreter Anwendungsfall wäre aber ein Kubernetes Cluster mit Fedora CoreOS und der Typhoon Distribution. Da zieht man mehrere VMs, also mindestens 3 Controller und 2 Worker, hoch, und das muss dann irgendwie automatisch gehen. Entweder indem man die Ignition Datei als Boot Data angibt und das ganze über eine API (mit Terraform) machen kann, oder eben mit PXE und einem matchbox Controller. Ersteres geht hier nicht und zweiteres ja leider nur so halbwegs mit manueller Intervention für jeden Host. Wenn man dann statt 2 Workern mal 20 braucht, wird's spassig.

Naja, der Anwendungsfall ist jetzt nicht (mehr) so dringlich. Ich wäre aber trotzdem gern auf Netcup zurückgekommen, wenn sich die Notwendigkeit für sowas bei mir mal wieder ergibt.

Zitat von Track1991

Coole Sache

Kannst Netcup mal Vorschlagen das es ins SCP Eingebaut wird unter Boot Reinfolge Netzwerkkarte1, Netzwerkkarte 2 und so weiter.

Das hab ich getan. Sie meinten aber, das wäre ein zu großer Eingriff in ihre Infrastruktur und sie wollen es nicht machen. Schade. Für solche Dinge muss man dann wohl doch zu den "großen" Anbietern gehen...

Hm, ich hab das jetzt grad mal ausprobiert.

Zwei vServer Mini gebucht, dann an beiden das vLAN konfiguriert. Auf dem ersten CentOS8 + DHCP + TFTP installiert und konfiguriert, so dass beide miteinander spielen und auf dem vNet Interface lauschen. Dann das netboot image von debian auf den frisch konfigurierten TFTP ausgepackt.

Die zweite Kiste hab ich auf dem vorinstallierten Debian 8 gelassen. vLAN per dhcp zieht sich eine IP Adresse, das geht schonmal, und mit dem TFTP Client kann ich von der zweiten Kiste die Dateien runterladen, die in der ersten Kiste auf dem TFTP liegen (also den Inhalt des netboot Paketes, was ich vorher da ausgepackt hab). Bootreihenfolge der zweiten Kiste geändert und hochgefahren.... aber in der VNC Konsole kommt nur kurz die Meldung "net1 inaccessible" und er bootet von Platte.

Wenn man während des net-boot Vorgangs rechtzeitig Ctrl-B drückt, dann kommt man in die iPXE Konsole und kann die iPXE Kommandos aufrufen. ifconf konfiguriert z.B. ein interface und ifconf net1konfiguriert bei mir das vLAN Interface auch erfolgreich, es wird eine IP gezogen. Und wenn ich dann autoboot net1 sage, fährt das netboot image von meinem TFTP Server hoch und präsentiert das Debian Installationsmenü... läuft!

Manuell könnte man den PXE Boot also mit ein paar Klimmzügen zum Laufen bringen. Aber schön ist das nicht. Schöner wär's, wenn ich im SCP einstellen könnte, dass die Kiste vom vLAN Interface booten soll und das dann auch passiert, wenn ich sie anschalte.

Zitat

1. Cloud vLAN egal welche Version (siehe https://www.netcup.de/vserver/root-server-erweiterungen.php)

Ah interessant, das werd ich mir mal ansehen. Werd ich sowieso brauchen. Hm, 100Mbit/s in der freien Version sind ja nicht so dolle...

Zitat

Weiß ich aber nicht weiß ob der Server im SCP dann auch über das Cloud vLAN dann Booten kann, weil man dort mit Cloud vLAN zwei Netzwerkkarten hat

Das ist die große Preisfrage. Nur dann würde das ja funktionieren.

Danke jedenfalls

Zitat von nxtd

Meine Frage: Ist das wirklich normal? Finden wirklich dauerhaft Brute-Force Angriffe auf Server statt? Oder bin ich hier außergewöhnlich stark betroffen?

...

Oder gibt es andere Ansätze, die ich treffen könnte?

Das ist absolut normal. Die SSH PasswordAuthentication abstellen ist das erste was man in einem offen zugänglichen Server machen muss. Bei CentOS/RedHat z.B. in /etc/ssh/sshd_config -> "PasswordAuthentication no".
Aber vorher noch SSH keys anlegen und hochladen, sonst sperrst du dich selber aus (siehe ssh-keygen und ssh-copy-id. Oder Windows Putty... damit kenn ich mich aber nicht aus.)

Wenn man das gemacht hat ist (zumindest bei SSH) erstmal Ruhe. Dann kriegen sie mit, dass sie mit einem Passwort sowieso nicht reinkommen.

Zitat

Habe nun DenyHosts oder fail2ban entdeckt, werde vermutlich eines von beiden testen. Kann jemand Erfahrungen dazu teilen?

Fail2ban hab ich neulich auch entdeckt, und installiert weil ich brute force Attacken auf mehrere Mailserver hatte. Funktioniert da ganz gut. Für SSH würde ich mich aber nicht ausschließlich darauf verlassen.

Hallo,

ich würde gerne einen oder mehrere vServer bzw. Root Server per PXE (pxelinux) booten um sie mit entsprechend angepassten, vorkonfigurierten Betriebssystemen zu befruchten.

Ist das möglich? Hat das schonmal jemand gemacht? Ich müsste dafür ja für meine Server eine PXE Bootumgebung einrichten können, oder zumindest das pxeliux.cfg Verzeichnis mit den entsprechenden Config Dateien irgendwie einem schon existierenden TFTP Server bekannt geben, der beim net boot meiner Instanzen abgefragt wird. Oder ich müsste einen eigenen, selbst gehosteten TFTP Server eintragen können, auf den dann beim net boot verwiesen wird.