Erreur lors de la connexion au référentiel fossile en ligne après modification du mot de passe

Question

J'ai créé un référentiel fossile sur un compte d'hébergement partagé dont je dispose. J'ai créé un script Perl fossil.pl qui pointe vers un référentiel cloné que j'ai mis en place sur l'espace web. J'ai mis toutes les autorisations correctes (755). Quand je vais à fossil.pl, je reçois le web ui. Tout est cool. Cependant, j'ai un problème avec les poussées et j'espère que quelqu'un pourrait me diriger vers une solution. Lorsque je clone un référentiel, il me définit un nouveau mot de passe (Toby) dans le nouveau référentiel cloné. Si j'appuie sur ce référentiel en ligne sans changer le mot de passe, cela fonctionne très bien, je peux pousser les changements de ma machine locale vers le dépôt en ligne. Cependant, une fois que je change le mot de passe pour Toby (à quelque chose de plus facilement mémorisé par moi), j'obtiens l'erreur suivante.

Bytes  Cards Artifacts  Deltas Send:   
1810   9   0   2 
1Server Error: not authorized to write 
fossil: server says: not authorized to 
write 

Quelqu'un sait pourquoi cela se produit? Quelqu'un sait comment réparer ça?

Answer 1

Fossil a récemment modifié les détails de la façon dont il enregistre les mots de passe, ce qui a eu une incidence sur la façon dont l'authentification est effectuée pendant le clonage, le push, le pull et la synchronisation. L'un des résultats de cette modification est que le mot de passe initial du premier compte d'utilisateur créé pour vous par le clone stocke le mot de passe à l'ancienne, mais que la modification d'un mot de passe le met à jour. Pour forcer tous les enregistrements de mot de passe dans un référentiel à utiliser la nouvelle méthode, utilisez "fossil test-hash-passwords".

Je vérifierais que les deux copies de fossiles sont après cette révision, en améliorant les deux extrémités au besoin. Notez qu'en cas de mise à niveau vers les versions les plus récentes, vous devez effectuer une reconstruction fossile sur le serveur (et localement aussi pour tous les clones) en raison de changements dans le schéma de la base de données. Comme c'est toujours sûr à faire, il est sage de le faire après toute mise à niveau.

Answer 2

Jusqu'à récemment, les utilisateurs et les mots de passe n'étaient jamais clonés. C'est généralement une bonne idée, lorsque vous clonez, de vous assurer que le mot de passe local et votre télécommande sont identiques et de le tester avec une synchronisation.