Bonjour,
 
J'utilise à la maison un vieux PC qui sert de serveur NextCloud. Les requêtes sont redirigée vers ce serveur via une VM installée sur ma Freebox Delta, mais cette VM n'étant pas assez puissante je suis passé à une machine physique (et je regrette un peu, mais c'est pas le débat )
 
Bref, j'ai remarqué que le ventillo de ma Freebox est tout le temps à 100%, et qu'elle est chaude.
Si j'arrête ma VM (qui pourtant ne fait rien, y'a qu'une Apache avec un règle de redirection vers mon NextCloud) je ventillo se calme après un moment.
 
Mon serveur NextCloud, même donne, y'a que ça qui tourne dessus, et même quand personne n'est en train de consulter / uploader des documents, le ventillo tourne comme un malade et de l'air bouillant sort de l'alim.
 
N'espérant pas franchement trouver de solution à ce souci de surconsommation (on sait jamais, je vous en parle au cas où vous ayez une idée) j'ai imaginé au moins couper le serveur quand personne ne s'en sert (et la VM aussi).
 
En gros, après 23h00 jusqu'à 8:00 personne ne va aller dessus, et si c'est le cas, tant pis
 
J'ai vu qu'avec rtcwake je peux demander au server de se rallumer à une heure donnée (ou après un délai) lorsqu'il est en veille profonde (voir même éteint).
Comment automatiser une mise en veille (ou extinction complète si ça marche) puis le redémarrage ?
 
Je pensais éventuellement mettre un cron qui fait un rtcwake pour dans 9 heures suivi d'un shutdown, mais est-ce qu'il y a plus élégant ?
 
 
Sinon, je suis sur ubuntu 22.04, sans interface graphique (sur la VM et la machine physique).
Avez-vous une idée de pourquoi ça consomme autant ? Comment mettre en veille les disques quand non sollicités, et réduire la consommation du CPU quand non sollicité, comme ça se fait nativement sous Windows ?

Ton message soulève pas mal de question :
 
Qu'est ce qui consomme du CPU/disque sur la machine physique ? n'y aurait-il pas des tentatives de connexions par des bots (voir éventuellement fail2ban ou équivalent dans ce cas) ?
 
Pourquoi une VM sur la delta ? pourquoi pas une redirection de port simple et tu mets ton reverse proxy sur la machine physique ?
 
pour la mise en veille, effectivement un timer systemd ou un cron devrait faire l'affaire. rtcwake rallume et éteint la machine, pas besoin de shutdown.
 
pour le CPU, il passe automatiquement dans les modes basses conso si il n'est pas utilisé. Pour les disques, ça dépend mais normalement c'est aussi le cas.

Bonjour Mjules, merci pour ta réponse.

En effet, moi aussi je me pose des questions, et j'avoue que faute de temps/compétences j'ai tendance à laisser de côté "du moment que ça marche..."

Ca c'est une très bonne question.
Quand je lance htop alors que le serveur est idle, je ne vois rien de bien particulier sur le serveur NextCloud. Utilisation de moins de 5% du CPU, et pareil pour les disques, pas grand chose.
Cependant, chose que je ne m'explique pas trop, c'est que j'ai tout de même en permanance du bordel qui tourne... Pourtant NextCloud est une application web, donc si personne n'est connecté dessus, elle ne devrait rien faire...

Par contre, à force de rajouter des modules dans tous les sens pour avoir une instance NextCloud qui marche pas trop mal et fait ce que je veux, j'avoue que je suis totalement pollué par des process dont je n'ai qu'une vague idée de l'utilité.

Par exemple, coolwsd est un des process qui tourne le plus lorsque le serveur est idle.
A priori, c'est un bout de Collabora Online, je ne vois pas pourquoi il tourne quand il n'est pas sollicité.

Il y a aussi redis-server, à priori c'est un gestionnaire de cache. Sans lui, ça rammait à mort (la faute au disque dur qui n'est franchement pas rapide). C'est la rançon de faire tourner un serveur avec du matos bas de gamme de plus de 10 ans Mais à nouveau, je ne vois pas pourquoi un gestionnaire de cache travaillerait constamment quand il n'est pas sollicité...

En tout cas, j'ai l'impression d'être sous Windows, avec des process qui tournent dans tous les sens sans qu'on sâche pourquoi

https://cloud.manga-torii.com/index [...] WEG4Adksig

Pour ce qui est de détection d'intrusion, j'ai regardé un peu avec iftop et j'ai rien vu de bizarre, visiblement c'est plus ou moins que du trafic sollicité.
J'ai installé une appli dans NextCloud qui est censée me prévenir s'il y a des tentatives de login anormales et j'ai jamais eu d'alerte...

A la base, j'avais mis OwnCloud sur cette VM. J'avais tout configuré le certbot et le reverse proxy, mais c'était franchement trop lent (finalement guère plus que ma machine physique au final mais bon ) donc j'ai dégagé toute la partie OwnCloud, mais vu que j'ai moyennement envie de tout reconfigurer le reverse proxy et la partie certbot, j'ai préféré laisser la VM sur la Delta.
Aussi, même si je doute que ce soit mesurable, ça me permet de gérer le chiffrage SSL sur la Delta plutôt que sur mon serveur physique qui n'est franchement pas une flèche.

Enfin, il m'arrive régulièrement de mettre à disposition des application web pour faire des tests, l'utilisation du reverse proxy sur la Delta m'évite de trop jouer avec la config du serveur NextCloud (quand on sait pas trop ce qu'on fait, vaut mieux éviter de trop jouer avec des serveurs qui servent vraiment )

Enfin, le fait que tout le trafic passe par la VM de la Delta permet à priori de réduire l'exposition du serveur : par exemple Collabora Online ne risque pas d'être appelé en direct, etc. Je sais pas si ça change grand chose en termes de sécurité mais bon... Si ça fait pas de bien ça doit pas faire de mal non plus

J'ai mis un cron. Sur la VM de la Delta, rtcwake ne fonctionne pas du tout. Visiblement il n'y a rien au niveau de la gestion ACPI dans la Delta.
Par contre, sur le serveur NextCloud, ça marche nickel (enfin, je verrai ce soir et demain matin si ça marche si bien que ça ). En tout cas, j'arrive même à éteindre complètement le PC et le rallumer automatiquement. Ca évitera qu'il tourne pour rien toute la nuit.

Ok, c'est déjà ça, même si c'est pas trop visible du coup. Le souci vient probablement du fait qu'il y a ces process qui tournent en permanance et qui empêchent de mettre quoi que ce soit en veille...

Hmmmm...

Alors pour les tentatives d'intrusions, je viens d'installer fail2ban sur la VM de la Delta (ma DMZ) et après 5 secondes d'activation j'ai déjà deux IP bannies pour avoir tenté des connexions ssh

pour les connexions ssh il faut changer le numero de port. tu seras bien moins emmerdé.  

En fait, mon cerveau vient de s'allumer...

J'ai shooté la DMZ et ajouté qu'une redirection du port 443 vers ma VM...
C'est tellement plus simple

Du moment que le reverse proxy de la VM dispatche ensuite vers les autres serveurs...

Bon, je laisse quand même fail2ban on sait jamais, mais logiquement plus d'accès direct depuis l'extérieur hors port HTTPS...

Salut

Je reviens vers vous, car mes tentatives se sont toute soldées en epic fail...

Déjà, rtcwake ne veut pas fonctionner en cron.
J'ai trouvé (vraiment pas grand chose, surtout des gens bloqués et d'autres qui comprennent pas pourquoi) quelques pistes :
- Ne pas lancer rtcwake avec le cron de mon utilisateur, mais celui de root.
J'ai donc créé la ligne cron avec la commande suivante :

=> On est bien d'accord que ça crée des commandes cron qui vont tourner avec le compte root ?

cron n'a pas forcément connaissance des variables d'environement, à commencer par PATH. Ainsi, il ne faut pas lancer rtcwake directement, mais son chemin complet.

which rtcwake retourn /usr/sbin/rtcwake j'ai donc indiqué ce chemin dans mon cron :

Il ne se passe rien à 22h30

J'ai tenté d'ajouter des logs, j'ai rajouté un autre cron juste avant :

J'ai jamais eu de fichier dtc.log créé.

J'ai créé un script et tenté de lancer le script avec cron, que nada.
J'avoue que je sais plus du tout quoi tenter, j'ai l'impression que cron avec le compte root est HS...

Pourtant, si je crée un cron avec mon user, pas de souci, ça tourne, au détail près que rtcwake n'a pas le droit d'arrêter la machine avec mon compte...

Du coup je suis passé à la sauvegarde sur un disque USB.
Bon, j'ai réussi à monter le disque, et même faire en sorte qu'il soit monté automatiquement au démarrage.
Ouf, un truc qui marche.

J'ai ensuite créé un script (pompé sur la documentation de NextCloud qui passe le site en mode maintenance, fait un rsync pour copier les fichiers sur le disque externe, puis fait un backup de la bdd, et enfin sort du mode maintenance).

Si je lance avec mon compte, rsync échoue : pas accès au dossier de NextCloud.
J'ai donc créé un crontab pour le user du site, et tout fonctionne bien à un détail : impossible de faire le backup, car le user du site n'est pas un sudouser.
J'ai trouvé de la doc sur le sujet, modifié un fichier de conf pour sudo, et maintenant, si je lance la commande en faisant un sudo -u www-data ça marche bien.
Par contre, depuis le cron, ça marche jusqu'à la fin du rsync, mais le backup de la base ne passe pas.

J'aurais jamais cru que ce serait aussi pénible...

J'ai épuisé stackoverflow et askununtu. Google m'accuse de l'attaquer DoS... Microsoft Bing est entré dans un état de catatonie, j'ai même vu Bilou lui-même essayer de le réanimer en lui chantant du VBScript... Je ne sais plus vers quel saint me tourner

Billou, c’est impossible parce qu’il est parti en 2008 et ça commence à dater. Tu confondrais pas avec Satya, le PDG actuel depuis 9 ans ?

Y'a que Bilou qui sait chanter du VBScript
 
Sinon, on s'égare, moi je suis perdu avec tout ça

Bon, v'là maintenant que ça marche mais en horaires décalés...
 
Visiblement root n'est pas au courant qu'il est en France, et travaille en UTC, car mon serveur s'est arrêté à 00:30 et rallumé à 8:30 au lieu de 22:30 -> 6:30
 
Reste plus qu'à modifier l'heure et ça devrait être bon... Je sens que je vais être emmerdé avec l'heure d'hivers du coup...
 
Par contre je sais pas pourquoi ça se met à marcher d'un coup (comme le backup MySQL d'ailleurs, finalement il a marché hier )

Je viens de réveiller encore quelques neurones.. (fait pas bon de vieillir...)
En fait cette règle "DMZ" vient de l'époque juste après ma migration de Freebox Révolution à Freebox Delta : ils m'avaient fait sauté mon IP fixe ainsi que mon IP full stack.

Hors, avec la Delta, si t'as pas une IP full stack, impossible de voir les VM depuis le gestionnaire des règles NAT.
=> D'où l'obligation de passer en DMZ... Et du coup c'était resté comme ça depuis...

Bon, pour ma timezone, ça avance...
 
Le PC était en timezone "Etc/UTC" comme je le soupçonnais.
 
Par contre, y'a un truc bizarre. Donc il se croyait à 9h30 quand il était 11h30.
 
Pourtant, si je faisais un "touch test.log", je voyais bien avec un "ls -l" que j'avais créé le fichier 11h30
 
Bon, j'ai suivi ces instructions :
https://stackoverflow.com/questions [...] n-schedule
 
On verra ce que ça donne ce soir