totof2000 a écrit 2038 commentaires

1/ Pour apprendre à faire une mise à jour plus tard :D ?

2/ Peut-être pour éviter d'essuyer les plâtres sur une distrib trop récente ? (perso je laissee toujours au moins 3 mois avant de faire les MAJ LTS chez moi).

3/ Parce qu'il ne savait pas ? (la réponse la plus probable à mon avis).

Je rencontre tellement de gens, y compris professionnellement, qui sont incapable de debugger es problèmes de perf sur des systèmes containerisés, qui copient/collent des lignes dans des dockerfiles sans savoir ce qu'il font.

Je ne peux malheresement que constater la même chose. Et l'expérience que j'ai avec les IA me montre qu'elle fait souvent la même chose ( je l'ai constaté avec Claude qui souvent part en boucle dans des tentatives de réslution en cascade en essayant des trucs à la con alors que pour résoudre le probème il suffit de s'arreter, et de chercher à comprendre - en lisant la doc - comment fonctionne le truc).

Par exemple pf moi la syntaxe me rentre pas dans la tête. Je sais que le but c'est que ça ressemble à du langage naturel, mais je sais pas si c'est que mon niveau en anglais est pourri ou si c'est une sorte de vallée de l'étrange.

Ben je ne sais pas pourquoi tu n'accroches pas mais honnetement, j'ai essayé IPFilter (puis Packet Filter plus tard), et honnetement je ne reviendrai jamais à IPTable ou dérivés. Mais comme tu le dis c'est peut-être un problème avec l'anglais … D'ailleurs un exemple pour s'en convaincre.

Le code Packet Filter :

# Macros
int_if="rl0"
ports_ouverts_pour_tous="{ http https }"
ports_ouverts_pour_lequipe="{ ssh 21 60000:60100 }"

# Tables
table <ip_de_lequipe> { XYZ.XYZ.XYZ.XYZ, XYZ.XYZ.XYZ.XYZ, XYZ.XYZ.XYZ.XYZ }

# Normalisation du trafic
scrub in no-df

# NAT
nat on egress -> (egress)

# Règles de filtrage
block in
pass out keep state
pass in on egress proto tcp from <ip_de_lequipe> to port $ports_ouverts_pour_lequipe
pass in on egress proto tcp to port $ports_ouverts_pour_tous
block in quick on $int_if proto tcp from $int_if:network to port 4662
pass quick on !egress

La même chose en iptable (issu de chatgpt donc à prendre avec des pincettes) :

#!/bin/sh
set -eu

int_if="rl0"
egress_if="eth0"
int_net="192.168.1.0/24"

ip1="XYZ.XYZ.XYZ.XYZ"
ip2="XYZ.XYZ.XYZ.XYZ"
ip3="XYZ.XYZ.XYZ.XYZ"

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

# Différence avec "scrub in no-df" : iptables n'a pas d'équivalent direct ; TCPMSS ne traite que le MSS TCP sur les paquets SYN routés.
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

iptables -t nat -A POSTROUTING -o "$egress_if" -j MASQUERADE

iptables -A INPUT -i "$int_if" -s "$int_net" -p tcp --dport 4662 -j DROP
iptables -A FORWARD -i "$int_if" -s "$int_net" -p tcp --dport 4662 -j DROP

iptables -A INPUT -i "$int_if" -j ACCEPT
iptables -A FORWARD -i "$int_if" -j ACCEPT

iptables -A INPUT -i "$egress_if" -p tcp -s "$ip1" -m multiport --dports 22,21,60000:60100 -j ACCEPT
iptables -A INPUT -i "$egress_if" -p tcp -s "$ip2" -m multiport --dports 22,21,60000:60100 -j ACCEPT
iptables -A INPUT -i "$egress_if" -p tcp -s "$ip3" -m multiport --dports 22,21,60000:60100 -j ACCEPT

iptables -A INPUT -i "$egress_if" -p tcp -m multiport --dports 80,443 -j ACCEPT

Avec nftables (toujours issu de chatgpt pour être transparent) :

#!/usr/sbin/nft -f

flush ruleset

define int_if = "rl0"
define egress_if = "eth0"
define int_net = 192.168.1.0/24

table inet firewall {
    set ip_de_lequipe {
        type ipv4_addr
        elements = { 198.51.100.10, 198.51.100.11, 198.51.100.12 }
    }

    set ports_ouverts_pour_tous {
        type inet_service
        elements = { 80, 443 }
    }

    set ports_ouverts_pour_lequipe {
        type inet_service
        flags interval
        elements = { 22, 21, 60000-60100 }
    }

    chain input {
        type filter hook input priority filter; policy drop;

        ct state established,related accept
        iifname "lo" accept

        iifname $int_if ip saddr $int_net tcp dport 4662 drop
        iifname != $egress_if accept

        iifname $egress_if ip saddr @ip_de_lequipe tcp dport @ports_ouverts_pour_lequipe accept
        iifname $egress_if tcp dport @ports_ouverts_pour_tous accept
    }

    chain forward {
        type filter hook forward priority filter; policy drop;

        ct state established,related accept

        iifname $int_if ip saddr $int_net tcp dport 4662 drop
        iifname != $egress_if accept

        iifname $egress_if ip saddr @ip_de_lequipe tcp dport @ports_ouverts_pour_lequipe accept
        iifname $egress_if tcp dport @ports_ouverts_pour_tous accept
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;

        oifname $egress_if masquerade
    }
}

table inet mangle {
    chain forward {
        type filter hook forward priority mangle; policy accept;

        # Différence avec "scrub in no-df" : nftables n'a pas d'équivalent direct complet ; cette règle ne traite que l'ajustement MSS TCP, pas la normalisation PF ni le retrait global du bit DF.
        tcp flags syn tcp option maxseg size set rt mtu
    }
}

Pour ma part je trouve que Packet Filter reste bien plus lisible et compréhensible que IPTable ou NFtable.

D'ailleurs c'est vraiment un truc à savoir en passant de linux à BSD, c'est que les perfs vont morfler.

t'as pas un peu l'impression d'exagérer là ? :)

En terme de perf, FreeBSD n'a pas forcément grand chose à envier à Linux en général. Il y a certainement des usages ou effectivement il sera en dessous, mais dire que "les perfs vont morfler", mis à part cas précis et besoins spécifique, je pense que c'est vraiment exagérer.

Par contre pour NetBSD et OpenBSD, sans aller jusqu'à dire que "les perfs vont morfler", je dirais que les perfs ne sont pas la priorité pour ces deux derniers : l'un favorise la portabilité (NetBSD - on trouve un tas de machines/CPU sur lequel tourne ce système), l'autre la sécurité (Openbsd), parfois effectivement au détriment des perfs. Mais pour la plupart des usages (hors jeux ) il n'y aura pas de différences perceptibles.

Il faut avoir joué avec IPFilter ou Packet Filter pour se rendre ompte à quel point gérer des règles de firewall est bien plus facile sous xBSD que sous Linux par exemple …

Le règles iptables sont à gerber ….

Loin d'être inutile, au contraire. J'adore ce genre d'analogie.

Faudrait apprendre un peu à contextualiser quand vous voyez des mots dans un phrase, plutôt que de jouer les chiens de Pavlov et de passer votre temps à vouloir censurer tout et tout le monde juste pour donner plus d'importance que vous en avez.

Bah, comme on dit, "l'argent n'a pas d'odeur" …. Linux était un cancer tant qu'ils ne pouvaient pas se faire d'argent avec. Aujourd'hui, ils ont trouvé un modèle économique pour faire payer leurs clients, donc pour eux c'est bon.

Nul doute que si un jour, ils trouvent moyen de développer une distribution Linux qui leur rapportera beaucoup beaucoup d'argent, ils le feront.

Internet a été justement conçu pour résister à ce type d'attaques. Quand je luis que "Les conséquences militaires et stratégiques d’une coupure des câbles pourraient être plus graves encore. Les armées dépendent de communications sécurisées sur de longues distances et d’une coordination en temps réel." … Ca me fait bien rire. Au pire on aura un ralentissement global, on ne ourra peut-être pas lire des flux venus des US en 4k, mais rien ne sera bloqué si l'Iran coupe des cables ….

… Pour financer les dépenses des entreprises en jetons IA, il suffira de licencier les employés.

Si tu lui demandes "remplace les printf par des cout dans ce code C++", il ne va pas te demander "est-ce que je remplace aussi les sprintf?", puis "est-ce que je remplace aussi les fprintf?", puis "est-ce que tu veux que je remplace aussi les printf(stderr, …) par cerr?", etc. C'est un coup à devenir dingue, tu vas finir par écrire "ARRETE DE POSER DES QUESTIONS ET REMPLACE TOUS CES P*** DE PRINTF".

Ben justement : pour ma part je m'attends à ce que l'IA me pose ces questions plutôt que de prendre l'initiative et d'extrapoler. Je perds beaucoup plus de temps à corriger les extrapolations erronées de l'IA, et à lui rappeler de ne pas supposer qu'à confirmer les questions qu'elle pourrait me poser.

Le message qui est passz (en tout cas celui que j'ai perçu), c'est "A cause de Microsoft, des tas de PC sont morts et enterrés" … Le message sous-jacent "SVP Mr Microsoft, veuillez faire quelque chose pour éviter ça" … Et du coup, ma perception est que l'APRIL s'associe à cette demande. Pas très cohérent. Message brouillé.

A la limite l'April aurait pu intervenir dans la mise en scène (en cosplay manchot qui ressucite les PC morts et enterrés pour y installer un Linux par exemple). Mais là c'est pas terrible je trouve.

OK il faut RTFM mais si tu dois t'attendre à ce que la documentation réinvente les définitions des mots ça reste problématique.

Bienvenue dans le XXIeme siècle ou tout le monde réinvente sa propre définition des mots.

Alors, si. L'appel simple devrait retourner une erreur si le volume est utilisé. Et une option dans l'appel pour "forcer". C'est ce que fait l'API AWS de mémoire ; voire même, la deuxième option n'existe pas : il faut détacher le volume avant de le supprimer.

Effectivement, s'il s'agit d'un volume attaché à une VM, l'appel ne devrait pas aboutir. Mais dans ce cas précis, je ne suis pas convaincu que ça aurait changé grand chose …

Et il y a aussi des services cloud qui proposent de "locker" une ressource : tu dois faire un "unlock" avant de faire un "delete". Cela permet de pas se foirer lors d'un appel en masse.

La aussi, ça n'aurait pas changé grand chose, car l'IA semblait avoir récupéré un token qui lui aurait permis de faire tout ça …. Ca se serait fait en plus d'appels API.

Et aussi, le plus sûr, quand tu delete, ça delete pas tout de suite. Et tu as 24h pour ouvrir un ticket pour qu'on se sauve tes données.

C'est peut-être la seule mesure qui aurait permis de récupérer rapidement les données.

1. The Railway GraphQL API allows volumeDelete with zero confirmation. A single API call deletes a production volume. There is no "type DELETE to confirm." There is no "this volume is in use by a service named [X], are you sure?" There is no rate-limit or destructive-operation cooldown. No environment scoping. Nothing between an authenticated request and total data loss.

Une API c'est fait pour automatiser. Et quand on automatise c'est justement pour ne pas se prendre ces confirmations. Et je ne suis pas convaincu que ça aurait pu empêcher l'agent de forcer la suppression s'il en avait envie. Pour moi le problème est surtout là :

1. Railway's volume backups are stored in the same volume. This is the part that should be a red alert for every Railway customer reading this. Railway markets volume backups as a data-resiliency feature. But per their own docs: "wiping a volume deletes all backups."

La doc de Railway appelle effectivement un backup quelque chose qui ne l'est pas ….. mais au final c'est écrit quand même dans la doc. Alors, oui on peut reprocher la terminologie utilisée par Railway, mais aussi les personnes qui l'ont mis en oeuvre sans lire la doc …

Perso, je suis d'avis que la grosse partie de la responsabilité n'est ni chez l'IA, ni chez Railway.

C'est ce que je me suis dit mais en réfléchissant autrement c'est peut-être pas si idiot.

Supposons que je veuille stocker des cartons vides dans une pièce. Je vais les entreposer jusqu'à ce que la pièce soit pleine. Or il m'en reste à entreposer. Du coup j'ai deux possibilités : soit je stocke les cartons dans une autre pièce (mais je n'ai pas d'autre pièce à mins de 20 km), soit je prends certains des cartons, je les les plie, pour dégager de la place pour mettre le reste de mes cartons …

Ca veut dire quoi ça ?

Les mainframe n’ont jamais était en mesure de tenir la charge d’internet

Oui, au temps pour moi, merci d'avoir corrigé le lapsus.

LTSpice par exemple, DCMOTO un émulateur d'ordinateurs thomson, mais aussi d'autres logiciels, parfois libres mais qui n'ont pas été portés sous Windows.

Je crains que ce focus ne laisse de côte d'autres problèmes de compatibilité our d'autres applis. Mais je peux me tromper.

• Caractères GSM : jusqu’à 160 par message
• Caractères Unicode : 70 maximum

Tu peux tenter l'envoi de messages RCS (basé sur IP et non sur GSM): ils font sauter la limite du nombre de caractères (et permettent l'envoi de texte riche comme le font les applis style signal/whatsapp), mais dans un format "interopérable". Cependant ce format n'est pas forcément supporté par tous les systèmes d'exploitation des téléphones mobiles (les ordiphones sous Androïd ou IOS le supportent, mais c'est pas forcément le cas pour les téléphones non smart … ). Enfin, je ne sais pas si on peut facilement envoyer des messages de type RCS à partir d'un module SMS 4G ou 5G comme on le fait pour des SMS … ou s'il faut passer par un opérateur (je sais que certains fournissent des API payantes pour le faire)

La encore, on a de l'exagération de la part d'un dirigeant pour justifier les crédits qu'on lui a attribués … Celà dit je ne remets pas en question le fait que l'IA puisse aider un dev, mais là on est dans l'exagération.

C'est un oeuf au plat ?

De même, est-ce compliqué pour un prestataire de service de mettre en place plusieurs rappels ? Ça me semble utile, en tout cas.

Je peux te le faire pour 120 eurons par mois.

J'utilise uptimerobot et je suis prévenu à la moindre interruption de service

J'avais pas réellement fait attention à cette partie de ton message, et après coup je suis allé voir chez eux : https://uptimerobot.com/domain-expiration-monitoring/?ref=header

Get notified about the domain expiration date.

Use domain monitoring to receive alerts 30, 14, 7, and 1 day before your domain name expiration, and view the domain expiration date anytime in your dashboard.

Oui, j'attends plus d'un fournisseur de services.

Pour lui mettre la pression: c'est Yulpa.io. J'aimerais qu'ils changent quelques trucs.

Faut aussi savoir se prendre en main non ?