Mir ist da ein trefflich Missgeschick passiert. In einer Sekunde der
Unachtsamkeit verwechselte / vertauschte ich im Kopf ein * mit einem
/...
Nun schrob ich denn, wohlwissend das ich mich in /var/www/ befand :
1
chown -R www-data:www-data /
2
3
anstelle eines:
4
5
chown -R www-data:www-data *
Als der Rechner dann doch länger als 2sec brauchte, viel mir dies
Missgeschick sofort ins Auge. Jedoch kam ein Abbruch da schon zu spät ?
Ich komme nicht in sudo weil nun unter sudo kein Zugriff mehr auf
sudoers besteht... Booten tut Ubuntu allerdings noch. Bringt zwar
komische Fehlermeldungen (so schnell bin ich nicht, und auf die Logs
komm ich nimmer) aber läuft an.
Da es sich nur um einen production-server handelt wäre der Verlust jetzt
nicht unbedingt soooo schwer, halt extrem nervig und aufwendig. Aber
Rückgängig zu machen fällt in diesem Fall wahrscheinlich aus oder?!
Wenn ja: ich würde am Mittwoch Abend (anderer Standort, ca. 300km
entfernt) an meinen zweiten Server rankommen mit exakt der gleichen
Hardware, exakt der gleichen Toolchain. Kann ich da einfach die HDD
clonen mittels dd oder lieber doch mit rsync? Morgen und Mittwoch würde
ich mir dann eine andere Arbeit suchen. ?? Aber machbar wäre das oder?
An Stelle eines zweite Systems kommst du auch über ein Live-System von
DVD/USB ran. Aber bis du das wieder gerade gebogen hast, ist der Backup
längst eingespielt.
Du könntest ein Script bauen, dass owner/group des anderen baugleichen
Systems erfasst und daraus ein weiteres Script erzeugt, das sie
wiederherstellt.
TestX schrieb:> Backup einspielen oder neu installieren. Alles andere dauert> länger
Backup habe ich von meinen Daten auf dem Server, einmal auf einem
entfernten Fileserver und einmal lokal auf meinem Rechner sowie USB
Stick.
Aber ein komplettes Backup des Systems habe ich natürlich nicht. Das
steht ja nun 300km entfernt. Und neu aufsetzen mit der Toolchain, da
gehen dicke 1 bis 1.5 Tage ins Land, die ich anders nutzen könnte.
Oder meinst du mit "Dauer Länger" das umsetzen der alten Rechte des
Systems?
Rene K. schrieb:> Mir ist da ein trefflich Missgeschick passiert. In einer Sekunde der> Unachtsamkeit verwechselte / vertauschte ich im Kopf ein * mit einem> /...
Ach, war ja nur ein chmod. Ich ein Kollege hat mal ein rm -rf / gemacht,
statt "./" :-)
> Ich komme nicht in sudo weil nun unter sudo kein Zugriff mehr auf> sudoers besteht... Booten tut Ubuntu allerdings noch. Bringt zwar> komische Fehlermeldungen (so schnell bin ich nicht, und auf die Logs> komm ich nimmer) aber läuft an.
Viele Dienste brauchen die korrekten Berechtigungen, wie z.B. mysql etc.
Sudo basiert auf korrekten Benutzer der Executable, und das SETUID bit.
Das hast du warscheinlich durcheinander gebracht.
> Da es sich nur um einen production-server handelt wäre der Verlust jetzt> nicht unbedingt soooo schwer, halt extrem nervig und aufwendig. Aber> Rückgängig zu machen fällt in diesem Fall wahrscheinlich aus oder?!
CTRL+Z macht hier nicht rückgängig ;-)
> Wenn ja: ich würde am Mittwoch Abend (anderer Standort, ca. 300km> entfernt) an meinen zweiten Server rankommen mit exakt der gleichen> Hardware, exakt der gleichen Toolchain. Kann ich da einfach die HDD> clonen mittels dd oder lieber doch mit rsync?
Geht beides, dd kopiert halt alle bytes, auch die, die nicht verwendet
werden. rsync kopiert nur die Dateien.
Wenn du rückgäng machen willst:
Mach mal rsync mit "n", also
rsync -avzn -e "ssh" / remoteuser@X.X.X.X:/
Mit parameter "n" wird angezeigt, was gemacht würde.
https://unix.stackexchange.com/questions/291276/rsync-with-destination-owner-and-permission-possible/358103
Mit Parameter "-o" und "-g" vielleicht noch explizit User / Group
vergleichen.
Vielleicht kannst du dann nur die Fehler zurück synchronisieren, damit
wieder alles läuft.
> Morgen und Mittwoch würde> ich mir dann eine andere Arbeit suchen. ?? Aber machbar wäre das oder?
Sowohl dd als auch rsync funktioniert um Linux Systeme zu klonen. (nicht
theoretisch, praktisch, mache ich ab und zu ;-))
Bei rsync musst du danach die /etc/fstab noch anpassen, du hast
wahrscheinlich andere Partitions IDs, swap steht noch zusätzlich in
einer Datei, kann ich nicht auswendig, merkst du aber, der Wartet beim
Booten so 30s auf die falsche ID ;-)
Dann Bootloader, falls UEFI, reicht eine korrekte Partition, falls MBR:
grub nochmals installieren.
Viel Erfolg!
mfg Andreas
A. K. schrieb:> Du könntest ein Script bauen, dass owner/group des anderen baugleichen> Systems erfasst und daraus ein weiteres Script erzeugt, das sie> wiederherstellt.
Das wäre auch eine Option. ? Quasie eine Liste anlegen lassen welche für
jede Datei / jedes Verzeichnis die Daten liest in eine Tabelle gibt und
dann hier wieder rückspielt. Muss ich dann zwar über ne LiveCD machen da
ich ja nicht mehr sudoen kann.
Rene K. schrieb:> Das wäre auch eine Option. ? Quasie eine Liste anlegen lassen welche für> jede Datei / jedes Verzeichnis die Daten liest in eine Tabelle gibt und> dann hier wieder rückspielt.
Nix Tabelle. Ein Shell-Script erzeugen, mit sowas wie
chown affe.tot /
chown bin.laden /bin
....
oder auch dezimal, und dann einfach laufen lassen.
Andreas B. schrieb:> Viel Erfolg!>> mfg Andreas
Vielen Dank für deine Infos.
Ja ich werde einfach am Mittwoch die Platte mitnehmen und mit dd clonen
lassen. Das einzigste was ich da beachten muss, dass ich da über ein
Livesystem boote, da ich sonst die persistenz der Platte (da ja sonst im
Gebrauch) verliere.
Es gibt ein paar Stellen, die nach dem "dd" angepasst oder neu generiert
werden sollten. Und die alte Platte enthält zwar die falschen Owner,
aber immerhin die richtigen Daten, also vorher retten. Irgendwas aus
/etc /var ... brauchst du vielleicht noch.
Hallo Rene,
Meine Empfehlung wäre auch rsync:
Andreas B. schrieb:>> Wenn ja: ich würde am Mittwoch Abend (anderer Standort, ca. 300km>> entfernt) an meinen zweiten Server rankommen mit exakt der gleichen>> Hardware, exakt der gleichen Toolchain. Kann ich da einfach die HDD>> clonen mittels dd oder lieber doch mit rsync?> Geht beides, dd kopiert halt alle bytes, auch die, die nicht verwendet> werden. rsync kopiert nur die Dateien.>> Wenn du rückgäng machen willst:> Mach mal rsync mit "n", also>> rsync -avzn -e "ssh" / remoteuser@X.X.X.X:/>> Mit parameter "n" wird angezeigt, was gemacht würde.
Tipp: mit -i statt -v bekommt man für jede Datei aufgelistet was genau
sich unterscheidet und was nicht, z.B. Timestamp, Berechtigungen, Owner,
Group usw.
Und das -e "ssh" kann man auch weglassen, ist eh default...
> https://unix.stackexchange.com/questions/291276/rsync-with-destination-owner-and-permission-possible/358103>> Mit Parameter "-o" und "-g" vielleicht noch explizit User / Group> vergleichen.
-o und -g sind bereits in -a enthalten (-a bedeutet dass fast alle
Metadaten der Dateien beim kopieren synchronisiert werden) -- da Du aber
ja nur Owner und Group setzen willst, würde ich statt -a lieber -rog
verwenden, damit werden z.B. Permissions und Timestamp gar nicht mehr
synchronisiert, nur noch Owner und Group.
-x sollte noch dazu, da sonst auch /proc und /sys usw synchronisiert
würde
Also zusammengefasst etwa so:
rsync -rogizx -n / remoteuser@X.X.X.X:/
Dann die Ausgabe durchschauen, und falls es passt, dann ohne -n aufrufen
um es tatsächlich ausführen zu lassen.
Wenn Du den kaputten Server auch Remote mit einem Livesystem booten
kannst brauchst damit nichtmal die 300km zu fahren, geht dann alles
übers Netz...
Mathias A. schrieb:> Also zusammengefasst etwa so:>> rsync -rogizx -n / remoteuser@X.X.X.X:/>> Dann die Ausgabe durchschauen, und falls es passt, dann ohne -n aufrufen> um es tatsächlich ausführen zu lassen.
Vielen Dank, das schaue ich mir mal an.
Mathias A. schrieb:> Wenn Du den kaputten Server auch Remote mit einem Livesystem booten> kannst brauchst damit nichtmal die 300km zu fahren, geht dann alles> übers Netz...
Ich kann beide Server vice-versa Remote bedienen. Ob ich remote ein
anderes BS booten kann, hab ich noch nie probiert. ? Haben beide aber
iDRAC. Aber das ist nicht so wild. Ich kann ja entweder die LiveCD
booten bevor ich losmache oder ich nehme das Ding einfach komplett mit -
wie gesagt, er hat eh keine feste Arbeit zu verrichten und die 300km
muss ich so oder so fahren, ob das nun mit dem Server passiert wäre oder
nicht. ?
Rene K. schrieb:> Und neu aufsetzen mit der Toolchain, da> gehen dicke 1 bis 1.5 Tage ins Land, die ich anders nutzen könnte.
Pro-Tipp fürs nächste mal neu aufsetzen: komplettes Setup als Script
festhalten, welches du im Havariefall nur neu ausführen musst um vom
nackten OS zu deiner Toolchain zu kommen.
Alternativ Docker o.ä.
Rene K. schrieb:> Ob ich remote ein> anderes BS booten kann, hab ich noch nie probiert. ? Haben beide aber> iDRAC.
Hängt von der iDRAC Lizenz ab. Aber wenn du Virtual Console hast, dann
auch Virtual Media. Und davon kannst du booten.
Hi,
die Berechtigungen sind in den deb Paketdaten enthalten.
Hier hat das mal einer aufgearbeitet:
https://hyperlogos.org/page/Restoring-Permissions-Debian-System
Sollte auf jeden Fall einen brauchbaren Zustand herstellen.
(nur falls das Backup gerade auf einem anderen Planeten liegt).
Gruß M
A. K. schrieb:> Oder eben auch das System sichern.
Ist dann trotzdem blöd, wenn es genau ein undokumentiertes System gibt,
auf dem die Toolchain läuft. Was, wenn das ganze mal auf einen anderen
Server soll?
Es ist immer hilfreich, ein System auf Knopfdruck nachbauen zu können.
Gerade, wenn es als Entwicklunssystem verwendet wird. Gibt z.B. auch nix
nervigeres, als einem neuen Mitarbeiter erstmal 10 Abhängigkeiten
manuell hinkonfigurieren zu müssen, bis er endlich produktiv arbeiten
kann.
woas i nit schrieb:>> Es ist immer hilfreich, ein System auf Knopfdruck nachbauen zu können.>> ansible rocks ;-)
Wobei ich ein bestimmtes System meist nur einmal baue, das dient dann
als Template für viele. Da reichen Stichworte / Handprotokolle für die
nächste Release.
Ist eher selten heutzutage, dass ich @work noch etwas anderes als einen
Hypervisor direkt aufs Blech installiere. Als VM hat man Snapshots als
Sicherheit bei kritischen Aktionen, automatisch wie manuell.
A. K. schrieb:> Ist eher selten heutzutage, dass ich @work noch etwas anderes als einen> Hypervisor direkt aufs Blech installiere. Als VM hat man Snapshots als> Sicherheit bei kritischen Aktionen, automatisch wie manuell.
Mit automatischen, z.B. stündlichen, btrfs- oder lvm-Snapshots kann den
oben gemachten Fehler auch ohne VM in wenigen Sekunden rückgängig
machen..
Sooo... Ich kann Erfolg verzeichnen ☺️ hat mit dd geklappt. Musste dann
nur meine Netzwerkeinstellungen ändern und dann lief alles schon wieder.
Ich danke euch für eure ganze Hilfe. Uuuund... Ich werde nun auch das
komplette System in meinen Backupplan mit einbeziehen, das habe ich
gelernt ?
woas i nit schrieb:> ansible rocks ;-)
Frei nach fefe:
Unsere Software ist zu komplex, wir haben die Komplexität nicht im
Griff! Pass auf, wir machen da ein verteiltes System daraus! Dann sind
die Einzelteile weniger komplex. Vielleicht können wir das dann unter
Kontrolle bringen.
Das verteilte System braucht viel mehr administrativen Aufwand. Pass
auf, den automatisieren wir weg! Wir machen Container! Docker!
Docker-Aufsetzen braucht viel mehr administativen Aufwand. Pass auf,
den automatisieren wir weg! Wir machen Kubernetes!
Kubernetes braucht viel mehr administativen Aufwand. Pass auf, den
automatisieren wir weg! Wir machen Ansible!
Ansible braucht viel mehr administativen Aufwand. Pass auf, den
automatisieren wir weg! Wir machen Chef / Salt!
;)
Rene K. schrieb:>> Da es sich nur um einen production-server handelt wäre der Verlust jetzt> nicht unbedingt soooo schwer, halt extrem nervig und aufwendig. Aber> Rückgängig zu machen fällt in diesem Fall wahrscheinlich aus oder?!
Production heist doch Produktion? Und der war unwichtig? Dann bitte
sagen welche Firma ihr seid, damit man eure Produkte meiden kann.
PS: Wenn man solche Fragen hier stellt, sollte man die Finger von
Servern und deren Wartung und Service Fachleute machen lassen, ausser
man bastelt zu hause rum.
Rene K. schrieb:> Sooo... Ich kann Erfolg verzeichnen ☺️ hat mit dd geklappt. Musste dann> nur meine Netzwerkeinstellungen ändern und dann lief alles schon wieder.> Ich danke euch für eure ganze Hilfe. Uuuund... Ich werde nun auch das> komplette System in meinen Backupplan mit einbeziehen, das habe ich> gelernt ?
Schön zu hören, und danke für die Rückmeldung!
Bäcker schrieb:> Production heist doch Produktion? Und der war unwichtig? Dann bitte> sagen welche Firma ihr seid, damit man eure Produkte meiden kann.
Du wärst vermutlich erstaunt, wie viele Firmen und ordentliche
Einrichtungen du dann meiden müsstest... traurig, aber wahr.
TR.OLL schrieb:> Kilo S. schrieb:>> Er hat doch was Produziert ;-)>>>> Traffic, Zeitaufwand, Lerneffekt...>> Ja das Server schroten kontraproduktiv ist.
Nein, das ist ein wichtiger Teil des Wirtschaftswachstums!!
Der Thread ist ja nun schon lange tot. ? Und nochmal: es sind meine
Privatserver, es gibt zwei Stück, an zwei verschiedenen Standorten:
Daheim und an meinem Zweitwohnsitz an meiner Arbeitsstelle. Mit
Wirtschaftswachstum hat das aber allerdings nix zu tun... Da wie gesagt
Privat und für mein Hobby. ☺️
Und ja: Server Schrotten ist kontraproduktiv.
Thread beobachten
Seitenaufteilung abschalten