Feature request: Desaster Recovery

Anregungen & Feature Requests
bert
Posts: 104
Joined: August 5th, 2009, 10:01 am

Feature request: Desaster Recovery

Post by bert » December 14th, 2015, 8:04 pm

Hallo!

Jedes Update ist ein gewisser Nervenkitzel - geht anschließend noch alles? Ruft in 15 min der erste OpvenVPN-Roadwarrior an, weil er keinen Zugriff hat? Etc.

Könnte man nicht eine Funktion implementieren, dass man beim Booten auf die letzte Konfig zurückwechseln kann (inkl ALLER Einstellungen) und/oder eine Backup-Funktion, die wirklich ein bootfähiges ISO erstellt, das automatisch alles so installiert, dass die Kiste wieder läuft?

Michael

User avatar
gocart
Posts: 556
Joined: December 16th, 2013, 4:43 pm
Location: Germany

Re: Feature request: Desaster Recovery

Post by gocart » December 14th, 2015, 8:36 pm

Hallo,

Deswegen betreibe ich meinen ganzen Fire-Zoo in ESXi VMs. (Und noch ein paar andere Gründe) Da kann ich vorher einen Snapshot machen. :) Ich weiß, hilft dir nicht weiter. Ist aber das Konzept wie man an so was heran geht. ps. Jetzt bitte keine Sicherheitsdiskussionen. Die gehen ins Leere!

gocart

5p9
Mentor
Mentor
Posts: 1860
Joined: May 1st, 2011, 3:27 pm

Re: Feature request: Desaster Recovery

Post by 5p9 » December 15th, 2015, 8:59 am

Hi,

die Idee mit "Cache-Modus" bis zur Aktivschaltung fände ich auch gut. Im Moment behelfe ich mich mit Acronis und einem Fullbackup der Disk. Da IPFire nicht so groß ist geht das auch recht schnell und ich habe gleich eine externe Sicherung vor dem Backup samt aller Einstellungen.

VG, 5p9
Mail Gateway: mail proxy

Image

Image

User avatar
MichaelTremer
Core Developer
Core Developer
Posts: 5790
Joined: August 11th, 2005, 9:02 am

Re: Feature request: Desaster Recovery

Post by MichaelTremer » December 15th, 2015, 10:17 am

Hi,

naja, wir machen ja Testreleases. Die sind dazu da, dass man solche Fehler findet, wenn da mal welche sein sollten. Ich wüsste nicht, dass in letzter Zeit OpenVPN so betroffen war wie du es schilderst.

Ich bin gegen solch ein Rollback-Feature aus dem einfachen Grund, dass dann niemand mehr die Bugs reportet. Man dreht halt einfach wieder zurück auf den alten Stand und dann gilt das Motto "aus den Augen, aus dem Sinn". Und die Sicherheitsprobleme, die oft mit den Updates gelöst werden sind dann wieder offen...

-Michael
Support the project with our Donation Challenge!

Get Commercial Support for IPFire and more from Lightning Wire Labs!

Image

bert
Posts: 104
Joined: August 5th, 2009, 10:01 am

Re: Feature request: Desaster Recovery

Post by bert » December 15th, 2015, 11:08 am

MichaelTremer wrote:Hi,

naja, wir machen ja Testreleases. Die sind dazu da, dass man solche Fehler findet, wenn da mal welche sein sollten. Ich wüsste nicht, dass in letzter Zeit OpenVPN so betroffen war wie du es schilderst.
Jahreswechsel 2013/14 hab ich in schlechter Erinnerung. Mit einem Update hat OpenVPN nicht mehr funktioniert. Ersatzmaschine aufsetzen hilft nicht viel, weil ja die Zertfikate der Nutzer nicht passen ...
Ich bin gegen solch ein Rollback-Feature aus dem einfachen Grund, dass dann niemand mehr die Bugs reportet. Man dreht halt einfach wieder zurück auf den alten Stand und dann gilt das Motto "aus den Augen, aus dem Sinn".
Also lieber (viel) mehr (präventive!!!) Arbeit und Ärger auf den Produktivsystemen? So muss man eine Ersatzkiste vorhalten, Image machen vor dem Update, etc. Alles - wie Du selbst richtig schreibst - völlig unnütz und Zeitverschwendung, weil's eh in 98% der Fälle keine Probleme gibt. Aber wenn die 2% eintreten ....

Michael

Hellfire
Posts: 694
Joined: November 8th, 2015, 8:54 am

Re: Feature request: Desaster Recovery

Post by Hellfire » December 15th, 2015, 11:39 am

MichaelTremer wrote: Ich bin gegen solch ein Rollback-Feature aus dem einfachen Grund, dass dann niemand mehr die Bugs reportet. Man dreht halt einfach wieder zurück auf den alten Stand und dann gilt das Motto "aus den Augen, aus dem Sinn". Und die Sicherheitsprobleme, die oft mit den Updates gelöst werden sind dann wieder offen...
Michael,

richtig, aber aus genau diesem Grund wird es auch immer nur sehr wenige freiwillige Tester geben, die bereit sind auf ihren Produktiv-Maschinen eine Beta Version einzuspielen. Testmaschinen haben die wenigsten, wenn dann vllt. noch in einer VM, aber dort kann niemals ein Produktiv-System simuliert werden. Da ist der Aufwand einfach zu hoch.

Was das Anliegen aus dem OP angeht würde es sogar möglicherweise bedeuten, die OpenVPN Clients umzustellen, damit diese in die VM umgeleitet werden um vernünftig bzw. zuverlässig testen zu können und es würde möglicherweise auch bedeuten ganze Netzwerke neu konfigurieren zu müssen ein Update in Gänze testen zu können.

Ich zögere ebenfalls noch mit einem Update auf 95, weil doch das ein oder andere Posting hier schon eingetroffen ist, das Probleme mit der 95er beschreibt. Von daher finde ich die Idee mit dem "Wiederherstellungspunkt" ala Windows gar nicht Mal so schlecht. Der Ansatz klingt jedenfalls gut.
Zumindest könnte man bei ersichtlichen Fehlern diese melden und bei kritischen Fehlern wieder zurück auf den alten Stand gehen.

Ich persönlich würde zeitnah updaten falls das Backup etwas besser geregelt ist, das eingebaute Backup ist halt doch nur für die Settings gut und rsync und wie sie alle heißen sind ja auch nicht gerade benutzerfreundlich. Ob das Backup dann auch nach einem Restore wieder IPFire zum Laufen bring, wage ich (mit meinen bescheidenen Linux Kenntnissen) zu bezweifeln.

Gut, das ist jetzt meine persönliche Meinung aber auch die wollte ich kundtun. Nichtsdestotrotz bin ich mit IPFire sehr zufrieden. Ich hätte zwar noch das ein oder andere Feature mit drin, wie Internet-Zeitkontingente einzelner Hosts aber Mal sehen, eventuell wird's ja was in V3.

Grüße,
Michael
Image

User avatar
MichaelTremer
Core Developer
Core Developer
Posts: 5790
Joined: August 11th, 2005, 9:02 am

Re: Feature request: Desaster Recovery

Post by MichaelTremer » December 15th, 2015, 2:36 pm

Hellfire wrote:
MichaelTremer wrote: Ich bin gegen solch ein Rollback-Feature aus dem einfachen Grund, dass dann niemand mehr die Bugs reportet. Man dreht halt einfach wieder zurück auf den alten Stand und dann gilt das Motto "aus den Augen, aus dem Sinn". Und die Sicherheitsprobleme, die oft mit den Updates gelöst werden sind dann wieder offen...
Michael,

richtig, aber aus genau diesem Grund wird es auch immer nur sehr wenige freiwillige Tester geben, die bereit sind auf ihren Produktiv-Maschinen eine Beta Version einzuspielen. Testmaschinen haben die wenigsten, wenn dann vllt. noch in einer VM, aber dort kann niemals ein Produktiv-System simuliert werden. Da ist der Aufwand einfach zu hoch.
Ich muss das vielleicht noch einmal etwas anders erklären. Ich bin eigentlich nicht generell gegen so ein Feature. Wir haben das in IPFire 3. Allerdings bin ich dagegen, dass das generell die Mode wird das zu tun. Das ist dann so ein bisschen wie mit Windows XP das noch viele Leute nutzen, da sie entweder Angst vor dem Update haben oder wissen, dass danach nichts mehr gehen wird.

Sicherlich ist das ein hoher Aufwand zu testen. Der hohe Aufwand ist im Augenblick aber leider auf wenige Schultern verteilt. Wenn sich mehr Tester einbringen würden, dann würde es von allein schon weniger schwierig werden.
Hellfire wrote:Ich zögere ebenfalls noch mit einem Update auf 95, weil doch das ein oder andere Posting hier schon eingetroffen ist, das Probleme mit der 95er beschreibt. Von daher finde ich die Idee mit dem "Wiederherstellungspunkt" ala Windows gar nicht Mal so schlecht. Der Ansatz klingt jedenfalls gut.
Zumindest könnte man bei ersichtlichen Fehlern diese melden und bei kritischen Fehlern wieder zurück auf den alten Stand gehen.
Bugs in neuen Releases haben wir immer. Das ist nicht schön, aber leider eben so. Manchmal betreffen diese viele Nutzer, manchmal nur wenige. Mit Testen bekommt man das eigentlich gut weg.

Rein technisch habe ich im Augenblick aber keine Lösung wie man das in IPFire 2 implementieren würde.

-Michael
Support the project with our Donation Challenge!

Get Commercial Support for IPFire and more from Lightning Wire Labs!

Image

Massaguana

Re: Feature request: Desaster Recovery

Post by Massaguana » December 15th, 2015, 2:52 pm

Also ich würde mich über solch eine Funktion auch freuen, wie von bert geschrieben ist das Update immer mit Nervenkitzel Verbunden... Ein Vollwertiges Backup würde schon viel helfen...

Das es so wenige Tester gibt wundert mich Persönlich nicht... Ihr macht es einem echt schwer...

Grüße
Massaguana

WhyTea
Administrator
Administrator
Posts: 533
Joined: January 31st, 2011, 8:52 am
Location: Dortmund

Re: Feature request: Desaster Recovery

Post by WhyTea » December 15th, 2015, 3:16 pm

Massaguana wrote:Also ich würde mich über solch eine Funktion auch freuen, wie von bert geschrieben ist das Update immer mit Nervenkitzel Verbunden... Ein Vollwertiges Backup würde schon viel helfen...
Wie Michael schon sagte wird eine solche Funktion nicht generell abgelehnt. Eine Implementierung in IPFire 2.x gestalltet sich allerdings sehr schwierig. Wenn sich allerdings Jemand findet der sich dieser Aufgabe annnehmen möchte... Freiwillige vor! Selbstvesrtändlich würden wir Diesen dann auch nach kräften unterstützen.
Massaguana wrote: Das es so wenige Tester gibt wundert mich Persönlich nicht... Ihr macht es einem echt schwer...
Interessante Aussage! Wie genau machen WIR es einem Tester denn schwer?
If you like to support us, please contribute by donating.

My IPFire@Home - always in stable-tree
Image
Libvirt, Squid, Squidclamav, URL-Filter, OpenVPN, Samba, Cups, Transmission

My 2nd - always in testing-tree

Image
Squid, Squidclamav, URL-Filter, Update-Accelerator, OpenVPN, WLAN-AP, Transmission

WhyTea
Administrator
Administrator
Posts: 533
Joined: January 31st, 2011, 8:52 am
Location: Dortmund

Re: Feature request: Desaster Recovery

Post by WhyTea » December 16th, 2015, 10:37 am

Leider habe ich Antworten auf meine Frage nur per PM bekommen die ich natürlich hier nicht öffentnlich mache.

Dennoch möchte ich, nicht zuletzt, aufgrund Dieser noch einmal etwas zum Thema testen sagen.

Das ganze Thema testen ist ein komplexes und schwieriges Unterfangen.
Einerseits benötigen wir natürlich so viele Rückmeldungen wie möglich andererseits können wir mit einer simplen Aussage wie :"xy geht seit dem letzen update nicht mehr" wenig anfangen.
Wir benötigen dann schon mehr. Nach Möglichkeit eine genaue Beschreibung des Testscenarios (was, wann, wo, wie stellt es sich dar) mit Logfiles und aussagekräftigen Screenshots, sofern möglich.

Eine allgemeingültige Anleitung dafür kann man eigentlich nicht schreiben da man jede Funktion in IPFire anders testen muss.

Daher ergibt es sich häufig, dass Jeder nur das testet und testen kann was er auch benutzt. Und genau dort liegt auch wieder ein Problem. Wenn man feststellt, dass etwas das man benutzt / braucht nicht funktioniert möchte man auch zeitnah einen Fix. Dies ist allerdings nicht immer möglich. Natürlich ist daher das testen für jemanden der nur ein IPFire-System hat en Problem.

Das sehen wir natürlich ein. Aber es gibt auch Einige die 20 und mehr System im Einsatz haben und nicht testen. An diese Appelieren wir um so stärker uns bei beim testen zu unterstützen!
If you like to support us, please contribute by donating.

My IPFire@Home - always in stable-tree
Image
Libvirt, Squid, Squidclamav, URL-Filter, OpenVPN, Samba, Cups, Transmission

My 2nd - always in testing-tree

Image
Squid, Squidclamav, URL-Filter, Update-Accelerator, OpenVPN, WLAN-AP, Transmission

bert
Posts: 104
Joined: August 5th, 2009, 10:01 am

Re: Feature request: Desaster Recovery

Post by bert » December 16th, 2015, 12:47 pm

Ich hab zwar nur 2 IPFire im Einsatz, melde aber jedes Problem (auch ausführlich via bugzilla).

Ich würde auch viel eher updaten und so ev beitragen, Fehler zu finden und zu melden, aber bei dem Riesenaufwand, ein defektes System wieder zurückzusetzen, lasse ich lieber ein paar Tage wenn nicht Wochen (bei großen Updates und vielen Problemmeldungen hier im Forum dazu) vorübergehen. Somit ist das Fehlen einer einfachen Fall-back-Funktion dafür verantwortlich, was das IPFire-Team zu Recht aufzeigt:

- es wird zu wenig rückgemeldet
- es werden Updates nicht rasch eingespielt

Da es hier schon erwähnt wurde: Was genau kann denn IPFire3 diesbezüglich und wann kommt es?

Noch eine Frage: Was (auch) helfen würde wäre eine Möglichkeit, (fast) idente Maschinen über Konfig-Files zu bauen. Also wenn die HW ident ist, sollte es möglich sein, die gesamte (!) Konfig zu übertragen (inkl aller Zertifikate für OpenVPN, etc). Dann könnte man einfach eine Reserve-Kiste vorhalten, die auch bei OpenVPN-Fehlern rasch wieder Zugang schafft.

Michael

WhyTea
Administrator
Administrator
Posts: 533
Joined: January 31st, 2011, 8:52 am
Location: Dortmund

Re: Feature request: Desaster Recovery

Post by WhyTea » December 17th, 2015, 11:11 am

IPFire3 ist aktuell noch in einem sehr frühen Status der Entwicklung. Eine Roadmap geschweige denn einen Releasetermin hierfür gibt es noch nicht. Wenn es so etwas gibt werden wir es veröffentlichen!

Als Desasterrecovery kann ich nur empfehlen vor einem Update ein Image zu machen. Ich selbst nutze Clonezilla [http://clonezilla.org]dafür.
IPFire selbst benötigt nur wenig Speicherplatz und ein Image ist in wenigen Minuten erstellt.

Aufpassen sollte man nur wenn man Große Datenmengen hat. Als Beispiel können bei der Nutzung von Squid, Samba oder Owncloud schnell einige GB an Daten enstehen die man nicht mit einem Festplattenimage sichern sollte. Das dauert einfach zu lange. Daher empfehle ich immer diese Daten auf einem seperatem Laufwerk zu speichern.

Bei einem Hardwarewechsel müssen immer Konfiguartionsnacharbeiten vollzogen werden da sich beispielsweise MAC-Adressen ändern und somit die Netzwerkkonfiguration überarbeitet werden muss.

- Daniel
If you like to support us, please contribute by donating.

My IPFire@Home - always in stable-tree
Image
Libvirt, Squid, Squidclamav, URL-Filter, OpenVPN, Samba, Cups, Transmission

My 2nd - always in testing-tree

Image
Squid, Squidclamav, URL-Filter, Update-Accelerator, OpenVPN, WLAN-AP, Transmission

Massaguana

Re: Feature request: Desaster Recovery

Post by Massaguana » December 17th, 2015, 12:26 pm

Das mit clonezilla klingt Interessant... Kannst du das näher erläutern? Läuft das von nem USB Stick aus?

WhyTea
Administrator
Administrator
Posts: 533
Joined: January 31st, 2011, 8:52 am
Location: Dortmund

Re: Feature request: Desaster Recovery

Post by WhyTea » December 17th, 2015, 1:07 pm

Alle nötigen Informationen findest du hier: http://clonezilla.org/clonezilla-live.php
If you like to support us, please contribute by donating.

My IPFire@Home - always in stable-tree
Image
Libvirt, Squid, Squidclamav, URL-Filter, OpenVPN, Samba, Cups, Transmission

My 2nd - always in testing-tree

Image
Squid, Squidclamav, URL-Filter, Update-Accelerator, OpenVPN, WLAN-AP, Transmission

Massaguana

Re: Feature request: Desaster Recovery

Post by Massaguana » December 17th, 2015, 2:16 pm

Tja, so einfach scheint dies nicht zu sein...

- Ich benötige direkten/ manuellen Zugriff auf die Kiste. Dazu nen VGA Monitor und ne Tastatur...
- Durch das Booten mit clonezilla ist mein Zentrales Netzwerkelement ohne Funktion, d.h. keine Netzlaufwerke...
- Meine ECO bietet nur 2 USB Anschlüsse, also müssen die Daten auf den USB Stick auf dem clonezilla läuft. Was bei 16 GB und der Größe von IPFire möglich sein sollte. Mir wird angezeigt das ich etwa 2,6 GB benötigen würde. Leider bricht die Image Erstellung mit der Meldung nicht genügend Speicherplatz ab.

Damit brauch ich nen USB Hub oder so samt eine externen Festplatte...

Post Reply