Spricht eigentlich etwas dagegen die bei einigen Linux Derivaten per z.B. „apt-get update“ angestoßenen Updates für installierte Pakete jede Nacht automatisch z.B. Per Cron Job zu machen?
Ich ertappe mich eh dabei, dass ich beim sporadischen, manuellen Updaten per Terminal sowieso bei Nachfragen immer „Y/es“ mache und nicht vorher in dem Wust nachsehe, ob da vielleicht was nicht upgedatet werden soll. Kann ich in den meisten Fällen eh nicht beurteilen.
Wie handhaben das die Linux Benutzer hier?

Hi Johann,

ja, kannst Du so machen.
Da meine Linux Kisten meist kl. VMs mit speziellen Aufgaben sind, habe ich jede Conf-Datei, welche ich jemals angefasst habe, vorher einmal in .ORG unbenannt und die editierte Dateien sichere ich in ein spezielles Verzeichnis welches Hosts/NameDesHosts heisst.

Diese Verzeichnisse sind genau wie die wirklichen Machinen aufgebaut.
Diese Vogehensweise habe ich mir auf der Arbeit abgeguckt.
Z.B.: habe ich einen Kiste für DNS und einen webserver. Die pfade lauten dann:
Hosts/DNS-Server/etc/bind/db.p.....
Hosts/Webserver/etc/apache2/sites-available/000-default........conf
Hosts/Webserver/etc/php/7.0/apache2/php.ini
Dieses Konstrukt macht mir ein Neuaufbau/Umzug/Wiederherstellen relativ einfach.

Bisher sichere ich diese Dateien auch einfach per script weg.
Angedacht ist aber (deshalb diese Struktur oben), ein script erstellen, welches mir beim hochfahren prüft, ob die gesicherten Dateien einen anderen Zeitstempel haben als die laufenden und mir dann eine email schicken.
So könnte ich immer überwachen, ob mir ein Update meine Konfig kaputt macht.
Aber wie gesagt ist angedacht, scripten ist auch nicht unbedingt meine Stärke.

T@cky

> Spricht eigentlich etwas dagegen die bei einigen Linux Derivaten per z.B.
> „apt-get update“ angestoßenen Updates für installierte Pakete jede
> Nacht automatisch z.B. Per Cron Job zu machen?
> Ich ertappe mich eh dabei, dass ich beim sporadischen, manuellen Updaten
> per Terminal sowieso bei Nachfragen immer „Y/es“ mache und nicht vorher
> in dem Wust nachsehe, ob da vielleicht was nicht upgedatet werden soll.
> Kann ich in den meisten Fällen eh nicht beurteilen.
> Wie handhaben das die Linux Benutzer hier?

Dagegen spricht eigentlich nichts. Die meisten Distros haben aber sowieso nen Update-Mechanismus, die anzeigen, wenn es was Neues gibt. Von welcher Distro reden wir denn?

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> Spricht eigentlich etwas dagegen die bei einigen Linux Derivaten per z.B.
> „apt-get update“ angestoßenen Updates für installierte Pakete jede
> Nacht automatisch z.B. Per Cron Job zu machen?
> Ich ertappe mich eh dabei, dass ich beim sporadischen, manuellen Updaten
> per Terminal sowieso bei Nachfragen immer „Y/es“ mache und nicht vorher
> in dem Wust nachsehe, ob da vielleicht was nicht upgedatet werden soll.
> Kann ich in den meisten Fällen eh nicht beurteilen.
> Wie handhaben das die Linux Benutzer hier?

Hey, das Problem kenne ich  

Habe mich aber erkundigt und damit kannst du eigentlich nichts falsch machen. Wenn du eh nicht nachschaust was geupdatet wird, kannst du es auch automatisch machen lassen. Da spricht nichts gegen. Zudem kannst du im nachhinein ja immer noch anschauen wofür genau das Update jetzt war, wenn es dich denn dann interessiert.

Liebe Grüße 

Die Struktur zur Sicherung der confs ist nicht dumm, da denke ich mal drüber nach. Ich mache es bei meinen Backupskripten der Tuxe so, dass ich nächtens immer jeweils tar.gz mache, welche auch /etc und eventuelle homeverzeichnisse ( z.B. .ssh Krempel usw.) von Usern mit in den Tarball schreiben.
Deine Lösung mit der angedachten Timestampprüfung ist natürlich eine elegante Lösung für derlei eventuellen Fall, dass ein Update da tatsächlich etwas vergriesgnaddelt.
Muss ich mir, zumindest bei den Produktivsystemen, mal genauer Gedanken zu machen, viele Dank für den Denkanstoß!

Debian, Ubuntu und Raspbian. Die haben alle apt/aptitude als Mechanismus. Ich nutze die allerdings headless, ich sehe da im Allgemeinen nicht auf z.B. irgendwelchen Desktopsmeldungen o.ä., dass neue Updates bereitstehen.
U.a. deswegen auch meine Frage, ob ich mir das nicht automatisiere, weil ich nicht dauernd auf allerlei Gerätschaft diese Listen einsehen möchte.
Ggf. schreibe ich je nach Maschine ein Skript für lediglich spezielle Pakete, die upgedatet werden sollen, aber auch das würde ich dann am liebsten CRON an die Wange heften.

> Habe mich aber erkundigt und damit kannst du eigentlich nichts falsch
> machen. Wenn du eh nicht nachschaust was geupdatet wird, kannst du es auch
> automatisch machen lassen. Da spricht nichts gegen. Zudem kannst du im
> nachhinein ja immer noch anschauen wofür genau das Update jetzt war, wenn
> es dich denn dann interessiert.

Na ja, falls z.B. dem ein oder anderen SSH Dämon oder dem systemd-Service bei einem Update etwas passiert stehe ich im Anschluss dumm da. Beim manuellen Update bin ich eventuell noch live in einer bestehenden SSH Session auf der Maschine und könnte noch reagieren.
Würde mir nächtens etwas den Zugang verbauen hätte ich dann erst einmal Aufwand da wieder dran zu kommen.

> Debian, Ubuntu und Raspbian. Die haben alle apt/aptitude als Mechanismus.
> Ich nutze die allerdings headless, ich sehe da im Allgemeinen nicht auf
> z.B. irgendwelchen Desktopsmeldungen o.ä., dass neue Updates bereitstehen.
>
> U.a. deswegen auch meine Frage, ob ich mir das nicht automatisiere, weil
> ich nicht dauernd auf allerlei Gerätschaft diese Listen einsehen möchte.
> Ggf. schreibe ich je nach Maschine ein Skript für lediglich spezielle
> Pakete, die upgedatet werden sollen, aber auch das würde ich dann am
> liebsten CRON an die Wange heften.

Klar, Cronjob bietet sich bei sowas an. Nur manchmal hast du bei Paketen irgendwelche Abfragen, was gemacht werden soll. Dann steht das Ganze halt.

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> Na ja, falls z.B. dem ein oder anderen SSH Dämon oder dem systemd-Service
> bei einem Update etwas passiert stehe ich im Anschluss dumm da. Beim
> manuellen Update bin ich eventuell noch live in einer bestehenden SSH
> Session auf der Maschine und könnte noch reagieren.
> Würde mir nächtens etwas den Zugang verbauen hätte ich dann erst einmal
> Aufwand da wieder dran zu kommen.

Kannst du nicht einen Automatismus einbauen, der bei einem apt-get upgrade nebenher läuft und die Kiste rebootet, wenn apt nicht nach einer gewissen zeit Fertig meldet?
Ich kenn das von Fernwartungen bei Cisco-Routern. Wenn du da aus Versehen die falsche Zeile löschst, hast du dich selber ausgesperrt und kommst erst nach einem Reboot wieder rein. Deshalb startet man bei sowas nen Reboot mit Verzögerung für den Fall.

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> Klar, Cronjob bietet sich bei sowas an. Nur manchmal hast du bei Paketen
> irgendwelche Abfragen, was gemacht werden soll. Dann steht das Ganze halt.

Stimmt, ich erlebe es zwar selten aber es kommt vor. Mindestens bei PHP Updates. Oft poppt da die Abfrage wegen php.ini nach dem Update auf. Speziell dort muss ich einmal schauen, ob der Switch „-y“ bei apt-get update bei sowas greift und den standard triggert. Guter Hinweis, danke.

> Kannst du nicht einen Automatismus einbauen, der bei einem apt-get upgrade
> nebenher läuft und die Kiste rebootet, wenn apt nicht nach einer gewissen
> zeit Fertig meldet?

Muss ich mal drüber sinnieren. Mindestens bei den essentiell wichtigen Systemen die unter allen Umständen per SSH erreichbar sein müssen komme ich um so etwas nicht herum.
Da muss eine Lösung her die SSHD und Firewalltechnisch nahezu kugelsicher ist.
Tja, ist wohl wie in meiner Signatur. Das Einfache zickt mal wieder herum und gestaltet sich schwierig...

> Muss ich mal drüber sinnieren. Mindestens bei den essentiell wichtigen
> Systemen die unter allen Umständen per SSH erreichbar sein müssen komme
> ich um so etwas nicht herum.
> Da muss eine Lösung her die SSHD und Firewalltechnisch nahezu kugelsicher
> ist.

Ich hab meinen vServer so abgesichert, daß ich für SSH ein Zertifikat brauche. Da lief mal ein Angriff über brute force mit was weiß ich wie vielen Loginversuchen. Man könnte das dann natürlich auch noch über VPN spielen wenns ganz sicher sein soll. Außerdem landen bei mir IPs mit einer gewissen Anzahl ungültger Logins automatiach auf einer Blacklist.

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> > Klar, Cronjob bietet sich bei sowas an. Nur manchmal hast du bei Paketen
> > irgendwelche Abfragen, was gemacht werden soll. Dann steht das Ganze
> halt.
>
> Stimmt, ich erlebe es zwar selten aber es kommt vor. Mindestens bei PHP
> Updates. Oft poppt da die Abfrage wegen php.ini nach dem Update auf.
> Speziell dort muss ich einmal schauen, ob der Switch „-y“ bei apt-get
> update bei sowas greift und den standard triggert. Guter Hinweis, danke.

Das kannst du schon so machen, ich meine, da gibt es so einen Schalter. Nur ob Standard immer das Richtige ist, ist halt die Frage. Wobei, ich kann mich nicht erinnern, wann ich das letzte Mal die andere Option genommen hätte.

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0