GentooForum.de

Danke Dir, bell

Das mache ich gleich. Bin grade noch ein Experiment am wagen: Wollte mal die Konsistens von dem Vollbackup mit einer Systemrekompilierung probieren. Das geht schnell, der Server ist ein 'heißer Ofen' . Hat schon von 325 Paketen 130 neugebaut
Mal sehen ob es dann geht...

Was mich nur so sehr wundert: Erinnerst Du Dich, ich hatte Dir mal erzählt, das ich mein System hier zuhause damals auf RAID umstellen wollte, was auch problemlos geklappt hatte: Hatte alles per "cp -a $usw." auf eine externe Platte geschoben, die Plattenvorbereitungen getroffen und zurückgespielt, chroot und nötiges geändert, worauf das RAID auch lief. Ähnlich zu diesem Vorgehen ist doch dieser Fall hier beim Server... Platten vorbereitet, RAID erstellt, gemountet und zurückentpackt. Dann chroot um grub wieder zu installieren. Nur dabei gehts dann nicht... Werd nachher nochmal in den Kernel schauen ob dort "EFI-GPT" enabled ist. Nur warum der Param plötzlich nicht mehr da sein sollte, würde mich auch wundern. Bei Imageerstellung lief das System ja. Also müssten die Parameter ja so übernommen worden sein. Da ist irgendwo ein Fehler, ein klitzekleiner fehler, den ich aber nicht lokalisieren kann, weil infolge System-Nichthochlaufens natürlich in keinem Log finden kann.

Guten Abend/Morgen Josef

Da hast Du Recht Josef, und ich mache Backups auf diese Art und Weise selbst nicht gerne. Die Datenbanke, MySQL und andere empfindliche Dienste hatte ich auch nicht online während der Erstellung. Das würd ich mit phpmyadmin machen, hatte mich dahingehend auch schon eingelesen.

Nach den ganzen Tests von gestern, die Backups (die mit Parameter "Stay In Filesystem" erstellt wurden, um eben nicht virtuell, vom Kernel/Diensten während der Runtime zur Verfügung gestellte Dinge zu sichern, sind mir aber einige Dinge besonders aufgefallen, die ich mal an dieser Stelle schildern wollte:

- Das wahrscheinlich Wichtigste: Sobald der Festplatteninhalt (auch im heruntergefahrenen Zustand) dem Dateisystem enthoben wird (Rescue-System starten und dann sichern) und anschliessend auf ein neuerstelltes Dateisystem zurückfließt, funktioniert das Backup nicht mehr.
Und genau dies ist es, was mich wahnsinnig verwundert und auch beißt, zu erfahren, woran es liegt.

Bell und ich hatten vor kurzer Zeit bei einer Unterhaltung über die Möglichkeit gesprochen, aus einem bestehenden NICHT-RAID-System ein RAID zu machen. Bell erklärte mir da, das man im Rescue/bzw. InstallCD-Environment die Partitionen mounten könne und per "cp -a $Ordner" auf ein anderes Laufwerk verschieben könne, weil man um das RAID zu erstellen, ja die Platte löschen muss, wobei gentoo mitgelöscht würde. Also muss es an einen Verwahrungsort für diese Zeit.

Dies hatte bei mir zuhause auch exakt so funktioniert! Ordner auf andere Platte, RAID erstellt, zurück damit auf die gemounteten mdX-Arrays und die Configs angepasst. Noch gechrootet um grub wiederinstallieren zu können und mdadm zu installieren, initramfs für die mdraid-Module zu bauen, sowie Kernel-Rekompilierung.

Danach startete dann mein exaktes System als SW-RAID-1 neu und ohne Probleme.

Dies habe ich gestern auch zu allererst auf dem Server versucht: In im Rescue gestartet (TFT-Net-Boot vom Serverprovider). Dann die ordner per "cp -a $Ordner" (wie o.g.) kopiert. Platte gesäubert, RAIDs neu und formatiert. Die Ordner zurück und chroot: Kernel/Initramfs neu. Das war auch ein neues System, was ich gestern dafür testweise erstellt hatte. Nachdem es auf die neue Partiitionen zurückkam, (hatte auch auf die UUID´s der Platten in der mdadm.conf sorgfältig geachtet) - startete der Server nicht mehr. Grub installiert, woraufhin ebenfalls das grub2-mkconfig-Problem auftauchte. Wie, wenn ich Tartarus-Backups zurückspiele.

Nur WARUM? Wenn das doch nicht klappen würde, wieviele Serverbetreiber sichern auf diese Art und Weise, dann wäre das doch nicht empfohlen?! Selbst im heruntergefahrenen Zustand gesicherte, mit "cp -a" verschobene Systeme sind nach Rückkehr nicht mehr startbar.

Es mag jetzt die pure Paranoia sein bei mir... Aber das einzige, was ein großer Unterschied zwischen meinem System zuhause und das auf dem Server ist, iest der Kernel: Hier habe ich gentoo-sources, auf dem Server hardened-sources...
Und dies hat ein gradm-Passwort... - Ich könnte mir vorstellen, das während des Bootens dieses Passwort abgefragt wird, weil der kernel womöglich erkennt, das er auf einer HDD mit anderer UUID gestartet wird. Nur davon bekomme ich natürlich nichts mit, weil ich erst mit Starten des sshd-Servers an den Server rankomme. Oder ich muss mir für einen halben Tag "KVM-Over-IP" mieten, wenn ich sowas rausbekommen möchte. Nur das ist nicht grade billig.

Was meint Ihr dazu? Paranoia oder ist da evtl. was wahres dran?

Wie meinst Du "Backup-Zielverzeichnis, bell? Das, wohin das backup auf den SFTP geschoben wird?

Ich hab mir heut nochmal paar Gedanken gemacht und werd mal ein Image auf einem anderen meiner Systeme installieren, also ein Serverimage. Das RAID disablen und mal versuchen es dort zu starten. Auf das Ergebnis wär ich echt mal zu scharf...

Was ich aber heute auch noch gefunden habe: Der Hardened-Kernel mit grsecurity und PaX schränkt wohl in einer besonderen Weise das /proc Dateisystem ein:

Zitat von »http://www.gentoo.org/proj/en/hardened/grsecurity.xml«

Filesystem Protection

Fighting Chroot and Filesystem Abuse

Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.

Ich werd das gefühl nicht los, das das daran liegen könnte.

Hallo bell und Schorsch,

@Schorsch,
Glückwunsch, auch ein Hetzner-Kunde
Mit Deinem Vorschlag, das Ganze in einer VM zu testen, ist nicht schlecht! Ich vermute, das bell Recht hat und ich genau sowas finden werde. Werde die nächsten Tage mal schauen, hier einen Rechner per Acronis zu sichern, ihn danach Platt zu machen und ein Serverimage darauf installiere um zu sehen, was da beim Start genau passiert. Hatte meine Frage auch mal ins Serverforum gegeben, mal sehen ob vielleicht jemand eine Idee hat, dennoch mit Tartarus und speziellen params (unter berücksichtigung der xattr, wie bell meint) erfolgreich zu sichern.

Wie lange bist Du denn schon bei Hetzner?
OT:
Hatte übrigens Deinen Beitrag "Meinung und Erfahrung nach Nutzung von Gentoo über 3 Monate" gelesen Da hast Du aber einiges gelernt, Schrosch! EBuilds zu schreiben kann ich immer noch nicht. Lernen würd ichs wahrscheinlich, aber siehst ja, was ich um die Ohren habe Gentoo x 2 )
Aber ist schon ein Klasse System. Egal wo 'Du' davon erzählst, die leute, die jahrelang Debian nutzen, Debian wie sich selbst kennen, probieren gentoo aus und wollen nicht mehr zu Debian zurück. Innnerhalb 1 Monat nun 3 solcher User in anderen Foren erlebt
Gentoo war nach meinem Distro-Hopping von Sommer 2011 das letzte, das ich probiert habe. Kennen tu ich es länger schon, aus einem IRC im Jahre 2002/2003. Als gentoo ganz neu war. Doch nach Lesen der HowTo´s war ich froh, Debian gehabt zu haben. Da dies aber bei mir zuhause nicht lief und ich einheitliche Systeme auf Server und zuhause verwenden wollte, arbeitete ich mich dennoch dann ein. Solltest Du bell und Josef also mal ergraut antreffen, ich bin es schuld ) An dieser Stelle mal 1000den Dank an die beiden. Ohne sie wäre ich nicht soweit wie ich nun gekommen bin!
/OT

@bell,
Wie ich gegenüber Schrosch schon erwähnt hatte: Denke, Du hast Dein Bauchgefühl nicht zu unrecht! Und ich vermute, das das Rescue-System keine xattr handlen kann. Denn das System, was ich erstellt hatte, das Minimal-Probesystem, konnte nach verschieben per "cp -a Memorystick" und zurück auf die danach geleerte und neupartitionierte Platte ebenfalls nicht mehr gestartet werden.

PaX Parameter hatte ich in dieser (Probe-Mini) Installation folgende aktiv:



Im Serverenvironment, das ich die letzten Monate in Betrieb hatte, waren nicht nur PaX, sondern gar grsecurity und sysctl aktiv. Alles, was grsec und PaX nur anbietet:

GrSecurity


Im Moment verwende ich bei der komplett neuaufgesetzten Installation zwar wieder hardened-Sources, jedoch ohne jegliche PaX-Parameter. PaX ist derzeit im kernel disabled. Sowie grsecurity.

Was mir aber noch zu meiner geplanten Testreihe, solche Images hier zum Laufen zu bringen, zu untersuchen, einfällt:
Anfangs, im kompletten Serverenvironment hatte ich KEINE Hardened-Sources installiert, sondern, wie hier zuhause auf meiner Mühle, gentoo-sources. Die Images, habe ich ALLE auch hier zuhause bei mir auf BlueRays gesichert. Somit: Zwar eine Menge Arbeit, doch testen - welches Image lässt sich restoren/welches nicht... (kernelabhängig) - dürfte interessant werden. Aber ich glaub jetzt im Voraus schon: Du liegst mit Deiner Vermutung richtig, bell!

PS. Jetzt wird mir auch klar, warum selbst nach der kompletten Systemrekompilierung von vergangener Woche mein MailSystem zwar startete, aber lief wie ein "Sack Nüsse". Konnte weder Senden, noch empfangen. Habe jede der fast 20 Konfigs: Dovecot/Postfix MySQL-Auth wahrscheinlich 5mal durchgecked und verglichen. (Habe per 'scp' wichtige Configs immer zu mir nachhause heruntergeladen und hier gesichert. So konnte ich gut vergleichen: Wann war welche Config welcher Version, wie aufgebaut. - Nirgends Fehler gefunden Trotzdem lief nichts :/

Ihr kennt mich doch , ihr wisst, das ich keine Ruhe finde, solange ein Problem, was ich nicht begreife, besteht...

Bell, hab was bezüglich Deiner Vermutung gefunden:

Zitat

Hardened-Sources-Dokumentation

Can I disable PaX features at boot?

Although this is not advised except when used to rescue the system or for debugging purposes, it is possible to change a few of PaX behaviours on boot via the kernel command line.

Passing pax_nouderef in the kernel cmdline will disable uderef which can cause problems on certain virtualization environments and cause some bugs (at times) at the expense leaving the kernel unprotected against unwanted userspace dereferences.

Passing pax_softmode=1 in the kernel cmdline will enable the softmode which can be useful when booting a not prepared system with a PaX kernel. In soft mode PaX will disable most features by default unless told otherwise via the markings. In a similar way, pax_softmode=0 will disable the softmode if it was enabled in the config.

Heißt für mich jetzt mal:

1.) Hast Recht, bell
2.) Evtl. könnte man ein System zurückspielen, es auch starten, wenn man in die Kernelzeile von grub einbaut, weil dies mit einem Systemstart eines PaX-'UNvorbereitetem' Systems vergleichbar ist... Der kernel versucht über die xattr das Dateisystem anzusprechen, was nicht mehr gelingt: Systemstart schlägt fehl.

Beschlossene Sache: DAS probier ich hier mit einem Rechner aus

Zitat von »bell«

Warst Du zwischen den beiden Posts an dem Thema dran? Falls ja, solltest Du jetzt ausschlafen, bevor Du weiter machst
Und mache bitte das [gelöst] wieder raus, denn das Problem ist es anscheinend ja noch nicht.
Berichte ob der Boot-Parameter was verändert. Ist ja echt Spannend.

Hallo bell && Schorsch,

Jo, heute, äh, gestern Morgen hab ich mich auch entsprechend gefühlt Hatte dann aber paar h geschlafen, bis Mittag. Dann habe ich erstmal noch ein anderes kleines Bestätigungsexperiment gestartet:
Hatte doch erzählt, das ich vor kurzer Zeit nach Deiner Anleitung per auf einen externen Datenträger verschoben habe, dann hier ein RAID mit 2 baugleichen Laufwerken erstellt habe. Das hatte ja auch alles exakt funktioniert. Leider hatte ich aber an diesem RAID nicht lange Freude, weil eine der beiden Platten kaputtging. Das erste Mal fror beim 'world'-Update gentoo ein. Stand 6 Stunden bei Paket xyz Ich war nicht zuhause, dachte, 'wenn ich gleich heimkomm, schnell noch neustart und aus...' aber daraus wurde nichts. Dann verwendete ich die Platte weiter und eines Tages startete dann nach GRUB-Echo: "....wird geladen" nichts mehr. Da ich aber nicht wieder alles auf NON-RAID stellen wollte, hatte ich ein Image zurückgespielt und dann ohne RAID weitergemacht.
Nur waren die Partitions-Tabellen MsDos. GPT gefällt mir aber irgendwie besser da es auch größere Partitionen unterstützt und halt fortschrittlicher ist.

...da es sich auch gut als Bestätigung, das ein -normaler- Kernel 'übertragbar' ist, eignet, hab ich dann gestern beschlossen, mein System per gentoo-livecd zu starten, und per alles auf ein externes Laufwerk zu verschieben. Wie damals. Und auch genauso wie ich es als Alternative zu tartarus-Sicherung beim Server probierte. Platte im Rechner leergemacht, mit parted, mklabel gpt, gpt-vorbereitet. (Ausserdem hatte ich schon länger vor, swap als allererste Partition zu verwenden, erst DANACH /boot - weil am Anfang die Platte schneller ist). Vom externen LW zurück per 'cp -a' auf die neuen Partitionen. (Kleine Korrektur: Bei gpt muss man eine kleine unformatierte partition am Anfang des Laufwerks erstellen um grub später installieren zu können, da gpt im Gegensatz zu MsDos KEINEN MBR besitzt).
-> chroot -> Kernel neukompiliert, weil ich ein Modul hinzufügen wollte. -> initramfs neu -> world-update -> neustart: Einwandfrei! Und NUN, nächste Woche wird das aber wahrscheinlich, sonst werde ich von meiner Frau geschlachtet (bringt aber keine neuen tiefergehenden PaX-Erkenntnisse ) - das EIGENTLICHE Experiment. Doch wie man wieder sah, mit gentoo-sources aufgesetzte Systeme machen keine Probleme beim abheben und umportieren.

Nächste Woche , auf jeden Fall. Das ist echt spannender als der beste Kinokracher
Sollte sich wirklich herausstellen, das der o.g. Parameter, PaX per Kernelzeile zu disablen um das System temporär im NON-xattr zu bedienen, Abhilfe schafft hatte ich mir mal paar Gedanken gemacht, wie weiter verfahren werden könnte, denn PaX soll ja danach wieder funktionieren:

Ich könnte mir vorstellen, den Kernel dann ohne PaX zu rekompilieren, neuzustarten, diesmal ohne Kernelzeilenparameter. Ob das geht. Wenn JA, den Kernel nochmal rekompilieren damit er neue xattr erstellt und anwenden kann. Sollte das wider Erwarten NICHT funktionieren, bliebe noch ,damit das hardened-toolchain (binutils, usw.) mit neuerstellt wird. Dann sollte es aber spätestens gehen. Kommt nächste Woche

@Schorsch,

Mit Hetzner bin ich bis jetzt auch sehr zufrieden. Ich schreibe mit jemandem aus einem anderen Forum noch, der aufgrund dessen, das kaum mehr ein Serverhoster Kunden an Vertragslaufzeiten bindet, mittlerweile bei 4 Providern Server gemietet hatte, und mittlerweile 2 Ausfälle, jedoch nie einen, solange er bei Hetzner vorher jahrelang Kunde war(!). Er kommt nun wahrscheinlich auch zu Hetzner zurück.

Schorsch, Du sagst, das Du ein Gentoo-Hardened - basierendes Image für Deinen Server bei Hetzner lokal per VM vorbereitest. Bedeutet ja, - ähnlich meines Vorhabens - ein Image auf "fremde" Partitionen zu übertragen. Wenn ich, um mein Vollbackup aufspielen zu können, den Inhalt des Servers löschen muss, und danach mein Image nicht mehr geht... dann sehe ich, das Du evtl. auch, sofern Du PaX im Kernel enabled hast, in die selbe 'Misere' rennen könntest, die ich gerade habe/hatte.
Ich hätte einen Vorschlag: Natürlich nur, wenn Du einverstanden bist!
Dein Hardened-gentoo-System befindet sich derzeit in Deiner VM, soweit hab ich Dich richtig verstanden? Hättest Du was dagegen, dieses Image, was Du dort erstellst, auf eine 2te VM zu übertragen und dort zu starten?
Das müsste für PaX genug sein, sein 'wahres Gesicht' zu zeigen. Nicht nur mir/uns hier würdest Du bei unserem Problem helfen, sondern Dir selbst auch: Du würdest wissen, ob Dein Image per hardened-PaX-xattr auf einem anderen System laufen kann... - ...und noch bevor Du es an Deinem Root ausprobieren wirst!

Das wäre wirklich echt hilfreich für uns alle hier, zu wissen! Nichts desto Trotz werd ich nächste Woche auch hier etwas mit dem Image experimentieren

Vielen Dank Euch Beiden, @bell und @Schorsch

Hallo Schorsch_76, Josef und bell,

Zitat von »schorsch_76«

Wikipedia [1] meint, dass xattrs nicht sehr von den Userspace Programmen unterstützt oder genutzt werden. Ich denke dass dies ein Thema beim Backup per cp sein könnte.

Jep! Denke genauso. Bzw. Ich hatte mir vom Serverprovider, also, von Hetzner probeweise einen 16gb Stick anschliessen lassen. Die wollten für paar h kein Geld dafür, nur wenn er dauerhaft als zusätzlicher Datenträger arbeitet, am Server verbleibt, kostet es Gebühr.

Dann hatte ich im Rescue gebootet und per 'cp -a $Ordner' halt alles von den gemounteten RAID-Platten auf den formatierten und gemounteten Stick geschickt. Nach wiederherstellung startete der Server aber auch in diesem Fall leider nicht!
Vermute, Du wirst, wenn Du per cp -a genauso verfährst, ähnliches feststellen. Vielen Dank Dir übrigens für Deine Hilfsbereitschaft!!!
Was mich nur wundert:

Zitat von »bell«

	Quellcode
1 2 3	--preserve[=ATTR_LISTE] Angegebene Dateiattribute erhalten (Voreinstellung: "mode,ownership,timestamps"), wenn möglich weitere Attribute erhalten: context, links, xattr, all

Das "-a" nimmt also context, links und xattr noch zusätzlich mit.

Und genau an dieser Stelle komme ich dann in große Verwunderung: Wenn er bei cp -a die xattr´s mitberücksichtigt, was löst dann den Fehler aus? Dann müsste es ja normalerweise gehen.

Mit dem Rescue-System, bell, das ist ein Minimal-Debian-System mit neuerem Kernel und einigen anderen Sachen aus dem Debian-Testing-Sortiment. Also wenn Schorsch eine Debian-Live-CD oder auch GentooLiveCD nimmt, dann müsste der Vorgang eigentlich, sofern er per 'cp -a' vonstatten geht, sehr ähnlich meines sein.

Das aber tartarus die xattr nicht mitnimmt... Ich vermute, man muss in diesem Falle tartarus eine Parameterzeile einfügen, das er diese Params mitnehmen muss. tartarus ist speziell für Rootserver-Backups zugeschnitten und mich würde ein Fehlen einer solchen Möglichkeit - speziell in diesem Falle - doch echt extrem verwundern.

Praktisch wie die Zeile: "Stay in Filesystem" - Könnte es doch auch die Zeile: "Preserve all xattr on Kernelmarkings" geben, nur um ein Beispiel zu nennen. Hab schon überlegt, Wertabyte (Programmierer von tartarus) mal zu kontaktieren. Im Serverforum schweigt man sich auch aus darüber

@Josef
Jo, Humor tut gut Mal sehen ob wir die gentoo-Airlines noch erleben

Den Stick müsste ich nochmal anschliessen lassen. Sonst hätte es mir zusätzliche Kosten erzeugt. Das kann ich aber nochmal beauftragen. Das andere könnte ich mal gleich überprüfen. Könnte funktionieren, da ich im Rescue-System ebenfalls user "root" bin. Das System, wird wie ich verstehe per netboot geladen und steht während der gesamten Arbeit dann ausschliesslich im RAM. Man bekommt jedesmal ein anderes Pass wenn man das Rescue aktiviert.