Installation sur Arch (Étape 1 OK)


#1

Hello,
Je viens de réussir l’installation de la stack v3 sur ArchLinux, en adaptant la page d’installation manuelle sur Debian. Content, je.

J’ai coincé sur un point de la doc : le fichier de conf qu’elle nous fait installer dans /etc/cozy/cozy.yaml

mkdir /etc/cozy
curl -o /etc/cozy/cozy.yaml \
     https://raw.githubusercontent.com/cozy/cozy-stack/master/cozy.example.yaml
chown -R cozy: /etc/cozy

n’est pas utilisé dans la commande de lancement de la stack

sudo -b -u cozy sh -c '/usr/local/bin/cozy-stack serve \
     --log-level info \
     --host 0.0.0.0 >> /var/log/cozy/cozy.log 2>> /var/log/cozy/cozy-err.log'

Du coup, lors de la création d’instances, ça essaie d’écrire dans /usr/local/bin/storage et ça n’a pas le droit. (ça ne doit pas, en tout cas).

Donc comme ça, c’est mieux, avec la config qui va bien :

sudo -b -u cozy sh -c '/usr/local/bin/cozy-stack serve \
     -c /etc/cozy/cozy.yaml \
     --log-level info \
     --host 0.0.0.0 >> /var/log/cozy/cozy.log 2>> /var/log/cozy/cozy-err.log'

Maintenant y’a plus qu’à essayer de faire tourner des applis utiles dessus, du genre collect/Konnectors. Me suis pas penché sur nsjail encore, ça marche comment, globalement ?


#2

Hello !
Merci pour le retour.

Normalement ce fichier de configuration est chargé par défaut, (/etc/cozy/cozy.yaml et ~/.cozy.yaml sont cherchés et utilisés si présents).
Par contre le modèle par défaut ne définit pas le répertoire de stockage.

Il faut le renseigner correctement pour qu’il ne cherche pas à écrire dans son répertoire de démarrage.


#3

Le fichier dans /etc/cozy/cozy.yaml était correctement renseigné, et je n’ai pas de fichier $HOME/.cozy.yaml.

Je suppose qu’il ne le lisait pas, parce dès que j’ai utilisé le paramètre supplémentaire ci-dessus. Ce qui m’a mis la puce à l’oreille c’est l’aide de la commande cozy-stack. Je suis en alpha-3, si j’ai bien compilé comme il faut.


#4

Bizarre… Vérifié à l’instant

# strace -fe stat cozy-stack config print |& egrep "/(etc|root)/"
[pid  5515] stat("/root/.cozy/cozy.json", 0xc4201a8858) = -1 ENOENT (No such file or directory)
[pid  5515] stat("/etc/cozy/cozy.json", 0xc4201a89f8) = -1 ENOENT (No such file or directory)
[pid  5515] stat("/root/.cozy/cozy.toml", 0xc4201a8d38) = -1 ENOENT (No such file or directory)
[pid  5515] stat("/etc/cozy/cozy.toml", 0xc4201a8e08) = -1 ENOENT (No such file or directory)
[pid  5515] stat("/root/.cozy/cozy.yaml", 0xc4201a9148) = -1 ENOENT (No such file or directory)
[pid  5515] stat("/root/.cozy/cozy.yml", 0xc4201a9488) = -1 ENOENT (No such file or directory)
[pid  5515] stat("/etc/cozy/cozy.yml", {st_mode=S_IFREG|0755, st_size=244, ...}) = 0

Vérifie si tu n’avais pas un des ces fichiers à traîner.


#5

.yml !
Le mien est cozy.yaml, scrupuleusement copié/collé de la doc :slight_smile:


#6

Le .yaml est cherché avant le .yml, donc s’il est présent c’est lui qui sera chargé d’abord.


#7

Alors je donne ma langue au chat. Je ne trouve aucun fichier cozy.json/toml/yaml/yml en dehors de /etc/cozy. Et encore moins avec les droits en lecture pour l’utilisateur.


#8

Hello @Lanza,

tu as réussi à t’en sortir finalement ?


#9

Comme je le dis au dessus, ça marche bien en spécifiant le chemin de la config dans la commande. Si je le vire, il pète un câble une fois sur deux (mais pas complètement à tous les coups).

Je viens de compiler la dernière version ( 2017 milestone 4 sprint 3) et je n’ai pas réessayé sans lui passer le chemin du fichier de config (if it’ s not broken, don’t fix it, qu’ils disent).

Et, bonne nouvelle, Collect s’est mis à marcher avec cette nouvelle version, mais je n’ai toujours pas compris si la stack s’occupait toute seule de démarrer les connecteurs, ou s’ils fallait ajouter/configurer des trucs à la main ? Trainline et EDF (les seuls que j’ai testés pour l’instant ne me récupèrent rien du tout).


#10

Hello @Lanza,

Pour utiliser les connecteurs, tu as besoin de composants (nsjail notamment) qui ne figuraient pas dans la première documentation d’installation manuelle.
Cette documentation est à présent dépréciée, puisque nous avons créé des paquets pour Debian et fil·le·s.
Je te conseille de consulter ce dépôt pour voir comment nous faisons sous Debian et voir si tu peux adapter le processus à Arch :


#11

J’avais installé nsjail, effectivement, mais juste installé.

Là, c’est tout plein de machins compliqués avec de vrais morceaux de chroot dedans… :scream:
Il va falloir que je prenne le temps de bien regarder de quoi il en retourne et peut-être bien venir vous embêter sur IRC.


#12

Youpi.

Ça pourrait être l’occasion de documenter un peu cette partie, ce qui ne ferait pas de mal.

Voire de commencer à réfléchir à une implémentation des connecteurs plus adaptée à l’auto-hébergement (les choix technologiques actuels correspondent à notre besoin, l’hébergement de nombreux serveurs sur la même architecture, avec un niveau de sécurité très élevé pour garantir l’isalation de chaque serveur). D’autres pistes plus légères sont peut-être possibles pour l’auto-hébergement, où les contraintes de charge, performance, isolation, etc, sont différentes.


#13

Ce serait une bonne idée s’il y a du temps disponible, parce qu’en auto-hébergé on a plutôt la situation inverse : rien n’est jamais pareil qu’ailleurs et (voire parce que) il y a une foultitude de services qui tournent sur la même machine (un mastodon, un gitlab, un serveur matrix, un…).

La stack cozy a toujours quelque tendance à supposer qu’elle est seule usufruitière des lieux, ce qui est pratique parce que ça s’installe tout seul (récup des certificats, etc), mais qui peut être compliqué s’il y a déjà des voisins, (et qu’on a déjà prévu les certifs avec la config nginx qui va bien, par exemple, ou un couchdb qui traîne dans un coin, ou…).

Maintenant je sais que si j’installe un nouveau serveur, c’est cozy d’abord, les autres ensuite ^^. Dans ce sens-là, ça marche plutôt pas mal.


#14

Oui, tu as raison, Cozy a un peu tendance à s’« imposer ». Le problème est surtout au niveau de la configuration du proxy : si on veut une installation complète, avec les certificats, il faut configurer NGinx et il est difficile de le faire sans écraser une éventuelle configuration pré-existante. Peut-être pourrions-nous scinder l’installation en deux étapes, la seconde facultative, et poser la question : installation complète en configurant tout, ou installation uniquement de la pile Cozy, charge à l’admin de configurer ensuite NGinx.


#15

Je ne peux parler qu’en mon nom, et pour mon cas, je ne connais pas le profil des autres utilisateurs auto-hébergés. Mais dans mon cas, les docs sous forme de tutoriel sont un peu frustrantes, parce qu’elles expliquent comment installer, mais pas comment ça marche, ce qui est embêtant au moment où ça foire.

J’aurais surtout besoin d’une doc qui explique :

  • de quelles dépendances j’ai besoin ?
  • où je trouve quoi ? (config, data, applications, dans la hiérarchie des répertoires)
  • la grammaire de la config.
  • quels processus sont sensés tourner, et qui démarre quoi ?
  • comment les différents composants interagissent entre eux (http, sockets, pipes…) ?

Avec ça, je peux me débrouiller, faire cohabiter avec les voisins, isoler si je veux, chrooter ou pas, gérer les droits, compiler au besoin, etc.

Maintenant j’ai bien conscience que votre objectif est d’être le plus facile d’accès, et les paquets font ça très bien pour qui veut monter un serveur cozy rapidement.

Mais pour des utilisateurs “avertis”, (sans non plus être @aeris) j’ai le sentiment qu’une doc expliquant les points du dessus sera plus utile que des paquets, même s’ils proposent plusieurs options.

Cela dit les deux options que tu proposent me paraissent sensées. Mais plutôt que de poser la question à l’installation, je scinderais en deux paquets : un premier qui n’installe que la stack, les dépendances sans lesquelles elle ne démarre pas et les scripts/units de démarrage, mais sans les lancer (du genre “cozy-core” ?); et un second qui dépend du premier qui va en plus configurer nginx , les certifs, etc (“cozy” tout court ?) et démarrer le tout à la fin.


#16

C’est déjà le cas en fait.

La doc est conçue pour être permettre une installation sans faire de supposition sur la machine, et installe donc le méta-paquet cozy qui ramène tout ce qu’il faut pour installer un cozy rapidement (dont cozy-stack, cozy-couchdb, cozy-nsjail, cozy-coclyco…)
Mais tu peux très bien n’installer que cozy-stack, qui ne fournit que la stack (il n’y a aucune dépendance) et te laisse te débrouiller avec tout le reste.

Actuellement cozy/cozy-stack sont beaucoup moins intrusifs qu’a pu l’être la v2 et ne cherchent pas à s’imposer.
Par contre oui, si tu utilises les outils « user friendly » comme cozy-coclyco, on ne peut pas traiter tous les cas et passer notre vie à chercher à s’intégrer à l’existant sur ta machine. Ça nécessite donc des configs existantes compatibles pour pouvoir fonctionner.
Rien ne t’empèche de faire tes propres configs, mais il ne faut pas utiliser ces outils du coup, et tout faire toi-même à la main (génération des certificats, création des vhosts, création des instances…)


#17

Comme dit plus haut, personnellement je suis sous Arch et pas Debian, donc la question des paquets ne se pose pas pour moi et je n’ai pas regardé profondément l’organisation des paquets. Je donnais mon sentiment à @Clochix sur sa proposition.

Mais suffisamment pour savoir que ça ne dit pas comment ça marche, qu’est-ce qui tourne, quand, comment, comment ça cause (même si je subodore que ça passe par http), et qui démarre quoi. ^^


#18

Ça c’est documenté par ici :slight_smile:
Plus généralement, il y a beaucoup d’information ici.


#19

Hello @Lanza,

Tu as tout à fait raison, une telle documentation serait très utile. Non seulement pour celleux qui veulent comprendre ce qu’iels font, mais également pour simplifier la maintenance. Une fois le Cozy installé, avoir une compréhension globale de son fonctionnement me semble indispensable pour administrer le serveur.

Hélas, je manque de temps pour rédiger une telle documentation. Comme le pointe @aeris, des documents existent, mais on a besoin d’une autre doc, plus orientée auto-hébergement.
Si les journées pouvaient, à l’instar des tweet, doubler de durée…


#20

@aeris : je crois que tu te méprends sur mes intentions : je fais un retour et je donne mes impressions suite à la demande de @Clochix. Ce que vous ferez de ce retour est à votre discrétion.

Je sais où sont ces docs, et je les ai parcourues, et je donne mon avis: il m’a manqué quelque chose entre le tuto et la doc développeur ce qui est l’objet de la discussion.

Voilà un exemple de ce qui me manque :

La doc de l’install Debian me dit :

If you want to use konnectors, you need to initialize the NodeJS chroot

(Currently this script only works for Debian and will be adapted for Ubuntu and Raspbian soon)

/usr/share/cozy/konnector-create-chroot.sh

La doc d’install manuelle ne me dit rien du tout.
La doc sur github me dit qu’il existe des workers, des jobs, et que je peux POST/PUT/DELETE des jobs/workers/ et même la source des konnectors, dont voici d’ailleurs un exemple si je veux en écrire un autre, les champs du manifeste, les permissions, etc.

Il y a un petit gap entre les deux, qui pourrait dire, par exemple :

les konnectors tournent avec nodeJS dans un environnement nsjail obligatoire/facultatif, ils sont lancés à intervalles réguliers par un job de la stack qui est/n’est pas prévu dans le code/paquet original de celle-ci, ou qui est créé à l’installation de cozy collect, ou que vous devez créer à la main.

Je ne demande pas qu’on me livre cette doc inexistante là, maintenant, tout de suite, ni qu’on taille la distribution de la stack à mes besoins. Je ne demande rien ici, d’ailleurs. Je fais juste part de mon impression. ^^