/!\ Ce billet contient un certain niveau de rage et de frustration envers un logiciel non coopératif et bugué. Merci d’en tenir compte lors de votre lecture. /!\

Mise à jour du 09 décembre 2014, 14h

J’ai reçu un mail d’un lecteur qui m’explique comment il a laissé tombé Owncloud devant le manque constant de fiabilité et est passé à SeaFile. Il donne plus de détails sur son blog : « Ownbutt, SparkleShare, Git-Annex, Seafile… Quelle solution libre pour héberger et synchroniser ses fichiers ? » et a rédigé une dépêche sur LinuxFR pour présenter la version 3 : « Seafile, un Dropbox-like libre à héberger sort en version 3 »

Effectivement ça a l’air alléchant, mais SeaFile ne propose pas encore de service CardDav, ni CalDav pour synchroniser des contacts ou des calendriers. Ayant laissé tombé mon instance Baïkal pour passer à OwnCloud, ça m’embêterai de séparer à nouveau ces services là.

Article d’origine

ownButt est un logiciel en PHP qui sert à héberger son propre service de partage de fichiers. Globalement c’est un équivalent libre de Dropbox qui fait aussi de la synchro de contacts et de calendriers.

Il y a quelques temps maintenant, les gestionnaires du projet ont annoncé en grande pompe le module de chiffrement côté serveur qui permet aux utilisateurices de s’assurer que leur hébergeur ne pourras pas voir le contenu des fichiers envoyés. (À ce point là, il est important de noter que la personne en charge de l’administration dispose d’une clé de récupération, au cas où.)

Même si je suis mon propre hébergeur, je me suis empressé d’activer ce module lors de l’installation de mon instance il y a deux ou trois mois, imaginant déjà libérer mes potes du joug de Dropbox en les rassurant sur le fait que je ne pourrais pas accéder à leurs dick- ou clit-pics sans qu’illes soient au courant.

Si vous êtes pressés je vous la fait courte : J’aurais pas du.

J’ai donc commencé à utiliser le client de synchronisation d’abord en transférant toute ma dropbox, puis en activant l’envoi automatique de mes photos prises sur mon téléphone, puis en y mettant mes dotfiles pour y avoir accès de partout.

Jusqu’au jour où, pour une raison inconnue, le client de synchronisation d’ownButt a merdé pendant la synchro de mon dossier .atom (l’éditeur de github) et je me suis retrouvé avec MariaDB qui râlait à la DUPLICATE ENTRY dans une table.

Évidemment à ce point il y a trop de fichiers en erreur pour corriger à la main et ça me semble trop aléatoire pour être scripté rapidement.

Après recherches, des pistes semblent indiquer que c’est du à la manière dont le module de chiffrement gère (mal) les noms de fichiers. Je me suis donc dit que j’allais juste le désactiver, qu’ownButt déchiffrerait mes fichiers au fil des accès et que j’aurais juste à supprimer mon dossier pourri et à le renvoyer.

Hahaha, naïf que je suis. Il faut lancer manuellement une requête de déchiffrement dans les options et évidemment ça prend un temps fou. Firefox laisse tomber la requête AJAX au bout d’une demi heure, mais ça continue de tourner et c’est le max execution time de PHP qui détermine le temps avant plantage (En l’occurrence, ce fut une heure)

Je ne me laisse pas démonter et je met un petit set_time_limit(0) au début du script histoire d’être sûr et je le relance en gardant un œil sur les logs dans un tmux. Deux heures plus tard il plante à nouveau Calling method ->machintruc() on a non-object

Je commence un peu à m’échauffer parce que quand on utilise des fonctions qui renvoient nulll ou un objet, la moindre des choses c’est de vérifier qu’on a bien un objet après l’appel à cette fonction… J’ajoute cette vérif en loguant bien les erreurs et je relance le bouzin.

Après cinq heures à mouliner¹ c’est au tour de MariaDB de se plaindre : General error: 2006 MySQL server has gone away Parce que oui, le timeout il est par défaut à 300 secondes. Donc on ouvre la connexion et cinq heures plus tard il y a plus personne au bout du fil. Nouvel essai.

Après 6 heures, les logs s’arrêtent de défiler (j’ai rajouté le log du chemin de chaque fichier déchiffré histoire de voir quand ça s’arrête parce que sinon c’est le noir complet) et comme il n’y a pas d’erreur je commence à me dire que ça y est, peut-être mes galères sont terminées. Je me connecte donc à l’interface web pour voir et… « Le chiffrement était désactivé mais vos fichiers sont toujours chiffrés. Veuillez vous rendre sur vos Paramètres personnels pour déchiffrer vos fichiers. » cette cochonnerie de message est toujours là. MAIS IL Y A PAS D’ERREUR ! APACHE SE TOURNE LES POUCES !

Évidemment après vérification, une grande partie de mes fichiers est toujours chiffrée, j’ai beau relancer leur script de merde ça ne change absolument rien et le client de synchro râle toujours qu’il n’a pas pu synchroniser * fichiers en raison d’une erreur inattendue sur le serveur.

Bref, je suis bon pour tout supprimer et tout renvoyer. Ce qui avec mon accès ADSL va prendre environ… 130 heures à vitesse maxi. (ノಠ益ಠ)ノ

N’activez pas le module de chiffrement d’ownButt. Sauf si vous voulez vous prendre la tête pour rien.

/!\ Ce billet contient un certain niveau de rage et de frustration envers un logiciel non coopératif et bugué. Merci d’en tenir compte lors de votre lecture. /!

Mise à jour du 09 décembre 2014, 14h

J’ai reçu un mail d’un lecteur qui m’explique comment il a laissé tomber Owncloud devant le manque constant de fiabilité et est passé à SeaFile. Il donne plus de détails sur son blog : « Ownbutt, SparkleShare, Git-Annex, Seafile… Quelle solution libre pour héberger et synchroniser ses fichiers ? » et a rédigé une dépêche sur LinuxFR pour présenter la version 3 : « Seafile, un Dropbox-like libre à héberger sort en version 3 »

Effectivement ça a l’air alléchant, mais SeaFile ne propose pas encore de service CardDav, ni CalDav pour synchroniser des contacts ou des calendriers. Ayant laissé tomber mon instance Baïkal pour passer à OwnCloud, ça m’embêterait de séparer à nouveau ces services là.

Article d'origine

ownButt est un logiciel en PHP qui sert à héberger son propre service de partage de fichiers. Globalement c’est un équivalent libre de Dropbox qui fait aussi de la synchro de contacts et de calendriers.

Il y a quelques temps maintenant, les gestionnaires du projet ont annoncé en grande pompe le module de chiffrement côté serveur qui permet aux utilisateurices de s’assurer que leur hébergeur ne pourra pas voir le contenu des fichiers envoyés. (À ce point là, il est important de noter que la personne en charge de l’administration dispose d’une clé de récupération, au cas où.)

Même si je suis mon propre hébergeur, je me suis empressé d’activer ce module lors de l’installation de mon instance il y a deux ou trois mois, imaginant déjà libérer mes potes du joug de Dropbox en les rassurant sur le fait que je ne pourrais pas accéder à leurs dick- ou clit-pics sans qu’illes soient au courant.

Si vous êtes pressés je vous la fait courte : J’aurais pas dû.

J’ai donc commencé à utiliser le client de synchronisation d’abord en transférant toute ma dropbox, puis en activant l’envoi automatique de mes photos prises sur mon téléphone, puis en y mettant mes dotfiles pour y avoir accès de partout.

Jusqu’au jour où, pour une raison inconnue, le client de synchronisation d’ownButt a merdé pendant la synchro de mon dossier .atom (l’éditeur de github) et je me suis retrouvé avec MariaDB qui râlait à la DUPLICATE ENTRY dans une table.

Évidemment à ce point il y a trop de fichiers en erreur pour corriger à la main et ça me semble trop aléatoire pour être scripté rapidement.

Après recherches, des pistes semblent indiquer que c’est dû à la manière dont le module de chiffrement gère (mal) les noms de fichiers. Je me suis donc dit que j’allais juste le désactiver, qu’ownButt déchiffrerait mes fichiers au fil des accès et que j’aurais juste à supprimer mon dossier pourri et à le renvoyer.

Hahaha, naïf que je suis. Il faut lancer manuellement une requête de déchiffrement dans les options et évidemment ça prend un temps fou. Firefox laisse tomber la requête AJAX au bout d’une demi heure, mais ça continue de tourner et c’est le max execution time de PHP qui détermine le temps avant plantage (En l’occurrence, ce fut une heure)

Je ne me laisse pas démonter et je met un petit set_time_limit(0) au début du script histoire d’être sûr et je le relance en gardant un œil sur les logs dans un tmux. Deux heures plus tard il plante à nouveau Calling method ->machintruc() on a non-object

Je commence un peu à m’échauffer parce que quand on utilise des fonctions qui renvoient null ou un objet, la moindre des choses c’est de vérifier qu’on a bien un objet après l’appel à cette fonction… J’ajoute cette vérif en loguant bien les erreurs et je relance le bouzin.

Après cinq heures à mouliner¹ c’est au tour de MariaDB de se plaindre : General error: 2006 MySQL server has gone away Parce que oui, le timeout il est par défaut à 300 secondes. Donc on ouvre la connexion et cinq heures plus tard il y a plus personne au bout du fil. Nouvel essai.

Après 6 heures, les logs s’arrêtent de défiler (j’ai rajouté le log du chemin de chaque fichier déchiffré histoire de voir quand ça s’arrête parce que sinon c’est le noir complet) et comme il n’y a pas d’erreur je commence à me dire que ça y est, peut-être mes galères sont terminées. Je me connecte donc à l’interface web pour voir et… « Le chiffrement était désactivé mais vos fichiers sont toujours chiffrés. Veuillez vous rendre sur vos Paramètres personnels pour déchiffrer vos fichiers. » cette cochonnerie de message est toujours là. MAIS IL Y A PAS D’ERREUR ! APACHE SE TOURNE LES POUCES !

Évidemment après vérification, une grande partie de mes fichiers est toujours chiffrée, j’ai beau relancer leur script de merde ça ne change absolument rien et le client de synchro râle toujours qu’il n’a pas pu synchroniser * fichiers en raison d’une erreur inattendue sur le serveur.

Bref, je suis bon pour tout supprimer et tout renvoyer. Ce qui avec mon accès ADSL va prendre environ… 130 heures à vitesse maxi. (ノಠ益ಠ)ノ

N’activez pas le module de chiffrement d’ownButt. Sauf si vous voulez vous prendre la tête pour rien.

/!\ Ce billet contient un certain niveau de rage et de frustration envers un logiciel non coopératif et bugué. Merci d’en tenir compte lors de votre lecture. /!

Mise à jour du 09 décembre 2014, 14h

J’ai reçu un mail d’un lecteur qui m’explique comment il a laissé tomber Owncloud devant le manque constant de fiabilité et est passé à SeaFile. Il donne plus de détails sur son blog : « Ownbutt, SparkleShare, Git-Annex, Seafile… Quelle solution libre pour héberger et synchroniser ses fichiers ? » et a rédigé une dépêche sur LinuxFR pour présenter la version 3 : « Seafile, un Dropbox-like libre à héberger sort en version 3 »

Effectivement ça a l’air alléchant, mais SeaFile ne propose pas encore de service CardDav, ni CalDav pour synchroniser des contacts ou des calendriers. Ayant laissé tomber mon instance Baïkal pour passer à OwnCloud, ça m’embêterait de séparer à nouveau ces services là.

Article d'origine

ownButt est un logiciel en PHP qui sert à héberger son propre service de partage de fichiers. Globalement c’est un équivalent libre de Dropbox qui fait aussi de la synchro de contacts et de calendriers.

Il y a quelques temps maintenant, les gestionnaires du projet ont annoncé en grande pompe le module de chiffrement côté serveur qui permet aux utilisateurices de s’assurer que leur hébergeur ne pourra pas voir le contenu des fichiers envoyés. (À ce point là, il est important de noter que la personne en charge de l’administration dispose d’une clé de récupération, au cas où.)

Même si je suis mon propre hébergeur, je me suis empressé d’activer ce module lors de l’installation de mon instance il y a deux ou trois mois, imaginant déjà libérer mes potes du joug de Dropbox en les rassurant sur le fait que je ne pourrais pas accéder à leurs dick- ou clit-pics sans qu’illes soient au courant.

Si vous êtes pressés je vous la fait courte : J’aurais pas dû.

J’ai donc commencé à utiliser le client de synchronisation d’abord en transférant toute ma dropbox, puis en activant l’envoi automatique de mes photos prises sur mon téléphone, puis en y mettant mes dotfiles pour y avoir accès de partout.

Jusqu’au jour où, pour une raison inconnue, le client de synchronisation d’ownButt a merdé pendant la synchro de mon dossier .atom (l’éditeur de github) et je me suis retrouvé avec MariaDB qui râlait à la DUPLICATE ENTRY dans une table.

Évidemment à ce point il y a trop de fichiers en erreur pour corriger à la main et ça me semble trop aléatoire pour être scripté rapidement.

Après recherches, des pistes semblent indiquer que c’est dû à la manière dont le module de chiffrement gère (mal) les noms de fichiers. Je me suis donc dit que j’allais juste le désactiver, qu’ownButt déchiffrerait mes fichiers au fil des accès et que j’aurais juste à supprimer mon dossier pourri et à le renvoyer.

Hahaha, naïf que je suis. Il faut lancer manuellement une requête de déchiffrement dans les options et évidemment ça prend un temps fou. Firefox laisse tomber la requête AJAX au bout d’une demi heure, mais ça continue de tourner et c’est le max execution time de PHP qui détermine le temps avant plantage (En l’occurrence, ce fut une heure)

Je ne me laisse pas démonter et je met un petit set_time_limit(0) au début du script histoire d’être sûr et je le relance en gardant un œil sur les logs dans un tmux. Deux heures plus tard il plante à nouveau Calling method ->machintruc() on a non-object

Je commence un peu à m’échauffer parce que quand on utilise des fonctions qui renvoient null ou un objet, la moindre des choses c’est de vérifier qu’on a bien un objet après l’appel à cette fonction… J’ajoute cette vérif en loguant bien les erreurs et je relance le bouzin.

Après cinq heures à mouliner¹ c’est au tour de MariaDB de se plaindre : General error: 2006 MySQL server has gone away Parce que oui, le timeout il est par défaut à 300 secondes. Donc on ouvre la connexion et cinq heures plus tard il y a plus personne au bout du fil. Nouvel essai.

Après 6 heures, les logs s’arrêtent de défiler (j’ai rajouté le log du chemin de chaque fichier déchiffré histoire de voir quand ça s’arrête parce que sinon c’est le noir complet) et comme il n’y a pas d’erreur je commence à me dire que ça y est, peut-être mes galères sont terminées. Je me connecte donc à l’interface web pour voir et… « Le chiffrement était désactivé mais vos fichiers sont toujours chiffrés. Veuillez vous rendre sur vos Paramètres personnels pour déchiffrer vos fichiers. » cette cochonnerie de message est toujours là. MAIS IL Y A PAS D’ERREUR ! APACHE SE TOURNE LES POUCES !

Évidemment après vérification, une grande partie de mes fichiers est toujours chiffrée, j’ai beau relancer leur script de merde ça ne change absolument rien et le client de synchro râle toujours qu’il n’a pas pu synchroniser * fichiers en raison d’une erreur inattendue sur le serveur.

Bref, je suis bon pour tout supprimer et tout renvoyer. Ce qui avec mon accès ADSL va prendre environ… 130 heures à vitesse maxi. (ノಠ益ಠ)ノ

N’activez pas le module de chiffrement d’ownButt. Sauf si vous voulez vous prendre la tête pour rien.

Cette après-midi je suis tombé sur un partage trollesque d’un gros malin qui voulait se payer une bonne tranche de rigolade au détriment de ces imbéciles de féministes qui prennent la tête (cliquez sur la miniature pour le lire en entier) :

Ce truc est « intéressant » à plusieurs égards.

D’abord parce qu’il est partagé par des gens qui généralement s’érigent contre « la dictature de la pensée unique » et qui soudain, devant des femmes qui émettent des opinions à l’évidence contradictoires, sont tellement troublés qu’ils ne peuvent plus répondre que « Lol, ces connasses arrivent même pas à être d’accord. » et que ça me fait doucement ricaner.

Ensuite parce qu’il enchaîne des arguments pouvant être vus différemment selon le contexte où ils sont énoncés.

Quand cette phrase provient d’une personne identifiée comme féministe, il est évident qu’on se place dans un contexte militant énonçant les choses comme elles devraient être (selon le point de vue de la personne.)

Mais elle peut aussi être prononcé par quelqu’un de non engagé, éventuellement plein de bonne volonté qui considère que l’égalité est d’ors et déjà acquise.

On appelle ça être gender-blind et il existe un équivalent raciste : color-blind. Ce sont ces gens qui refusent de voir les inégalités et les discrimination et s’en justifient par le fait que EUX, personnellement, traitent tout le monde sur un pied d’égalité.
Par conséquent, il serait formellement impossible qu’ils puissent bénéficier du moindre privilège ou qu’ils puissent être sexistes ou racistes.

Alors que non seulement leur comportement individuel importe peu quand on parle de systèmes oppressif (et très souvent ce comportement n’est même pas remis en cause), mais en plus, à moins de vivre dans une bulle isolée il est absolument impossible de ne pas prendre part à de tels systèmes.

Réduire les problèmes systémiques à un problème de personnes est un moyen facile des les faire disparaître sous le tapis. On appelle ça la dépolitisation et, si c’est malheureusement une des pratiques courante chez celles et ceux qui ne luttent pas pour l’égalité, elle est encore plus présente chez celles et ceux qui luttent CONTRE.

Dans ce cas, c’est là que les féministes arrivent et expliquent que la situation est loin d’être égalitaire, qu’il existe des différences entre les hommes et les femmes comme par exemple dans le partage inégal des tâches ménagères, la valorisation inégales entre les activités traditionnellement dévouées aux hommes ou aux femmes, ou encore dans les différences de salaire à poste et compétences équivalentes.

C’est là aussi que des gens comme (par exemple) les anti-gender de la manif pour tous arrivent (mais ils ne sont pas les seuls) et protestent puisque selon eux les hommes et les femmes étant biologiquement différents, il est donc naturel que les unes soient traitées différemment des autres. Ils en profitent au passage pour passer sous silence que ce qui est « naturel » n’est pas si évident et intuitif à définir que ça mais aussi que nos comportements et nos actes sont très largement influencés par notre culture.

On peut retrouver ce point de vue dans « Women are unique in every way » puisque si les femmes sont uniques mais ont toujours pour point commun d’être des femmes, elles sont bien à traiter différemment (on peut même y voir le sexisme bienveillant du galant homme qui traite chaque femme de manière exceptionnelle.) D’où la protestation : « Now he’s saying women and men aren’t equal. »

Mais en même temps, rappeler que les femmes sont chacune uniques et ne peuvent pas se cantonner à ce que la société voudrait leur imposer c’est aussi et surtout ce que disent les « social justice warriors », en généralisant aussi aux hommes, puisque selon nous, chaque unique individu a ses réactions, ses envies, ses préférences propres et il serait beaucoup plus intéressant de vivre dans une société où on ne force pas les gens à rentrer dans un moule qu’ils n’ont pas choisis pour mieux les exploiter.

Bref, ce petit extrait des Simpsons montre bien que contrairement à ce que certaines personnes aiment bien ânonner ad nauseam (« Moi je regarde les idées, pas les personnes. ») une même phrase peut vouloir dire tout et son contraire selon les intentions de son auteur.

Cette après-midi je suis tombé sur un partage trollesque d’un gros malin qui voulait se payer une bonne tranche de rigolade au détriment de ces imbéciles de féministes qui prennent la tête (cliquez sur la miniature pour le lire en entier) : [caption id=“attachment_1537” align=“aligncenter” width=“193”] L’homme et la femme sont égaux…ou pas…enfin si ![/caption] Ce truc est « intéressant » à plusieurs égards. D’abord parce qu’il est partagé par des gens qui généralement s’érigent contre « la dictature de la pensée unique » et qui soudain, devant des femmes qui émettent des opinions à l’évidence contradictoires, sont tellement troublés qu’ils ne peuvent plus répondre que « Lol, ces connasses arrivent même pas à être d’accord.