Notes sur l'administration du site et de la machine.

On utilise actuellement (novembre 2012) 5 Go (novembre 2013) 9 Go (suite au passage partiel en FLAC) sur disons 500Go disponibles d'espace disque. quid_des_sources_wav_co.

… et moins de 1Go près de 3Go (en comptant les bots de merde) de bande passante par mois.

Note: L'hébergement de MPLY nous est gracieusement offert, la machine en question héberge d'autres sites, et est louée chez Online à 20€ HT/mois.

Des stats sur les visites etc sont dispos, mais pas publics comme ils sont là. Quelques personnes sont arrivées chez nous en tapant “Alizée” ou “vidigal” (je soupçonne qu'ils ont beaucoup cherché, ou que l'effet trackage de Google les a aidé). Et quelques sites référenceurs dont CaCa (essentiellement) et Mus-Incong, les autres sont des clicks un peu perdus. Une personne s'est notamment demandée «est il bon pour les yeux de travailler dans le nord ?» via Google et est tombée chez nous. On renverra à au_turbin_camarade et à premier_mai pour creuser cette question.

La limite pour le poids d'un fichier à envoyer vers le wiki est: 195Mo.

• https://www.dokuwiki.org/faq:uploadsize
• Extrait de /etc/apache2/mods-available/fcgid.conf :

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidConnectTimeout 60
  FcgidMaxRequestLen 200000000
</IfModule>

Et aussi:

Un petit tour dans php.ini pour passer de 128Mo de memory limit à 256Mo

De façon à éviter les:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 46774099 bytes) in Unknown on line 0, referer: http://mauvaispourlesyeux.tk/lib/exe/mediamanager.php?ns=&edid=wiki__text

Ou aussi, d'après cette page

Pour pouvoir uploader des fichiers de plus de 2Mo, il est nécessaire d’augmenter les capacités d’upload d’Apache. On modifie le fichier php.ini (nano /etc/php5/apache2/php.ini) et on y recherche les valeurs post_max_size et upload_max_filesize que l’on définira à 200M (200Mo dans mon cas suffit mais vous pouvez indiquer plus si vous le voulez).

L’upload de gros fichier étant plus long, on définit max_execution_time à 600 (voir plus selon votre connexion).

S'est posée la question pour transmerdunor, soit des sessions anormalement grandes. Qq remarques:

• Côté hébergement et stockage, ça va. On est pas en train de stocker des émissions de radios diffusées diffusées et enregistrées avec une grande régularité
• Il est légèrement incensé de balancer ça par HTTP (donc d'augmenter la limite du wiki). Le transfert est plus du ressort de rsync via ssh, ou de sftp.
• Il s'agit d'un usage exceptionnel (donc on accepte que la copie se fasse par clé USB ou autre) ou “universalisable”, dans ce cas, privilégier la possibilité de mener la chose entièrement via internet, et Envisager un compte SSH avec seul accès FTP (sans shell).

Toute autre extension sera refoulée par le Wiki, donc tenez vous-en à cette liste (qui peut être agrandie au besoin). Les lignes qui contiennent un “!” signifient que le fichier sera téléchargé lors d'un click gauche plutôt que directement lu dans le navigateur.

jpg     image/jpeg
jpeg    image/jpeg
gif     image/gif
png     image/png
tgz     !application/octet-stream
tar     !application/x-gtar
gz      !application/octet-stream
bz2     !application/octet-stream
zip     !application/zip
rar     !application/rar
pdf     application/pdf
ps      !application/postscript
doc     !application/msword
xls     !application/msexcel
ppt     !application/mspowerpoint
rtf     !application/msword
swf     application/x-shockwave-flash

rpm     !application/octet-stream
deb     !application/octet-stream

sxw     !application/soffice
sxc     !application/soffice
sxi     !application/soffice
sxd     !application/soffice

odc     !application/vnd.oasis.opendocument.chart
odf     !application/vnd.oasis.opendocument.formula
odg     !application/vnd.oasis.opendocument.graphics
odi     !application/vnd.oasis.opendocument.image
odp     !application/vnd.oasis.opendocument.presentation
ods     !application/vnd.oasis.opendocument.spreadsheet
odt     !application/vnd.oasis.opendocument.text

ogg     audio/ogg
flac    !audio/flac
mp3     !audio/mpeg

ogv     video/ogg
avi     !video/x-msvideo
mpg     !video/mpeg
mpeg    !video/mpeg
mov     !video/quicktime
mp4     !video/mp4
mkv     !video/x-matroska

pd      !application/x-puredata

… pour les albums musicaux dans /rel/

Dans le crontab du serveur,

crontab -e

# m h  dom mon dow   command
0 5 * * * su -c '/var/www/mauvaispourlesyeux.tk/rel/script_new.sh >> /var/www/mauvaispourlesyeux.tk/log_script.txt 2>&1' www-data

Le fichier script_new.sh en question.

• … créé aussi les .m3u, .nfo
• … créé aussi les informations sur les fichiers audio (spectre, etc)
• … effectue les conversions en mp3 et ogg

Le fichier http://mauvaispourlesyeux.tk/log_script.txt sert (pas proprement) à récupérer les éventuelles erreurs d'execution.

On utilise sox pour générer une représentation fréquentielle (spectrum) des fichiers sons. C'est joli, et ça peut même avoir une petite utilité. Il manque la génération de la forme d'onde (waveform, ce qu'on voit dans audacity et autres éditeurs audio), ce qui permettrait de voir comment elles sont masterisées…mais ça n'est pas possible avec les vieilles versions de sox (absent de debian wheezy !).

Note: Pas possible avec sox de vraiment ajuster la zone fréquentielle: http://sox.10957.n7.nabble.com/Spectrogram-for-custom-frequency-region-td2461.html

Actuellement, bug avec certains titres aux caractères accentués. Lié à la manière dont sont encodés les noms de fichiers par le wiki. Réglé à “url” ici, à voir si on aurait pu utiliser utf-8…

Expl sur infos, 01_remix_dilettante_1_le_re%CC%82ve_philouzophie_a_franc%CC%A7ois_flamand.ogg ; pourrait venir du fait que le nom du fichier n'est pas passé par l'étape “nettoyage” du wiki, je sais plus…

Voir aussi des solutions permettant de nettoyer le nom de fichier en bash: http://stackoverflow.com/questions/296536/urlencode-from-a-bash-script

Dans l'idée, il ne faudrait uploader que du FLAC sur MPLY (si c'est destiné à finir dans le catalogue, car si c'est juste 2-3 morceaux comme ça à l'arrache/temporaire c'pas forcément la peine).

Donc à partir des FLAC on produit les .ogg et les .mp3. Les .OGG sont en qualité 5. Les .MP3 sont encodés avec le preset –extreme, voir explications ici. A noter que même en preset –extreme ou –insane, un MP3 sera éventuellement moins bon qu'un Ogg en qualité 5. Un MP3 reste un MP3, donc coupe les fréquences hautes. Le reste est question d'algo psychoacoustiques assez peu discutés et comparés y compris au sein des milieux audiophiles (rien ici)

Le nom de domaine est à renouveler chaque année aux alentours de mi-fin février.

Je me rend compte qu'on pourrait rendre cette étape un peu moins sensible.

• en utilisant une boite email commune pour recevoir l'email de rappel de renouvelement. Le hic c'est qu'il faut une adresse email de contact bien fiable, à voir si celles en MPLY peuvent y prétendre (une histoire de serpent qui se mord la queue ?). On ne peut hélas pas préciser plusieurs adresses de contact.
• en laissant l'accès au compte dot.tk à plusieurs personnes, qui pourront donc changer la valeur des DNS et effectuer ce renouvèlement gratos.

Quant à la fiabilité du service DOT.TK, on s'est amusés à recenser les coupures que l'on a imputé à leur serveur DNS, en voilà l'historique : dottk

Voir aussi : http://www.freenom.com/en/freenom-api.html

Un problème notable de dot.tk : si un NDD nouvelement enregistré pointe sur une erreur, le NDD sera annulé et squatté.

(pas la meilleure, il vaudrait mieux écraser le wiki existant)

1. Installer un dokuwiki tout frais, faire le tour des nouveautés avec le template par défaut.
2. Copier les pages + medias du wiki vers la nouvelle install
3. Copier le template mply vers la nouvelle install
4. Voir le diff entre ancienne et nouvelle version du template standard
5. Repomper les fichiers de config, les mettre dans la nouvelle install
6. …

+ Penser à :

• /nonwiki/ (activer +Indexes dans la config de papache)
• le lien symbolique de /rel/ et de “data”

• Rincewind vers Angua
• Angua vers Adora Belle
• Site Jacko

… en guise d'inspiration.

• http://0.tuxfamily.org/doku.php
• http://www.randonner-leger.org/
• http://www.lescarottessauvages.org/association/presentation
• http://www.mosaic-industries.com/embedded-systems/sbc-single-board-computers/68hc11-c-language/instrument-control/microcontroller
• https://www.dokuwiki.org/dokuinstall (d'autres…)
• http://dunetna.probeta.net/doku.php/, usage en mode «blog» par une développeuse Debian

… toujours pour s'inspirer, d'autres sites appréciés pour une raison ou une autre

• http://blog.tincho.org/posts/Setting_up_my_server:_netfilter/, un ikiwiki transmuté en blog

• La bannière actuelle (Foucault) fait 220×114 (80+34). Retenir: 114px de hauteur, la largeur peut varier autant qu'on veut.
• La police du texte “mauvais pour les yeux” est [F500] (paquet fonts-f500) inspirée de wip3out.
• Icones: download: http://openclipart.org/detail/166618/download-by-mrtossum ; http://openclipart.org/detail/3827/floppy-disk-download-icon-by-selanit

• CSS de la partie admin pas parfait (liste des utilisateurs, “entêtes” de config.
• La bordure irrégulière ne va pas toujours jusqu'en bas
• Texte manquant avec le <a href> dans http://mauvaispourlesyeux.tk/article/logiciels?do=recent

Quelques plugins susceptibles de nous intéresser…

• http://www.dokuwiki.org/plugin:wrap (déjà installé)
• http://www.dokuwiki.org/plugin:asciisvg
• http://www.dokuwiki.org/plugin:svgedit
• http://rg42.org/wiki/abcmidi
• http://www.dokuwiki.org/plugin:ditaa : Diagrammes avec ditaa: http://ditaa.sourceforge.net
• http://www.drost-tenfelde.de/doku.php/?id=dokuwiki:plugins:icalendar:demo ; calendrier Ical (bof) https://www.dokuwiki.org/plugins?plugintag=calendar
• https://www.dokuwiki.org/plugin:gallery ; voir plus bas.
• https://www.dokuwiki.org/plugin:folded : permet de masquer/afficher des sections de texte voire carrémment des pages avec le plugin :page

• Virer la catégorie “Article” qui en fait ne sert à rien.
• Checker les pages orphelines (sitemap)
• Prévoir une partie pour les pages internationalisées (:en: :es: …)
• Des déplacements de fichiers media à faire. Voir si on peut les faire à la main → Oui ! On peut les faire depuis le serveur, donc sans avoir à réuploader le fichier à chaque fois.
• Des gens s'attèlent + ou - à rendre possible les déplacements de pages dans Dokuwiki

• Envisager une version anglaise (plus statique donc moins chiante à entretenir) de MPLY :D
• L'upload multiple ne marche pas avec midori: http://forum.dokuwiki.org/post/30535 ; http://valums.com/ajax-upload/ ⇒ Juin 2014: on s'en tape probablement !
• Pourrait y'avoir un script ou un cron qui sauvegarde le répertoire pages en .zip, que les internautes pourraient récupérer.
• QUESTION: voir si on peut rendre l'édition du wiki publique, sans inscription.
• Idée: Torrentifier pour distribuer les alboums (ou d'autres ressources ?)
• Problème: les anciens albums (sans FLAC) ne remplissent pas les critères pour le script de création d'albums (pages infos, spectres, etc…).
• Problème: la compression gzip n'est pas activée. Provoque des erreurs «PHP Warning: ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output compression' in /var/www/mauvaispourlesyeux.tk/inc/init.php on line 139». Voir le topic ?t=24030 sur le forum Admin du copain.
• Faire une mise à jour de dokuwiki …
• Dépot Git, avec interface publique pour chopper le code .zip
• Idée: Dropbox-like libre, avec authentification commune avec le wiki. Problème: le wiki sert déjà à ça, ne pas rajouter de frontière entre partage public et privé.

• Corriger la couleur des blocs de < file >
• Distinguer les blocs contenus dans les doubles ', normalement affichés en courier new, exemple
• Voir si on peut ajouter un “padding” sur le bord droit de l'écran pour que le texte ne colle pas.
• Virer les sous-sections “Modifier” pour chaque bloc avec entête, ou bien modifier la couleur en surbrillance (noir sur noir actuellement)
• Nom du contributeur en blanc sur blanc dans l'historique des modifs
• Rendre visibles les icônes pour les fichiers medias en liens. Checker /lib/exe/css.php, css_filetypes(). Now: interwiki, footnotes, TOC, idx_dir (mediamanager). Filename dans codeblock téléchargeable.
• Certains éléments dans la page syntax continuent de mal passer.
• Certains éléments lors des “diff” passent mal.
• Bordure noire lien souligné dans la page “détails” des images.
• Déplacer les fichiers de mply006, mply008 et mply009 ! (… les réuploader au bon endroit …)
• Création de .m3u, boutons [download] et [listen] pour chaque album
• Le lien vers “S'enregistrer” qui n'est pas visible … http://mauvaispourlesyeux.tk/article/entretien_site?do=login
• Automatiser les archives .zip pour les albums
• (wontfix) Bizarrerie: mon navigateur considère www.mply.tk et mply.tk comme 2 sites différents (les mots de passe sont enregistrés pour l'un, pas pour l'autre) ⇒ L'alias est fait au niveau du serveur Apache ainsi qu'au niveau du DNS. C'est le navigateur qui ne veut pas réunir les 2 domaines.

• prototype1 prototype2 prototype3 prototype4 (avec cd/lp indiqué) prototype5 prototype6 prototype7 de page d'accueil

Question et auto-réponse: Faut-il une mailing-list MPLY ? Vous savez, pour n'envoyer qu'un seul email, et prévenir tout le monde: les bicarbo, nos copiaines, nos collaborateurices… des gens qui s'inscrivent/désinscrivent à volonté pour suivre “notre actu”, des dates de concerts, de sorties de disques…. Réponse: non, car c'est un trop gros bordel administratif (pas technique) à gérer, qu'on risquerait d'oublier que ça existe ou qu'on sâche pas trop pour certains mails “on le balance individuellement ou au groupe ?”… mais vu que certains collectifs emploient ce genre d'outil, la question était à poser. Et la réponse peut changer dans le temps.

A noter que le wiki a un “flux RSS” qui permet de suivre s'il y a eu des modifs dans le wiki … je m'en sers pas car je viens checker MPLY régulièrement de tte manière. Aussi, il n'y a pas de flux RSS spécifique aux “concerts” ou aux autres types d'annonces, bien qu'il soit possible de le faire ! (si on restructure un peu).

Le flux de suivi classique du RSS est: http://mauvaispourlesyeux.tk/feed.php

Le flux pour ne suivre qu'une catégorie (namespace) du wiki est: http://mauvaispourlesyeux.tk/feed.php?mode=list&ns=article (ici, on suivra le namespace “:article:”

Hoooop, un peu de doc: https://www.dokuwiki.org/syndication ; c'est plus flexible que ce que je pensais, et c'est même le bordel je comprends pas tout …

Un expl, les diff: mauvaispourlesyeux.tk/feed.php?mode=list&ns=article&content=diff

On doit pouvoir pointer pour les diffs d'une page précise, ou d'un namespace précis, ou autre …

HIhihoho, du coup voilà un des trucs qu'on peut faire, les 8 derniers changements de MPLY:

• nouvelles_lettres_de_tristan:2023_09 - red alert
• zik:tristan:nl-202309.jpg - créée
• zik:tristan:nl-202309.ogg - créée
• nouvelles_lettres_de_tristan
• nouvelles_lettres_de_tristan:2023_08 - créée
• zik:tristan:nl-202308.ogg - créée
• zik:tristan:nl-202308.jpg - créée
• synthese_graphisme - [Autres]

Ce serait classe de regrouper les flux RSS des concerts/projections/etc des différents sites (indymedia, salles..) et d'afficher uniquement ceux du jour/(sur)lendemain (ou du jour passé en paramètre) → 'tain, l'agenda d'indymedia n'est pas en RSS → … et c'est en fait pareil sur un peu tous les sites, grrrouu

Tiens, marrant, si j'ajoute le flux RSS https://lille.indymedia.org/spip.php?page=backend ici, ça me fait un Internal Server Error. → Il semblerait que ce soit dû au “?” et ils conseillent d'utiliser des “url shortener”, mouais..

Si on les met en ligne, ça peut servir:

1. à faire des remixes
2. à reconvertir les fichiers dans des formats que les gens aiment bien (mp3, flac, opus :D)

Vu que la machine sur OVH a de la place (~250Go/1 To au total, en comptant les backups etc), et que l'ensemble des fichiers sons de MPLY en Flac devrait avoisiner 15Go au bout de plusieurs années de fonctionnement, tout roule…

Conclusion: passage au .flac. Et délocalisation des répertoires /rel/ et /data/media/ par un lien symbolique vers un espace de stockage à part (hors VM) sur la machine.

Le catalogue de MPLY est référencé sur le site MusicBrainz, précisément ici. L'intérêt premier, c'est que ça résoud la question du «Comment tagger proprement les fichiers». L'intérêt second, c'est de tirer profit de la plateforme et de ses outils, dont picard. Par contre, on n'utilise pas encore les outils côté serveur, coir http://mauvaispourlesyeux.tk/rel/script_new.sh. Et l'intérêt métaphysique, c'est que bien que Musicbrainz existe depuis lurette, on fait un peu figure d'early-adopters, et on peut être curieux des effets de sa démocratisation. Le projet est en cout cas en développement assez actif et très ouvert. Un autre intérêt, c'est que si on est pas content du nom donné à une chanson au moment de la sortie, on pourra toujours la changer dans la base de données MB (et sur mply.tk), ainsi, les personnes qui ont déjà téléchargé l'album avec les mauvais tags pourront facilement avoir ce changement reflété, si elles utilisent un logiciel compatible avec musicbrainz (genre un lecteur audio pas con, ou picard).

Apparemment, des bindings python sont dispos: https://python-musicbrainzngs.readthedocs.org/en/latest

Pour faire comme JKP, on pourrait en profiter pour faire une playlist globale de tous les albums MPLY, au format XSPF. XSPF étant calqué sur XML, un pas de plus vers le web ouvert.

Pas mega-nécessaire. Doit y'avoir des plugins pour faire ça. Ca permettrait d'avoir un format plus approprié pour l'impression et la consultation hors-ligne.

Dommage, on aurait pu utiliser ça pour les pages mply0xx, si on l'avait mis dans un namespace adéquat.

https://www.dokuwiki.org/plugin:gallery

Note: on peut éditer les légendes via le Gestionnaire de médias (en bas de chaque page), en éditant les données EXIF. Choisir l'image, puis aller dans l'onglet “éditer”).

Avec lightbox: ne se met pas tout à fait en plein écran, et ne permet pas de faire un click droit sur l'image (MERCI JAVASCRMERDE). Donc pas de lien direct ? Il faudrait ajouter une option.

En outre, un alignement des images qui reste un peu fastidieux: n'occupe que 80% de l'écran en mode centré, a des bordures moches (actuellement retirées) et trop espacées (réglables si on met &0 comme paramètre, voir aussi éventuellement &crop).

Possibilité de lire du Media RSS/Atom.

Le thème pp_default (!= light_rounded) me semble le meilleur, les autres ont des boutons moches.

On doit spécifier la durée du slideshow, ainsi que le thème, dans le fichier de config (et non pas dans Administrer).

J'aurais préféré que la version étendue soit le mode par défaut. Actuellement le slideshow fait se repositionner vers le mode “mini” quand il passe à l'image suivante.

Bon, je suis allé quémander ces fonctions sur le forum de dokuwiki, on verra bien…

Bon ben, PrettyPhoto a été remplacé par SwipeBox, qu'est assez basique…

Je viens de trouver un truc bizarre dans la liste d'inscrits

sindy924 	Kaylee Wigginton	Darrin221Y2N@aol.com

Un bot qui serait donc passé outre le captcha. Ah ben en fait y'a pas de Captcha, donc c'est un miracle que le wiki n'ait pas encore été envahi.

→ C'est arrivé. Le wiki a eu à peu près 14000 nouveaux comptes en 2 jours, et 10 nouvelles pages créées pour balancer du spam. Rien de grave car facile à nettoyer (ça aurait pu être pire). Du coup, changement de mode de captcha, on passe d'un truc pré-rempli en javascript, à un captcha VISUEL+AUDIO, j'aurais préféré un captcha sémantique… on verra si ça bloque le spam.

Note: il est possible bien que peu probable que j'aie viré des comptes légitimes dans l'élan … Précisément, si le compte a été créé entre le 16 avril 2013, et le 14 juillet 2013, il a été supprimé.

19/07/13: 40 robots inscrits en ayant le captcha réglé sur Image+Sound. ⇒ Trouver un plugin ou implémenter un captcha sémantique… MàJ Dokuwiki pourrait aider. → Mise à jour du plugin captcha uniquement. Nettoyé la liste des users, et rebasculé vers “captcha prérempli par javascript”.

03/08/17: 7-8 comptes inscrits, le plugin captcha était à jour, donc je bascule sur le mode “question fixe”.

… Possible que ça se fasse un jour. (et mon cul c'est du tofu le fait)

L'intérêt est non-négligeable, plutôt que de clicker sur les albums un par un, on pourrait juste chopper le torrent, et, magie de bittorrent, si on n'a pas envie de tout télécharger on peut selectionner les albums qu'on veut.

Et pourquoi pas aussi sur Soulseek. Problème: le client en mode console il suinte un peu du ionf. On ne peut donc pas trop faire de seedbox (à voir).

→ http://web.archive.org/web/20101023220328/http://mauvaispourlesyeux.tk/ ; au début on ressemblait à ça, c'est seulement après qu'on est devenus des gros chanmés black&white

La question se pose dès lors qu'on propose des boites emails avec notre nom de domaine. La précarité des solutions auto-hébergées, ou le nécessité d'investir une nouvelle boite email avec du courrier ancien, fait qu'on doit pouvoir songer à faire la migration.

• https://github.com/rgrove/larch/ (en Ruby)
• https://github.com/joeyates/imap-backup (aussi en Ruby), permet de faire des backups locaux au format Maildir. Semble se galérer et mouliner dans le vide lorsque la boite est trop grosse.
• Sinon ptet même que Thunderbird/Icedove est cap' de le faire.
• D'autres outils dans d'autres langages (pas noté les liens).
• http://offlineimap.org/

…à refaire le template, après mise à jour du code (assez vieux) du wiki.

Les fonts ont été pécho ici : https://www.fontsquirrel.com/fonts/list/find_fonts/0?filter[license][0]=web À cause des histoires merdiques de licence, peu pratique de les utiliser/choisir.

Il reste encore à cacaïfier le template, c'est à dire rajouter un peu de décoration…

+ voir pour le 'youarehere'

+ voir les mply0xx:infos : les détails file info se mettent à droite et sont coupés

+ voir pour un fond du site autre que tout noir.

+ zone edit mply