mikrocontroller.net

Forum: PC Hard- und Software [Linux] Ubuntu Server geschrotet?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Rene K. (xdraconix)


Bewertung
-1 lesenswert
nicht lesenswert
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 :

chown -R www-data:www-data /

anstelle eines:

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?

von TestX (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Backup einspielen oder neu installieren. Alles andere dauert länger

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Rene K. (xdraconix)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Andreas B. (andreasb)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Rene K. (xdraconix)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Rene K. (xdraconix)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Mathias A. (mrdelphi)


Bewertung
-1 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
von Kalle (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Zunächst sollte geklärt werden, ob wirklich geschrotet gemeint ist oder 
nicht eher geschrottet.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Jo, ich fürchte wenn er den geschrotet hat,
ist echt nichts mehr zu machen.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Wobei "*" doch eher etwas von einem Schrotschuss als von einem 
Präzisionsschuss hat.

von Rene K. (xdraconix)


Bewertung
-1 lesenswert
nicht lesenswert
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. 😅

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.ä.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Oder eben auch das System sichern.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von MVP (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von vn nn (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
vn nn schrieb:
> Es ist immer hilfreich, ein System auf Knopfdruck nachbauen zu können.

Natürlich, aber das ersetzt eigentlich keinen Backup.

: Bearbeitet durch User
von woas i nit (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
vn nn schrieb:
> Es ist immer hilfreich, ein System auf Knopfdruck nachbauen zu können.

ansible rocks ;-)

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Ctrl+Z (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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..

von Dirk J. (dirk-cebu)


Bewertung
-2 lesenswert
nicht lesenswert
Mit Windows wäre das nicht passiert ;)

von Administrator (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dirk J. schrieb:
> Mit Windows wäre das nicht passiert ;)

icacls hilft, man muss nur mehr schreiben ;)

von Rene K. (xdraconix)


Bewertung
2 lesenswert
nicht lesenswert
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 😅

von A. K. (prx)


Bewertung
3 lesenswert
nicht lesenswert
Du solltest noch die SSH Host Keyfiles neu generieren.

: Bearbeitet durch User
von vn nn (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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!

;)

von TR.OLL (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Seit wann schrotet man Server?

von Bäcker (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Ben B. schrieb:
> Jo, ich fürchte wenn er den geschrotet hat,
> ist echt nichts mehr zu machen.

Doch, ein SchrotUbuntubrot.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Ganz normaler Schritt in der Müllverwertung.

von Bäcker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von TR.OLL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ganz normaler Schritt in der Müllverwertung.

Auch eine Methode das Problem zu beseitigen.

von Mathias A. (mrdelphi)


Bewertung
0 lesenswert
nicht lesenswert
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!

Beitrag #6133458 wurde vom Autor gelöscht.
von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kilo S. (kilo_s)


Bewertung
0 lesenswert
nicht lesenswert
Er hat doch was Produziert ;-)

Traffic, Zeitaufwand, Lerneffekt...

von TR.OLL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kilo S. schrieb:
> Er hat doch was Produziert ;-)
>
> Traffic, Zeitaufwand, Lerneffekt...

Ja das Server schroten kontraproduktiv ist.

von Reinhard S. (rezz)


Bewertung
0 lesenswert
nicht lesenswert
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!!

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.