LFMF: OpenBSD Upgrade bei EUserv

SierraX

Well-Known Member
Guten Morgen,

gestern hab ich auf einem meiner Spiel und Lernserver (Miserfi S V6) erst mal das von Euserv als Dev angebotene OpenBSD 5.8 zu installieren... Hat damit nicht gebootet... nuja ist ja auch beschrieben das es schwere Fehler geben kann...
Nachdem das gescheitert ist, hab ich das als Testing markierte OpenBSD 5.6 installiert. NICHTS daran gemacht, ausser die OpenBSD 5.7 Dateien von A nach B zu kopieren (nuja die Übertragungsgeschwindigkeit war teilweise grauenhaft, obwohl es 2 Server von Euserv sind).
Egal ich habe mich an die Anleitung http://www.openbsd.org/faq/upgrade57.html#upgrade gehalten. Sollte ja kein Problem sein...
Allerdings ... ich weiss nicht an welcher Stelle es dann passiert, bzw passiert ist (weil es auf einem 2ten OpenBSD Server nachvollzogen werden konnte). Stimmte das root Passwort nicht mehr mit dem aus den Serverdaten überein und ich konnte mich somit nicht mehr einloggen.
Das Problem kann und sollte umgangen werden, in dem man eine authorized_keys mit einem seiner PublicKeys unter /root/.ssh anlegt.
Ob es auch durch kopieren der alten /etc/spwd.db geht hab ich noch nicht probiert, da aber nach Entpacken der tarballs sehr viele Funktionen nur noch eingeschränkt bis gar nicht mehr funktionieren sollte man es nicht darauf ankommen lassen wenn es sich um ein Produktiv System handelt.
Falls man es wieder aufräumen will, sollte man ein passwd root ausführen und das Passwort aus den Serverdaten neu hinterlegen. Sowie ggf die /root/.ssh/authorized_keys wieder löschen.
Und noch ein weiterer Tip: Da sudo und alles was damit zu tun hat bei OpenBSD 5.8 aus der base geflogen ist, sollte man sich wirklich als root einloggen und nicht über einen "Substitute User (sudo su -)" kommen.

Hope this helps
Kind Regards and Happy Whatever
SierraX

p.s. Den Text habe ich ursprünglich für das EUserv Forum geschrieben... ich nehme an, das die meisten hier selbst auf diese Schlussfolgerungen gekommen wären
 
Da sudo und alles was damit zu tun hat bei OpenBSD 5.8 aus der base geflogen ist, sollte man sich wirklich als root einloggen und nicht über einen "Substitute User (sudo su -)" kommen.
Aber genau das sollte man grundsätzlich nie machen. Als User root einloggen ist keine gute Idee. Ein einfaches "su -" sollte als User auch genügen, wenn man das Passwort weiss vom User root. Als Ersatz für sudo gibt es übrigens doas [1]

Gruss

[1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/doas.1
 
IMHO eben nicht. Vom Betriebssystem völlig unabhängig würde ich SSH ausschließlich mit Schlüsselpaaren nutzen und ein normales Login via Passwort deaktivieren.

Ich weiss jetzt gerade nicht, was bei EUserv in den AGBs drin steht... AFAIK gibt es Hoster die ein solches Verhalten als angriff auf die Security Policy sehen und sowas mit Sonderkündigungen ahnden könnten... Ich hatte schonmal einen Server wo ich zwar root bekam... aber keine rechte hatte das Passwort zu ändern. Lässt man hier das Passwort leer oder ändert es, kann auf alle Fälle der Support nicht mehr auf den Server zugreifen. Nicht das ich viel vertrauen in deren OpenBSD Kompetenz hätte aber bevor sie mir eine Abschaltung aufdrücken oder irgendwas kaputt hauen weil sie mit nem ungeeigneten LiveSystem an die Platte ran gehen wenn ein Netzwerkdienst Amok läuft und sie nicht als root drauf kommen... lass ich das Passwort lieber als möglichkeit und setze es erneut auf das Automatisch vom Hoster vergebene. (ich komme aus dem Monitoring... ich hab schon so einiges gesehen)
Bei "deinem" Server im Keller geb ich dir aber absolut recht.
 
Aber genau das sollte man grundsätzlich nie machen. Als User root einloggen ist keine gute Idee. Ein einfaches "su -" sollte als User auch genügen, wenn man das Passwort weiss vom User root. Als Ersatz für sudo gibt es übrigens doas [1]

Gruss

[1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/doas.1
Lies dir noch mal meinen Artikel durch und grüble über einen logischen Fehler...
wenn man NICHT als root mit dem vorgegebenen Passwort per SSH rein kommt... wie sollte das dann als "su -" per Passwort gehen?

doas als ersatz für sudo ist ein mögliches Henne/Ei Problem... die doas.conf ist erst vorhanden, wenn 5.8. aufgespielt wird... nach dem aufspielen (wir reden hier immer noch von eine Installation OHNE "install kernel") vor dem reboot kann man nicht mal ein "cat" anständig ausführen, wie es mit nano, vi und so weiter aus schaut weiss ich noch nicht, kann mir aber vorstellen das nicht besser ausschaut... also die doas.conf ist zu diesem Zeitpunkt wahrscheinlich nicht mehr konfigurierbar. Wenn ich also nach einem neustart "doas" Rechte brauche um root zu werden aber root sein muss um mir diese rechte zu erteilen... wie gehts dann weiter?
Auch ob das "sudo" von 5.7 in 5.8 noch funktioniert habe ich noch nicht getestet, ich werde berichten. Z.Z. Habe ich 2 Server mit OpenBSD 5.7. bei EUserv... Wobei einer halb produktiv verwendet wird, und beim anderen noch nicht mal der freie HDD Speicher gelabelt ist
 
Lies dir noch mal meinen Artikel durch und grüble über einen logischen Fehler... wenn man NICHT als root mit dem vorgegebenen Passwort per SSH rein kommt... wie sollte das dann als "su -" per Passwort gehen?
Das war auch darauf bezogen, wenn das System dann fertig installiert ist und nicht während dem Update.
 
Auch ob das "sudo" von 5.7 in 5.8 noch funktioniert habe ich noch nicht getestet, ich werde berichten.

Ich hab den einen Server jetzt auf OpenBSD 5.8 upgegradet... und dabei traten die Probleme nicht auf. Also ich konnte mich per "su -" mit dem Passwort, das ich vor dem upgrade auf das Automatische von EUserv gesetzt habe, als root anmelden. Ich hab grad keine Lust nach zu forschen warum das so ist... vielleicht hat sich von 5.6 auf 5.7 die Login Prozedur von /etc/shadows auf /etc/pwd.db geändert und ich habs überlesen...
Direkt nach dem Punkt "/sbin/oreboot" in der Anleitung hatte ich mich als ein vorher angelegten "wheel" User angemeldet. Und das sudo aus 5.7 funktionierte noch... erst im letzten schritt nach dem sysmerge wird angegeben, das man die sudo Sachen löschen sollte, und somit auf doas umsteigen...
 
Zurück
Oben