Docker > Nextcloud-Let'sEncrypt nem frissül, well-known/acme-challenge elérési probléma

Linux-haladó

Sziasztok!

Aki tud, legyen kedves segíteni:

Fut dockerben egy nextcloud, szépen jwilder/nginx-proxy:alpine proxy-val, a Let's Encrypt image a jrcs/letsencrypt-nginx-proxy-companion.
A számítógép elől a 80-as port véletlenül lezárásra került, és emiatt, vagy más miatt augusztus 1-i az utolsó Let's Encrypt frissítés.
A 80-as port kinyitását elvégeztem, hogy http://oldalam.valami/.well-known/acme-challenge hivatkozást elérje a Let's Encrypt frissítés.
Nem akarok varázsolni, ezért a

docker exec nextcloud-letsencrypt /app/force_renew

szkripttel (https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion…) próbáltam frissíteni. Elhasalt, azt mondja, hogy a http://oldalam.valami/.well-known/acme-challenge nem elérhető. Igaza van... Ám a proxy image-ben a default.conf-ban szerepel a

server {
        server_name oldalam.valami;
        listen 80 ;
        access_log /var/log/nginx/access.log vhost;
        # Do not HTTPS redirect Let'sEncrypt ACME challenge
        location /.well-known/acme-challenge/ {
                auth_basic off;
                allow all;
                root /usr/share/nginx/html;
                try_files $uri =404;
                break;
        }
        location / {
                return 301 https://$host$request_uri;
        }
}

bejegyzés, avagy, ha 80-as porton el kellene érni az /acme-challange útvonalat.
Lehet, hogy ez egy mezei nginx bajság, nem tudom. (Igazából azt sem értem, hogy a ~/docker_images/proxy/conf.d/default.conf miért kerül felírásra minden docker restart után. Lehet, hogy van egy template, amiből legenerálódik a fájl, de azt meg nem találom.)
A lényeg, hogy nem tudom frissíteni Let's Encryptet így. A fentiek alapján kérem a segítségeteket.
Köszönöm előre is.

  • 479 megtekintés

( Crayon | 2020. 11. 01., v – 16:54 )

Szia!

Nem ismerem ezt a proxy image-et, de a default.conf valószínűleg benne van a konténerben, ezért "íródik vissza" a tartalma dokcer restart után.

A port gondra: nem írtad, hogy milyen network mode-ot használsz, ha bridge (ez ugye az alapértelmezett) akkor érdemes csekkolni, hogy a 80as port tényleg erre a proxy konténerre van-e forwardolva.

A visszaíródás tmpl-ből mehet, és amúgy nincs is vele gond, mert jól csinálja az ngnix konfigurációt.
Nmappoltam a domaint:

[...]
PORT     STATE  SERVICE
[...]
80/tcp   open   http
443/tcp  open   https
[...]

Elérhető kívülről. Nekem úgy tűnik, hogy .well-known/acme-challenge-re is forwardolni szeretne az ngnix, amit a szkript kizár. (400 Bad Request The plain HTTP request was sent to HTTPS port nginx/1.17.6)

READY.
󠀠󠀠‎‏‏‎▓

Mégegyszer:
Az URL, amit a bot lekér, annak a végén nincsen /, viszont te egy / végú URL-t proxyzol ki.

A / nélküli URL-re nem fog matchelni a proxyszabály, így hiába is várod, hogy működjön, mert 301 fog visszajönni automatikusan, HTTPS-re irányítással.

Tudod, az a baj, hogy működött. Most mérgemben kiveszem a routert előle, ahogyan volt, mikor az utolsó regisztráció sikeres volt (aug 1.) bár a 80/443-as portok átirányítva a gépre. Az első dolgaim között volt, hogy a let'sencript igényelt portjaira rákerestem, de semmi elvarázsolt igénye nincs.

READY.
󠀠󠀠‎‏‏‎▓

Az egyik olvtársunk - köszönöm szépen neki - javasolta emailben, hogy a htaccess-t töröljem ki ideiglenesen a frissítés idejére. Sajnos nem sikerült.
Nem vagyok híve a rombolásnak, de mert az időm drága most nagyon, lehet, hogy újraépítem az egészet, de szintén docker alapon, mert azért tetszik a dolog. (Holnapig még elmélkedem.)

READY.
󠀠󠀠‎‏‏‎▓

Ez nekem nem egyértelmű, hogy mit jelent: "elhasal". De mindegy is, nem nekem kell megérteni.

Én valahogy így csinálnám:

- felraknék egy default apache konténert a docker-compose-ba

- megnézném compose networkön belülről h elérem-e (100% el fogod)

- expose-olnám a host 81-es portjára

- megnézném intranetről h elérem-e (ezzel biztosítod h a hoston nincs firewall ami megállítaná)

- megnézném internetről h elérem-e (ezzel biztosítod h nincs sehol máshol firewall ami megállítja)

Namost ha ez 81-en összejött akkor ugyanezt kell megcsinálnod 80-ra és 443-ra is, a másik konténerrel és készen vagy.

zászló, zászló, szív

( Elbandi v | 2020. 11. 01., v – 23:15 )

egyszeru a megoldas: kidobod ezeket a random docker imageket, es szepen felrakod a gepre pure nginx+php+mysql. nem urtechnika a telepites.

arrol nem is beszelve hogy security szempontbol ezek az imagek kitudja mit tartalmaznak (vagy fognak tartalmazni egy jokis hack utan)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Akár működhetne ez is, de én inkább a random docker imagek helyett a teljesen hivatalosra mennék rá. Évekig használtam, tényleg hozzáértően össze van kalapálva.

Sajnos a github webes felülete nem működik éppen, de asszem itt van: https://github.com/nextcloud/docker

szerk.: https://github.com/nextcloud/docker/tree/master/.examples/docker-compos…

Ezt javaslom, minden gyönyörűen meg van benne kalapálva. Csak fel kell egy kicsit paraméterezni. Az adatok data containerre mennek.

( agostonl | 2020. 11. 02., h – 05:17 )

+1 a Docker nélküli telepítésre. Hamar megvan.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( gabrielakos v | 2020. 11. 02., h – 06:48 )

Ha most nem ment a frissítés akkor van egy rossz hírem elsőre: sose ment.

Szerintem hosszú távon jobban jársz ha megérted és megtanulod hogyan működik a docker. Ez az út a Kuberneteshez, ami pedig a jövő - illetve inkább a jelen már. Különösen ajánlom a docker-compose megtanulását. Először is csinál neked belső hálót defaultból, ahol a konténerek elérik egymást - és csak egymást, másodszor sokkal kevesebbet kell gépelni. És megtanulható, nem akkora űrtechnika mint a k8s.

Menjünk szépen sorban:

- melyik docker container mappelődik a host 80-as portjára? (és a 443-ra?) Biztos hogy a proxy?
- hogyan csatlakozik a proxyhoz a letsencryptes image?
- hogyan csatlakozik a nextcloud a többihez?
- az image-ben levő file-okat sose fogod tudni permanensen módosítani, restartkor az overlay file system megy a kukába
- azokat a konfigokat, certificate fileokat v bármilyen fileokat amiket meg akarsz tartani azokat be kell mountolni filesystem path-ból, akkor megmaradnak két restart között is, és ha "kívülről" szerkeszted akkor bent is változik

zászló, zászló, szív

- melyik docker container mappelődik a host 80-as portjára? (és a 443-ra?) Biztos hogy a proxy?
- hogyan csatlakozik a proxyhoz a letsencryptes image?
- hogyan csatlakozik a nextcloud a többihez?

A teljes yml fájlban leírásra kerülnek a portok és a kapcsolódások - ha jól gondolom:

$ cat docker-compose.yml 
version: '3'  

services:

  proxy:
    image: jwilder/nginx-proxy:alpine
    labels:
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
    container_name: nextcloud-proxy
    networks:
      - nextcloud_network
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./proxy/conf.d:/etc/nginx/conf.d:ro
      - ./proxy/vhost.d:/etc/nginx/vhost.d:rw
      - ./proxy/html:/usr/share/nginx/html:rw
      - ./proxy/certs:/etc/nginx/certs:ro
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro
    restart: unless-stopped

  letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: nextcloud-letsencrypt
    depends_on:
      - proxy
    networks:
      - nextcloud_network
    volumes:
      - ./proxy/certs:/etc/nginx/certs:rw
      - ./proxy/vhost.d:/etc/nginx/vhost.d:rw
      - ./proxy/html:/usr/share/nginx/html:rw
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped


  db:
    image: mariadb
    container_name: nextcloud-mariadb
    networks:
      - nextcloud_network
    volumes:
      - db:/var/lib/mysql
      - /etc/localtime:/etc/localtime:ro
    environment:
      - MYSQL_ROOT_PASSWORD=xxxxxxxxxxxxxx
      - MYSQL_PASSWORD=mysql
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    restart: unless-stopped

  app:
    image: nextcloud:latest
    container_name: nextcloud-app
    networks:
      - nextcloud_network
    depends_on:
      - letsencrypt
      - proxy
      - db
    volumes:
      - nextcloud:/var/www/html
      - ./app/config:/var/www/html/config
      - ./app/custom_apps:/var/www/html/custom_apps
      - ./app/data:/var/www/html/data
      - ./app/themes:/var/www/html/themes
      - /etc/localtime:/etc/localtime:ro
    environment:
      - VIRTUAL_HOST=valami.oldal
      - LETSENCRYPT_HOST=valami.oldal
      - LETSENCRYPT_EMAIL=valami.oldal@valami.oldal
    restart: unless-stopped

volumes:
  nextcloud:
  db:

networks:
  nextcloud_network:

- az image-ben levő file-okat sose fogod tudni permanensen módosítani, restartkor az overlay file system megy a kukába
- azokat a konfigokat, certificate fileokat v bármilyen fileokat amiket meg akarsz tartani azokat be kell mountolni filesystem path-ból, akkor megmaradnak két restart között is, és ha "kívülről" szerkeszted akkor bent is változik

Igen, ez furcsa volt elsőre, de megértettem, köszönöm.

READY.
󠀠󠀠‎‏‏‎▓

"- a docker volume-ok hasznosságáról (vs. directory mount) még nem vagyok meggyőződve"

Pedig hasznosak. Egy absztrakciós réteget adnak a kezedbe, és nem kell a hostra directoryt mountolni, ha mondjuk S3 bucket a storage. Vagy éppen sshfs.

A storage driverek megkönnyítik az ember dolgát, hogy ne kelljen a host filerendszerrel baszakodnia (sok esetben hozzá se fér az ember a hosthoz közvetlenül, amin a konténer fut, csak a Docker Compose-on keresztül kérhet bármit is).

Lásd itt: https://hub.docker.com/search?type=plugin&category=volume

Van persze csomó community volume plugin is, pl. SSHFS, CIFS/SMB.

http://netshare.containx.io/

 

Így a host gépről nem kell tudnod semmit, mindent megold a Docker.