Conversation

Notices

1. Embed this notice
   sebsauvage (sebsauvage@framapiaf.org)'s status on Sunday, 06-Apr-2025 21:59:26 JST sebsauvage

   #Linux #sécurité #question
   Beaucoup d'admins Linux sont fiers de l'uptime de leur serveur, et essaient de l'avoir le plus haut possible. Ok je comprend.
   Mais quand on sait qu'il existe une classe de malewares qui subistent exclusivement en mémoire (et qui ne survivent pas à un reboot), est-ce que rebooter son serveur de temps en temps ça ne serait pas - au final - une bonne pratique ?

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 06-Apr-2025 21:59:23 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Breizh
     @breizh @sebsauvage Ouais je verrais plus une fierté d'avoir un joli uptime dans le sens disponibilité du/des services plus que uptime dans le sens manque de reboot.
     Le soucis quelque part c'est que la différence entre les deux est pas souvent faite.
   • Embed this notice
     Breizh (breizh@pleroma.breizh.pm)'s status on Sunday, 06-Apr-2025 21:59:25 JST Breizh

     in reply to

     @sebsauvage C’est mon job, perso, et je connais pas beaucoup d’admins sérieux qui sont fiers au premier degré d’un gros uptime.

     Rien que pour les màj kernel faut reboot régulièrement, personnellement j’essaye de mettre la limite autour de 3 mois (et je fais même un mois sur mes machines perso parce que des fois j’ai la flemme de restart les services un à un après une mise à jour ahah).

     En général un gros uptime est plutôt inquiétant au contraire, parce qu’on a aucune idée du comportement qu’aura la machine au démarrage. Quand on doit tripoter des machines qui ont 2, 3 voire 5 ans d’uptime parce qu’oubliées dans un coin, on est pas sereins au taf… (surtout que leur conf date aussi en général, et n’ont pas forcément été suivies – avec les machines plus récentes et l’automatisation le risque est moindre).

   • Embed this notice
     Lord (lord@pleroma.lord.re)'s status on Sunday, 06-Apr-2025 22:15:09 JST Lord

     in reply to

     @sebsauvage

     15:07:33 up 1145 days, 23:52

     Rock solid ! :-D

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Breizh (breizh@pleroma.breizh.pm)'s status on Monday, 07-Apr-2025 08:08:47 JST Breizh

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Suricat

     @Tacitus @sebsauvage @lanodan Ça dépends du contexte. Pour tes machines persos, tu comptes bien comme tu veux (ou des machines internes sans impacts sur autrui).

     Par contre des serveurs qui hébergent les sites et données de clients, tu vas pas le reboot comme ça. Faut planifier etc, et on va avoir du mal à justifier des reboot trop fréquents…

     Quant à un cas de migration par exemple, prévoir un downtime de quelques heures c’est pas pareil que prévoir un downtime de quelques minutes aussi. Et si celui de quelques minutes devient des heures, c’est pas bon non plus.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Suricat (tacitus@masto.bike)'s status on Monday, 07-Apr-2025 08:08:48 JST Suricat

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Breizh

     @breizh @sebsauvage @lanodan tant que c'est de l'indisponibilité prévue, ça compte pas dans le downtime

   • Embed this notice
     Breizh (breizh@pleroma.breizh.pm)'s status on Monday, 07-Apr-2025 08:08:50 JST Breizh

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @lanodan @sebsauvage Clairement, oui. Pour ça aussi qu’un reboot trop souvent (genre une fois par semaine ou plus), c’est pas bon non plus (sauf si tu tournes sur plusieurs machines avec répartition de charge ou équivalent), parce que ça fait un trou dans la disponibilité.