Marc Quinton a écrit 1551 commentaires

• sur ma BAL perso, qui remonte à l'Antiquité ou presque, avant d'avoir un compte Gmail : très très peu de spam ;
• concernant la BAL de madame, c'est une autre affaire. Ca l'agace sérieusement.

Je ne pense pas que cet environnement, tel qu'il est livré avec un mécanisme antispam rudimentaire soit apte à être utilisé dans de bonnes conditions.

pour ma part, j'ai un mix entre :
- autoriser l'accès avec MDP mais uniquement avec une liste d'IP ou masque réseau (local par exemple) ; c'est une white-list ;
- pour les autres, authentification uniquement avec clés ssh.

voir aussi l'initiative BlueHat de la DINUM avec 4 prix de 10K€ en coordination avec la fondation NLnet : https://code.gouv.fr/fr/bluehats/prix-bluehats/

voici une liste de projets bénéficiaires associés a ce fond souverain : https://www.sovereigntechfund.de/tech

concernant Docker, la réponse est ici : https://documentation.rootdb.fr/install/install_with_docker.html

et les docker-compose.yml ici : https://github.com/RootDBApp/infra

j'ai acheté un Crucial P5 Plus, 1To l'année passée fin juin, à 65€, dans une boutique toulousaine. Il est actuellement à 110€ et 99€ sur une boutique en ligne en 4 lettres.

Ca pique !

Vous pouvez retrouver un reportage très détaillé sur la filature de la police française et serbe d'envoyé spécial du 25 avril, à partir de 02:00 minutes.

sur github, des pages statiques, au format Markdown avec le tag Awesome font très très bien l'affaire !

concernant les aspects financiers, selon ce ticket, ils sont accessibles une fois membre de l'association. La transparence est de mise, mais obtenir les infos de manière plus ouverte serait intéressant.

Codeberg dispose d'un service "blog" pour assurer sa communication avec une catégorie Letters from Codeberg ; on peut y voir des infos concernant la vie de l'association, les mises a jour des différents services, les incidents, des appels à contribution. Pas vu grand-chose concernant les finances.

on peut aussi regarder du coté de la commande rtcwake : https://www.baeldung.com/linux/auto-suspend-wake ; elle permet de mettre en sommeil et relancer la machine après un temps déterminé.

je lis : "La gravité serait telle que les services municipaux concernés touchés sont à l'arrêt. Des équipements de sécurité numérique de Floirac ont été compromis."

une règle élémentaire voudrait que l'on arrête tous le SI en cas de doute d'une intrusion, qu'elle soit d'importance minime ou très importante. On peut aussi tout simplement déconnecter les services exposés sur Internet le temps de prendre la température du SI.

Je n'ai pas lu dans l'article d'information indiquant que les données précieuses et sans backup avaient été placées dans des containeurs chiffrés. Comment juger de prime abord de l'importance de l'attaque. Prendre des précautions, y compris trop de précautions avant remise en service, me semble indispensable.

merci ; je viens de poster le service en "lien".

exact ; il y a 2 options :

-j maxjobs
-l maxload

mais qui est Jia Tan

je cite :
[…]
Mais qui est donc ce Jia Cheong Tan ? Sans surprise, nombreux ont été ceux qui ont enquêté sur cette personne depuis la découverte. Les trois parties de son nom affiché sont certes chinoises, mais toutes sont originaires de régions et de langages différents du pays. Il semble donc probable que quelqu'un ait simplement mixé des noms chinois pour donner le change. La piste du hacker isolé paraît également peu crédible au vu du temps et des ressources investies, ou même des capacités d'exploitation d'une faille aussi massive. Un service de renseignements, un puissant groupe de hackers, voire carrément un État sont donc des suspects plus probables…"

nouveau lien avec de façon très détaillée, tout l'historique des commits et échanges par ML : chronologie de l'attaque contre le logiciel libre XZ.

encore un autre ; une sorte de honeypot avec des infos qui remontent dans les logs : https://github.com/amlweems/xzbot

en voici un autre :
- https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b

ici encore : https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

je ne comprends pas qu'on travaille d'une autre façon quand on exploite des applis Web en particulier dont les dépendances sont de plus en plus difficiles à gérer avec le temps qui passe. Comprendre "d'une autre facon" que Docker qui est vraiment très adapté à cette tache.

Grace a docker, dès qu'on a une appli Linux qui "ne fait que" des E/S réseau et disque, elle est potentiellement dockerisable et cela permet de la rendre indépendante de l'OS sur lequel elle tourne. C'est selon moi le Graal.

Mais, c'est vrai, ca ne fonctionne pas tout le temps, en particulier avec des applis de type desktop (GUI en client lourd).

Sans compter qu'avec le docker-hardening, on peut faire des choses assez sympas : limiter cpu, mémoire, FD ; rendre l'image read-only ; parfois du rootless.

je vois ici, un bénéfice concernant Apple de 24 milliards de dollars pour 2023 ; comment expliquer ce que tu avances ? On est très loin des 250 milliards annuel ; j'estime une année d'activité pro à environ 250 jours de travail.

c'est arrivé vers le 8 février et toujours pas de bilan. Mais que fait la police ! il est écrit de contacter dpo@iliad.fr, mais si chacun le fait, ça risque de lui donner bien du travail, a moins d'une réponse automatique.

Le périmètre de la fuite n'est pas précisé :
- quelles données
- quels clients, pour quels services.

ca m'agace un peu. Ou est la transparence ?

régalez-vous des commentaires sur ce site. Comme si l'informatique était une évidence pour tout un chacun.

On peut aussi voir dans l'algorithme des années bisextiles, un lien avec Jésus ; puis un autre de rappeler que "l'année solaire dure 365,2425 jours calendaires" ; ouf …

merci pour le feedback.

pour compléter, il existe un paquet debian permettant de gérer des taches de maintenance de facon périodique : https://github.com/qiwichupa/btrfsmaintenance

pour ce qui me concerne avec BTRFS :
- RAS a titre perso, sur un NAS avec 3 disques partitionnés et 2 types de RAID (5 et JBOD)
- un incident sur un serveur de backup en 5 ans environ ; il héberge 150To de données. Nous avons fait au plus simple : formatage et resynchro des données.

J'ai aussi des VM qui ont des partitions ou disques virtuels en BTRFS sans incident ; j'avais créé des volumes BTRFS pour la fonction snapshot, avant d'en disposer sur infra de virtualisation Proxmox + CEPH.