Bonjour,
J’ai une instance VC1S chez Scaleway, le serveur est Debian Jessie (x86_64-debian-jessie-2016-04-06_15:26).
Sur ça, je fais tourner un serveur fossil : c’est un exécutable autonome qui gère un dépôt, lui aussi un fichier autonome.
Fossil m’indique, dans le panneau d’administration, que :
WARNING: Device "/dev/null" is not available for reading and writing.
WARNING: Device "/dev/urandom" is not available for reading. This means that the pseudo-random number generator used by SQLite will be poorly seeded.Le serveur, appelé fossil, est dans usr/bin.
Le dépôt, appelé repo.fossil, se trouve dans /root/repo.
Pour lancer le serveur, je fais :
fossil open repo.fossil
nohup fossil server &La première commande ouvre le dépôt, le seconde lance fossil en mode serveur.
Dans /dev, entre autres choses, il y a :
crw-rw-rw- 1 root root 1, 3 Apr 8 2016 null
crw-rw-rw- 1 root root 1, 9 Apr 8 2016 urandomL’instance Debian est celle par défaut. Je n’ai procédé à aucune modification… Je me suis contenté de copier fossil dans usr/bin et le dépôt dans /root/repo.
Outre les deux messages d’erreur dans le panneau d’administration, si je clone le dépôt et que je modifie quelque chose, lorsque je commite, fossil, au moment de la synchronisation, m’indique:
Error: not authorized to write
Autosync failed.Une idée de ce qu’il conviendrait de faire ?
# utiliser un autre gestionnaire de depot ?
Posté par NeoX . Évalué à 1.
arreter d'utiliser un "fossile" et utiliser un gestionnaire de depot "moderne" ? :D
[^] # Re: utiliser un autre gestionnaire de depot ?
Posté par Olivier . Évalué à 2.
Le seul gestionnaire décentralisé et open source plus récent, c’est Veracity… :D
C’est vraiment mieux ?
[^] # Re: utiliser un autre gestionnaire de depot ?
Posté par NeoX . Évalué à 2.
je pensais plus à git qui est decentralisé,
et c'est quand meme utilisé dans beaucoup de projet, donc on est sur de trouver de la documentation et des astuces pour faire ce que l'on veut.
[^] # Re: utiliser un autre gestionnaire de depot ?
Posté par Olivier . Évalué à 1.
Ma réponse sur Veracity était ironique. Je connais bien sûr Git, mais je veux utiliser fossil.
# etrange tes commandes
Posté par NeoX . Évalué à 2.
ne faudrait-il pas :
- lancer le serveur avant de lui passer des commandes
- faire l'init du depot avant de l'ouvrir
- puis ouvrir le depot ?
la documentation ici
dit
fossil init nouveauprojet
[^] # Re: etrange tes commandes
Posté par Olivier . Évalué à 1.
Oui, il faut d’abord ouvrir un dépôt, puisque le serveur se rapporte à un dépôt.
Ouvrir un dépôt crée les fichiers selon le dernier état du dépôt et crée un fichier temporaire qui signale que le dépôt est ouvert avec des données qui lui sont utiles.
Le dépôt a été initialisé et rempli avec les fichiers sur mon PC. Puis je l’ai copié sur le serveur, l’ai rouvert et lancé le serveur.
Avec Fossil, il n’y que 3 fichiers pour tout gérer:
— l’exécutable,
— le dépôt, qui est un fichier SQLite,
— un fichier temporaire SQLite, quand le dépôt est ouvert.
# La réponse…
Posté par Olivier . Évalué à 3.
On m’a donné la réponse sur la liste de Fossil.
En fait, il s’avère que Fossil se lance par défaut dans un chroot jail s’il est lancé par root.
Donc, trois solutions:
Si on est content du chroot jail, faire:
mkdir dev
mknod dev/null c 1 3
mknod dev/urandom c 1 9
Si on n’est pas content du chroot jail, lancer le serveur avec l’option --nojail…
Ou bien, ne pas lancer le serveur avec root mais avec un autre utilisateur. (Option retenue.)
L’ironie de l’histoire, c’est que je voulais d’abord tester en root pour ne pas être ennuyé par les questions de droit…
# merci pour la découverte
Posté par ComputingFroggy (site web personnel) . Évalué à 2.
Merci pour ce post qui m'a fait découvrir fossil
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.