Installation Cozy V3 sur Debian 9 (bis) ... cozy-stack failed


#1

Après une première expérience auto-hébergée sur un serveur Kimsufi, je me suis dit que ce serait quand même mieux que mes données soient hébergées directement chez moi …

J’ai pas très bien fait les choses, j’ai eu pas mal de galères, et je me suis dit que ça valait ptet le coup de vous les rapporter !? Attention, c’est long …

Donc … je me suis lancé dans une install sur un Intel NUC, sous Debian 9 (64 bits), version Testing:
root@cozy:~# cat /etc/apt/sources.list.d/cozy.list
deb https://apt.cozy.io/debian/ stretch testing

L’installation (via apt install cozy) en elle-même s’est passée sans incidents.

J’enchaine sur un cozy-coclyco create et là … “c’est le drame”:
root@cozy:/mnt/htpc# cozy-coclyco create cozy.home.zzzzz.com contact@zzzzz.com
[INF] Create new account key /etc/ssl/private/account.pem
[INF] Accept TOS: https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
[INF] Creating new master key /etc/ssl/private/cozy.pem
[INF] Create instance cozy.home.zzzzz.com with email contact@zzzzz.com
[ERR] Failed to create instance for domain cozy.home.zzzzz.com
[ERR] Error: Post http://127.0.0.1:6060/instances?Apps=&Dev=false&DiskQuota=0&Domain=cozy.home.zzzzz.com&Email=contact%40zzzzz.com&Locale=en&Passphrase=&PublicName=&Settings=&Timezone=: dial tcp 127.0.0.1:6060: getsockopt: connection refused
[ERR] Error occurs during command (‘cozy-stack’, ‘instances’, ‘add’, ‘cozy.home.zzzzz.com’, ‘–email’, ‘contact@zzzzz.com’)
[ERR] Failed to create instance for domain cozy.home.zzzzz.com
Error: Post http://127.0.0.1:6060/instances?Apps=&Dev=false&DiskQuota=0&Domain=cozy.home.zzzzz.com&Email=contact%40zzzzz.com&Locale=en&Passphrase=&PublicName=&Settings=&Timezone=: dial tcp 127.0.0.1:6060: getsockopt: connection refused
Traceback (most recent call last):
File “/usr/bin/cozy-coclyco”, line 11, in
load_entry_point(‘cozy-coclyco==1.0’, ‘console_scripts’, ‘cozy-coclyco’)()
File “/usr/lib/python3/dist-packages/cozy/coclyco/init.py”, line 56, in cli
args.cmd(args)
File “/usr/lib/python3/dist-packages/cozy/coclyco/pki.py”, line 114, in create_instance
email)
File “/usr/lib/python3/dist-packages/cozy/coclyco/cmd.py”, line 73, in exec
raise e
cozy.coclyco.cmd.ImprovedCalledProcessError: Command ‘cozy-stack instances add cozy.home.zzzzz.com --email contact@zzzzz.com’ returned non-zero exit status 1
stdout:

stderr:
Failed to create instance for domain cozy.home.zzzzz.com
Error: Post http://127.0.0.1:6060/instances?Apps=&Dev=false&DiskQuota=0&Domain=cozy.home.zzzzz.com&Email=contact%40zzzzz.com&Locale=en&Passphrase=&PublicName=&Settings=&Timezone=: dial tcp 127.0.0.1:6060: getsockopt: connection refused

(NB: j’ai masqué mon nom de domaine, mais je confirme qu’au niveau DNS tout est OK)

Hum, visiblement je n’ai rien en écoute sur le port 6060.
Et effectivement:
root@cozy:~# netstat -lntp | grep 6060
root@cozy:~#

Coup de bol, j’ai un point de comparaison puisque j’ai un Cozy sur un Kimsufi: c’est donc cozy-stack qui est censé écouter sur ce port:
root@ns3xxxx:~# netstat -lntp | grep 6060
tcp 0 0 127.0.0.1:6060 0.0.0.0:* LISTEN 28865/cozy-stack
root@ns3xxxx:~# ps -ef | grep 28865
root 3693 3685 0 14:56 pts/2 00:00:00 grep 28865
cozy-st+ 28865 1 0 2017 ? 00:00:50 /usr/bin/cozy-stack serve

cozy-stack tourne bien sur mon NUC:
root@cozy:~# ps -ef | grep cozy-stack
cozy-st+ 2380 1 5 16:05 ? 00:00:00 /usr/bin/cozy-stack serve

mais quand je regarde les logs, surprise:
root@cozy:~# tail /var/log/cozy/stack.log
(…)
Jan 6 15:57:25 cozy cozy[1703]: time=“2018-01-06T15:57:25+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 15:57:26 cozy cozy[1703]: time=“2018-01-06T15:57:26+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 15:57:27 cozy cozy[1703]: time=“2018-01-06T15:57:27+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 15:57:28 cozy cozy-stack[1703]: Error: Could not reach Couchdb 2.0 database
Jan 6 15:57:29 cozy cozy[1714]: time=“2018-01-06T15:57:29+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 15:57:30 cozy cozy[1714]: time=“2018-01-06T15:57:30+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 15:57:31 cozy cozy[1714]: time=“2018-01-06T15:57:31+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 15:57:32 cozy cozy[1714]: time=“2018-01-06T15:57:32+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 15:57:33 cozy cozy[1714]: time=“2018-01-06T15:57:33+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 15:57:34 cozy cozy[1714]: time=“2018-01-06T15:57:34+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”

Pourtant CouchDB tourne bien:
root@cozy:~# ps -ef | grep couch
couchdb 1156 1 3 15:51 ? 00:00:09 /opt/couchdb/bin/…/erts-8.2.1/bin/beam.smp -K true -A 16 -Bd – -root /opt/couchdb/bin/… -progname couchdb – -home /opt/couchdb – -boot /opt/couchdb/bin/…/releases/2.1.0/couchdb -name couchdb@localhost -setcookie monster -kernel error_logger silent -sasl sasl_error_logger false -noshell -noinput -config /opt/couchdb/bin/…/releases/2.1.0/sys.config
couchdb 1167 1 0 15:51 ? 00:00:00 /opt/couchdb/bin/…/erts-8.2.1/bin/epmd -daemon
couchdb 1186 1156 0 15:51 ? 00:00:00 erl_child_setup 1024
couchdb 1192 1186 0 15:51 ? 00:00:00 sh -s disksup
couchdb 1194 1186 0 15:51 ? 00:00:00 /opt/couchdb/bin/…/lib/os_mon-2.4.1/priv/bin/memsup
couchdb 1195 1186 0 15:51 ? 00:00:00 /opt/couchdb/bin/…/lib/os_mon-2.4.1/priv/bin/cpu_sup

et il écoute bien:
root@cozy:~# lsof -p 1156 | grep -i tcp
beam.smp 1156 couchdb 13u IPv4 247689 0t0 TCP *:38685 (LISTEN)
beam.smp 1156 couchdb 14u IPv4 247691 0t0 TCP localhost:44987->localhost:epmd (ESTABLISHED)
beam.smp 1156 couchdb 21u IPv4 247700 0t0 TCP localhost:5986 (LISTEN)
beam.smp 1156 couchdb 23u IPv4 283099 0t0 TCP localhost:5984 (LISTEN)
root@cozy:~# lsof -p 1167 | grep -i tcp
epmd 1167 couchdb 3u IPv4 282354 0t0 TCP *:epmd (LISTEN)
epmd 1167 couchdb 4u IPv6 282355 0t0 TCP *:epmd (LISTEN)
epmd 1167 couchdb 5u IPv4 282356 0t0 TCP localhost:epmd->localhost:44987 (ESTABLISHED)

et voilà ce que j’ai niveau ports en écoute sur mon NUC:

root@cozy:~# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 449/rpcbind
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 566/nginx: master p
tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 1167/epmd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 541/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1010/exim4
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 1014/sshd: root@pts
tcp 0 0 0.0.0.0:38685 0.0.0.0:* LISTEN 1156/beam.smp
tcp 0 0 127.0.0.1:5984 0.0.0.0:* LISTEN 1156/beam.smp
tcp 0 0 127.0.0.1:5986 0.0.0.0:* LISTEN 1156/beam.smp
tcp 0 0 127.0.0.1:45731 0.0.0.0:* LISTEN 1590/cozy-stack
tcp6 0 0 :::111 :::* LISTEN 449/rpcbind
tcp6 0 0 :::80 :::* LISTEN 566/nginx: master p
tcp6 0 0 :::4369 :::* LISTEN 1167/epmd
tcp6 0 0 :::22 :::* LISTEN 541/sshd
tcp6 0 0 ::1:25 :::* LISTEN 1010/exim4
tcp6 0 0 ::1:6010 :::* LISTEN 1014/sshd: root@pts

On dirait que c’est un problème de credentials, vu que CouchDB me balance une 401:

root@cozy:/var/log/couchdb# tail couchdb.log
[notice] 2018-01-06T15:08:46.333720Z couchdb@localhost <0.19948.0> a40e192e63 localhost:5984 127.0.0.1 undefined GET / 401 ok 3
[notice] 2018-01-06T15:08:47.342667Z couchdb@localhost <0.19958.0> 9e34654d04 localhost:5984 127.0.0.1 undefined GET / 401 ok 3
[notice] 2018-01-06T15:08:48.350776Z couchdb@localhost <0.19985.0> 090a759258 localhost:5984 127.0.0.1 undefined GET / 401 ok 3
[notice] 2018-01-06T15:08:49.361652Z couchdb@localhost <0.19995.0> 0aed7dfb14 localhost:5984 127.0.0.1 undefined GET / 401 ok 3
[notice] 2018-01-06T15:08:50.370741Z couchdb@localhost <0.20022.0> 56d543b767 localhost:5984 127.0.0.1 undefined GET / 401 ok 3
[notice] 2018-01-06T15:08:51.379303Z couchdb@localhost <0.20032.0> 4522e3dc4c localhost:5984 127.0.0.1 undefined GET / 401 ok 2
[notice] 2018-01-06T15:08:51.823973Z couchdb@localhost <0.20039.0> 1fca1fa75d localhost:5984 127.0.0.1 undefined GET / 401 ok 2
[notice] 2018-01-06T15:08:52.833478Z couchdb@localhost <0.20059.0> a6ffa647c1 localhost:5984 127.0.0.1 undefined GET / 401 ok 3
[notice] 2018-01-06T15:08:53.841925Z couchdb@localhost <0.20078.0> f768650b59 localhost:5984 127.0.0.1 undefined GET / 401 ok 3
[notice] 2018-01-06T15:08:54.850746Z couchdb@localhost <0.20098.0> db1ee8a59e localhost:5984 127.0.0.1 undefined GET / 401 ok 3

J’ai vérifié les credentials dans mon /etc/cozy/cozy.yml et le mot de passe correspond bien à ce que j’ai généré avec keepass et inséré lors du process ncurses d’install:
couchdb:
url: http://cozy:xxxxxxxxxxxxxxxxx@localhost:5984/

J’ai fait un petit tunnel pour accéder à Futon et regarder ce qui se passe.
Je n’ai que 2 DB system (_replicator et _users) avec 1 record chacun

Sur le Kimsufi, j’ai les mêmes + les databases cozy-zzzzz-com* (logique car ici le cozyclo a fonctionné) et global/instances (créé aussi par cozyclo ?)

de guerre lasse, j’ai fini par remove/purge tous les packages cozy* et recommencer l’install plus minutieusement:
apt install cozy

en interactif ncurses, l’installer me demande:
1- le type de couchdb souhaité (cluster/standalone/none)
2- configuring cozy-couchdb : Password for the CouchDB “admin” user + confirmation
3- couchdb ip+port : localhost:5984
4- couchdb nodename : couchdb@localhost
5- couchdb admin username: admin (mais on l’a pas déjà créé ??)
6- couchdb admin password …
7- couchdb cozy username: cozy
8- couchdb cozy password …
9- cozy stack admin password

Je vérifie, et là, cozy-stack fonctionne:
root@cozy:~# tail /var/log/cozy/stack.log
Jan 6 16:28:41 cozy cozy[2352]: time=“2018-01-06T16:28:41+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 16:28:42 cozy cozy[2352]: time=“2018-01-06T16:28:42+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 16:28:43 cozy cozy[2352]: time=“2018-01-06T16:28:43+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 16:28:44 cozy cozy[2352]: time=“2018-01-06T16:28:44+01:00” level=warning msg=“Could not reach Couchdb 2.0 database, retrying in 1s”
Jan 6 16:35:07 cozy cozy[3396]: time=“2018-01-06T16:35:07+01:00” level=info msg=“Starting in-memory broker with 4 workers” nspace=jobs
Jan 6 16:35:07 cozy cozy-stack[3396]: Ready and waiting for connections:
Jan 6 16:35:07 cozy cozy-stack[3396]: http server major started on “127.0.0.1:8080”
Jan 6 16:35:07 cozy cozy-stack[3396]: ⇨ http server started on 127.0.0.1:8080
Jan 6 16:35:07 cozy cozy-stack[3396]: http server admin started on “127.0.0.1:6060”
Jan 6 16:35:07 cozy cozy-stack[3396]: ⇨ http server started on 127.0.0.1:6060

Je réfléchis, et je comprends …
sur ma précédente install, j’avais mis un mot de passe différent entre les étapes 2 et 6
J’ai donc set un password sur couchdb, mais j’ai fourni un mauvais password couchdb à cozy.

Du coup je pense que le process d’install peut peut-être être un peu clarifié ?
Mes idées:

  • soit par de la doc
  • soit en récupérant le password de l’étape 2 et en skippant les étapes 5 et 6 (tiens d’ailleurs pourquoi demander le username en étape 5 alors qu’on ne peut pas le choisir ? vous pourriez presque mettre “admin” en dur non ?)
  • soit en demandant le password en étape 6 mais aui lieu de demander confirmation du passwordd, plutot tester la connexion à couchdb avec les credentials fournis , et refuser de continuer si la connexion est KO ?

Bref du coup je continue, et je lance mon cozy-coclyco … et là, ça marche … presque:
root@cozy:~# cozy-coclyco create cozy.home.zzzzz.com contact@zzzzz.com
[INF] Create instance cozy.home.zzzzz.com with email contact@zzzzz.com
[INF] Install app onboarding on cozy.home.zzzzz.com
[INF] Install app settings on cozy.home.zzzzz.com
[INF] Install app drive on cozy.home.zzzzz.com
[INF] Install app photos on cozy.home.zzzzz.com
[INF] Install app collect on cozy.home.zzzzz.com
[INF] Generate CSR for CN cozy.home.zzzzz.com & SAN {‘collect.cozy.home.zzzzz.com’, ‘cozy.home.zzzzz.com’, ‘settings.cozy.home.zzzzz.com’, ‘onboarding.cozy.home.zzzzz.com’, ‘drive.cozy.home.zzzzz.com’, ‘photos.cozy.home.zzzzz.com
}
[INF] Issue certificate for {‘collect.cozy.home.zzzzz.com’, ‘cozy.home.zzzzz.com’, ‘settings.cozy.home.zzzzz.com’, ‘onboarding.cozy.home.zzzzz.com’, ‘drive.cozy.home.zzzzz.com’, ‘photos.cozy.home.zzzzz.com’}
[INF] Validate collect.cozy.home.zzzzz.com
Traceback (most recent call last):
File “/usr/bin/cozy-coclyco”, line 11, in
load_entry_point(‘cozy-coclyco==1.0’, ‘console_scripts’, ‘cozy-coclyco’)()
File “/usr/lib/python3/dist-packages/cozy/coclyco/init.py”, line 56, in cli
args.cmd(args)
File “/usr/lib/python3/dist-packages/cozy/coclyco/pki.py”, line 128, in create_instance
self.__issue_certificate(slug, domain)
File “/usr/lib/python3/dist-packages/cozy/coclyco/pki.py”, line 88, in __issue_certificate
self._issue_certificate(csr)
File “/usr/lib/python3/dist-packages/cozy/coclyco/acme.py”, line 264, in _issue_certificate
auth = [self.__authorize_domain(domain) for domain in domains]
File “/usr/lib/python3/dist-packages/cozy/coclyco/acme.py”, line 264, in
auth = [self.__authorize_domain(domain) for domain in domains]
File “/usr/lib/python3/dist-packages/cozy/coclyco/acme.py”, line 191, in __authorize_domain
response.raise_for_status()
File “/usr/lib/python3/dist-packages/requests/models.py”, line 893, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http://collect.cozy.home.zzzzz.com/.well-known/acme-challenge/sPNFMHvZ4-D_Jd8tKhmjsmUHFv2dSQJaShV-6En6_i0

Là c’est plus facile, et c’est encore un peu ma faute : je n’ai pas désinstallé nginx donc il n’a pas été réinstallé, et il manque ces directives de configuration dans /etc/nginx/sites-enabled/default
location /.well-known/acme-challenge/ {
alias /etc/ssl/private/acme-challenge/;
}

Je les ajoute, je reload nginx, puis je relance coclyco.

Ca marche à peine mleux:
root@cozy:~# cozy-coclyco create cozy.home.zzzzz.com contact@zzzzz.com
[INF] Create instance cozy.home.zzzzz.com with email contact@zzzzz.com
[ERR] Failed to create instance for domain cozy.home.zzzzz.com
[ERR] Error: Conflict: Instance already exists
[ERR] Error occurs during command (‘cozy-stack’, ‘instances’, ‘add’, ‘cozy.home.zzzzz.com’, ‘–email’, ‘contact@zzzzz.com’)
[ERR] Failed to create instance for domain cozy.home.zzzzz.com
Error: Conflict: Instance already exists
Traceback (most recent call last):
File “/usr/bin/cozy-coclyco”, line 11, in
load_entry_point(‘cozy-coclyco==1.0’, ‘console_scripts’, ‘cozy-coclyco’)()
File “/usr/lib/python3/dist-packages/cozy/coclyco/init.py”, line 56, in cli
args.cmd(args)
File “/usr/lib/python3/dist-packages/cozy/coclyco/pki.py”, line 114, in create_instance
email)
File “/usr/lib/python3/dist-packages/cozy/coclyco/cmd.py”, line 73, in exec
raise e
cozy.coclyco.cmd.ImprovedCalledProcessError: Command ‘cozy-stack instances add cozy.home.zzzzz.com --email contact@zzzzz.com’ returned non-zero exit status 1
stdout:

stderr:
Failed to create instance for domain cozy.home.zzzzz.com
Error: Conflict: Instance already exists

“Instance already exists”
… Effectivement j’ai lancé une install de cette instance, qui est partiellement installée

Là j’ai cherché un peu comment avancer mais je suis un peu coincé:

J’ai tenté
root@cozy:~# cozy-coclyco regenerate cozy.home.zzzzz.com
(…)
[INF] Validate onboarding.cozy.home.zzzzz.com
Traceback (most recent call last):
File “/usr/bin/cozy-coclyco”, line 11, in
load_entry_point(‘cozy-coclyco==1.0’, ‘console_scripts’, ‘cozy-coclyco’)()
File “/usr/lib/python3/dist-packages/cozy/coclyco/init.py”, line 56, in cli
args.cmd(args)
File “/usr/lib/python3/dist-packages/cozy/coclyco/pki.py”, line 162, in regenerate
self.__issue_certificate(slug, domain)
File “/usr/lib/python3/dist-packages/cozy/coclyco/pki.py”, line 88, in __issue_certificate
self._issue_certificate(csr)
File “/usr/lib/python3/dist-packages/cozy/coclyco/acme.py”, line 264, in _issue_certificate
auth = [self.__authorize_domain(domain) for domain in domains]
File “/usr/lib/python3/dist-packages/cozy/coclyco/acme.py”, line 264, in
auth = [self.__authorize_domain(domain) for domain in domains]
File “/usr/lib/python3/dist-packages/cozy/coclyco/acme.py”, line 191, in __authorize_domain
response.raise_for_status()
File “/usr/lib/python3/dist-packages/requests/models.py”, line 893, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http://onboarding.cozy.home.zzzzz.com/.well-known/acme-challenge/IIlh2pXIxe83OH62ZGQYdWYzn5DYh1Cs1lTECzu1sa0

Egalement testé:
root@cozy:~# cozy-coclyco renew cozy.home.zzzzz.com
[INF] No certificate for cozy.home.zzzzz.com

Testé également
root@cozy:~# cozy-coclyco vhost cozy.home.zzzzz.com
[INF] Generate nginx vhost for cozy.home.zzzzz.com
[INF] Enable nginx vhost for cozy.home.zzzzz.com
[INF] Reload nginx
[ERR] Job for nginx.service failed because the control process exited with error code.
[ERR] See “systemctl status nginx.service” and “journalctl -xe” for details.

Vérification faite, j’ai mon vhost configuré:
root@cozy:~# ls /etc/nginx/sites-enabled/cozy.home.zzzzz.com
/etc/nginx/sites-enabled/cozy.home.zzzzz.com

root@cozy:~# ls -l /etc/ssl/private/cozy.home.zzzzz.com.crt /etc/ssl/private/cozy.pem
ls: cannot access ‘/etc/ssl/private/cozy.home.zzzzz.com.crt’: No such file or directory
-rw-r–r-- 1 root root 241 Jan 6 16:53 /etc/ssl/private/cozy.pem
root@cozy:~#

bon, là j’avoue je sèche un peu, donc tant pis, je repars pour un tour:

  • purge de cozy, de nginx, de
  • apt install cozy
  • export COZY_ADMIN_PASSWORD
  • cozy-coclyco create …

et là, encore la même erreur:
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http://cozy.home.zzzzz.com/.well-known/acme-challenge/aQIw5toediw-6anD3AUdSuXEBEOrHkO513lG0XwxTX4

Je n’ai que le vhost par défaut
root@cozy:/etc/nginx/sites-enabled# ls -l
total 0
lrwxrwxrwx 1 root root 34 Jan 6 16:58 default -> /etc/nginx/sites-available/default

et il ne contient aucune directive acme-challenge:
root@cozy:/etc/nginx/sites-enabled# grep challenge default
root@cozy:/etc/nginx/sites-enabled#

Je sèche complet.

Est-ce que ça pourrait être lié au fait que l’utilise beaucoup de subdomains ( *.cozy.home.zzzzz.com ) ?


#2

En fait de 1 à 4, c’est la configuration de couchdb, qui ne dépend pas de cozy directement.
À l’étape 5, du paquet cozy-stack du coup, on a besoin du mot de passe défini à l’étape 2 du paquet couchdb.

A priori tu as un souci de configuration sur ton nom de domaine ou ton reverse proxy nginx.
Ou alors un problème de hairpinning qui fait que ta box ne sait pas gérer correctement l’accès à une IP externe depuis ton réseau local.


#3

En fait de 1 à 4, c’est la configuration de couchdb, qui ne dépend pas de cozy directement.
À l’étape 5, du paquet cozy-stack du coup, on a besoin du mot de passe défini à l’étape 2 du paquet couchdb.

Yep c’est ce que j’avais intuité.
Pas moyen de récupérer le password pour que ça soit transparent pour l’utilisateur, j’imagine ?
Du coup je sais pas trop

A priori tu as un souci de configuration sur ton nom de domaine ou ton reverse proxy nginx.
Ou alors un problème de hairpinning qui fait que ta box ne sait pas gérer correctement l’accès à une IP externe depuis > ton réseau local.

Damn tu as surement raison ! Je suis sur une BBox …
En ajoutant les résolutions à mon résolveur local, j’ai du mieux.

Maintenant je me mange cette erreur:
requests.exceptions.ConnectionError: HTTPConnectionPool(host=‘drive.cozy.home.zzzzz.com’, port=80): Max retries exceeded with url: /.well-known/acme-challenge/(…) (Caused by NewConnectionError(’<requests.packages.urllib3.connection.HTTPConnection object at 0x7fd1697c17b8>: Failed to establish a new connection: [Errno 111] Connection refused’,))

Ca doit pas être grand chose, je re-testerai demain (sur une install clean) …


#4

Bon, j’ai fait quelques tests, j’ai pas encore abouti …

On va passer sur le fait que je n’avais aucun problème de hairpinning mais que j’avais foiré ma conf:

  • j’avais d’abord oublié d’activer une règle reverse-proxy (voir plus bas)
  • et en voulant le bypasser j’ai introduit une erreur sur la zone DNS locale.

Désormais ces 2 soucis sont corrigés, et j’en suis là:

[INF] Validate drive.cozy.home.zzzzz.com
/usr/lib/python3/dist-packages/urllib3/connectionpool.py:845: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
InsecureRequestWarning)

Je pense que mon archi est un peu foireuse:

  • J’ai une BBox Miami, avec une IP publique
  • Tout le trafic vers cette IP publique est routée vers un serveur en DMZ chez moi, qui héberge (entre autres) un reverse-proxy nginx
  • pour COZY, j’ai configuré mon nginx comme suit (avec du letsencrypt):
    server {
    listen 80;
    server_name cozy.home.zzzzz.com ~^(.*).cozy.home.zzzzz.com$ ; # Mon COZY
    location / {
    proxy_pass http://192.168.1.248:80/;
    }
    access_log /var/log/nginx/cozy.access.log combined;
    error_log /var/log/nginx/cozy.error.log warn;
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/cozy.home.julienrobin.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/cozy.home.julienrobin.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    if ($scheme != “https”){
    return 301 https://$host$request_uri;
    } # managed by Certbot
    }

et apparemment mon reverse-proxy général fait bien son boulot (la première requête est un redirect http vers https, la seconde est la réponse au challenge)
192.168.1.254 - - [07/Jan/2018:10:43:13 +0100] “GET /.well-known/acme-challenge/rVZsrtZbmHv28D7KBQkfVzhSQfqXG9tN-ModGqrjBJs HTTP/1.1” 301 178 “-” “python-requests/2.12.4”
192.168.1.254 - - [07/Jan/2018:10:43:13 +0100] “GET /.well-known/acme-challenge/rVZsrtZbmHv28D7KBQkfVzhSQfqXG9tN-ModGqrjBJs HTTP/1.1” 200 87 “-” “python-requests/2.12.4”

et sur le nginx de cozy j’ai bien la réponse également:
192.168.1.252 - - [07/Jan/2018:10:43:13 +0100] “GET /.well-known/acme-challenge/rVZsrtZbmHv28D7KBQkfVzhSQfqXG9tN-ModGqrjBJs HTTP/1.0” 200 87 “-” “python-requests/2.12.4”

J’ai également testé en désactivant la redirection http => https sur mon reverse-proxy général … même sanction.

Je pense que je suis en train de faire un gloubiboulga de SSL là, mais je trouve pas ce qui cloche :-/


#5

On sort un peu du support Cozy là :wink:
Pour Let’s Encrypt, tu es dans un cas non supporté officiellement, puisque tu as un reverse-proxy devant le reverse-proxy du Cozy. Ça peut fonctionner, mais il va te falloir comprendre ce que tu fais :yum:
En particulier, il ne faut pas faire le Let’s Encrypt depuis le 2nd reverse proxy, mais bien depuis celui en DMZ.
Et donc tu ne peux pas utiliser cozy-coclyco, tu dois faire tout le travail de configuration du nginx cozy à la main. Et il va te falloir aussi bien galérer pour synchroniser tous les 30j le certificat du 1er reverse-proxy avec le 2nd…


#6

oui effectivement …

Je vois pas trop de solution simple à mon affaire …

Le plus simple serait certainement que je mette ma machine Cozy en DMZ, que je l’installe tout bien comme il faut, puis que j’y ajoute mes autres règles de reverse-proxy

J’avais aussi pensé patcher coclyco pour mon usage personnel … mais après avoir jeté un oeil au code, c’est clairement pas de mon niveau ! :stuck_out_tongue:


#7

Le problème n’est pas que au niveau de TLS. Avec IPv4, tu ne peux pas avoir 2 machines en frontal en DMZ sur le même port.
Donc si tu as déjà un reverse-proxy, c’est forcément lui qui va devoir s’occuper de la négociation TLS. Et donc gérer le Let’s Encrypt. Et devra aussi reverse-proxyfier le cozy au passage.
Il faut donc des mécanismes de synchro entre ton reverse-proxy qui sera le seul capable de prendre en charge l’enrollement Let’s Encrypt, et ton cozy qui aura aussi besoin du certificat à un moment donné (et du nouveau tous les 90 jours).

Avoir 2 machines en HTTPS sur le même réseau, avec Let’s Encrypt c’est très rapidement devoir mettre en place plein de solutions « custom » pour que ça tombe en marche tout seul.
Par exemple un tunnel SSH password-less pour pouvoir rsync/scp le nouveau certificat tous les 90j sur le cozy et reload le nginx côté cozy après chaque renouvellement Let’s Encrypt.

Les joies de l’auto-hébergement quoi…


#8

Bonjour,

Je me permets de déterrer le topic pour savoir si tu avais trouvé une solution ? Je suis dans le même cas que toi, derrière un nginx en “frontend”.

Merci d’avance.


#9

Bonjour @Ryuk3n,

Il n’y a malheureusement pas de solution toute faite, et une config qui fonctionne pour X ne fonctionnera peut-être pas pour Y :confounded:
Il faut comprendre tous les besoins (Let’s Encrypt & cie, comment fonctionne ACME, les subtilités du NAT…) pour adapter à ta configuration…

Les joies de l’auto-hébergement diront certains :joy: