[09:06] <pLaTo0n> moin
[09:24] <burgard> uhuuu vergessen xchat zu starten 
[09:24] <burgard> ...
[10:05] <NTQ> moin
[10:08] <NTQ> Ich hab zwei Server, die LXC Hosts auf ZFS sind. Meine Backupidee ist, dass jeder Host von all seinen Container nachts einen Snapshot macht und den dann inkrementell zum jeweils anderen Server überträgt. Falls ein Server komplett ausfällt, kann man so das Backup direkt auf der anderen Maschine starten. "lxc copy" kenne ich, aber geht das auch inkrementell?
[10:10] <NTQ> Ich hab auch zfs send und zfs receive gefunden. Das sieht schon ziemlich gut aus, aber ich hatte gehofft da gibt es vielleicht schon fertige Skripte, die die Kombination aus LXC und ZFS hier direkt handhaben können. Notfalls schreib ich mir selbst was.
[10:15] <dadrc> Soweit ich weiß, gibt's für LXC nichts fertiges
[10:20] <jimsio> hey, beim recherchieren finde ich bzgl. mnt vs media: mnt - temporäre user mounts. media für removable media. - nun will ich eine partition auf einer internen festplatte dauerhaft mounten. was nehm ich da?
[10:21] <k1l> mnt
[10:29] <leszek> jimsio: im Grunde ganz egal. Du kannst auch einen eigenen Ordner kreiren. Da in /media aber udisks automatisch sachen mountet, wie Wechselmedien, würde ich evtl. doch einen Unterordner in /mnt erstellen
[10:32] <jimsio> intuitiv hätte ich das auch gesagt. danke euch
[10:57] <geser> NTQ: vielleicht wäre drbd was für dich, damit kannst du block-Devices in Echtzeit auf andere Server spiegeln.
[11:05] <NTQ>  geser: Klingt interessant, ist aber hier nicht mehr möglich. zfs ist bereits eingerichtet und die System laufen damit.
[11:05] <NTQ> Ich werde dann was eigenes basteln.
[11:30] <k1l> NTQ: kannst auch in #lxcontainers fragen
[11:33] <NTQ> Ich war bisher immer in #lxc. Da sind sie aber nicht so gesprächig. Warte schon seit ein paar Tagen auf Antwort. Dann probier ich es mal noch dort.
[11:48] <lahmer> hallo leute
[11:49] <lahmer> hier meine Frage: kann mir jemand bitte sagen wie der DD befwhl mit komprimierung geht. ich möchte eine partition sichern dd if=/dev/sda1 of=/tmp/test.img
[11:49] <k1l> lahmer: siehe hier https://wiki.ubuntuusers.de/dd/#Image-einer-Partition-sichern
[11:49] <le_bot> Title: dd › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[11:50] <k1l> dort ist auch beschrieben was man beachten muss und wie man das komprimierte dann wieder einspielt
[11:58] <lahmer> werd ich mal lesen danke
[13:47] <geser> NTQ: drbd wäre eine Schicht unter dem zfs (also zwischen Partition/LVM und Dateisystem). Ich weiß leider nicht, ob man das noch nachträglich zwischenschieben kann. Ansonsten bräuchtest du ein Wartungsfenster für ein paar mv-Befehle.
[13:50] <NTQ> geser: Na ich glaube ich bleibe lieber bei zfs send und receive. Mit drbd kann ich ja erst mal auf einem anderen Server herumspielen und lernen, wenn hier mal unnütze Hardware herumfliegt
[13:53] <geser> NTQ: zfs send und receive kann auch vorteilhaft sein, da du dann eine gewisse Zeit hättest zwischen den Backups um mögliche Pannen zu retten. Bei drbd wird jede Änderung sofort auf die anderen Nodes repliziert (auch die unbeabsichtigten).
[13:54] <NTQ> Ja, das wäre dann ja kein Backup mehr.
[13:56] <NTQ> Mein Skript kann bisher lokal Snapshots aller Container machen und sie nach einer gewissen Zeit wieder löschen. Falls man mal in einem Container etwas versemmelt, kann man so ein sehr schnelles Restore machen. Gleichzeitig wird der neuste Snapshot auf den anderen LXC Host kopiert, falls da noch kein Container mit dem Namen existiert. Falls doch, wird mit zfs send/receive die Differenz übertragen.
[13:57] <NTQ> Am letzten Teil mit zfs send/receive bin ich gerade. Der Rest läuft gut.
[13:57] <NTQ> Bevor ich einen Snapshot mache, fahre ich den Container immer sauber runter und danach wieder hoch, damit alles konsistent ist. Und das geht ja innerhalb von Sekunden.
[13:58] <NTQ> Ich könnte auch stateful Snapshots machen, aber das wäre bei uns hier übertrieben. Das kann ich immer noch optional einbauen, wenn ich Lust hab.
[14:50] <MultiStorm> tomreyn: hello ...
[14:52] <MultiStorm> tomreyn: ich habe mal eine frage an dich, ich habe ja meinen MySQL server so konfiguriert, wie du es angeratten hattest, ich hoffe du erinnerst dich, allerdings sehe bemerke ich allerdins ein komisches verhalten brauche ich für die Verbindung eine Zertifikats datei?
[14:55] <koegs> MultiStorm: du brauchst einen public key, keine zertifikate
[15:05] <MultiStorm> koegs: wie oder wo bekomme ich den ?
[15:07] <MultiStorm> koegs: ist das das ? => https://www.thomas-krenn.com/de/wiki/OpenSSH_Public_Key_Authentifizierung_unter_Ubuntu
[15:07] <le_bot> Title: OpenSSH Public Key Authentifizierung unter Ubuntu – Thomas-Krenn-Wiki (at www.thomas-krenn.com)
[15:08] <MultiStorm> ich bin halt deswegen verwirrt, weil es mal geht und mal nicht, noch merkwürdiger, speicher ich die passwörrter geht es bisher immer ...
[15:36] <koegs> MultiStorm: jetzt denk doch mal kurz in Ruhe nach warum es mit gespeicherten Passwörtern immer geht...
[15:37] <koegs> MultiStorm: und ohne die seite ganz gelesen zu haben, scheint es Public Key Auth bei SSH zu beschreiben, ja
[15:41] <MultiStorm> koegs: naja es liegt sicher nicht an einer fehleingabe des Passworts
[15:42] <MultiStorm> zu langsam ?
[15:57] <koegs> MultiStorm: wie immer gilt, was sollen wir da ohne logs zu sagen???
[16:06] <MultiStorm> ja das ist das problem, der SQL Server scheint das nicht zu protokollieren, jedenfalls habe ich keine logs gefunden
[16:07] <MultiStorm> mir ist schon klar das ihr nicht raten könnt, ich wollte ja auch eigentlich nur wissen ob eine SSH keyfile benötigt wird :-)
[16:44] <koegs> MultiStorm: du musst entweder ein Passwort benutzen oder einen Keyfile anlegen und den Public Teil auf dem Server anlegen. Der Privat Key verlässt nie den Client.
[19:10] <tsal> moin!
[19:11] <jokrebel> namd
[19:12] <tsal> Ich versuche aus einem größerem verzeichnisbaum ein tarball zu erstellen, allerdings wird der prozess immer vom OOM killer abgeschossen. Und das obwohl noch jede menge ram und swap frei sind. Was macht man da am besten?
[19:34] <Frickelpit> den Verzeichnisbaum aufsplitten in kleine tar-Pakete mit Kompression und dann alle zusammen in ein tar packen evtl?
[19:37] <tsal> jo werd ich wohl versuchen
[19:38] <tsal> verstehe ja nicht wie das system OOM sein kann wenn noch 5 GB speicher frei sind
[19:39] <ppq> vermutung: irgendwas mit /tmp und tmpfs
[19:39] <ppq> aber eigentlich sollte tar dort von sich aus nicht hinschreiben, iirc
[19:39] <k1l_> was ist das denn für ein verzeichnisbaum und wie liest du den ein, damit der oom killer anspringt?
[19:40] <ppq> tsal, machst du das per GUI oder CLI?
[19:40] <ppq> wenn ersteres, probier mal letzteres, das muss auf jeden fall funktionieren
[19:40] <tsal> per cli.
[19:41] <tsal> Im prinzip ist das ein windows userverzeichnis, so 100 000 dateien, um 80 GB
[19:42] <tsal> und ich lese es mit tar -cv pfad/zum/verzeichnis | pigz -1 > userbackup.tgz ein
[19:43] <ppq> hm, gleiches verhalten wenn du tar direkt das kompromieren machen lässt?
[19:43] <tsal>  /tmp scheint nur so 150kB drin zu haben
[19:44] <tsal> puh, werd ich jetzt mal ausprobieren. 
[19:45] <Longbottom> tsal: Kann das Dateisystem in dass du schreibst so große Dateien? Manche können nur maximal 4GB große Dateien.
[19:45] <tsal> ext4, sollte eigentlich gehen
[19:48] <tsal> Hier ist der output von so einem OOM kill: http://paste.ubuntu.com/23990428/
[19:48] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[19:49] <tsal> kompression ohne pigz läuft noch, mal gucken ob es auch abgeschossen wird. Dauert halt viel länger
[19:50] <ppq> tsal, ahja, terminal abgeschossen und nicht tar/pigz. dann hat das was mit der pipe zu tun
[19:50] <ppq> vermute mal ein problem mit pigz
[19:51] <tsal> hm, ich dachte das abgeschossene programm ist nicht immer das schuldige
[19:52] <ppq> joa, eben
[19:53] <tsal> hm, was macht man da? pigz nicht mehr benutzen?
[19:54] <tsal> gibt es einen guten weg herauszufinden was genau da schief geht?
[19:54] <k1l_> tsal: könnte sein, dass da mit dem datenstream nicht ordentlich umgegangen wird und stattdessen der ram volläuft.
[19:56] <tsal> kann sein, sah aber nicht so aus bei der beobachtung mit htop
[19:57] <tsal> kann natürlich sein, dass es für einige zeit ok funktioniert, und dann plötzlich eine riesige ram menge anfordert
[19:59] <tsal> Ok, war wohl nicht pigz
[19:59] <tsal> mit tar -cvzf ist es genauso passiert
[20:00] <tsal> diesmal "Feb 13 20:55:01 vdrserv kernel: [1387936.147140] cron invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0"
[20:00] <tsal> aber ergebnis dasselbe: bash abgeschossen
[20:00] <ppq> huh
[20:04] <ppq> probier's mal mit --hard-dereference 
[20:05] <ppq> quelle: http://serverfault.com/a/8734
[20:05] <le_bot> Title: linux - Why does "tar -cSf file.tar source" run out of memory? - Server Fault (at serverfault.com)
[20:06] <tsal> läuft. Habs wieder über pigz laufen lassen damit man auf das ergebnis nicht zu lang warten muss.
[20:08] <ppq> wars das tatsächlich? ok
[20:08] <tsal> nein, jetzt wurde es abgeschossen 
[20:09] <tsal> "Feb 13 21:07:40 vdrserv kernel: [1388692.377255] sh invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0"
[20:09] <tsal> dasselbe ergebnis
[20:09] <tsal> puhhh
[20:09] <k1l_> was sagt denn "free -m"?
[20:10] <tsal> während es läuft oder nachdem es abgeschossen wurde?
[20:11] <tsal> zweiteres ist: http://paste.ubuntu.com/23990580/
[20:11] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[20:13] <tsal> hm, vielleicht ist der speicher fragmentiert? Die kiste läuft seit 16 tagen.
[20:15] <tsal> ich würde den rechner ja neu starten, aber das geht erst morgen abend.
[20:16] <jokrebel> Uptime ist alles! ;-) gute Nacht
[20:16] <tsal> jokrebel: gute nacht!
[20:19] <ppq> tsal, bei RAM spielt das keine rolle, der ist (wie der name schon sagt) wirklich wahlfrei :)
[20:20] <tsal> naja, vielleicht sind nur kleine stücke übrig, sodass es nicht genug am stück alloziieren kann
[20:21] <ppq> da gibt's kein "am stück"
[20:21] <tsal> bei 5GB frei eigentlich schwer vorstellbar...
[20:22] <ppq> tsal, guck mal mit strace was tar da macht
[20:22] <ppq> am besten dann kompression mit tar damit es nur einen prozess gibt
[20:23] <tsal> problem ist halt: wenn der tab abgeschossen wird ist die strace ausgabe weg.
[20:23] <tsal> oder soll ich die in eine datei schreiben lassen?
[20:23] <ppq> jo
[20:27] <tsal> trace läuft
[20:27] <tsal> das kann jetzt dauern... es hat durch das tracen einiges an geschwindigkeit eingebüßt
[20:29] <ppq> tsal, wenn es zu langsam ist, kannst du ja auch tar -v nutzen und dessen ausgabe in ne datei umleiten, ist sicherlich schneller
[20:29] <ppq> so kannst du wenigstens gucken ob es immer bei der selben datei passiert
[20:30] <tsal> ah, ne jetzt wurde es abgeschossen.
[20:30] <tsal> hat doch nicht so lang gedauert
[20:31] <tsal> letzte 2 zeilen: read(8, "\34\21Z\325\262\314&\241/a\351\206\316O\320\357\16\232\32\25\341\217|W\17\332K|\16\17P\204"..., 10240) = 10240
[20:31] <tsal> write(4, "\34\21Z\325\262\314&\241/a\351\206\316O\320\357\16\232\32\25\341\217|W\17\332K|\16\17P\204"..., 10240Process 1929 detached
[20:31] <tsal>  <detached ...>
[20:32] <tsal> hm ich lass es mit tar -v laufen und schau ob es an derselben datei anhält
[20:40] <tsal> ok, es bleibt nicht an derselben datei stehen
[20:41] <ppq> versuch mal die allein zu komprimieren
[20:43] <tsal> ppq: welche meinst du jetzt?
[20:43] <dreamon> Kann man eine Luks Datei auch mit dem Filemanager einbinden? Laut wiki ja. Nur wie geht das? Verwende thunar
[20:44] <ppq> tsal, nevermind, hab das "nicht" überlesen.. sollte auch ins bett
[20:44] <tsal> ich werde es nochmal ohne tmux probieren, und vertag es dann wohl bis nach neustart morgen
[20:45] <ppq> dreamon, der erkennt die nur, wenn sie direkt in der partition liegen. dateibasierte container gehen afaik nicht direkt im dateimanager
[20:46] <dreamon> WIKI: LUKS-Geräte können aber in GUI komfortabel per Maus-Klick eingebunden werden. Das Passwort kann dabei im Falle von GNOME im Schlüsselbund, bei KDE in der KDE Brieftasche hinterlegt werden, sodass LUKS-Geräte ohne extra Abfrage eingehängt werden können.Unter GNOME kann man LUKS-Geräte mittels des GVFS (Gnome Virtual File System) einbinden.
[20:46] <ppq> jo, wie gesagt
[20:47] <dreamon> Aha. Ok, dann halt auf die händische
[20:48] <ppq> einfach ein script anlegen
[20:48] <ppq> ggf. noch einen starter per .desktop file
[20:49] <dreamon> jo. Danke
[20:59] <tsal> hm, interresant. Ohne tmux läuft es... noch...
[21:01] <tsal> der tmux tab in dem ich die ausgabe mit tail -f angesehen habe wurde vom oomkiller abgeschossen
[21:01] <tomreyn> dreamon: wenn du das regelm#ßig brauchst könntest du dir ein loop device mit der luks-datei in fstab schreiben mit user-option und nicht-automatischem mount. dann sollte es im dateimanager autauchen und durch nen klick darauf sollte dann der popup erscheinen. denke ich. ;)
[21:01] <tsal> tar läuft aber weiter... da es ausserhalb tmux läuft
[21:01] <tomreyn> *passwort-popup
[21:04] <tsal> ja ich würde sagen tmux ist schuld...
[21:21] <tsal> so, tar ist durchgelaufen, tmux hat alle tabs bis auf einen vom oomkiller abschießen lassen
[21:21] <tsal> geheimnis gelöst würd ich sagen
[21:22] <tsal> vielen dank an alle die mir bei der fehlersuche geholfen haben!
[21:28] <tsal> so, schlafenszeit. Gn8!