Skip to main content

22_Readeck

readeck

Imagecodeberg.org/readeck/readeck:latest
EtatUp 9 hours
Compose projectreadeck
Reseaureadeck_default
URLhttps://readeck.juxjux.ovh

Ports

HoteContainerIP
45678000/tcp0.0.0.0
45678000/tcp::

Volumes

Source (hote)DestinationTypeMode
/home/debian/readeck/exports/exportsbindrw
/readeckvolumerw
/home/debian/readeck/data/readeck/databindrw

Integration Claude Code — MCP

Statut MCPMCP actif
Outils (prefix)mcp__readeck__
ConfigurationScript Python : C:\Users\eliob\.claude\mcp_readeck.py | Auth : token API Bearer (MFA actif sur le compte web)

Outils disponibles

  • get_bookmarks
  • get_bookmark
  • create_bookmark
  • update_bookmark
  • delete_bookmark
  • get_labels
  • get_profile

Ce que nous pouvons faire ensemble

  • Sauvegarder un article ou une page web depuis Claude Code
  • Parcourir et rechercher les articles enregistrés
  • Organiser les bookmarks avec des labels
  • Mettre à jour le statut (lu/archivé) d'un article
  • Supprimer des bookmarks obsolètes

Sauvegarde de la base de données

Sauvegarde automatique quotidienne de la base SQLite de Readeck vers kDrive Infomaniak. Mise en place le 2026-06-01.

Paramètres

Script/opt/backups/vps_backup.sh
CronTous les jours à 2h du matin (0 2 * * *)
Type baseSQLite — /readeck/data/db.sqlite3 (dans le container)
Méthodedocker cp readeck:/readeck/data/db.sqlite3
Taille base~8.5 Mo
Format archive.7z (compression niveau 5)
DestinationkDrive Infomaniak — TOOJUX/jux_vps/readeck (dossier ID 1427922)
Rétention7 jours glissants
Nommage fichierreadeck_db_YYYY-MM-DD.7z

Note

Le volume /readeck (non bindé) contient les fichiers des articles (images, HTML). La base SQLite ne couvre que les métadonnées et le texte extrait — les contenus médias ne sont pas inclus dans ce backup.

Incident résolu — pages trop lourdes rejetées (2026-08-20)

Symptôme : l'extension navigateur Readeck échouait à sauvegarder certaines pages, avec une erreur indiquant une page trop lourde.

Cause

Le vhost nginx qui sert readeck.juxjux.ovh (fichier trompeur sites-enabled/radicale.juxjux.ovh, voir plus haut) n'avait pas de directive client_max_body_size. Nginx applique alors sa limite par défaut de 1 Mo. L'extension navigateur envoie le contenu complet de la page (DOM) en POST plutôt qu'une simple URL — une page riche en images dépasse facilement ce seuil, d'où un rejet (413) que l'extension affiche comme « page trop lourde ».

Correctif

Fichiersites-enabled/radicale.juxjux.ovh
ModificationAjout de client_max_body_size 100M; dans le bloc serveur 443, juste après server_name readeck.juxjux.ovh;
Sauvegarde/home/debian/nginx-backups/radicale.juxjux.ovh.bak-260820
Vérificationsudo nginx -t puis sudo nginx -s reload, testé en conditions réelles — la sauvegarde de pages précédemment refusées fonctionne

Piège rencontré : le premier fichier de sauvegarde a été déposé par erreur dans sites-enabled/ lui-même. Comme nginx inclut sites-enabled/* sans filtrer sur l'extension, ce doublon a déclenché un warning conflicting server name. Toujours sauvegarder les fichiers de vhost en dehors de sites-enabled/ (ex. /home/debian/nginx-backups/).

Si une page dépasse encore 100 Mo, augmenter la valeur dans ce même fichier puis recharger nginx.

No comments to display

Back to top