-=[ silmaril ]=- a écrit 1463 commentaires

Le concept de secureboot et de l'informatique de confiance en soit est plutôt intéressant aussi.

La possibilité de s'assurer qu'une machine n'a pas été modifiée de façon inattendue, que ton serveur situé a trois mille kilomètres n'est pas modifié par ton hébergeur, … c'est plutôt une bonne chose

Après l'implémentation c'est toujours là que le bàt blesse …

Serveur avec bi-cpu et 128Go de ram, avant que iceweasel arrive à bouffer tout ça y a de la marge quand même ^{^}

Peut-être que tes distributions live se chargeait automatiquement en ram ?
Ou alors les logiciels que tu utilisait se prêtaient bien aux latences de l'usb.

Pour avoir tester sur un serveur pour le benchmarker et avoir eu besoin de lancer un navigateur depuis le liveUSB la différence entre le ramdisk et le direct-to-usb se comptait en minutes au niveau du chargement du navigateur et en dizaines de secondes pour le chargements de pages / retours en arrière.

Même l'ouverture d'un terminal je constatait une réactivité très notablement supérieure, pour un temps de chargement global similaire voir inférieur car la copie séquentielle dans le ramdisk puis la réactivité de celui-ci était largement compensée par les lenteurs d'accès aleatoire de la clef usb

Ce n'est pas parce que les données sont "périmées" au sens HTTP que le serveur doit supprimer le cache, notamment pour ce que je cherche à faire.

Vu que tu travaille avec un serveur de type proxy cache HTTP bien sûr que si.

Je pense que tu as mal recopié la conf, la config que j'ai mis en lien c'est ça :
…

Ce sont les lignes 41/42 oui mais la ligne 59 override ce paramêtrage pour les index de paquets:

location ~ ^{/alpine/(?.*/APKINDEX.tar.gz)$} {
proxy_pass http://alpine-mirrors/$target_uri;
proxy_cache_valid 200 1m;
}

sinon si tu veut gérer plus finement ton cache le mieux est probablement de faire un vrai mirroir pour le coup:
https://wiki.alpinelinux.org/wiki/How_to_setup_a_Alpine_Linux_mirror

J'utilise un miroir avec mise en cache du dépôt Alpine Linux

ce n'est donc pas un miroir, juste un proxy cache.

Cependant je voulais savoir s'il existait un moyen pour un client HTTP de demander au miroir de lui servir une ressource en version mise en cache, même si elle est périmée

Souvent quand on pense devoir détourner le fonctionnement d'un outil c'est qu'on a soit pas compris les mechanismes racines de celui-ci ou qu'on a déployé une configuration qui ne correspond pas a nos besoins ^{^}

Dans ton exemple, la durée d'inactivité avant suppression du cache est d'un an, mais les données ne sont mise en cache au mieux que sur une journée ce n'est pas bien cohérent.

J'ai regardé du côté de l'en-tête HTTP Cache-Control, il semble que la valeur only-if-cached semble convenir. Est-ce que ma compréhension de cet en-tête est bonne, et pensez-vous qu'il s'agisse du meilleur moyen pour parvenir à mon but ?

pas vraiment non:

The “only-if-cached” request directive indicates that the client only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status code.

Si tu veut que ton cache soit utilisé en priorité sur de longues périodes il faut augmenter la durée de mise en cache et baisser les possibilitées de revalidation.
Dans ton cas l'index des APK n'est en cache que pour 1 minute a cause des lignes 57-60 du fichier en exemple:

location ~ ^/alpine/(?<target_uri>.*/APKINDEX\.tar\.gz)$ {
    proxy_pass http://alpine-mirrors/$target_uri;
    proxy_cache_valid 200 1m;
}

Ajouter "updating" à la ligne "proxy_cache_use_stale" permettra aussi à ton proxy de fournir la version précédente pendant la phase de mise à jour de la ressource ce qui devrait beaucoup aider à ton problème.

Au niveau validitées des caches, l'index je le monterai à 4h à minima, voir une journée, tandis que le reste doit pouvoir être monté à plusieurs mois, je ne connais pas alpine plus que ça mais un package n'a pas de raison d'être modifié in-place

L'intérêt est visible assez rapidement quand tu démarre un live-usb debian en mode normal vs en mode 'toram' ^{^}

Les images "live" debian (et donc probablement ubuntu et dérivés) supporte l'option "toram" pour monter le FS en mémoire, ce qui est infiniment plus utilisable que depuis le support initial.

Yep, ça arrive.

Juste un truc qui me perplexifie dans cette histoire:

On a des backups quotidiens, heureusement. Seulement on ne peut pas monter /dev et /etc du backup parce qu'on boot sur une debian-free et on est sur une debian non-free…
On les récupère en .tar.gz et on les redépose au bon endroit. On arrive à accéder en ssh à la machine, les voyants repassent au vert. Ouf…

Quel rapport entre les backups et debian-free/non-free qui sont des packets supplémentaires / firmware additionnels ?
Le backup n'est pas accessible car la carte réseau utilise un firmware closed ? si c'est ça votre "rescue" devrait être ajusté pour inclure cette contrainte…

Also "/dev/" est soit un dossier virtuel généré par udev, il suffit généralement de retrigger udev pour qu'il soit refresh:

udevadm control --reload-rules
udevadm trigger
Mais apparement vous avez rebooter donc …

Et si c'est un /dev statique il y a la commande MAKEDEV normalement, quoi qu'elle est généralement dans /dev ce qui pourrait poser un problème…

Et le 4 ?

Après avoir passé un moment à batailler avec jekyll + rouge + jekyll-assets et ne plus supporter les messages d'erreurs bizarres, les conflits et bloquages de versions de modules ruby et autres joyeusetées je suis passé sur Hugo

J'en ai profité pour refaire le theme graphique à l'identique (ou presque) visuellement mais sans tout les "helpers" JS/CSS présent initialement et en basant la structure html au plus proche des best-practices html5 (ou du moins de ce que j'ai compris du html5 ⁾ ie usage des tag articles, aside, nav, …

Je n'ai plus sous la main les chiffres exacts mais la page nécessite 40Ko la ou la base utilisé pour le theme jekyll tapait plutôt dans les 800Ko.

L'un des trucs les plus surprenant à été le bouton twitter d'ailleurs, qui rajoute discrètement 120/140Ko quand instancié via le js normal (pour au final 5/6 lignes de CSS ….)

Le projet git est connecté à cloudflare pages pour rendre l'update aussi efficace que possible.

https://github.com/bplessis/blog/
https://blog.plessis.info/

J'ai fait tourner mon blog peu actif sur jekyll pendant un moment et j'ai beaucoup souffert de l'écosystème et notamment "jekyll-assets" qui bloquait les mises à jours et avait des comportement bizarres qui m'ont fait perdre un temps fou…

La migration sur hugo à été une délivrance

Tu peut l'appeller ccslinux.com.conf mais effectivement l'extension .conf est obligatoire depuis un petit moment maintenant

Pour la partie "$corp" le soucis vient probablement d'une précédente gestion cloud de la machine, le poste à du contacter AzureAD ou windows autopilot pour et la machine s'est automatiquement reauthentifiée de part des identifiants matériels:

During setup or the OOBE wizard, Windows will connect to Microsoft services and check whether a PC is AAD joined or Windows Autopilot is set up or the like. If this is true, it will automatically reconfigure.

The PC is identified using a "hardware hash". What's in it is not documented by Microsoft.

The company that owned the device must release it from their management. Yes, the company can access it otherwise.

https://superuser.com/questions/1700523/why-does-the-company-name-and-domain-show-up-login-on-windows-10-installer

Petit complément aux solutions précédentes:

sur un parc homogène (ou en tout cas sur des OS dérivés de debian/apt) avec une volonté de contrôle apt-dater (https://github.com/DE-IBH/apt-dater) est un très chouette outil pour avoir une vision globale de l'état du parc et pour y appliquer les remédiations nécessaires.

Je dirais ça dépend surtout de combien ils vous font payer ça je pense.
Pour une petite librairie coopérative, si en plus vous disposez d'un contrat Office365 passer sur une offre business premium vous permet d'accéder à un tas de fonction dont la version "online" de defender qui à mon sens devrait être largement suffisante pour le risque

Surtout si vous avez en place des backups et un usage des outils OneDrive & co pour le travail interne

Oh bein en général les EDR sont des solutions basées sur des anti-virus classiques (ex Trend Micro Apex One est soudainement devenu Trend Micro EDR Machin Truc Bidulle, mais en fait on installe toujours ApexOne, juste il a un module de reporting supplémentaire

Si si bien sûr.

WSUS + GPO permettent d'automatiser le déploiement des patches de sécurité et certaines mises à jours.
Par contre effectivement si on parle d'un SI a base de Windows Server 2008 ça ne le mettra pas magiquement à jour en server 2019

Le mode "php" ne gère que la colloration syntaxique du code php, si tu mixe du php et autre chose (html, js, css, …) il va falloir regarder les solutions "multi-mode":

• https://www.emacswiki.org/emacs/MultipleModes
• https://web-mode.org/
• https://github.com/fgallina/multi-web-mode ..

Ta seule erreur est sur le POSTROUTING:
ce sont les packets à destination de ton interface VPN + ip rpi qu'il faut source-nater pour que le retour tcp passe bien par ton serveur et pas en direct sur la route par defaut du rpi2.

il faut donc modifier le MASQUERADE pour un "-o tun0" ou "-o tap0" selon l'interface construite par openvpn

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Hello,

Il n'existe aucune solution magique à ta demande, quand tu utilise /dev/sdb tu accéde au disque en mode block, il n'existe absolument aucune methode magique pour en bloquer l'accès, mis à part ne pas utiliser le compte root / sudo

Même chiffrer (et non crypter) le disque ne solutionnera pas ton problème.

Quelques options:
* ne pas travailler en root (utiliser udev pour fournir un accès à ton compte utilisateur sur les périphériques de type clef usb
* créer un script/utiliser un outil dédié pour formater les clef que tu pourra restreindre / ajouter des checks pour éviter de wiper ton disque
* créer un alias pour dd pour rajouter ces checks

Ancien ou pas des clusters/secteurs défectueux sur un disque c'est pas bon, et non ça ne fait pas parti du rodage …

Et si le disque est neuf avec des secteurs défectueux je l'inviterai à en demander un remplacement rapide.

Oui il y a un système de remplacement de secteurs dans certains disques (en général c'est plus les SSD d'ailleurs) mais s'il les vois re-apparaitre régulièrement c'est soit que le disque n'inclus pas cela, soit que le pool de remplacement est plein

Cela peut se comprendre, si Raku est capable d'interpréter du Perl, l'inverse tient de de l'impossible.

Je ne sais pas si cela peut se comprendre mais je ne vois pas le problème dans cette affirmation, si effectivement raku est capable d'interpréter du perl 5 alors tout est bien non, on respecte la backword-compat. Je ne connais pas des masses de choses qui sont forward-compatible sur une version majeure N+1.

Même perl 5.10 va avoir du mal a interpréter du code utilisant les fonctionnalités réçentes.

La vrai question est plutot: qu'as-tu comme message d'erreur au boot post coupure de courant ?

Prochaine coupure vérifie le contenu de /boot/efi avant de reinstaller grub.

Si c'est le bios qui perd la séquence de démarrage il peut être intéressant de regarder ce que dit efibootmgr et de faire juste le grub-install
voir même de copier /boot/efi/EFI/debian/grubx64.efi dans /boot/efi/EFI/BOOT/BOOTX64.EFI, c'est le boot-code utilisé par défaut en l'absence de paramètrage spécifique dans le BIOS / efibootmgr.

TL;DR: Non ce n'est pas possible / souhaitable

Réponse longue:
Un serveur NFS publie un dossier physique local (et uniquement ça), exemple srv1 va publier /home/agora, srv2 va aussi publier /home/agora
Si tu monte srv1:/home/agoro sur srv2 dans le dossier /home/agora c'est le dossier NFS qui sera le dernier monté sur le repertoire et ton système ne vera plus les fichiers du /home/agoro "local", et inversement sur srv2
Tu va te retrouver avec des dossiers différents sur chaque machine, avec le coût (latence, performance) du fs NFS et le comble c'est que les data de srv2 seront sur srv1 et inversement, (sauf si le demon qui accède à /home/agora est démarré avant les montages NFS auquels cas le truc sera encore plus rigolo car tu vera les fichiers de srv2 sur srv1 pendant que le programme qui tourne sur srv1 modifiera potentiellement d'autre fichiers).

Dans ton cas les options que je vois sont:
1 Définir une et une seule machine comme repository de stockage, et utiliser NFS pour exporter ce repository ailleurs (simple mais implique d'avoir toujours le serveur NFS d'actif / l'allumer en premier)
2 Utiliser un FS clusterisé type Ceph/GFS/GlusterFS (potentiel de prise de tête ++)
3 mettre en place une synchronisation two-way a base de rsync par exemple + cron pour replication régulière (nécessite d'avoir une certains marge de manoeuvre sur la disponibilité des fichiers)

ça et le fait de fournir un exemple complet étudiable parce que la il ne presente qu'une des fonctions de son outil, et pas celle qui enregistre le tableau dans un fichier donc on va avoir du mal à trouver pourquoi l'enregistrement déconne …