Debian Konfigurationsdateien absichern

[User0101]

Hallo,

gibt es eine Möglichkeit Konfigurationsdateien auf dem Server abzusichern, damit diese Dateien nach einem Update nicht überschrieben werden?
Ich hatte vor langer Zeit ein Problem, mein SSH-Konfigurationsdatei wurde beim Update überschrieben und ich konnte nicht auf mein Server zugreifen.
Was kann ich in so einem Fall machen, damit Login funktioniert?

[tomBuilder]

Hallo,

gibt es eine Möglichkeit Konfigurationsdateien auf dem Server abzusichern, damit diese Dateien nach einem Update nicht überschrieben werden?
Ich hatte vor langer Zeit ein Problem, mein SSH-Konfigurationsdatei wurde beim Update überschrieben und ich konnte nicht auf mein Server zugreifen.
Was kann ich in so einem Fall machen, damit Login funktioniert?

Debian fragt mich, bevor ein Configfile überschrieben wird, üblicherweise mit folgende,m dialog:

---

 Configuration file ``/etc/bar/foo.conf`'

==> File on system created by you or by a script.
==> File also in package provided by package maintainer.  What would you like to do about it ?  

Your options are:

Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version  
D     : show the differences between the versions  
Z     : background this process to examine the  

The default action is to keep your current version.

[erc]

gibt es eine Möglichkeit Konfigurationsdateien auf dem Server abzusichern, damit diese Dateien nach einem Update nicht überschrieben werden?

Die Konfigruation überschreibt es nicht automatisch. Entweder hast du ein ranziges Auto-Update Script, oder beim Update die falsche Taste gedrückt. Die Vorauswahl ist immer N. Spielt dabei auch keine Rolle ob das update mit -y/-yes gestartet wurde.

Was kann ich in so einem Fall machen, damit Login funktioniert?

Kommt drauf an was der Hoster dir da anbietet. Üblich sind eine serielle Konsole, Remote KVM, oder ein Net Boot eines anderen OS. Wenn der Hoster nix derartiges anbietet, muss das ein Techniker des Hosters machen.

[tomBuilder]

und,

solange der rechner nicht den runlevel wechselt, und dann auch nicht nicht immer,
bleibt deine ssh sizung offen, gegebenenfalls lässt sich zukünftig erstmal ein neues login testen, und dann ausloggen ?

und

die dateien in /etc in eine backup einzuschlissen ist nicht die verwerflichste aller ideen.