baldessari

Archivio digitale di Luciano Baldessari — Django 1.4 / Python 2.7 (progetto del 2012, rimesso online nel 2018). Live: http://baldessari.densitydesign.org/

Stato dell'archiviazione (verificato il 2026-08-26)

✅ Tutto il contenuto è ora al sicuro e verificato, sia in git che localmente:

• db/db.sqlite — database, già in git. Confrontato riga per riga con il db in produzione sul server: tutte le tabelle di contenuto (57 progetti, 1436 disegni, 7495 lettere, 412 attori, 3 percorsi tematici, 26 dettagli tematici, admin log...) hanno conteggi identici. Nessun dato mancante o disallineato.
• baldessari/*Exp.json e i JSON in baldessari/archivio/management/commands/ — export testuali ridondanti degli stessi dati, già in git.
• baldessari/media/ — 2.5GB, 58.115 file reali (immagini di disegni, lettere, documenti; più 68 .DS_Store innocui già presenti sul server), recuperati via rsync dal server (/var/www/baldessari.densitydesign.org/baldessari/media/) il 2026-08-26. Conteggio file e dimensione verificati identici a quelli sul server. Non è in git (troppo pesante, ed esplicitamente escluso in .gitignore) — esiste anche altrove, vedi baldessari/media/README.md per dove trovare il backup (NAS/Drive/OneDrive del laboratorio).
• dbaccess/ — scheletro di un secondo progetto Django (django-admin startproject), mai configurato e non referenziato da nulla nel resto del repo. Non serve per far girare l'archivio: si può cancellare senza perdere nulla, se volete.
• Dockerfile, .python-version — containerizzazione del progetto, verificata e corretta, funziona end-to-end incluse le immagini (vedi "Avvio in locale").

Cosa NON portare via dal server, ora che abbiamo verificato

Sul server (/var/www/baldessari.densitydesign.org/) esistono anche due archivi zip di backup storici, ridondanti rispetto a quanto già recuperato: archiviobaldessari.zip (4.9GB, 2019 — bundle dell'intero vecchio server, env Python incluso) e media.zip (2.4GB, 2018 — snapshot della stessa media/ appena scaricata). Non serve scaricarli: il contenuto è coperto da quanto già recuperato qui.

✅ Dove sta il backup di media/ (non in git)

baldessari/media/ è stata impacchettata come media-baldessari-2026-08-26.tar.gz (2.3GB, SHA-256 in baldessari/media/README.md) e salvata in tre posti indipendenti dal server originale:

• NAS del laboratorio (smb://Densissimo._smb._tcp.local/densitydesign/projects/ [2011] Baldessari/)
• Google Drive del laboratorio
• OneDrive/SharePoint di Ateneo (link diretto in baldessari/media/README.md)

Dettagli completi, struttura delle cartelle e istruzioni di ripristino in baldessari/media/README.md.

Avvio in locale (il minimo indispensabile)

Serve solo Docker (Docker Desktop).

docker build -t baldessari-local .
docker run -d --name baldessari-run -p 8000:8000 \
  -v "$(pwd)/db:/app/db" \
  -v "$(pwd)/baldessari/media:/app/baldessari/media" \
  baldessari-local

Poi apri http://localhost:8000/ — redirige su /opere/progetti/elenco/. Funziona tutto: liste progetti, schede, timeline, mappa, galleria con le immagini, e admin (/admin/).

Per fermarlo:

docker rm -f baldessari-run

Admin / percorsi tematici

L'editing dei "percorsi tematici" (e di tutto il resto: progetti, disegni, lettere, attori...) si fa dalla Django admin, /admin/ — non esiste un login/editor custom in front-end (la view login in archivio/views.py è solo uno stub mai finito). Nel db ci sono 4 utenti (admin, leyla.ciaga, teresa, guest) ma le password non sono recuperabili (hash). Per testare in locale, resettarne una da shell:

docker exec -i baldessari-run python baldessari/manage.py shell <<'EOF'
from django.contrib.auth.models import User
u = User.objects.get(username='admin')
u.set_password('nuovapassword')
u.save()
EOF

Verificato funzionante: login, apertura di un percorso tematico, editing inline di titolo/testo/date/immagine per ogni tappa.

Note tecniche sul Dockerfile

• Base python:2.7 (fine vita, ma è l'unica versione compatibile con Django 1.4 / South / BeautifulSoup 3 usati dal progetto) — i repo apt sono stati ripuntati su archive.debian.org perché quelli standard non esistono più.
• Il codice originale fa import Image (stile vecchio PIL, pre-Pillow). Le versioni moderne di Pillow espongono solo PIL.Image. Ho aggiunto nel Dockerfile uno shim (Image.py che fa from PIL.Image import *) invece di modificare il codice sorgente originale.
• baldessari/baldessari_sketch/settings.py non è in git (è nel .gitignore, giusto così: contiene percorsi locali/segreti). Era già presente in locale — probabilmente creato durante un tentativo Docker precedente — con DEBUG=True e SQLite puntato a db/db.sqlite. Se dovesse mancare, va ricreato con DATABASES verso db/db.sqlite, MEDIA_ROOT/MEDIA_URL verso baldessari/media/ e /media/, STATIC_ROOT/STATIC_URL, e una SECRET_KEY qualsiasi (uso locale).
• Serve PIL/Pillow compilato con supporto jpeg/zlib/png/freetype: per questo va fatto girare in Docker (o Linux) — su macOS moderno la build nativa di Pillow 5.0.0 fallisce per librerie mancanti (testato).

Manutenzione del server di produzione (non riguarda l'archiviazione)

Due problemi trovati e sistemati sul server (baldessari.densitydesign.org) il 2026-08-26, indipendenti dal lavoro di backup:

• Disco quasi pieno (98%, 800MB liberi) — liberato spazio, ora al 71% (11GB liberi).
• db/db.sqlite in produzione non scrivibile (db.sqlite e la cartella db/ erano di proprietà di root, mentre Apache/mod_wsgi gira come www-data → qualsiasi scrittura, incluso il salvataggio di una sessione di login, falliva con DatabaseError: attempt to write a readonly database). Sistemato con chown www-data:www-data sul file e chgrp www-data + chmod 775 sulla cartella. La Django admin online torna a funzionare (login verificato).

Prossimi passi consigliati

1. Valutare se cancellare dbaccess/ (progetto scheletro inutilizzato).