Anfängerfrage - Edomi herunterfahren

[Lonie]

vento66 Kein Linux gibt 10 Jahre Support. Davon ab ja, etliche Windows 2008R2 Installationen welche vor kurzen aufgrund EOL ausgetauscht wurden liefen ohne murren etliche Jahre durch. Da waren Exchange, AD, Fileserver und diverse andere Kandidaten dabei.

[vento66]

Ja, das sind auch Server Betriebssysteme merkst was?

[jonofe]

Kein Linux gibt 10 Jahre Support.

Vielleicht sollten wir EDOMI auf Solaris migrieren: Solaris 11 hat Support bis 2031 und Extended Support bis 2034.

Wobei auch Redhat mehr als 10 Jahre Support gibt:

rhel_567_life_cycle_8_0919_phases.png

[vento66]

Nicht falsch verstehen, in einem Objekt steht auch ein Windowsrechner seit 2001 mit Elvis als Visu, nur hat der noch nie Internet gesehen....

[saegefisch]

saegefisch das ist unabhängig von deiner Virtualisierungslösung und bezieht sich rein auf CentOS. Dort muss das entsprechende systemd Script angepasst werden wobei ich das aktuell vorhandene nicht wirklich durchschaue. Theoretisch solltest du deinen Edomi Container aber ganz regulär stoppen können.

ja, das ist logisch, meine Frage war diesbezüglich missverständlich formuliert - wäre für jede andere VM wohl nicht anders.

Aber da endet meine Klarheit und jetzt wird's diffus bei mir...was müsste man am CentOS drehen/ändern/machen - auch in Bezug auf den Link von Michael "wintermute" - um Proxmox einfach neu starten zu können, ohne dass sich edomi danach mit "unerwarteter Reboot" zurück meldet. Ich weiß gar nicht verlässlich, ob dies bedeutet, dass der Neustart faktisch hart/unkontrolliert war aus edomi-Sicht oder kontrolliert beendet wurde, und nur informierend moppert, weil es sich übergangen fühlt aka. vom Entwickler die Führung des BS bei edomi sieht. Anders gefragt: Wen nich z.B. in Proxmox "reboot" ausführe, wird dann edomi mit den vorhandenen Scripten sauber beendet oder hart? Im ersten Fall ist nur die Meldung in diesem Kontext...unnötig. Im anderen Fall wäre ich an eine Sccript sehr interessiert, dass edomi dann sauber beendet.

[1mannlan]

Ich wollte hier keinen Krieg der Syteme auslösen und habe einfach ein paar Infos für Leute gegeben, die vielleicht ähnliches Planen. Kein System läuft ohne Wartung und Updates. Potentiell gefährdete Syteme gehören sowieso isoliert und da gehört auch ein veraltets CentOS (Edomi) dazu.
Natürlich könnte ich mich jetzt mit diversen Linuxdistributionen rumärgern, mehr Sicherheit zum Nulltarif bringt das meiner Meinung nach trotzdem nicht.

Ich habe auch nichts gegen Linux Systeme, nur sind die auch nicht automatisch sicherer, vorallem nicht wenn sie nie gepacht werden.

Wenn man ein richtiges Konzept hat, spielt es eigentlich kaum eine Rolle ob das Ganze direkt auf Hardware oder vielleicht virtuell läuft.
In meinem Fall möchte ich möglichst wenig Hardware, daher wird es auch ein Windows mit Hyper-V.

Meine Erfahrung hat mir geizeigt: Je mehr Syteme es gibt, umso anfälliger wird das Ganze und umso aufwändiger die Wartung.

Das führt am Ende manchmal dazu, dass garnichts gepacht wird, was noch fataler (sein kann) ist. Da gibt es genug Beispiele (Stuxnet, Wannnacry etc...)

[1mannlan]

Wen nich z.B. in Proxmox "reboot" ausführe, wird dann edomi mit den vorhandenen Scripten sauber beendet oder hart? Im ersten Fall ist nur die Meldung in diesem Kontext...unnötig. Im anderen Fall wäre ich an eine Sccript sehr interessiert, dass edomi dann sauber beendet.

Ich habe mir dadurch schon einmal Edomi zerschossen, daher habe ich ja nach einer Möglichkeit gefragt. Edomi wird hart gestoppt wenn du den Server herunterfährst.

Mit dem Script sagst du dem Betriebssystem, dass es beim Herunterfahren den Befehl ausführen soll. Wenn der Virtualisierungshost dann noch sauber konfiguriert ist, spricht er auch CentOS richtig an und würgt es nicht hart ab.

Dann sollte alles ohne Fehler laufen.

[wintermute]

veraltets CentOS

boarrr...

Kein Linux gibt 10 Jahre Support

Haeh?
CentOS 6: veroeffentlicht am 10.7.2011, EOS 30.11.2020
CentOS 7: veroeffentlicht am 7.7.2014, EOS 30.6.2024
CentOS 8: veroeffentlicht am 24.9.2019, EOS 31.5.2029

Gut, ich will nicht unfair und polemisch werden: das sind jeweils faktisch weniger als zehn Jahre, aber es sind schon "fast" 10 Jahre.
Aber vielleicht schoepfen wir unser Wissen aus unterschiedlichen Quellen?
Keine Ahnung wie Ihr immer alle auf diese Ideen kommt... Computer-Stammtisch oder so...

[wintermute]

um Proxmox einfach neu starten zu können, ohne dass sich edomi danach mit "unerwarteter Reboot" zurück meldet.

Also, mal ganz einfach formuliert: ziehste das Netzkabel und der Rechner geht aus, dann ist alles egal, dann hilft auch kein Script. Wenn Proxmox (ich hasse das Zeuch, aber egal) runterfaehert, sollte es vorher seinen VMs die Moeglichkeit geben sich sauber zu beenden, dazu wird ein entsprechendes Signal an die VM geschickt, aehnlich dem Runterfahren eines Rechners per Netzschalter. Wenn das passiert startet Linux (oder init oder systemd, je nach Version) eine Reihe Skripte die bestimmte Dienste und Services beenden. Das oben verlinkte Skript macht eben genau das fuer Edomi. Das gehoert dann in die Edomi-VM und muss dort dem init/systemd entsprechend bekannt gemacht werden.
Wenn Proxmox jetzt der VM sagt "fahr runter, Du dumme Lapuschka", dann wird irgendwann dieses Skript gestartet und beendet Edomi sauber, somit hast du auch kein Meldung beim naechsten Start, Wenn Proxmox die VM aber einfach nur "ausschaltet" hilft dir auch das Skript nicht weiter...

[saegefisch]

okay, okay, nun mal ganz konkret:

* Nach meinem Verständnis von VM-Hosts ist, dass beim Reboot oder herunterfahren der Gast stets eine Signal bekommt, dass er doch bitte sauber herunter fahren soll. Ich ging nicht davon aus, dass dies einem Steckerziehen gleich kommt. Nur bei edomi ist dieser Pfad abgeschnitten, richtig? Darum moppert edomi danach. Daher braucht es die Script-Magie, z.b. aus dem verlinkten Beitrag, damit edomi wieder eher konventionell regiert - was mein Ziel für die VM-Umgebung ist (nicht für mein Produktivsystem auf echtem Blech - da unterwerfe ich mich gerne und sehenden Auges dem Dogma des Schöpfers)
* Was muss man wie init/systemd in CentOS bekannt machen, damit beim nächsten reboot/herunterfahren edomi an selbst-suggestion glaubt...
* darf das Script dafür du_dumme_lapuschka.sh heißen oder nicht?

[wintermute]

darf das Script dafür du_dumme_lapuschka.sh heißen oder nicht?

Das kannst du halten wie ... sagen wir: wie ein systemd-Maintainer
Wie man das installiert steht hier, aber wenn Du es umbenennst, dann musst Du das auch entsprechend beim Einrichten beachten. (Ich moechte darauf hinweisen, dass in letzterem Link eine aeltere Version des Skriptes auftaucht, die Anleitung passt aber. Also: Anleitung aus dem letzten Link, Skript aus dem Ersten )

EDIT: ich habs nicht getestet, aber es sollte auch unter CentOS7 funktionieren. Zu anderen Systemen will ich nix sagen. Einfach mal ausprobieren, hilft Dir bei Deinem Problem sicher.

[eric4980]

Oder auch per "Befehl", z.B. mit einer Logik oder in der Visu.

Wie kann man das in die Visu integrieren?
Hab leider nichts in der Suche gefunden...

[Lonie]

Ja, das sind auch Server Betriebssysteme merkst was?

Micha, du sagtest "Kiste mit Redmonder Sicherheitslücke" da war nichts von Home Editionen zu lesen. Unabhängig dessen habe ich im Office-Bereich lieber ein Netz dieser "Redmond-Sicherheitslücken" zu administrieren als Unixoide. Aber an der Stelle driftet es ab und ich werde mich der Diskussion enthalten

[saegefisch]

Wie man das installiert steht hier,

Dank' Dir! Ich habe offenbar nicht richtig gesucht, sonst hätte ich genau das selber finden dürfen... und hätte uns die Frage hier sparen können...

[jonofe]

Edomi auf CentOS7 kommt doch schon mit einem systemd Startskript:

/etc/systemd/system/edomi.service

[Unit]
Description=EDOMI
Before=getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service
After=httpd.service mysqld.service network.target
Conflicts=getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service
[Service]
Type=simple
ExecStart=/bin/sh /usr/local/edomi/main/start.sh
ExecStop=/bin/sh /usr/local/edomi/main/stop.sh
TimeoutStartSec=0
StandardInput=tty-force
StandardOutput=inherit
StandardError=inherit
[Install]
WantedBy=default.target

Ich habe darin die ExecStop Zeile (rot) ergänzt)

und das stop.sh Skript sieht dann gemäß der CentOS6.5 Lösung von Michael so aus:

#!/bin/sh

edomipid() {[INDENT]echo `ps -ef | grep "/usr/local/edomi/main/proc/[p]roc_main.php" | awk '{print $2}'`[/INDENT]
 }

wait=10
echo -n $"Shutting down Edomi: "
/usr/bin/php /usr/local/edomi/main/control.php quit
rm -f /var/lock/subsys/edomi
sleep 1
PID=$(edomipid)
s=0

if [ "x$PID" != x ] ; then[INDENT]echo "Allowing Edomi to terminate within $wait seconds"[/INDENT]
 fi

while [ "x$PID" != x ]; do[INDENT]s=$((s+1))
echo -n "."
if [ "$s" -ge $wait ]; then[/INDENT][INDENT=2]echo "Edomi did not terminate, hard killing"
kill -9 $PID
exit 0;[/INDENT][INDENT]fi
sleep 1
PID=$(edomipid)[/INDENT]
 done
echo
exit 0;

Damit funktioniert es bei mir ganz wunderbar mit einem shutdown, poweroff oder reboot auf der Konsole.