Provare integrazione Etherpad

[feroda]

Provare integrazione Etherpad

[valerio-bozzolan]

Immagino ci si riferisca a questo repository:

https://github.com/iorestoacasa-work/docker-jitsi-meet

Ho notato che https://beta.etherpad.org in questo momento non è raggiungibile e apparentemente sono migrati qui: https://video.etherpad.com/ (trovato provando ad accedere senza HTTPs: http://beta.etherpad.org/ )

[valerio-bozzolan]

Modificando a mano la configurazione JavaScript di Jitsi, Etherpad funziona:

Il menù per aprire il pad non è così visibile. Credevo fosse legato alla chat, invece è una opzione nel menù contestuale (···).

Non sono riuscito a fargli leggere il file .env. Probabilmente non ho capito come dire a Docker di rilanciare web/rootfs/etc/cont-init.d/10-config che si occupa proprio di fare quello. Se qualcuno mi dà una dritta per risolvere questo mio problema, mando una pull request con questa piccola modifica che abilita il pad di beFair:

valerio-bozzolan/docker-jitsi-meet@1a706d1

P.S.

A margine forse alcuni nerd dovranno disabilitare il blocco dei cookie di terze parti perchè sennò non funziona il pad, se viene usato quello di default. Questo perchè il sito viene incluso con un iframe nella pagina di Jitsi ed essendo fornito da un dominio diverso da quello di Jitsi, e richiedendo cookie, potreste incappare nel suddetto blocco. Comunque questo "problema" - che comunque in qualche modo riguarda la privacy dell'utente - si potrebbe risolvere molto semplicemente piazzando un semplice proxy frontend con nginx, facendo servire Etherpad dallo stesso dominio... o comunque installando Etherpad sul server stesso. Nel primo caso il server finale non conoscerebbe l'IP dell'utilizzatore ma andrebbe comunque a contatto con i suoi contenuti e quindi andrebbe aggiornata la privacy policy per includere comunque quel servizio esterno. Nel secondo caso non servirebbe aggiornare la privacy policy.

[feroda]

grazie pinguino asdoso! anche le considerazioni sulla privacy bisogna tenerne conto. Non so se sono abbastanza lucido per darti qualche risposta:

1. darei la possibilità nel docker-compose di avere un etherpad nella propria installazione e aggiungere il servizio alla privacy policy
2. nella configurazione ciò non toglie che un host di iorestoacasa.work potrebbe specificare un servizio esterno (ad esempio https://pad.befair.it ;-) come hai fatto tu) e quindi sarebbe un problema della privacy policy di quel host

[feroda]

doh! ecco la tua risposta! https://iorestoacasa.work/faq.html#faq4

[valerio-bozzolan]

Riassumo un momento cosa ho provato nelle ultime ore.

Al momento l'immagine Docker Jitsi web NON riporterà automaticamente l'Etherpad nel file config.js.

Questo perchè al momento lo script di startup utilizzato nell'immagine Docker Jitsi web (/etc/cont-init.d/10-config) salta qualsiasi modifica al file config.js se esiste già (perchè lui si aspetta di prendere quello di default, fargli due modifiche, e non toccarlo mai più.

Vedi: https://github.com/jitsi/docker-jitsi-meet/blob/b039b29b7aeeee28f9f7395ec87e8aa69105ce9f/web/rootfs/etc/cont-init.d/10-config#L71

Siccome siamo noi a fornirgli il config.js lui non lo modifica mai (siamo noi a fornirglielo perchè al momento c'è scritto così nel file di configurazione del nostro Docker compose).

Vedi: https://github.com/iorestoacasa-work/docker-jitsi-meet/blob/4a81c3551666bed6b6e8696865c71fcf06877749/docker-compose.yml#L14

Si potrebbe volere modificare lo script di startup di Jitsi web per far sì che in ogni caso modifichi il file config.js anche se esiste già.

Vedi: https://github.com/iorestoacasa-work/docker-jitsi-meet/blob/master/web/rootfs/etc/cont-init.d/10-config

Il problema è che non si può modificare localmente. Anche se si elimina .jitsi-meet-config, o persino se si distrugge l'immagine a cannonate con docker rm e si ritira su tutto... poi rientrando nel container Jitsi web (con docker exec -it docker-jitsizmeet_web_1 bash) si può constatare che il suo file non è cambiato rispetto alle modifche che si ha in locale in web/rootfs/etc/cont-init.d/10-config. Presumo quindi che quest'ultimo file locale al momento non sia utilizzato.

Domanda: è proprio richiesto di NON modificare a mano il config.js? Perchè se lo si modifica a mano in concordanza con il file .env funziona tutto.