Problem z własną instancją Supli

[jaku2k]

Witam,
chciałem dziś zaktualizować Clouda do najnowszej wersji. Przed tym zdecydowałem się na zrobienie kopii zapasowej poleceniem

Code: Select all

docker exec supla-db mysqldump --routines -u root --password="$DB_PASSWORD" supla > supla.sql

Potem wpisałem sudo ./supla.sh restart, bo wyświetlało jakieś błędy i otrzymałem błąd (zdjęcia w załączniku).

problem1.PNG

problem.PNG

Proszę o pomoc w rozwiązaniu problemu.

[kris.sg]

Spróbuj wydać komendę:

Code: Select all

./supla.sh restart

bez sudo

[jaku2k]

Dziękuję za odpowiedź. Niestety wpisanie komendy bez sudo daje taką samą odpowiedź.

[jaku2k]

Spróbowałem tak:

Code: Select all

sudo su
./supla.sh restart

I chyba się załatwiłem, bo otrzymałem odpowiedź Removing supla-db

Czy oznacza to, że nie mogę już odzyskać danych z Supli (chodzi mi głównie o historię MEW-a)?

[pzygmunt]

Dane kontenera powinny pozostać

[jaku2k]

Dane kontenera powinny pozostać

Dziękuję za odpowiedź. Czy mógłbyś napisać, w jaki sposób mogę je znaleźć?

3. dzień bez Supli zakrawa o delirkę

[jaku2k]

Podbijam temat. Czy ktoś wie, jak znaleźć dane kontenera prywatnej instancji Supli?

[fracz]

Nic nie powinno zginąć, spokojnie.

Problemy, które pokazałeś, w ogóle nie dotyczą kontenerów supli, ale samego dockera lub compose.

Jeśli się da, zatrzymaj i usuń kontenery (usuwanie kontenerów NIE usuwa danych):

Code: Select all

docker-compose down

Niezależnie od tego, czy się to uda czy nie, zrestartuj całego dockera, albo nawet całego hosta. Dockera restartuje się różnie, ale powinno być coś podobne do

Code: Select all

sudo service docker restart

Po tym poleceniu wszystko powinno być ubite, tj.

Code: Select all

docker ps

zwróci pustą listę działających kontenerów. Jeśli nie - powtarzasz down z pierwszego bloku.

Następnie uruchamiasz

Code: Select all

./supla.sh start

i ma działać.

Nie używaj sudo do zarządzania kontenerami.

[jaku2k]

Dziękuję za odpowiedź.

Jeśli się da, zatrzymaj i usuń kontenery (usuwanie kontenerów NIE usuwa danych)

Po wpisaniu docker-compose down, otrzymuję takie same błędy, co przesłane w wiadomości powyżej.

Niezależnie od tego, czy się to uda czy nie, zrestartuj całego dockera, albo nawet całego hosta.

Zatrzymałem i uruchomiłem Dockera (zarówno z poziomu interfejsu graficznego - Supla działa na NAS-ie, jak i z poziomu terminala).

Po tym poleceniu wszystko powinno być ubite

Po włączeniu wyświetla, że chodzi uruchomiony już wcześniej supla-scripts (supla-cloud był wyłączone przed wyłączeniem i włączeniem Dockera).

Jeśli nie - powtarzasz down z pierwszego bloku.

Próba powtórzenia downa kończy się wyświetleniem błędów (tych samych, co przesłane w wiadomości powyżej).

1. Czy mogę usunąć konkretne kontenery komendą rm, zamiast down?

Problemy, które pokazałeś, w ogóle nie dotyczą kontenerów supli, ale samego dockera lub compose.

Dzięki tej cennej informacji trafiłem na wątek na GitHubie poruszający - zdaje się - podobny problem. Jeden z użytkowników napisał, że w jego przypadku rozwiązaniem okazało się postępowanie zgodnie z poradnikiem poinstlacyjnym, w którym jest przedstawiony sposób na dodanie użytkownika do grupy Docker celem uniknięcia wpisywania sudo przed poleceniem dla Dockera za każdym razem. 2. Czy ja powinienem coś takiego dodać?

To raczej nie jest rozwiązanie tego problemu, bo dotychczas wszystko działało bez tego... ale może warto spróbować?

[jaku2k]

Chyba udało mi się to popchnąć dalej...

dałem uprawnienia:

Code: Select all

sudo chmod 666 /var/run/docker.sock

Code: Select all

docker-compose down

- przeszło bez błędu. Zatrzymałem Dockera, uruchomiłem Dockera

Code: Select all

./supla.sh start

Coś poszło. Wybudowało kontenery, ale bez sudo nie mogłem nawet użyć komendy

Code: Select all

docker ps

Przypomniałem sobie poradę @fracz, żeby nie używać sudo do zarządzania kontenerami, więc - nie chcąc brnąć dalej z sudo jako podparciem - zatrzymałem Suplę.

Code: Select all

docker-compose down

Zatrzymałem i uruchomiłem Dockera. Utworzyłem grupę docker

Code: Select all

sudo synogroup --add docker

dodałem do niej użytkownika

Code: Select all

sudo synogroup --member docker Jakub

i zmieniłem uprawnienia (te trzy kroki wykonałem wg poradnika: https://davejansen.com/manage-docker-wi ... ology-nas/).

Code: Select all

sudo chown root:docker /var/run/docker.sock

Code: Select all

git pull

Code: Select all

./supla.sh start

zadziałało - zbudowało mi nowe kontenery. Dwa z nich (supla-db i supla-cloud) bez przerwy się restartują. Po wpisaniu

Code: Select all

docker logs --tail=50 supla-db

otrzymuję taką odpowiedź (powieloną wiele razy):

Code: Select all

error: database is uninitialized and password option is not specified
  You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD

a po wpisaniu

Code: Select all

docker logs --tail=50 supla-cloud

wyrzuca

Code: Select all

r service not known


In PDOConnection.php line 40:

  SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name o
  r service not known


In PDOConnection.php line 40:

  PDO::__construct(): php_network_getaddresses: getaddrinfo failed: Name or s
  ervice not known



In ConnectionFactory.php line 79:

  An exception occured while establishing a connection to figure out your pla
  tform version.
  You can circumvent this by setting a 'server_version' configuration value

  For further information have a look at:
  https://github.com/doctrine/DoctrineBundle/issues/673


In AbstractMySQLDriver.php line 112:

  An exception occurred in driver: SQLSTATE[HY000] [2002] php_network_getaddr
  esses: getaddrinfo failed: Name or service not known


In Exception.php line 18:

  SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name o
  r service not known


In PDOConnection.php line 40:

  SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name o
  r service not known


In PDOConnection.php line 40:

  PDO::__construct(): php_network_getaddresses: getaddrinfo failed: Name or s
  ervice not known

Wpisałem

Code: Select all

source /volume1/docker/supla/.env

ale nie otrzymałem żadnej odpowiedzi. Dałem

Code: Select all

./supla.sh restart

Code: Select all

Stopping SUPLA containers
Stopping supla-server ... done
Stopping supla-cloud  ... done
Stopping supla-db     ... done
SUPLA containers has been stopped.
Starting SUPLA containers
WARNING: The DB_PASSWORD variable is not set. Defaulting to a blank string.
Building supla-cloud
Sending build context to Docker daemon  15.87kB

Step 1/15 : FROM php:7.3.28-apache AS supla_cloud_base
 ---> 5445627cceb4
Step 2/15 : WORKDIR /var/www
 ---> Using cache
 ---> 2f7db134d899
Step 3/15 : RUN apt-get update     && apt-get install -y --no-install-recommends       libicu-dev       libpq-dev       ca-certificates       ssl-cert       libcurl4-gnutls-dev       git       unzip       mariadb-client       wget       supervisor       cron       libzip-dev       zip     && update-ca-certificates     && docker-php-ext-install       pdo_mysql       mbstring       opcache       intl       curl       zip     && apt-get autoremove     && rm -r /var/lib/apt/lists/*     && mkdir -p /var/log/supervisor
 ---> Using cache
 ---> fe16da3568f7
Step 4/15 : RUN apt-get update && apt-get install -y         libfreetype6-dev         libjpeg62-turbo-dev         libpng-dev     && docker-php-ext-install -j$(nproc) iconv     && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/     && docker-php-ext-install -j$(nproc) gd     && apt-get autoremove     && rm -r /var/lib/apt/lists/*
 ---> Using cache
 ---> d7b0b69a325e
Step 5/15 : COPY apache-conf /etc/apache2/sites-available
 ---> Using cache
 ---> 17c652ff7de0
Step 6/15 : COPY crontab /etc/cron.d/supla-cron
 ---> Using cache
 ---> 5faa974eaab4
Step 7/15 : COPY php.ini /usr/local/etc/php/conf.d/php-supla.ini
 ---> Using cache
 ---> 87f00d940548
Step 8/15 : RUN ln -s /usr/local/etc/php/php.ini-production /usr/local/etc/php/php.ini     && {         echo 'ServerTokens Prod\n';         echo 'ServerSignature Off\n';     } >> /etc/apache2/apache2.conf     && a2enmod headers rewrite expires deflate ssl cgi alias env     && chmod 0644 /etc/cron.d/supla-cron
 ---> Using cache
 ---> 6454d1da72f9
Step 9/15 : FROM supla_cloud_base AS supla_cloud_prod
 ---> 6454d1da72f9
Step 10/15 : ENV CLOUD_VERSION=2.3.37
 ---> Using cache
 ---> 7d6c35007b0a
Step 11/15 : RUN a2ensite default-ssl     && wget -nc https://github.com/SUPLA/supla-cloud/releases/download/v${CLOUD_VERSION}/supla-cloud-v${CLOUD_VERSION}.tar.gz     && mkdir cloud     && tar -xzf supla-cloud-v${CLOUD_VERSION}.tar.gz -C cloud     && rm -f supla-cloud-v${CLOUD_VERSION}.tar.gz     && cp cloud/app/config/parameters.yml.dist cloud/app/config/parameters.yml     && sed -i "s+/var/run/supla/supla-server-ctrl.sock+/supla-server/supla-server-ctrl.sock+g" cloud/app/config/config.yml     && sed -i "s#database_host: 127.0.0.1#database_host: supla-db#" cloud/app/config/parameters.yml     && sed -i "s#database_user: root#database_user: supla#" cloud/app/config/parameters.yml     && chown -hR www-data:www-data cloud
 ---> Using cache
 ---> c4c1ebc90abf
Step 12/15 : WORKDIR /var/www/cloud
 ---> Using cache
 ---> c3cd8f406fdf
Step 13/15 : COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
 ---> Using cache
 ---> 85e1976ee414
Step 14/15 : COPY cloud-entrypoint.sh /usr/local/bin/docker-php-entrypoint
 ---> Using cache
 ---> 66164ec0eae9
Step 15/15 : CMD ["/usr/bin/supervisord", "--nodaemon", "--configuration", "/etc/supervisor/conf.d/supervisord.conf"]
 ---> Using cache
 ---> 9eca759d513f
Successfully built 9eca759d513f
Successfully tagged supla_supla-cloud:latest
Building supla-server
Sending build context to Docker daemon  7.168kB

Step 1/11 : FROM debian:stretch
 ---> 28c1b600f6da
Step 2/11 : RUN apt-get update     && apt-get install -y --no-install-recommends         git         make         gcc         g++         default-libmysqlclient-dev         libssl-dev         wget         supervisor         ca-certificates         ssl-cert     && apt-get autoremove     && rm -r /var/lib/apt/lists/*     && mkdir -p /var/log/supervisor
 ---> Using cache
 ---> fa5198312b89
Step 3/11 : ENV LIBRESSL_VERSION=3.4.2
 ---> Using cache
 ---> 8247de596160
Step 4/11 : RUN cd /usr/src     && wget https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-${LIBRESSL_VERSION}.tar.gz     && tar zxvf libressl-${LIBRESSL_VERSION}.tar.gz && rm libressl-${LIBRESSL_VERSION}.tar.gz     && cd libressl-${LIBRESSL_VERSION}     && ./configure --prefix=/usr/src/libressl     && make && make install
 ---> Using cache
 ---> 95606f90a15b
Step 5/11 : ENV SERVER_VERSION=v2.3.53
 ---> Using cache
 ---> 083edefbe2a8
Step 6/11 : RUN git clone https://github.com/SUPLA/supla-core.git --branch ${SERVER_VERSION} /src     && cd /src/supla-scheduler/Release && make all SSLDIR=/usr/src/libressl     && cd /src/supla-server/Release && make all SSLDIR=/usr/src/libressl     && cp /src/supla-scheduler/Release/supla-scheduler /src/supla-server/Release/supla-server /usr/local/bin     && rm -fr /src     && mkdir -p /etc/supla-server
 ---> Using cache
 ---> 62ecfbbb4f39
Step 7/11 : COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
 ---> Using cache
 ---> d349092a8496
Step 8/11 : COPY supla.cfg /etc/supla-server/supla.cfg.initial
 ---> Using cache
 ---> e4213ff6c919
Step 9/11 : COPY server-entrypoint.sh /usr/bin/server-entrypoint
 ---> Using cache
 ---> 716b93843ae8
Step 10/11 : ENTRYPOINT ["/usr/bin/server-entrypoint"]
 ---> Using cache
 ---> 583eea753103
Step 11/11 : CMD ["/usr/bin/supervisord", "--nodaemon", "--configuration", "/etc/supervisor/conf.d/supervisord.conf"]
 ---> Using cache
 ---> 24a25a171041
Successfully built 24a25a171041
Successfully tagged supla_supla-server:latest
Starting supla-db ... done
Starting supla-cloud ... done
Starting supla-server ... done
SUPLA containers has been started.

Po wpisaniu docker ps i sprawdzeniu logów, wyświetla się to samo.

Czy mogę to wszystko jakoś naprawić? Proszę o pomoc.