Hat jemand eine 1€-Schüssel bei I0N0S und kann mir sagen ob diese in Frankfurt oder in Berlin steht?
Hier steht er in Frankfurt am Main. Allerdings würde ich jetzt nicht erwarten, dass das bei neuen Bestellungen immer so ist.
Hat jemand eine 1€-Schüssel bei I0N0S und kann mir sagen ob diese in Frankfurt oder in Berlin steht?
Hier steht er in Frankfurt am Main. Allerdings würde ich jetzt nicht erwarten, dass das bei neuen Bestellungen immer so ist.
BTW, da gibt es im SCP unter General einen Nick Eintrag (Spitzname). Wenn ich da was eintrage, welche Auswirkung hat das denn?
Das ist nur ein Eintrag, der im SCP erscheint, damit man die Server in der Übersicht besser identifizieren kann. Hat man mehrere Server, so ist die v20xxx angabe dann doch recht unübersichtlich. Außerhalb des SCP hat dieser Nickname keine Auswirkungen und auch auf den Server selbst hat das keinen Einfluss.
Sollte ich nun im Feld Hostname irgendwas anderes angeben, dann wird dieser Name zwar im installierten Linux in der `/etc/hosts` und der Kurzname in der `/etc/hostname` erscheinen, aber es wird dafür keinen DNS Namen geben.
Ist das so richtig?
Korrekt! Es wird kein DNS Eintrag angelegt - egal was man dort einträgt. Man kann entweder den vorgeschlagenen Hostnamen nehmen (für diesen gibt es schon einen entsprechenden DNS Eintrag) oder aber man trägt was komplett eigenes ein. In diesem Fall ist man aber komplett selbst verantwortlich für die DNS Enträge. Das Feld sorgt letztendlich wirklich nur dafür, welcher Hostname im System erscheint (was sich im Nachhinein natürlich auch nochmal ändern lässt).
Wieso das?
Ich mache das seit Jahren so und es funktioniert völlig problemlos, mit sehr kreativen hostnames. (Auch mit postfix)
Oft haben meine hostnames nicht den geringsten Bezug zur domain und den DNS-Einstellungen
[...]
Der Hostname muss natürlich nicht immer die Domain haben, unter der die Applikationen laufen. Das wollte ich damit nicht ausdrücken. Wenn man aber eine Domain nutzt, sollte man entweder eine Pseudo Domain nutzen (z.B. .local) oder eine, die man selbst kontrolliert (ich selbst habe z.B. Domains einzig für Hostnamen). Es ging mir vor allem darum, dass man nicht einfach so eine x-beliebige Domain nehmen sollte - auch wenn das technisch möglich wäre. Es wäre z.B. möglich, dass ich meinen Server ccp.netcup.net nenne. Aber wie man unschwer erkennen kann, ist das keine so gute Idee. Man kann natürlich lokal mit Hosts Einträgen arbeiten. Das kann aber u.U. auch etwas heikel sein, weil man das schnell mal vergisst oder falsch konfiguriert. Da wäre mir das Fehlerpotential viel zu hoch als dass es irgendeinen positiven Nutzen aufwiegen würde.
EDIT: Natürlich kann man auch einen Hostnamen nutzen, für den es keinen DNS Eintrag gibt. Aber man sollte halt dann sicherstellen können, dass es auch so bleibt, weil man entweder selbst die Domain besitzt oder die Domain nie einen öffentlichen DNS Eintrag bekommen kann (wie das obige Beispiel mit .local).
Wenn du dich für einen FQDN Hostnamen entscheidest, kannst du nicht irgendeinen Namen verwenden (theoretisch schon, ist aber keine gute Idee), sondern solltest auch darauf achten, dass die DNS Einträge hierfür korrekt sind. Der vorgeschlagene <ID>.<X>srv.de Hostname würde z.B. funktionieren. Ein fridolin.goodsrv.de wird so aber nicht funktionieren - davon wäre auch abzuraten. Du kannst aber unter deiner eigenen Domain einen beliebigen Hostnamen wählen. Die Gefahr ist sonst, dass du einen Hostnamen wählst, den es evtl. schon gibt und damit auch schon vorhandene DNS Records. Das kann zu unschönen Nebenwirkungen führen. Daher sollte man grundsätzlich immer nur so einen Hostnamen wählen, welchen man auch vollständig kontrolliert. Spätestens bei einem Mailserver wird das sonst ziemlich kritisch.
Kennt jemand gute (online) Kurse in Richtung IT-Systemadministration bzw. alles rund ums Thema Linux / Server? Oder Bücher? (Die Buchempfehlungen vom letzten Mal könnt ihr gerne erneut verlinken wenn ihr die grade parat habt - oder ich suche sie mir später zusammen.)
Die Kurse müssen nicht kostenfrei sein, wenn es sich lohnt.
So spontan fallen mir da die Bücher von Kofler ein (z.B. https://kofler.info/buecher/linux/). Die sind sicher nicht schlecht, weil sie auch regelmäßig aktualisiert werden. Das ist leider so ein Problem in der IT-Welt. Man hat quasi nie ausgelernt und muss immer am Ball bleiben. Bis ein Buch mal erschienen ist, ist der Inhalt dann oft schon veraltet. Grundlegende Dinge bleiben natürlich gleich. Aber man muss dann doch immer etwas aufpassen und darauf achten, wann das Buch geschrieben/veröffentlicht wurde.
2001:db8 ist explizit für die Dokumentation und Beispiele von öffentlichen Unicast Präfixen.
Ich kann nur mutmaßen, dass jemand db8 durch cafe ersetzt hat, weil es cooler klingt - ohne zu wissen, warum.
Letztenendes hängt es davon ab, wie du dein Cluster erreichen möchtest von außen, oder ob sowieso alles über einen Ingress Dienst geleitet wird.
IMHO empfielt sich dort meistens ein ULA Prefix bei Netcup - es sei denn du betreibst nur ein Single Host K8S "Cluster" - dann kannst du das auch mit einem zusätzlichen IPv6 Subnetz machen.
Danke für die Info bzgl. 2001:db8! Das kannte ich so auch noch nicht.
Im konkreten Fall habe ich das tatsächlich in einem Single Host K8s (k3s) evaluiert. Im normalen Fall, wenn man sowieso nur HTTP Anwendungen hat, läuft das alles über den Ingress Controller. Das ist kein Problem. Etwas umständlich wird es immer nur, wenn man andere Ports erreichbar machen will. In diesem Fall z.B. ein Gitea und dessen SSH Port. Am einfachsten geht das über einen HostPort (ist ja nur ein Single Node Cluster). Damit dieser dann aber auch über IPv6 erreichbar ist, muss der Cluster im Dualstack konfiguriert sein. Das war letztendlich der ausschlaggebende Punkt.
Alternativ kann man den Pod (wie z.B. den Ingress Controller) im Host Netzwerk laufen lassen. Dazu müsste die Applikation sich aber auf Port 22 binden können, was in meinem Fall nicht funktionierte, da ich die rootless Variante bevorzuge und das gitea binary keine entsprechenden capabilities gesetzt hat (auf ein Custom Image hatte ich keine Lust ;-)).
Danke! Das bestätigt mich in der Annahme, dass die 2001er Empfehlungen eher ungünstig sind. Wundert mich etwas, dass sie trotzdem überall genannt werden. Vermutlich einfach C&P. Ich dachte erst, dass wäre ein weiteres nicht geroutetes Präfix. Aber ich habe diesbezüglich gar nichts finden können und war dann entsprechend skeptisch.
Mal eine Frage an die IPv6 Experten. Ich bin dabei meine Kubernetes Cluster auf Dual-Stack umzustellen. Jetzt stehe ich allerdings vor der Frage welche Cluster / Service CIDR ich hier definieren soll.
Spontan hätte ich gesagt, dass ich hier Präfixe aus fd:: (Unique Local) wählen sollte (z.B. fd:cafe:42::/56 für die Cluster Cidr). Jetzt lese ich aber überall, dass die empfohlenen Netze diese hier sind
Aber warum 2001 und nicht fd? Für mich macht das gerade wenig Sinn. Übersehe ich hier etwas? Vielleicht hat ja von euch jemand eine Idee oder den passenden Hinweis für mich oder hat das vielleicht sogar selbst schon mal gemacht.
Habt ihr denn keine Angst, dass auch Proxmox z.B. an die Firma Broadcom verkauft werden könnte?
Die Wahrscheinlichkeit ist äußerst gering. Da Proxmox auf Open Source Technologie basiert, würde das schneller geforkt werden als die Tinte unter dem Vertrag trocknen würde Letztendlich ist Proxmox ja auch nur KVM bzw. LXC und als Storage kommt in der Regel Ceph zum Einsatz.
Anexia selbst hatte ja aber auch schon vorher Standorte in den USA. Daher dürfte der neue Standort von Netcup diesbezüglich eigentlich nicht viel ändern, da ja Netcup als Tochterfirma ja auch schon vorher betroffen gewesen wäre. Interessant ist dieses Thema unabhängig davon aber trotzdem. Ich vermute nur, dass wenn es so wäre, Anexia/Netcup hier offiziell gar nicht darüber sprechen dürfte.
Teste den Reverse DNS Eintrag doch einfach mal (z.B. mit dig -x $IP). Vielleicht hast du ihn ja konfiguriert, allerdings nicht ganz korrekt? Hast du ihn für IPv4 und IPv6 gesetzt? Ansonsten kannst du die IP oder en Eintrag auch gerne mal per PN schicken, dann kann ich es unabhängig davon mal überprüfen. Folgende Tools können dir auch noch weiterhelfen: https://mxtoolbox.com/SuperTool.aspx
Seit wann gibt es denn im SCP "Hostname"? Und wofür ist das gut? Dacht erst das sei der rDNS-Record, ist er aber anscheinend nicht.
Ist mir auch schon aufgefallen. Das ist der gleiche Hostname, den man während einer Image Installation setzen kann. Zumindest wurde dieser in meinem Fall automatisch ausgefüllt.
Es wäre sicher auch allen geholfen, wenn Netcup gerade bei den neuen ARM Servern eine etwas größere Auswahl an offiziellen ISO Images zur Verfügung stellen würde (z.B. Almalinux, Fedora, FreeBSD). Man muss ja nur das ISO einmal herunter und wieder hochladen. Viel mehr Aufwand ist das ja nicht. Bei den Custom Images kann ich es noch verstehen. Das ist durchaus etwas Aufwand, bis diese gebaut, getestet und dann zur Verfügung gestellt werden. Aber ein ISO ist ja nur ein ISO, hier sind ja keine Netcup spezifischen Änderungen notwendig. Es würde ja auch Anexia/Netcup helfen, wenn nicht 100 Kunden alle das gleiche ISO hochladen müssten, weil sie gerade kein Debian oder Ubuntu möchten. Das ist ja im Grunde auch nur unnötige Verschwendung von Bandbreite und S3 Speicherplatz.
Man kann sagen, was man will, aber das Netcup Forum ist einfach klasse! Kaum habe ich den letzten Beitrag geschrieben, fällt mir doch tatsächlich wie von Zauberhand die Lösung vor die Füße.
Die Lösung ist im Grunde sogar recht simpel
1. auto_reset_crashkernel no in der /etc/kdump.conf setzen
2. dnf reinstall kernel-core
3. Reboot
Alternativ kann man auch im 2. Schritt mittels grubby die bestehenden Grub BLS Einträge editieren, aber durch ein reinstall kann man überprüfen, dass der Eintrag bei einem zukünftigen Update auch wirklich nicht wieder erscheint. Ich hätte mir nur einen etwas aussagekräftigeren Variablennamen gewünscht. So war das auf den ersten Blick wirklich nicht zu erkennen, was es damit auf sich hat.
Crashkernel=no als Kernel-Parameter in Grub müsste kdump deaktivieren und dir dein Ram wiedergeben.
Ja, das funktioniert aber leider nur temporär für die schon installierten Kernel. Sobald ein Update ansteht, wird das dann wieder überschrieben. Dann greift wieder folgendes Skript:
was wiederum
ausführt und dort scheint es hardcodiert zu sein. Eine wirklich dauerhaft schöne Lösung ist mir da gerade nicht bekannt. Daher hätte mich mal interessiert, ob da jemand anderes was gefunden hat.
Letztendlich dauert es keine 5 Minuten und der Server ist mit einem anderen OS komplett neu aufgesetzt. Ich wollte aber mal Almalinux wieder eine Chance geben. Wenn man dann direkt mit so etwas konfrontiert wird, hat man schon direkt keine Lust mehr. Zumal kdump standardmäßig nicht einmal läuft. Der RAM wird also völlig unnötig vorenthalten.
Gibt es hier zufällig Almalinux User? Bei einem der letzten Updates scheint eine neuer Kernel Parameter hinzugekommen zu sein
Der führt dazu, dass ein gewisser Teil des RAMs reserviert wird und dem eigentlichen System nicht mehr zur Verfügung steht. Wenn das System sowieso viel RAM hat, ist es womöglich egal und man merkt es kaum, aber gerade bei kleinen VPS (z.B. die 1 GB Variante), hat das doch enorme Auswirkungen, wenn auf einmal fast 20% fehlen. Mir ist das jetzt selbst bei einem 1 GB VPS aufgefallen, weil hier auf einmal selbst einfache dnf Update Prozesse mit oom gekillt wurden und das ganze OS praktisch unbenutzbar wurde.
Man findet dazu relativ wenig. War das bei euch schon mal Thema? Ich überlege gerade wie man das am besten deaktiviert, denn das scheint ja kein Parameter aus der /etc/default/grub oder so, sondern durch die Kernel Installation selbst hinzugefügt worden zu sein.
Unter Almalinux 9.2 gab es das nämlich noch nicht. Irgendein Update seit dem scheint das mitgebracht zu haben.
Steht dein ARM VPS zufällig in VIE? Hier scheint es aktuell wirklich ein paar Probleme im SCP zu geben. Ich kann dort ebenfalls nichts machen und bekomme in allen Kategorien nur die Fehlermeldung
"Die Informationen können zurzeit nicht ermittelt werden. Bitte versuchen Sie es in wenigen Minuten erneut."
angezeigt. Aber der Server an sich läuft. Da gibt es keine Probleme. Nur über das SCP lässt sich dort aktuell nichts machen.
EDIT: Kaum habe ich die Antwort abgeschickt, schon geht es wieder. Aber das zeigt, dass es hier definitiv nicht ganz rund läuft.