Journal Éteindre son serveur la nuit et l'allumer automatiquement le matin

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
46
23
jan.
2022

Une situation classique

Imaginons une machine physique sous Linux hébergeant des services habituels (partage de fichiers, VPN…) utilisé par une petite entreprise/collectivité. Dans l'optique d'économiser de l'énergie, ce serveur devrait être allumé le matin et éteint le soir, automatiquement. Après tout, il faut bien qu'on divise notre production de CO2 par deux d'ici à 2030, ça ne va pas se faire tout seul.

Le serveur est un classique Dell PowerEdge T110 II, qu'on peut trouver d'occasion pour peu cher. Avec trois disque 3,5", il consomme entre 32 et 55 W selon mes mesures. Éteint entre minuit et 7h du matin, on économise donc entre 81 et 140 kWh par an. C'est pas grand chose mais c'est déjà ça.

Malheureusement, le BIOS ne permet pas de programmer un allumage automatique.

On peut quand même

Si je comprends bien, les machines qui implémentent ACPI (Advanced Configuration and Power Interface) et qui disposent d'une pile (pour garder l'heure), peuvent être programmées depuis le système d'exploitation pour démarrer automatiquement à une heure donnée : c'est le ACPI wakeup. Génial !

Sous Linux on y accède par le pseudo-fichier /sys/class/rtc/rtc0/wakealarm. C'est très basique, puisqu'on ne peut y lire/écrire que le prochain démarrage prévu, sous forme du nombre de secondes depuis epoch.

On veut le script !

Oui, on est donc obligé de faire un script qui, chaque jour, programme le prochain démarrage. Comme tout ce qui a trait à la gestion du temps, on se fait vite des nœuds au cerveau. C'est pour vous éviter ça que j'ai mis mon script et les explications sur Framagit. Je vous invite également à consulter le wiki de MythTV qui parle de cette fonctionnalité plus en détail.

  • # Quel circuit agit ?

    Posté par  (site web personnel) . Évalué à 5.

    Intéressant.

    Mais si l'UEFI ne gère pas et que l'OS est en veille, quel est le circuit qui réveille l'ordinateur ? Est-ce le circuit de l'horloge qui envoie un signal de réveil ? Est-ce que ce signal est envoyé à l'alimentation ? (qui réveillerait alors le CPU ?)

    • [^] # Re: Quel circuit agit ?

      Posté par  . Évalué à 8.

      il y a pas mal d'explication ici : https://www.linux.com/training-tutorials/wake-linux-rtc-alarm-clock/

    • [^] # Re: Quel circuit agit ?

      Posté par  . Évalué à 10. Dernière modification le 23 janvier 2022 à 21:42.

      Pour aller un peu plus dans le détail, il y a plusieurs réponses à ta question.

      Réponse 1 :

      Sur un serveur, tu vas souvent avoir un module de gestion du système qui ne s'éteint pas : le Board Management Controller (BMC). Sur les Dell c'est l'iDRAC je crois. Ça permet par exemple d'accéder à la console en réseau par une adresse IP séparée de celle de l'OS, éventuellement sur un câble dédié. Ça permet de gérer le serveur à distance : mettre à jour le BIOS, monter des clés USB par le réseau, voir la console, allumer/éteindre/reboot même quand le système est planté, gérer le retrait et l'insertion d'une alimentation à chaud, etc…

      On peut imaginer que le BMC possède une RTC ou en émule les fonctions. Et comme il ne s'éteint pas tant que les prises de courant sont branchées, ben il peut allumer le reste de l'ordi.

      Réponse 2 (cas plus général je pense) :

      Une puce RTC, c'est un petit composant électronique assez cher (1€), qui permet d'avoir l'heure, de gérer des alarmes, des comptes à rebours. On y accède par un bus série type I2C, entre autres possibilités.

      Par exemple, le MAX31341 est une RTC fabriquée par Maxim. Dans la doc, les pages 1, 7 et 8 donnent une idée du truc. Page 23, les registres de la première alarme sont décrits (c'est ce qu'on programme via le bus I2C).

      La doc du kit d'évaluation de ce composant RTC donne une idée de comment le mettre en œuvre, et de le repérer sur une carte mère. Sur la photo en page 1, la RTC est le petit carré noir avec marqué "U1" à côté (c'est pas que j'ai des bons yeux, c'est que c'est marqué page 11 et page 12 :D).

      Dans ce cas, on peut imaginer que la puce RTC va envoyer un signal "Allume toi" (équivalent de l'appui du bouton POWER ON du châssis, en gros) à la carte mère (selon la norme ATX j'imagine).

      Il y a sans doute d'autres réponses possibles, en fonction des cas (par exemple le CPU contient une RTC directement). J'ai approximé, mais je ne suis pas un spécialiste du sujet :D.

      • [^] # Re: Quel circuit agit ?

        Posté par  . Évalué à 3.

        pour ceux qui ne connaisse pas RTC : real time clock

        vous pouvez l'interroger directement avec la commande : hwclock

    • [^] # Re: Quel circuit agit ?

      Posté par  . Évalué à 8. Dernière modification le 24 janvier 2022 à 08:00.

      Bonjour

      Pour lire la date/heure donnée par la RTC
      il y a aussi :

      cat /proc/driver/rtc

      et pour ceux qui utilisent systemd
      il y a aussi :

      datetimectl

      Si vous voulez programmer un réveil automatique de la machine dans les 5 minutes suivantes, vous pouvez lancer, avec les privilèges du compte utilisateur root
      la ligne de commandes suivante :

      echo 0 > /sys/class/rtc/rtc0/wakealarm && date '+%s' -d '+ 5 minutes' > /sys/class/rtc/rtc0/wakealarm

      Après avoir lancé cette ligne de commandes,
      la RTC de votre machine la remettra en route 5 minutes plus tard
      sans que vous ayez besoin d'appuyer sur le bouton marche/arrêt

      vous pouvez, avant et après avoir lancer cette ligne de commandes,
      voir l'état des registres de la RTC en lançant un :

      cat /proc/driver/rtc

      et vous pourrez vérifier que la date/heure de réveil a bien été programmée
      et que l'interruption alarm_IRQ a été activée.

      J'utilisais cette méthode pour réveiller ma machine à 13:00 qui était de l'autre côté de la France de façon à pouvoir y accéder par une connexion ssh et la première chose que je faisais quand j'y étais connecté, c'était de désactiver le script qui la faisait se mettre hors tension à 13:30

      Avant de fermer ma session, je programmais la RTC pour que ma machine démarre automatiquement le jour et l'heure à laquelle j'avais prévu de m'y reconnecter.

      NOTE :

      • La RTC de mon ancien Asus GW53SW n'acceptait pas une heure de réveil
        en dessous de 121 minutes à partir de la date/heure actuelle.

      • À l'époque, les premiers PC n'avaient pas de RTC, alors on mettait quelques lignes dans le fichier autoexec.bat pour demander à l'utilisateur d'entrer la date et l'heure courante.

      • [^] # Re: Quel circuit agit ?

        Posté par  . Évalué à 2. Dernière modification le 24 janvier 2022 à 01:39.

        Bonjour

        Est-ce qu'un modérateur pourrait insérer dans la première ligne de l'avant dernier paragraphe de mon précédent message :

        à 13:00

        Ce qui donnera :

        J'utilisais cette méthode pour réveiller à 13:00 ma machine qui était de l'autre côté de la France …

        Désolé pour cet oubli.

        En vous remerciant par avance.

        Cordialement.

        • [^] # Re: Quel circuit agit ?

          Posté par  (Mastodon) . Évalué à 3. Dernière modification le 24 janvier 2022 à 08:01.

          Corrigé, merci.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # WOL

    Posté par  . Évalué à 8.

    Une autre idée,

    éteindre n-1 serveurs et utiliser celui qui reste allumé pour émettre des "magic packet"

    • [^] # Re: WOL

      Posté par  . Évalué à 9.

      Ou utiliser un Raspberry pi pour ça. C'est pas cher et ça consomme quasiment rien.
      Si t'as une Freebox, tu peux avoir aussi une image docker qui fait ça.

      • [^] # Re: WOL

        Posté par  (site web personnel) . Évalué à 4.

        J'ai mis un routeur OpenWRT avec 2 interfaces devant mon serveur, quand un paquet passe à destination du serveur, il y a un délai des 3 secondes le temps qu'une requête WOL soit envoyée au serveur qui dort un Suspend-to-ram.

        Je vais essayer de trouver le temps pour publier mon setup et mes scripts quelque part.

        A noter que la consommation électrique n'est qu'une petite partie de l'empreinte CO2, la majorité du CO2 émit est dans la production du matériel.

        • [^] # Re: WOL

          Posté par  . Évalué à 7.

          la consommation électrique n'est qu'une petite partie de l'empreinte CO₂

          <Contribution trollogène>
          D'autant que, pour le moment, une grande part de l'électricité est nucléaire et donc verte décarbonée…
          </Contribution trollogène>
          (vous pouvez moinsser)

  • # NIH !

    Posté par  . Évalué à 10.

    Hooo, une nouvelle roue !
    Pour la prochaine fois, tu pourras utiliser rtcwake qui fait ce que fait ton script, en y ajoutant une éventuelle mise en veille (S1, S3, S4) ou extinction (S5, avec la précision «Not officially supported by ACPI, but it usually works.»).
    Au passage, as-tu calculé la consommation de courant du démarrage du serveur par rapport à la consommation du serveur en veille ?
    Imaginons que la veille consomme 1W (optimiste), alors que le démarrage consomme 150W pendant 2 minutes (franchement vu le POST d'un PowerEdge c'est gentil).
    On a besoin d'éteindre pendant plus de 5H pour que la veille soit moins rentable que le démarrage… et c'est pas si loin que ça des 7H de coupure mentionnées ici.

    • [^] # Re: NIH !

      Posté par  . Évalué à 10.

      Attendu que :

      1. les disques durs mécaniques n'aiment pas du tout démarrer (les moteurs grillent à l'allumage en général) ;
      2. L'électronique vieillissante de la gamme Tx10/Rx10 va aussi apprécier moyennement ;
      3. Le consensus actuel est que c'est la fabrication du matériel qui est polluante et non pas son utilisation ;
      4. Changer un disque dur, c'est fabriquer du matériel ;

      il faut voir si c'est rentable écologiquement et financièrement de faire l'allumage et l'extinction tous les jours. Peut-être que seulement le week-end, pendant 2,5 jours, serait un meilleur équilibre, par exemple ?

      (et merci pour les infos sur ACPI Wakeup, je ne connaissais pas !)

      • [^] # Re: NIH !

        Posté par  . Évalué à 5. Dernière modification le 24 janvier 2022 à 09:25.

        J'ai un WD série verte (je subodore que vert est pour faire penser à "écologique", pas à "Bibliothèque verte" ni à "Islam", en tout cas je ne l'entends par réciter une sourate à chaque réveil), qui se met en sommeil automatiquement après une certaine période d'inactivité (10 ou 15 mn, je pense). L'inconvénient, c'est qu'il met 8 s à être accessible quand on le sollicite en état someilleux,, (ce qui est absolument intolérable, j'admets, j'ai dû perdre 2 ou 3.000 précieuses secondes dans ma courte vie de ±1,8*109 s, et le pire c'est que je ne sais pas où solliciter mes points carbone). Tout ça pour dire que j'imagine que WD a dû penser que le redémarrage n'était pas trop nocif, ou a dû prévoir un système pour que le HD ne souffre pas de ces démarrages à répétition, en tout cas ça fait 5 ans que je l'ai (dit-il en agrippant fermement une pièce en bois non synthétique).

        • [^] # Re: NIH !

          Posté par  (site web personnel) . Évalué à 2.

          Merci pour vos commentaires sont très intéressant, et font vraiment douter de la pertinence de mon idée :-)

          1. J'avais raté le fait que la mise en veille était optionnelle avec rtcwake, c'est pour ça que je l'avais écarté.
          2. La veille semble effectivement par rapport à un arrêt complet (compte tenu de la consommation au démarrage), d'autant que c'est certainement plutôt 5 W arrêté.
          3. Je ne connais rien en électronique, mais même si j'imagine bien que les moteurs des disques « souffrent » au démarrage, je ne crois pas déjà avoir vu un disque dont le moteur a lâché (on entend toujours le disque tourner). Après je dépanne plutôt des ordinateurs, donc les disques sont différents. Avez-vous d'autres expériences que moi là-dessus ?
          4. Je ne connais rien en électronique : est-ce que les composants électroniques d'un serveur (autres que les disques) s'usent plus au démarrage / en fonctionnement / en sortie de veille ?

          • [^] # Re: NIH !

            Posté par  . Évalué à 3.

            Je ne connais rien en électronique, mais même si j'imagine bien que les moteurs des disques « souffrent » au démarrage, je ne crois pas déjà avoir vu un disque dont le moteur a lâché (on entend toujours le disque tourner). Après je dépanne plutôt des ordinateurs, donc les disques sont différents. Avez-vous d'autres expériences que moi là-dessus ?

            J'ai déjà eu en réparation plusieurs disques dont le moteur avait lâché. Et là c'est poubelle et espérer que l'utilisateur a fait des sauvegardes (ou tenter plusieurs fois, genre 20 ou 30 fois, et espérer que le disque démarre au moins une fois, et s'il démarre se précipiter sur dd)

          • [^] # Re: NIH !

            Posté par  . Évalué à 4.

            je ne crois pas déjà avoir vu un disque dont le moteur a lâché (on entend toujours le disque tourner). Après je dépanne plutôt des ordinateurs, donc les disques sont différents. Avez-vous d'autres expériences que moi là-dessus ?

            Après chaque coupure de courant, sur mes baies non secourues en courant (environ 250 serveurs de calcul, qui peuvent se permettre de casser à tout moment), je dois remplacer quelques disques durs.

            Chez mes employeurs précédents, pareil après une extinction totale pour maintenance. C'est pire sur des disques qui ont eu "chaud" (local mal climatisé ou surchauffe temporaire suite à une panne de clim).

            Après, j'ai aussi quelques disques qui ont plus de 100000 heures de fonctionnement (~11 ans !) et vont très bien.

            Est-ce que les composants électroniques d'un serveur (autres que les disques) s'usent plus au démarrage / en fonctionnement / en sortie de veille

            Voir ceci : Courant d'enclenchement (en anglais : Inrush current).

            Sur des ordinateurs qui ne sont pas vraiment éteints quand ils sont éteints, le phénomène est sans doute limité, ceci-dit !

            • [^] # Re: NIH !

              Posté par  (site web personnel) . Évalué à 1.

              "je dois remplacer quelques disques durs."

              SSD ou plateaux?

              • [^] # Re: NIH !

                Posté par  . Évalué à 3.

                Plateau, de ce que j'en sais c'est un phénomène négligeable sur SSD. C'est vraiment le moteur qui doit tirer beaucoup d'énergie (par rapport à l'usage en croisière) au démarrage. C'est un comportement que tu as sur tout appareil motorisé.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: NIH !

          Posté par  (site web personnel) . Évalué à 5.

          Note que si en évoquant une panne de disque dur, tu ressens le besoin de toucher du bois, même synthétique, je te propose de rapidement lâcher le bois, et à la place, toucher un clavier pour mettre en place un système de sauvegarde ne lequel tu auras confiance !

          Ce n'est pas vendredi, mais c'est la pause de midi, alors j'ai le droit !

          • [^] # Re: NIH !

            Posté par  . Évalué à 2.

            Note que si en évoquant une panne de disque dur, tu ressens le besoin de toucher du bois, même synthétique, je te propose de rapidement lâcher le bois,

            Ah non, c'est plus facile de graver mes sauvegardes sur du bois que sur du marbre. Mes sauvegardes en marbre, c'est pour mes logiciels qui sont tellement beaux qu'ils vont traverser les siècles (mon marbre est toujours vierge, ceci dit).

            et à la place, toucher un clavier pour mettre en place un système de sauvegarde ne lequel tu auras confiance !

            Ben justement, ma sauvegarde est sur mon WD green :-) (enfin, une de mes sauvegardes).

            Mais je suis comme les marins, quand on parle d'un truc qui marche bien, on attire l'attention du père Murphy, alors, patte à 4 feuilles, fer de lapin, cheval de trèfle etc.

        • [^] # Re: NIH !

          Posté par  . Évalué à 3.

          Tout ça pour dire que j'imagine que WD a dû penser que le redémarrage n'était pas trop nocif, ou a dû prévoir un système pour que le HD ne souffre pas de ces démarrages à répétition, en tout cas ça fait 5 ans que je l'ai.

          Ou WD a calculé que pour l'usage «normal» considéré quand ils vendent ce disque dur, le nombre d'extinction ne nuira pas au disque dur.
          En l'occurence, comparé à leurs WD Red, ils sont vendus pour 300k cycles contre 600k, 2 ans de garanti contre 3 ans, et fait intéressant : ils consomment en idle 0.2W de plus… (J'ai pas retrouvé la datasheet complète, je me suis basé sur des comparatifs existants)

          • [^] # Re: NIH !

            Posté par  . Évalué à 1.

            En l'occurence, comparé à leurs WD Red, ils sont vendus pour 300k cycles contre 600k, 2 ans de garanti contre 3 ans

            Effectivement, c'est un argument de poids.

            et fait intéressant : ils consomment en idle 0.2W de plus…

            J'imagine que par idle tu veux dire en marche mais en attente de données ? Donc ils sont plus économiques si leur temps en pause (asleep) représente un bon pourcentage du temps de fonctionnement, mais si c'est pour être presque tout le temps en marche, ça semble couler de source qu'un HD standard est mieux adapté.

      • [^] # Re: NIH !

        Posté par  (site web personnel) . Évalué à 6.

        Il est peut être même plus rentable écologiquement de toujours laisser allumé le serveur. Mais les données manquent à ce sujet.
        https://forum.chatons.org/t/interet-s-de-gerer-l-extinction-reguliere-d-un-serveur/3008

        Adhérer à l'April, ça vous tente ?

    • [^] # Re: NIH !

      Posté par  . Évalué à 4.

      tu mets en parallèle la consommation en veille, alors que tu parles ensuite de consommation au démarrage du serveur.

      Alors qu'avec une mise en veille en mémoire, ça va consomme un peu (durant la veille), mais le redémarrage va être instantané (sans passer par le processus de boot).
      Avec une mise en veille sur disque, ça ne va rien consommer durant la "veille" puisque tout sera éteint. La sortie de veille va prendre un peu de temps au boot du bios, mais tout le processus de démarrage du serveur ne sera pas effectué de nouveau (sur mon PC, une sortie de veille de ce type prend 15 secondes maxi)
      De plus l'auteur du journal évoquait d'extinction complète de la machine a priori. Donc la veille ne consomme rien non plus.

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

      • [^] # Re: NIH !

        Posté par  . Évalué à 2.

        Il dit qu'il voit pas le rapport.

        Je disais que justement, la veille en mémoire consomme peu avec démarrage instantané. Du coup, si le démarrage à froid du PC prend 2 minutes et consomme beaucoup, le calcul est pas si évident que ça, peut-être que la veille pendant 5H consommera moins que le démarrage du PC…

        • [^] # Re: NIH !

          Posté par  . Évalué à 1.

          et moi je dis qu'il vaut mieux utiliser la veille sur disque, ce qui évite à la fois d'avoir une veille de 5H et un démarrage de 2 minutes…

          « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

          • [^] # Re: NIH !

            Posté par  . Évalué à 10.

            Je ne sais pas pour ce PowerEdge là, mais j'en ai déjà eu qui prenaient 2 minutes avant même que le noyau Linux ne démarre…

    • [^] # Re: NIH !

      Posté par  . Évalué à 2.

      Je n'y crois pas car le serveur en pratique ne se mettra pas en veille (sauf si tu le lui demande explicitement), il va juste ralentir sa consommation.

      Je pars du principe darwiniste que les virus présent sont les plus discrets, ceux ayant échappé à la vigilance des sysadmins. Il y a ceux profitant des période de faible activité pour s'activer (par exemple quand le sysadmin est absent), par exemple pour miner du Bitcoin. Et il suffit de peu de nuit d'activité intense pour ruiner l'avantage de la veille, car alors le serveur consomme un max d'énergie et use son matériel…

      Aujourd'hui beaucoup de disques serveurs sont SSD et ne connaissent donc pas le problème de démarrage que tu évoque.

      • [^] # Re: NIH !

        Posté par  . Évalué à 4.

        Je n'y crois pas car le serveur en pratique ne se mettra pas en veille (sauf si tu le lui demande explicitement), il va juste ralentir sa consommation.

        Je suggérais un sed e$shutdown$echo -n mem > /sys/power/state$ dans le script, rien d'autre.

        Aujourd'hui beaucoup de disques serveurs sont SSD et ne connaissent donc pas le problème de démarrage que tu évoque.

        Le journal évoque 3 disques à plateaux

    • [^] # Re: NIH !

      Posté par  (site web personnel) . Évalué à 1.

      Est ce qu'il pourrait y avoir une erreur de calcul?

      Il me semble que:
      - en veille + boot, on consomme 7h*5W + 150W*(2/60) = 40Wh
      - sans veille 7heure*32W = 224wh

      Ca reste, en énergie, économique non ?

      • [^] # Re: NIH !

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        perso j'ai également un serveur dell poweredge (le modèle T310) qui tourne 24h/24 7j/7 dans mon garage et je me suis également posé la question de l'éteindre la nuit, mais la perspective de fragiliser les disques m'effraie quelque peu au point d'abandonner l'idée de réduire mon bilan carbone.
        Honte à moi, mais ayant déjà subi une perte de donnée, je préfère ne pas augmenter les risques de panne, chat échaudé craint l'eau froide comme on dit.

        https://www.funix.org mettez un manchot dans votre PC

      • [^] # Re: NIH !

        Posté par  . Évalué à 2.

        En veille (suspend to RAM) il n'y a pas de boot.
        Avec l'extinction complète, il y a le boot.
        Après j'ai pas considéré la consommation idle du serveur… J'ai juste dit «tout se mesure»…

    • [^] # rtcwake ?

      Posté par  (site web personnel) . Évalué à 2.

      J'ai essayé la solution rtcwake sur plusieurs machines avec Ubuntu 21.10 mais j'obtiens à chaque fois une erreur d'écriture :

      $ sudo rtcwake -s 300
rtcwake : on considère que l'horloge matérielle utilise l'échelle UTC…
rtcwake : « wakeup » (réveil) depuis « suspend » avec /dev/rtc0 à Fri Jan 28 14:42:48 2022
rtcwake: erreur d'écriture

      alors que j'ai réussi avec la méthode utilisant /sys/class/rtc/rtc0/wakealarm

      • [^] # Re: rtcwake ?

        Posté par  . Évalué à 3.

        J'ai essayé la solution rtcwake sur plusieurs machines avec Ubuntu 21.10 mais j'obtiens à chaque fois une erreur d'écriture

        Que donne un strace, pour savoir sur quoi l'erreur a eu lieu ?
        Pour ma part, ça fait ~15 ans que j'utilise rtcwake, à une époque c'était mon réveil le matin, il me sert à automatiser des heures d'allumage sur des machines pendant mes absences… Le plus gros échec que j'ai eu c'est le réveil qui n'a pas sonné parce que le PC est mort pendant la nuit.

  • # Et le côté sécurité

    Posté par  . Évalué à 4. Dernière modification le 23 janvier 2022 à 19:58.

    En plus du côté écolo, j'y vois le côté sécurité. En effet on sait que les cyber-attaques ont plus souvent lieu la nuit et le week-end car les pirates savent que toutes les équipes SI ne travaillent pas. Éteindre les serveurs est donc un bon moyen de les sécuriser à faible coût. Bien sûr ce n'est pas suffisant.

    • [^] # Re: Et le côté sécurité

      Posté par  . Évalué à 7.

      En effet on sait que les cyber-attaques ont plus souvent lieu la nuit et le week-end car les pirates savent que toutes les équipes SI ne travaillent pas.

      Je suis curieux d'avoir une source là dessus. Je dirais qu'il existe des pirates au 4 coins du monde, et qu'ils piratent un peu à n'importe quelle heure, donc il est difficile de prévoir qu'il y a plus d'attaques la nuit (heure française), ou le week-end.
      Après, si c'est quelqu'un qui t'en veux, bin il va t'attaquer quand tu es up, donc bon :-(

      Du coup, le fait d'éteindre la nuit impacte pas sur la sécurité, mais bon, je peux me tromper.

      Du coup, ça m'a donné une idée, j'ai regardé mes logs, et sans surprise, j'ai plein de logs ssh:

      root@cerebrus:/var/log# grep "Failed password" auth.log | wc -l
      16896
      root@cerebrus:/var/log#
      Mais, oh surprise, le scan teste ce genre de user:

      Jan 23 04:43:55 cerebrus sshd[15734]: Failed password for invalid user wangyue from XX.XX.XX.XX port 49266 ssh2
Jan 23 04:43:55 cerebrus sshd[15736]: Failed password for invalid user wangzy from XX.XX.XX.XX port 49460 ssh2
Jan 23 04:43:55 cerebrus sshd[15737]: Failed password for invalid user wangzy from XX.XX.XX.XX port 49522 ssh2
Jan 23 04:43:55 cerebrus sshd[15742]: Failed password for invalid user xujia from XX.XX.XX.XX port 50106 ssh2
Jan 23 04:43:55 cerebrus sshd[15744]: Failed password for invalid user yjzhou_pc_1 from XX.XX.XX.XX port 50614 ssh2

      donc, à priori le scanner cherche des machines avec des comptes chinois (va savoir?)… 4h45 en france, c'est 11h45 en pleine journée en chine. Du coup, peu de chance de te faire péter ta machine éteinte ou allumée la nuit, mais des chinois en journée doivent se faire compromettre.

      • [^] # Re: Et le côté sécurité

        Posté par  . Évalué à 7. Dernière modification le 24 janvier 2022 à 09:47.

        Limite, vous ne parlez pas de la même chose. Le scan que tu as dans tes logs, c'est plus de la reconnaissance, ou de la tentative d'exploit automatisé. ça, ça tourne en permanence. Après, dans le cas d'une attaque ciblé, sur un acteur donné par une équipe organisée, comme avec les ransomwares en ce moment, les attaquants ont effectivement plutôt intérêt a déployé leur truc en HNO, quand il y a personne ou peu de gens qui travaille.

        Typiquement, par exemple dans cet article :

        Cyberattaque
        Paris Habitat : L’incident technique était bien un ransomware

        ../..

        « L’attaque a eu lieu le 27 octobre au soir et a été détectée le 28 au matin par nos systèmes informatiques »

        https://www.zdnet.fr/actualites/paris-habitat-l-incident-technique-etait-bien-un-ransomware-39913095.htm

        Après, fondamentalement, éteindre son système d'information le soir (si tant est que ce soit possible) est très largement insuffisant voire même assez inutile comme mesure de protection contre ça.

        Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

    • [^] # Re: Et le côté sécurité

      Posté par  . Évalué à 6.

      Pour digresser, en milieu professionnel, couper certains serveurs (VPN, Webmail…) pourrait être un bon moyen de garantir le droit à la déconnexion aux salariés…

  • # Et pour toute sorte d'appareil

    Posté par  . Évalué à 8.

    pour votre chauffage d'appoint, votre truc ou bidule électroménager que vous aimeriez éteindre et allumer de manière automatique: j'ai (re)découvert la prise programmable !

    (programmable avec des boutons ;) )

    5€ chez votre épicerie préférée.

    • [^] # Re: Et pour toute sorte d'appareil

      Posté par  . Évalué à 2.

      Pour de l'électronique il faut que la mise sous tension allume effectivement et ne mette pas l'appareil en mode veille. J'ai eu l'idée de piloter ma chaine hifi avec un truc du genre (plus précisément avec une multiprise dont une prise contrôle les autres genre ça https://www.amazon.fr/Multiprise-Automatique-Parafoudre-%C3%A9conomies-d%C3%A9nergie/dp/B008MQB24W), mais ça ne va probablement pas le faire malheureusement.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Et pour toute sorte d'appareil

      Posté par  (Mastodon) . Évalué à 4. Dernière modification le 24 janvier 2022 à 08:04.

      oui… mais non.

      tous les PC ne peuvent pas s'allumer sur le retour du courant. j'ai le soucis avec mon routeur/firewall : aucun réglage dans le BIOS ne le permet, je suis obligé de le rallumer à la main sur coupure de courant par exemple.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Et pour toute sorte d'appareil

      Posté par  . Évalué à 3. Dernière modification le 24 janvier 2022 à 10:12.

      Cette solution marche bien pour une box à la maison.

      Comme de toute façon, c'est le type de matos qu'on est obligé d'éteindre/rallumer régulièrement (en tout cas la mienne, un vieux coucou fourni par Numericable) sans quoi il plante lamentablement.

      Mais comme dis plus haut, pour un PC ou un serveur, ça risque de pas le faire puisque rien ne va automatiquement redémarrer. Sans compter que ça fait une extinction brutale, qui ne convient pas à tout (voire qui ne convient à rien en terme d'informatique).

      • [^] # Re: Et pour toute sorte d'appareil

        Posté par  (Mastodon) . Évalué à 4.

        Sans compter que ça fait une extinction brutale

        Oui alors en général tu prévoies le coup en programmant (cron) l'extinction par exemple à minuit, et tu coupes l'électricité à 00h15.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Et pour toute sorte d'appareil

      Posté par  . Évalué à 2.

      Attention à vérifier la capacité du schmilblick, à 5€ j'ai de gros doute sur sa capacité à laisser passer 500W sans fondre.

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Et pour toute sorte d'appareil

        Posté par  (Mastodon) . Évalué à 8. Dernière modification le 24 janvier 2022 à 13:08.

        500W c'est pas grand chose, ces trucs sont prévu pour des machines à laver, même à 5€ : c'est un interrupteur (et même pas un relai) qui fait la coupure.

        Je me doute qu'ils sont prévus pour 16A/3kW, qui est un peu le standard en matière de courant fort domestique.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # petit bug

    Posté par  . Évalué à 10.

    L'heure et aussi le jour peuvent changer entre les appels de 'date' dans ton script. Par exemple, si il est exécuté à 23:59.999, le dernier appel utilisant 'tomorrow' risque de s'exécuter après minuit, donc le lendemain et ton serveur ne se réveillera pas avant le 'lendemain du lendemain' soit 24 heures trop tard.

    • [^] # Re: petit bug

      Posté par  . Évalué à 2.

      Effectivement, ça peut même être bien simplifier avec un truc du genre :

      #!/bin/sh

same_day=$(date +%s -d "today    ${1}:${2}")
next_day=$(date +%s -d "tomorrow ${1}:${2}")
now=$(date +%s)

if [ $same_day -gt $now ]; then
    reboot=${same_day}
else
    reboot=${next_day}
fi

echo $reboot > /sys/class/rtc/rtc0/wakealarm

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: petit bug

      Posté par  . Évalué à 2.

      Le script se plante aussi d’une heure lors de passage à l’heure d’été/hiver.
      Probablement 2 fois par changement à vue de nez: le jour du changement, et le lendemain.

      Si avoir le choix dans la date est important, surtout en utilisant des heures locales, utilisez un vrai language avec un vrai support des dates.

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Bha logiquement faudrait faire l'inverse.

    Posté par  . Évalué à 1.

    Compte tenu que le réseau est moins sollicité la nuit (d'où les heures creuses), il faudrait couper la journée et faire tourner la nuit.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.