home.social

#autohebergement — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #autohebergement, aggregated by home.social.

fetched live
  1. Si vous êtes passé à la dernière version de #pixelfed la v0.12.9 et que vous validez les inscriptions des nouveaux utilisateurs manuellement (installation git clone), il y a de fortes chances que les inscriptions n'aboutissent pas. Un tout petit fix pour réparer ça : placez-vous dans le dossier d'installation de Pixelfed et collez ceci "sed -i 's/public function curatedOnboarding(Request \$request): RedirectResponse|View/public function curatedOnboarding(Request $request): RedirectResponse|ViewContract/' app/Http/Controllers/SiteController.php".

    Comme quoi il suffit d'un seul mot... On n'est pas à un bug près et... toujours pas de notifications à destination des admins.

    #souverainetenumerique #selfhosted #autohebergement #mesnumeriquesfr

  2. Petit mise à jour de mon article #Autohébergement - Avoir un #Yunohost "privé" derrière une #Freebox blog.genma.fr/Autohebergement-
    Avec une anecdote en fin d'article : comment on peut savoir que le NAT ne marche plus/n'est plus pris en compte. Je vous laisse lire ça blog.genma.fr/Autohebergement-

  3. Manifeste : pour une véritable souveraineté numérique du nom de domaine / Le constat : votre nom de domaine ne vous appartient pas vraiment

    L'éviction récente du collectif Autistici/Inventati de son nom de domaine historique en .org nous rappelle quelque chose d'important : posséder un serveur ne suffit pas à garantir qu'un service restera accessible.

    Imaginez que vous possédiez votre propre serveur, avec vos données, vos sauvegardes et uniquement des logiciels libres.

    Tout va bien… jusqu'au jour où le nom de domaine qui permet aux utilisateurs de trouver votre serveur disparaît.

    Votre serveur fonctionne toujours.
    Vos données sont toujours là.
    Mais pour une grande partie des utilisateurs, votre service vient tout simplement de disparaître du Web.

    C'est le problème que pose la dépendance à certaines extensions comme .com, .net ou .org.

    Un nom de domaine n'est pas une propriété

    Quand vous achetez un nom de domaine, vous n'achetez pas réellement le domaine.

    Vous obtenez un droit d'utilisation, pour une durée donnée et selon les règles du registre qui gère cette extension.

    Cela signifie qu'un nom de domaine peut, dans certaines circonstances, être suspendu, transféré ou supprimé.

    Le problème n'est donc pas uniquement technique : il est aussi juridique et politique.

    Les grands domaines historiques comme .com, .net et .org sont intégrés dans une infrastructure largement liée aux États-Unis, avec notamment l'ICANN et des registres comme Verisign ou Public Interest Registry (PIR).

    Ils peuvent donc être soumis à des décisions d'entreprises, à la réglementation américaine et, dans certains cas, à des mesures ayant des effets au-delà du territoire américain.

    Le .org, malgré son image historique de domaine associatif et communautaire, n'est pas une zone juridiquement neutre.

    Pourquoi cela devrait nous concerner

    On pourrait considérer que ce problème est exceptionnel et ne concerne que de grosses organisations.

    Mais c'est justement là que le sujet devient intéressant pour nos communautés.

    Nous défendons souvent :

    l'auto-hébergement ;
    les logiciels libres ;
    la décentralisation ;
    le Fediverse ;
    les infrastructures associatives ;
    la maîtrise de nos données.

    Mais si le nom qui permet d'accéder à notre infrastructure dépend entièrement d'une organisation située dans une autre juridiction, il reste un maillon que nous ne maîtrisons pas.

    C'est un peu comme construire une maison dont nous possédons les murs, les meubles et les clés… mais dont quelqu'un d'autre possède l'adresse.

    Le triptyque de la souveraineté DNS

    Si nous voulons réellement rendre nos infrastructures plus résilientes, il faut donc réfléchir à trois niveaux :

    1. Où est enregistré notre nom de domaine ?

    2. Qui contrôle les serveurs qui font fonctionner ce domaine ?

    3. Qui permet à nos utilisateurs de traduire ce nom en adresse IP ?

    Ces trois éléments sont liés, mais ils ne représentent pas le même niveau de contrôle.

    1. Choisir une extension dont le cadre juridique nous est proche

    Les extensions nationales et européennes comme .fr, .be, .de ou .eu sont rattachées à des registres européens et à des cadres juridiques européens.

    Cela ne signifie évidemment pas qu'un .fr ou un .eu est impossible à suspendre.

    Aucun nom de domaine n'est intouchable.

    Mais cela permet de réduire notre dépendance à une juridiction étrangère et de bénéficier du cadre juridique local ou européen.

    Règle n°1 :

    Pour les services importants, privilégions autant que possible des extensions européennes.

    Il ne s'agit pas nécessairement d'abandonner immédiatement nos .org, .com ou .net.

    Il s'agit plutôt de ne pas mettre tous nos œufs dans le même panier.

    2. Maîtriser la chaîne technique

    Changer d'extension ne suffit pas.

    Si notre domaine est européen mais que toute sa gestion dépend d'une entreprise située à l'autre bout du monde, nous avons simplement déplacé le problème.

    Il faut donc également regarder qui est notre registrar et où il est établi.

    Règle n°2 :

    Pour les domaines stratégiques, privilégions des registrars établis en Europe et soumis au droit européen.

    Mais il reste encore un autre élément : les serveurs DNS.

    Ce sont eux qui répondent à une question toute simple :

    « Quand quelqu'un demande monsite.fr, vers quelle adresse IP doit-il aller ? »

    Si nous contrôlons nous-mêmes ces serveurs, nous réduisons encore notre dépendance à des intermédiaires.

    Des logiciels libres comme BIND9 ou PowerDNS permettent parfaitement de faire cela.

    Règle n°3 :

    Lorsque c'est possible, gérons nous-mêmes nos serveurs DNS autoritatifs et protégeons nos zones avec DNSSEC.

    Cela ne rend pas notre domaine invulnérable, mais cela nous donne davantage de contrôle sur son fonctionnement quotidien.

    3. Ne pas dépendre d'un seul résolveur DNS

    Il reste un dernier maillon, souvent oublié.

    Quand votre navigateur demande :

    « Quelle est l'adresse IP de monsite.fr ? »

    il passe généralement par un résolveur DNS.

    Beaucoup de personnes utilisent aujourd'hui de grands services publics comme 8.8.8.8 ou 1.1.1.1.

    Ces services sont pratiques et peuvent être excellents techniquement.

    Mais ils représentent aussi une forme de concentration : une petite quantité d'acteurs traite une énorme partie des requêtes DNS mondiales.

    Si un résolveur décide de ne plus répondre pour un domaine, ou applique un filtrage particulier, ses utilisateurs peuvent avoir l'impression que le site n'existe plus.

    Règle n°4 :

    Développons et partageons des résolveurs DNS indépendants au sein de nos communautés et de nos réseaux.

    Et lorsque c'est pertinent :

    Règle n°5 :

    Utilisons des résolveurs que nous contrôlons, notamment via DoH ou DoT.

    L'objectif n'est pas de considérer automatiquement les grands résolveurs publics comme « mauvais ».

    L'objectif est plutôt de ne pas dépendre exclusivement d'eux.

    Une précision importante : le DNS n'est pas Internet

    Il faut également éviter un raccourci :

    le DNS ne constitue pas à lui seul Internet.

    Changer de .org pour .fr, héberger son propre DNS et utiliser son propre résolveur ne rendra pas une infrastructure totalement indépendante.

    Il restera toujours des dépendances : connexion Internet, opérateur, hébergeur éventuel, transit IP, certificats, matériel, adresses IP, etc.

    L'objectif n'est donc pas de rechercher une autonomie absolue ; elle est pratiquement impossible.

    L'objectif est de réduire les dépendances critiques et d'éviter les points de contrôle uniques.

    Conclusion : reprenons le contrôle de notre adresse

    La souveraineté numérique ne commence pas uniquement avec le choix d'un serveur, d'un hébergeur ou d'un logiciel libre.

    Elle commence beaucoup plus tôt :

    au moment où quelqu'un tape une adresse dans son navigateur.

    Nous pouvons posséder nos serveurs.

    Nous pouvons posséder nos données.

    Nous pouvons utiliser des logiciels libres.

    Mais si l'adresse qui permet d'accéder à tout cela dépend entièrement d'un acteur que nous ne maîtrisons pas, il reste une vulnérabilité importante dans notre chaîne de souveraineté.

    Alors, plutôt que de chercher une solution parfaite, commençons par diversifier :

    des domaines sous juridiction européenne,
    des registrars européens,
    des DNS autoritatifs que nous maîtrisons,
    des résolveurs indépendants et distribués.

    La souveraineté numérique ne signifie pas couper tous les liens avec le reste du monde.

    Elle signifie surtout ne pas dépendre d'un seul acteur pour continuer d'exister sur le Web.

    Et ça, c'est quelque chose que nos communautés peuvent commencer à changer dès aujourd'hui.

    #souverainetenumerique #dns #europe #autisticiinventati #nomdedomaine #selfhosted #autohebergement #mesnumeriquesfr

  4. Manifeste : pour une véritable souveraineté numérique du nom de domaine / Le constat : votre nom de domaine ne vous appartient pas vraiment

    friendica.mesnumeriques.fr/dis

  5. Salut la mastodonsphere !

    J’ai récemment installé FreshRss sur mon serveur yunohost. L’idée etant de me tenir informé mais en choisissant mes sources d’informations.

    J’aime beaucoup mais je me rends compte que plusieurs sites/medias ne proposent pas de flux rss pour suivre leurs publications. Y-a-t’il une solution? Vous faites comment vous?

    Merci

    Exemple ici : quotaclimat.org/actualites/
    #aide #rss #actu #autohebergement

  6. Voici un petit aperçu du travail de l'ombre en direct (htop, Proxmox, docker stats). La magie du libre et de l'auto-hébergement ! 🐧
    #AutoHebergement #Linux #PeerTube #Debian #Docker #Proxmox

    Musique: Glitch Fidelity
    Musicien: Marscott (from Audiio)

  7. Quel boulet.

    J'étais entrain de mettre en place un backup hors-site de mon serveur. Devant faire une pause, j'éteins mon ordi :
    $ sudo shutdown -h now

    J'étais dans ma session SSH 😬
    Je suis en vacances, et je viens d'éteindre mon serveur sur lequel j'héberge mes photos, mes films, mes musiques, mon nextcloud, une instance writefreely, ainsi que tous mes mots de passe sur Vaultwarden. Le seul moyen de l'allumer c'est d'être sur place.

    Je suis un boulet.

    #selfhosting #autohebergement #boulet #ssh

  8. Notre premier serveur, nommé Radis, est en place !

    Donc voici un petit article sur le blog pour continuer de raconter le déploiement de nos services :

    tubercule.fr/blog/projet-servi

    N'hésitez pas à retoot et à venir discuter avec nous sur XMPP, IRC ou ici ^^

    #hacking #autohebergement

  9. Ménage sur mon VPS cet après-midi. `docker system df` me sort un volume Docker à 9,95 Go. Il n'y a qu'un seul volume nommé sur la machine : celui de n8n.

    Dedans, `database.sqlite` : 9,2 Go. Pour zéro exécution en base — la purge automatique à 7 jours est active et fait son travail.

    Recherche : c'est connu et documenté. SQLite ne rend jamais l'espace au disque quand on supprime des lignes, il le marque simplement réutilisable en interne. Le fichier reste à son pic historique. Deux mois d'écritures à haute fréquence l'avaient gonflé, la purge a vidé les lignes, le fichier est resté tel quel.

    n8n prévoit le cas. Une variable à ajouter dans le docker-compose.yml :

    DB_SQLITE_VACUUM_ON_STARTUP=true

    Relance instantanée. `database.sqlite` : 3,8 Mo. Le volume entier : 170 Mo.

    Si vous hébergez n8n sur SQLite, allez regarder la taille de votre `database.sqlite`. La purge des exécutions ne suffit pas à récupérer la place.

    #n8n #SelfHosting #SQLite #Docker #Autohebergement

  10. Nouvelle instance, nouvelle #introduction ! Suite à l'annonce de la fermeture prochaine de toot.community, j'ai décidé de prendre mon destin en main et j'ai déployé ma propre instance GoToSocial.

    Je suis un #developpeur, #photographe et #bidouilleur de Paris ; mes posts concernent principalement la #technologie et son impact sur la société (si vous saviez à quel point ça me rend anxieux en ce moment), mes aventures d' #AutoHébergement et tout ce que je trouve intéressant ou drôle. J'ai aussi un blog pour tout ce qui ne rentre pas dans un toot ou qui pourrait être d'utilité publique, vous pouvez trouver quelques un de mes posts dans mon profil.

    À très vite !

    #IntroductionFR

  11. Mise à jour importante de sécurité Mailcow 2026-07a

    D'habitude je ne poste pas les notifications de mises à jour de Mailcow, mais je le ferai à partir de maintenant quand cela implique des patchs de sécurité.

    Source : github.com/mailcow/mailcow-doc

    🏖️🐮 Mooly 2026 | Postfix 3.10.12, Rspamd 4.1.0 & Nginx 1.30.3 - Révision A (Dernière version)

    Changements Importants :

    Cette mise à jour corrige plusieurs problèmes de sécurité dans mailcow. Nous vous recommandons vivement de mettre à jour votre instance mailcow dès que possible.

    Mises à jour et sécurité :

    - [Rspamd] mise à jour vers la version 4.1.4
    - Correction de la CVE-2026-42533 pour Nginx
    - Mise à jour de l'action `actions/stale` vers la version v11
    - Renforcement de la sécurité de mailcow

    Corrections :

    - fix : restauration de l'affichage de l'objet dans l'aperçu de la quarantaine
    - [Nginx] liaison IPv6 uniquement pour `default_server` si `ENABLE_IPV6` est activé
    - [Web] correction : `add/time_limited_alias` ignorait silencieusement les requêtes et la validité
    - [Web] renvoi de `sender_acl` dans l'API `get/mailbox`
    - fix : validation des paramètres d'origines autorisées CORS
    - [Web] renforcement de la correspondance des origines CORS et ajout de `Vary: Origin`
    - [Web] déplacement de la vérification de mise à jour de mailcow côté serveur
    - [Web] création d'un modèle de boîte aux lettres par défaut avec accès EAS et DAV
    - [ACME] saut de la demande de certificat MTA-STS si MTA-STS n'est pas activé pour un domaine

    #autohebergement #mailcow #email #privacy #mesnumeriquesfr #selfhosted #souverainetenumerique

  12. Avant de me séparer du dernier exemplaire du flier @yunohost je l'ai scanné pour vous en faire profiter.
    Lancer vous, c'est (assez) facile et très protecteur pour vos données personnelles.
    Un veil ordi, un #raspberrypi et hop vous êtes chez vous tranquille.
    #autohebergement #donnéespersonnelles #monboutd'internet #internet
    fichiers.ouvaton.coop/f.php?h=

  13. Bienvenue dans Immich v3.1.0 !

    Cette version apporte plusieurs améliorations visant à rendre l'utilisation plus agréable, ainsi qu'une nouvelle série de corrections de bugs. Découvrez les points forts ci-dessous.

    Points forts :

    - Verrouillage d'activité (wakelock) lors des téléversements (Web)
    - Annulation de l'archivage (Web)
    - Filtrage des éléments par chemin de fichier sur le serveur (Workflows)
    - Accès rapide à la page de maintenance (Web)
    - Meilleure accessibilité du bouton de diaporama (Web)
    - Amélioration de la synchronisation des rôles OIDC (OAuth)
    - Invalidation des sessions lors de la réinitialisation du mot de passe (admin-cli)

    * Verrouillage d'activité (wakelock) lors des téléversements (Web)

    Tout comme sur mobile, l'application Web activera désormais automatiquement un verrouillage d'activité (wakelock) pour empêcher l'écran de s'assombrir pendant les téléversements. Cette fonctionnalité nécessite une connexion HTTPS.
    Annulation de l'archivage (Web)

    * Après l'archivage d'éléments, la notification de réussite inclut désormais un bouton « Annuler » pour revenir en arrière.

    * Filtrer les ressources par chemin d'accès serveur (workflows)

    Le filtre de fichiers de ressources dispose d'une nouvelle option « Utiliser le chemin ». Lorsqu'elle est activée, le filtrage s'effectue selon le chemin d'accès réel sur le serveur plutôt que selon le nom de fichier d'origine.

    * Filtrer les ressources par métadonnées EXIF ​​(workflows)

    Un nouveau filtre de workflow a été ajouté, permettant de filtrer les ressources en fonction de leurs champs de métadonnées EXIF. Pour l'instant, seules les comparaisons de chaînes de caractères sont prises en charge ; les comparaisons numériques devraient être disponibles prochainement.
    ...

    Source : github.com/immich-app/immich/r

    Et comme toujours, mon instance gallery.mesnumeriques.fr reste ouverte 😉

    #immich #selfhosting #autohebergement #mesnumeriquesfr #privacy #souverainetenumerique

  14. Je viens de résilier mon serveur OVH, ça faisait plus de 20 ans que je l'avais. Il m'a été tellement utile pendant toutes ces années.

    Bref. 25€ d'économie par mois. De quoi me payer un nouveau disque dur tous les deux ans, joie (/i).

    #selfhosting #autohebergement