NeoX a écrit 18099 commentaires

La question est de les rendre le plus performant possible

alors c'est pas tant que site web que le code derriere qui va intervenir et la base de données si y en a une

par defaut, mysql par exemple est livrée en mode "developpement" en gros peu de concurrence, un cache limité, etc, il faut aller tuner la config pour etre plus "performant" et "production ready"

cf les docs de mysql/mariadb

le design de la base de donnée va ensuite jouer un role evidemment,
mais la maniere dont le code traite les pages, dont les images sont optimisées ou non, etc

c'est un peu comme un powerpoint,
j'ai vu des gens faire un diaporama de leur photo de vacances et ne pas comprendre que le fichier fait 5Go à la fin ?

tout simplement parce que les images etaient directement issue de l'appareil photo, sans reduction de taille, pour mettre dans un powerpoint en 1920x1080 quand la photo de base est en 12Mpx (3072x4096)

bref avant d'en arriver à optimiser le serveur web, il y a un monde avant :D

tu as une machine, et tu veux heberger du web ? avec ou sans php ?

partagé avec des utilisateurs simple utilisateurs (mutualisé) ?
ou tu veux dédiés des droits à tes utilsiateurs (VPS) ?

dans le premier cas, tu gardes ton debian, tu installes un panneau de config (virtualmin, plesk, cpanel), toi tu es root, eux sont utilisateurs et verrouillés dans leur dossier

dans le 2e, tu met de la virtualisation (KVM ou LXC) pour dedié des espaces à tes users,
ils seront root de leur emplacement.

perso pour le 2e j'aime bien proxmox,
tu peux avoir une machine, demain si t'en veux un 2e ou faire une migration, tu installes le 2e proxmox, tu montes un cluster entre les deux, et tu bascules tes KVM/LXC de l'un vers l'autre

pas moi en tout cas, je dois aller taffer pour remplir mon compte en banque :p

du coup il a besoin de tes infos pour creer ton compte et passer la commande

Alors qu'un système public les payant en amont leur permettrait de produire pour tous et de manière indépendante, ce qui serait bien plus viable.

oui et non
là tu sous entend que seuls les chercheurs pourraient etre payé pour chercher et trouvé.

Mais si moi dans mon garage je trouve une idée, un concept, comment je le monetise ?

Ici avec une prise zigbee qui mesure mon placard technique
- Boxe internet reduite au role de passerelle internet
- Switch POE 16 ports, 2.5Gbps
- 2 bornes wifi
- un nas DS1821 avec 6 disques dedans (3x10To, 3x6To)
- deux glinet (un vieux 6416 en DHCP, un B3000 en routeur VPN)

Conso : 153W à 171W

Prise dans le salon pour une TV, une barre de son, un Shield nvidia, un miniswitch 5 ports 1Gbps :
- 11W à 23W en 'pause'
- 90W à 108W en action

Fichier -> Imprimer -> Choisir l'imprimante… ?

c'est parce qu'il met son PC sur l'interface enp 3 s0,
et pour une raison obscure veut faire un bridge sur enp 2 s0

si tu veux avoir les 2 PC sur le meme reseau que la boxe, il faut en effet faire un bridge contenant les 2 interfaces (p2 et p3), puis brancher un cable vers la box, un autre vers le 2e PC

et c'est le br0 qui sera dhcp client de ta box.

autre piste, laisser les deux interfaces separées
enp2s0 sur la boxe, en DHCP
enp3s0 sur le 2e PC, avec les deux machines en IP fixe sur un reseau differents de la box, le PC1 sur ce reseau sera aussi la passerelle du PC2

il te faudra alors activer

• l'IP_FORWARD pour que ca passe d'une carte à l'autre
• le MASQUERADE en sortie vers la box pour que la box pense que c'est le premier PC qui dialogue avec elle
• un firewall totalement ouvert sur le PC1 pour commencer

si tu le vois bien traverser en entrée (client -> IP box -> serveur VPN -> machine finale)
mais que le client n'a pas de retour (timeout) alors oui il te faut investiguer la partie "sortie internet"

car comme tu l'evoques il est possible que la machine finale, pour repondre au client sortent directement sur internet.

c'est ce que l'on appelle du routage assymetrique ca rentre d'un coté, ca sort de l'autre.

Deux possibilités

• la plus rapide, SNAT/MASQUERADE tes clients derriere l'IP VPn du serveur VPN
  ainsi la machine finale verra une demande provenant du serveur VPN via son IP vpn, repondra à son routeur par defaut, qui lui sait qu'il faut repondre par le VPN

• la plus complete activer :

  • ip forward sur le routeur client VPN
  • laisser le redirect default pour que le client change sa passerelle par defaut par le serveur VPN
  • sur le serveur VPN : ipforward evidemment + MASQUERADE de ce qui sort de ton reseau VPN derriere l'IP LAN du serveur VPN

J'ai fait une page de synthèse des configs réseau, est-ce qu'il y a quelque-chose qui m'échappe ou que je ne fais pas comme il faut?

bah là maintenant la question c'est : que te manque-t-il ?
tu as testé sur chacun des equipements en cours de trajet voir si tu vois tes flux ?

une commande magique à connaitre :

tcpdump -vnni any host XX.YY.ZZ.TT

pour voir tout ce qui entre et sort de cette machine et qui a comme IP XX.YY.ZZ.TT

Ctrl+C pour interrompre le dump

pareil que dit precedemment,

pour les photos, je deposes en general en dossier par date ou periode
genre 202505-stage_xxx, 20250501-anniversaire_toto

ensuite je jongles avec les tags pour dire qu'on voit tata, ou le pote machin

pour la music, je vais utiliser les classements de base Artiste/Album/morceau.mp3
pour les compilations ce sera Compile/Morceau.mp3

puis les tags eventuels ( rythm, clef, etc)

SteamOS qui commence à arriver sur les consoles portables autres que SteamDeck

Sinon y ChimeraOS (precurseur de SteamOS) qui semble faire le taff à condition d'avoir une carte graphique AMD

Est ce que ce sera plus simple ou il vaut mieux rester avec le routeur en client VPN?

techniquement y a pas de "mieux", c'est toi qui vois en fonction de ton besoin.

si tu as besoin que des machines de gauche accedent aux machines de droites (ou au conteneur de droite) alors il faut que le VPN soit sur ton routeur internet (openwrt)

si c'est uniquement pour les conteneurs de gauche, alors oui ce serait pertinent que le client soit dans un conteneur, et que les autres passent par lui pour aller sur internet

la question ne devrait-elle alors pas etre "comment ajouter une police de caractere sur mon linux mint ?" :D

alors il ne faut pas s'etonner de ne pas avoir toutes les fonctionnalités :/

une fois teams ouvert et connecté avec ton compte (via l'appli donc)
tu vas dans les … qui sont en haut à droite à coté de ton profile
puis "reglages"
et enfin "peripheriques"
dans le bloc 'audio device"

tu as l'option de faire un "test call"

c'etait le cas en 2022, et ca semble toujours etre le cas
https://answers.microsoft.com/en-us/msteams/forum/all/microsoft-teams-test-call/0346e563-c8d1-4254-87d1-08910506e1dd

PLutot que Writer j'aurais utilisé Libreoffice DRAW
ou Scribus comme dit plus bas

Là maintenant, j'aimerais essayer de couper le bon câble, puis si vraiment ça marche toujours pas, j'essayerais peut-être finalement d'acheter un écran pour rebrancher le temps de récup les données.

ne le coupe pas, debranche et isole le avec un bout de papier, comme çà si c'ests pas le bon, tu le rebranches :D

udo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE

qui est ce reseau 10.8.0.0/24 c'est ton reseau VPN ?

dans ton 1), precise le sens de ton flux pour etre sur
ici pour masquer ce qui vient des clients VPN derriere l'ip du serveur VPN, cela evite de devoir modifier les routeurs 192.168.1.6 et la box de ton voisin pour qu'il connaissent tes reseaux 10.0.4.0, 10.8.0.0, 192.168.11.0 …

iptables -t nat -A POSTROUTING -i tun0 -o ethLAN -s 10.8.0.0/24 -j MASQUERADE

j'imagine que tu as deja aussi un MASQUERADE pour que ton 10.0.4.17 puissent aller sur internet via lxcbr0, derriere l'IP 192.168.1.6

dans ton 2)
2.1) pour faire un routage sous linux :

ip r a DESTINATION via ROUTEUR

coté serveur VPN pour acceder au 192.168.11.0/24 via le client VPN

ip r a 192.168.11.0/24 via 10.8.0.x (IPClientVPN)

coté client VPN pour lui préciser comment acceder à 10.0.4.x/24, c'est un openWRT, cherche dans les menus le routage static pour lui dire que pour joindre 10.0.4.0/24 il faut passer par l'IP du serveur VPN (mais en principe ton client VPN doit deja avoir une route par defaut qui envoie tout dans le VPN)

2.2) sur ton serveur openvpn,
IP_FORWARD=1 evidemment pour que ca circule entre les interfaces (lan <-> tun0)
ROUTAGE comme indiqué

Chez TOI :
1°) chez toi, definir le client VPN comme la gatewway par defaut de tes machines, le plus simple donne lui simplement la meme IP que ta box internet (celle qui ne fonctionne plus, et debranche celle-ci)
seul le client VPN aura comme passerelle la box 4G

=> bon c'est deja le cas, tu as un routeur openWRT en coupure entre ton ADSL/4G et ton LAN
=> OK

Chez ton voisin
1°) masquer tous tes trafics derrieres ton serveur openvpn, ainsi toutes tes machines sortantes seront vu comme etant le "serveur VPN", le retour se fera alors par la box du voisin, qui renverra vers le serveur VPN, qui renverra au client

2°) Pour les services Externes qui vont rentrés par la box du voisin, redirection de port sur la box ou DMZ vers le serveur VPN, puis routage classique

2.1°) ajouter une route vers le reseau LAN de gauche (chez toi derriere la 4G) via le tunnel VPN du server VPN

ip r a 10.0.x.y/24 via ipclientVPN

2.2°) faire des regles de nat prerouting (redirection de port sur le serveur VPN) pour que le port XXXX coté LAN du server VPN, soit renvoyé vers l'IP YYYY de ton lan sur le port XXXX

Je ne vois aucune différence significative entre ces deux choix mais j'aimerais savoir si un des deux est plus recommandable que l'autre.

techniquement il n'y en a aucune,
dans un cas tu auras un compte toto@ton.fournisseur
dans l'autre cas, tu auras un compte toto@tondomaine.tld

ce sera bien deux comptes differents,

la question etant alors, comment veux-tu etre vu quand tu envoie de l'email depuis ce compte ?
comme toto@ton.fournisseur, ou comme toto@tondomaine.tld :D

ici la solution ressemble plus à un cluster de Pi pour faire du kubernetes, ou simplement plusieurs pi dans un meme rack

pour un NAS il n'y aurait qu'un seul pi, et plusieurs emplacements disques durs

mais l'idée est là

avec un reseau à part, donc pour la comprehension c'est un process isolé dans un sous reseau dédié

donc il faut le gérer comme tel.

ne pas exposé le port à l'exterieur et laisser le reverse proxy causer par l'interface reseau interne

regardes dans les modeles à imprimer soit meme pour gerer un NAS avec un RPi :D

ton NPM ecoute sur 80 et 443 de la machine physique,
il envoie ensuite selon les regles que tu lui donnes, vers des machines virtuelles, port 80 ou 443

à toi de modifier la config docker pour ne pas exposer le port 80/443 de snikket à l'exterieur du docker, il sera alors simplement lancer sur le reseau interne de docker comme pour les autres machines, et NPM enverra le 80 et 443 de chat.domain.tld vers l'IP de ce docker