WAS: Possible SQLITE Database corruption, NEW: Possible Access Rights Issue

microplayer commented 3 years ago

Hallo! Ich habe gerade erst mit einiger Mühe Part-DB "Version: 1.0.0-alpha" auf der Basis des Docker-Containers auf GitHub auf einer Synology DiskStation mit aktuellem DSM DSM 6.2.4-25556 ans Laufen gebracht. Die SQLITE Datenbank app.db liegt mit 336kB im Docker-Verzeichnis auf der Synology.

Heute, nach dem Anlegen von 88 Kategorien und lediglich 2 Komponenten kann ich die Komponenten zwar über die Suche oben rechts finden, angezeigt werden für diese Komponenten in der Maske aber nur Fragezeichen. Beim Klick auf die Fragezeichen des Namens erscheint dann die angehängte Fehlermeldung. Ich habe lediglich Informationen wie Name, Preis, Anzahl, Lieferant eingetragen, aber keine Bilder oder Dokumentation angehängt. Weder die Synology, noch der Container wurden "unterbrochen" oder neu gestartet, die Browser-Verbindung zum PC (aktuelles Mac 10.14.6 Mojave mit aktuellem Safari 14.1) wurde während der Anlage ebenfalls nicht unterbrochen.

Ich befürchte anhand der Fehlermeldungen, das die Datenbank korrupt ist. Eine Reparaturfunktion habe ich nicht gefunden.

Daraus ergeben sich für mich einige Frage:

Wie kann man meine DB möglichst reparieren? 88 Kategorien sind schon ein wenig Arbeit, die ich ungern wiederholen möchte.
Wenn es sich um einen Fehler handelt und im Main-Zweig auf GitHub korrigiert wurde, mit welchem Verzug kann ich mit einem aktualisierten Docker-Image rechnen?
Ist das überhaupt für den Container vorgesehen?

Grüße, Microplayer (gleiche Meldung auch bei mikrocontroller.net angelegt)

microplayer commented 3 years ago

Hi everybody, after a full night of sleep my initial level of disappointment lowered substantially. So this morning I rechecked things. Being logged in as a Standard User I read more thoroughly through the Server Error: 500 message and stumbled upon an entry stating: "src/EventSubscriber/LogSystem/LogAccessDeniedSubscriber.php (line 58)" This AccessDenied led me to to idea to check if the Admin User is also experiencing this odd behaviour when trying to look at components. The answer was: NO. Therefore I changed the title of this issue to "Possible Access Rights Issue"

Please have a look at the attached hardcopies. As described in german language above when opening this issue, I am not aware of any glitch and weirdness when I entered my first categories and parts.

I had one issue however during installation of the docker image: No luck whatsoever trying to install the SQLITE database using "docker exec --user=www-data partdb bin/console doctrine:migrations:migrate" as described here: [https://github.com/Part-DB/Part-DB-symfony/blob/master/docs/docker/docker-install.md] Loads and loads of error messages from the Symfony Framework.

Installation of DB finally went through when I logged in right into the Bash shell of the container "sudo docker exec -it partdb /bin/bash", when I became "root" and was able start "/var/www/html/bin/console doctrine:migrations:migrate " manually.

PLEASE BE AWARE: In my case the PHP(?) "bin/console" command was not part of the container's $PATH environment variable! This forced me also to first identify the full path to the "bin/console" command.
In order to make installation simpler for Docker hobbyists like me, you possible want to check PATH settings and access rights for "--user=www-data" inside the container.

Anyway, thank you very much for this impressive piece of software! Especially the responsive design is a major plus for me. It does not force me to sit at the desk to check and change inventory. I can do it on my iPad right from the couch. Thumbs up!

Kind regards, Microplayer

src_EventSubscriber_LogSystem_LogAccessDeniedSubscriber_php

Part-DB, Show All Parts as @Admin

Part-DB, Show All Parts as @StdUser

Part-DB Error Message

microplayer commented 3 years ago

OK, since I'm still alone here I tried to follow a different path to install the SQLITE DB in a freshly installed container based on jbtronics/part-db1:master. As I explained in my initial post I was not able to run the "sudo docker exec --user=www-data partdb /var/www/html/bin/console doctrine:migrations:migrate" command to create the SQLITE DB on my Synology.

Many, many lines of messages starting with: [2021-05-26T17:16:52.680344+00:00] php.INFO: User Deprecated: Since symfony/monolog-bridge 5.2: Passing an actionLevel (int|string) as constructor's 3rd .....

So I accessed the container by "docker exec -it npartb /bin/bash". There I ended up as "root": root@68108039e087:/var/www/html# whoami root root@68108039e087:/var/www/html# su www-data This account is currently not available. Trying to become www-data in order to run /bin/console from inside the container did fail :-/

Seems as if I could not become www-data to run "bin/console" is caused by the fact that www-data is not allowed to login to do the DB creation work:

cat /etc/passwd ... www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin ...

One workaround is providing the login shell for www-data upfront: su -s /bin/bash -c "/var/www/html/bin/console doctrine:migrations:migrate" www-data

But that failed also with the same load of error messages as cited above: WARNING! You are about to execute a database migration that could result in schema changes and data loss. Are you sure you wish to continue? (yes/no) [yes]:

yes

[2021-05-26T17:16:52.680344+00:00] php.INFO: User Deprecated: Since symfony/monolog-bridge 5.2: Passing an actionLevel (int|string) as constructor's 3rd ... ten's to one hundred+ of lines ... then ...: In AbstractSQLiteDriver.php line 70:
An exception occurred in driver: SQLSTATE[HY000] [14] unable to open database file
In PDOConnection.php line 31: SQLSTATE[HY000] [14] unable to open database file
In PDOConnection.php line 27: SQLSTATE[HY000] [14] unable to open database file
doctrine:migrations:migrate [--write-sql [WRITE-SQL]] [--dry-run] [--query-time] [--allow-no-migration] [--all-or-nothing [ALL-OR-NOTHING]] [--configuration CONFIGURATION] [--db-configuration DB-CONFIGURATION] [--] []

Unless I'm teached otherwise I would assume that something is really broken in the documentation how to bring up Part-DB in a container.

Kind regards, Microplayer

@Jan: Please try to help out here. Just one gentle push into to right direction needed.

jbtronics commented 3 years ago

Wie sind die Volumes in den Container eingebunden, und hat Docker die Zugriffsrechte auf die Ordner, wenn ein Ordner des NAS per Bind-Mount an den Container übergeben hat?

microplayer commented 3 years ago

An alle Leser: Entschuldigung für das Format, ich weiß aber nicht, auf welche Schlüssel das Markup reagiert...

........ @jbtronics - Danke für das Interesse an meinem Fall!

Verzeichnis der Synology, dessen Unterverzeichnisse "public_media" und "uploads" in den Part-DB Container gemountet werden:

admin@DS410:/volume1/docker/nPart-DB$ total 24 -rwxrwxr-x 1 admin 301 May 26 18:55 compose.sh -rwxrwxr-x 1 admin 326 May 26 19:03 createdb.sh -rwxrwxrwx 1 admin 789 May 25 14:32 docker-compose-nPart-DB.yaml -rwxrwxrwx+ 1 admin 920 May 25 13:01 org.docker-compose-rzink.yaml drwxrwxrwx+ 4 33 4096 May 28 00:21 public_media drwxrwxrwx+ 2 33 4096 May 28 00:35 uploads

Auf der Synology leiten sich die UID=2 bzw. 4 und GID=33 folgendermaßen her: cat /etc/passwd:

... daemon:x:2:2::/:/bin/sh ... lp_1552038200:x:4:7:lp:/var/spool/lpd:/sbin/nologin ...

Ich glaube aber, die IDs kommen aus meiner manuellen Rechtevergabe der gemounteten Directories im Container.

Die Gruppe=33 kommt vermutlich aus der expliziten Rechtevergabe innerhalb des Containers, die ich
beginnenden in /var/www/html gestartet hatte. Die Rechte auf "public_media" und "uploads" habe ich im Part-DB Container explizit manuell gesetzt auf UID=33=www-data und GID=33=www-data. Siehe auch weiter unten. chown -R www-data uploads chgrp -R www-data uploads und chown -R www-data public chgrp -R www-data public

Warum der User aus der "Außen"-Sicht der Synology inzwischen auf 2=bin bzw. 4=sync steht, kann ich aktuell nicht beantworten... Vielleicht passiert beim Anlegen der DB als "root" im Container?

Ein "ls -al /var/www/html/" im Container liefert ein für mich korrekt erscheinendes Bild:

... drwxr-xr-x 13 www-data www-data 4096 May 27 22:02 public drwxr-xr-x 20 www-data www-data 4096 Mar 14 22:47 src -rw-r--r-- 1 www-data www-data 24025 Mar 14 22:46 symfony.lock drwxr-xr-x 15 www-data www-data 4096 Mar 14 22:47 templates drwxr-xr-x 2 www-data www-data 4096 Mar 14 22:47 translations drwxr-xr-x 2 www-data www-data 4096 May 27 22:35 uploads ...

Für die Unterverzeichnisse ab public root@68108039e087:/var/www/html# ls -al /var/www/html/public/

total 48 drwxr-xr-x 13 www-data www-data 4096 May 27 22:02 . drwxrwxrwx 21 www-data www-data 4096 May 27 22:01 .. -rw-r--r-- 1 www-data www-data 4371 Mar 14 22:46 .htaccess drwxr-xr-x 8 www-data www-data 4096 May 27 22:01 build drwxr-xr-x 10 www-data www-data 4096 May 27 22:01 bundles drwxr-xr-x 4 www-data www-data 4096 May 27 22:02 ckeditor drwxr-xr-x 2 www-data www-data 4096 May 27 22:02 icons drwxr-xr-x 14 www-data www-data 4096 May 27 22:01 img -rw-r--r-- 1 www-data www-data 1074 Mar 14 22:46 index.php -rw-r--r-- 1 www-data www-data 386 Mar 14 22:46 manifest.json drwxr-xr-x 4 www-data www-data 4096 May 27 22:21 media

Und für die Teile unter "media": root@68108039e087:/var/www/html# ls -al /var/www/html/public/media/

total 16 drwxr-xr-x 4 www-data www-data 4096 May 27 22:21 . drwxr-xr-x 13 www-data www-data 4096 May 27 22:02 .. drwxr-xr-x 3 www-data www-data 4096 May 27 22:21 cache drwxr-xr-x 2 www-data www-data 4096 May 27 22:21 part

Vermutlich von früheren Experimenten bleiben zwei Attachments übrig, die ich seinerzeit leider nich mehr aus Parts-DB löschen konnte! root@68108039e087:/var/www/html# ls -al /var/www/html/public/media/part/

total 976 drwxr-xr-x 2 www-data www-data 4096 May 27 22:21 . drwxr-xr-x 4 www-data www-data 4096 May 27 22:21 .. -rw-rw-rw- 1 www-data www-data 114748 May 27 22:20 ledanzeigemodul16x8ht16k33matrixanzeigemodul-60b01b2f61076.jpeg -rw-rw-rw- 1 www-data www-data 871778 May 27 22:21 ledanzeigemodul16x8ht16k33matrixanzeigemodul-60b01b7f616c4.png

Ich habe gestern Abend dann den Container gelöscht und die DB neu angelegt um 22:31. root@68108039e087:/var/www/html/uploads# ls -al

total 664 drwxr-xr-x 2 www-data www-data 4096 May 27 22:31 . drwxrwxrwx 21 www-data www-data 4096 May 27 22:01 .. -rwxr-xr-x 1 root root 323584 May 27 22:31 app.db -rwxr-xr-x 1 www-data www-data 348160 May 25 10:25 app.db.rzink

Die in GitHub angegebene Zeile zum Anlegen der DB funktioniert - wenigstens bei mir - nicht: "docker exec --user=www-data partdb bin/console doctrine:migrations:migrate". Denn der user "www-data" hat in /etc/passwd des Containers keine eigene Shell gesetzt: www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin - siehe auch oben

Ich habe mir mit ""sudo docker exec -it partdb /bin/bash" beholfen und dann als "root" im Container explizit /bin/bash gesetzt und dann lediglich noch "/www/html/bin/console doctrine:migrations:migrate " manuell aufgerufen.

Hier ist übrigens der Output der doctrine:

[notice] Migrating up to DoctrineMigrations\Version20200502161750 [warning] Migration not needed for SQLite. Skipping... [warning] Migration DoctrineMigrations\Version1 was executed but did not result in any SQL statements. [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] Migration not needed for SQLite. Skipping... [warning] Migration DoctrineMigrations\Version20190902140506 was executed but did not result in any SQL statements. [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] Migration not needed for SQLite. Skipping... [warning] Migration DoctrineMigrations\Version20190913141126 was executed but did not result in any SQL statements. [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] Migration not needed for SQLite. Skipping... [warning] Migration DoctrineMigrations\Version20190924113252 was executed but did not result in any SQL statements. [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] Migration not needed for SQLite. Skipping... [warning] Migration DoctrineMigrations\Version20191214153125 was executed but did not result in any SQL statements. [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] Migration not needed for SQLite. Skipping... [warning] Migration DoctrineMigrations\Version20200126191823 was executed but did not result in any SQL statements. [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] Migration not needed for SQLite. Skipping... [warning] Migration DoctrineMigrations\Version20200311204104 was executed but did not result in any SQL statements. [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] Migration not needed for SQLite. Skipping... [warning] Migration DoctrineMigrations\Version20200409130946 was executed but did not result in any SQL statements. [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] [!!!] Permissions were updated! Please check if they fit your expectations! [warning] [warning] The initial password for the "admin" user is: b485267519 [warning] [notice] finished in 347.2ms, used 24M memory, 9 migrations executed, 71 sql queries

-> Dies halte ich tatsächlich für einen offensichtlichen Fehler in der Beschreibung zur Erstellung der DB auf GitHub - bis zum Beweis des Gegenteils durch Erläuterung meiner Fehlkonfiguration ;-)

Im nächsten Schritt habe ich dann die Ownership der DB auf www-data umgestellt:

root@68108039e087:/var/www/html/uploads# chown -R www-data /var/www/html/uploads/app.db root@68108039e087:/var/www/html/uploads# chgrp -R www-data /var/www/html/uploads/app.db root@68108039e087:/var/www/html/uploads# chmod og+w /var/www/html/uploads/app.db

root@68108039e087:/var/www/html/uploads# ls -al

total 664 drwxr-xr-x 2 www-data www-data 4096 May 27 22:31 . drwxrwxrwx 21 www-data www-data 4096 May 27 22:01 .. -rwxrwxrwx 1 www-data www-data 323584 May 27 22:31 app.db -rwxr-xr-x 1 www-data www-data 348160 May 25 10:25 app.db.rzink

Und da stehe ich jetzt.

Aus 3-5 ähnlichen Situationen habe ich leider bemerkt, das ich StorageLocations und Categories anlegen, umbennen und löschen konnte. Aber sobald ich Teile anlege und diese mit Bildern oder Attachments versehen, bekomme ich die weiter oben in Github gelisteten Error 500. Die Datenbank kann dann nur noch eingeschränkt bis gar nicht genutzt werden.
Leider habe ich keine Liste erlaubter Bild-Formate gefunden. Ebenso keine Übersicht, was in der 1.0.0.-alpha tunlichst vermieden werden sollte, weil eben "Alpha". Gehören vielleicht doch Attachments dazu? Oder erlebe ich eine nicht offensichtliche Einschränkung von SQLITE? Um ehrlich zu sein, glaube ich aktuell nicht mehr so recht an ein Rechteproblem. Eher vermute ich, dass meine Tests genau an den Stellen erfolgen, an denen der Alpha-Character zutage tritt... Da lasse ich mich aber gerne belehren.

Ich würde gerne mit der 1.0.0 weiterarbeiten, das sie mir von allen Optionen im Internet konzeptuell und grafisch am besten gefällt. Weitere Fragen zur Config beantworte ich deshalb sehr gerne. Danke für die Hilfe!

Microplayer

Als Ergänzung: sudo docker container inspect npartdb:

[ { "Id": "68108039e087783b96e0b0a2344e8f8b354d5212d7407d109a06d1fcd2ea6edf", "Created": "2021-05-26T16:56:04.384030313Z", "Path": "docker-php-entrypoint", "Args": [ "apache2-foreground" ], "State": { "Status": "running", "Running": true, "Paused": false, "Restarting": false, "OOMKilled": false, "Dead": false, "Pid": 13510, "ExitCode": 0, "Error": "", "StartedAt": "2021-05-27T22:32:36.408630798Z", "FinishedAt": "2021-05-27T22:32:31.608732105Z", "StartedTs": 1622154756, "FinishedTs": 1622154751 }, "Image": "sha256:e1e87e253691f2abd05b8250dff5776edd169e5335d9f2c1aba054e0459dbf0b", "ResolvConfPath": "/volume1/@docker/containers/68108039e087783b96e0b0a2344e8f8b354d5212d7407d109a06d1fcd2ea6edf/resolv.conf", "HostnamePath": "/volume1/@docker/containers/68108039e087783b96e0b0a2344e8f8b354d5212d7407d109a06d1fcd2ea6edf/hostname", "HostsPath": "/volume1/@docker/containers/68108039e087783b96e0b0a2344e8f8b354d5212d7407d109a06d1fcd2ea6edf/hosts", "LogPath": "/volume1/@docker/containers/68108039e087783b96e0b0a2344e8f8b354d5212d7407d109a06d1fcd2ea6edf/log.db", "Name": "/npartdb", "RestartCount": 0, "Driver": "aufs", "Platform": "linux", "MountLabel": "", "ProcessLabel": "", "AppArmorProfile": "docker-default", "ExecIDs": null, "HostConfig": { "Binds": [ "/volume1/docker/nPart-DB/public_media:/var/www/html/public/media:rw", "/volume1/docker/nPart-DB/uploads:/var/www/html/uploads:rw" ], "ContainerIDFile": "", "LogConfig": { "Type": "db", "Config": {} }, "NetworkMode": "npart-db_default", "PortBindings": { "80/tcp": [ { "HostIp": "", "HostPort": "8090" } ] }, "RestartPolicy": { "Name": "unless-stopped", "MaximumRetryCount": 0 }, "AutoRemove": false, "VolumeDriver": "", "VolumesFrom": [], "CapAdd": null, "CapDrop": null, "Dns": null, "DnsOptions": null, "DnsSearch": null, "ExtraHosts": null, "GroupAdd": null, "IpcMode": "shareable", "Cgroup": "", "Links": null, "OomScoreAdj": 0, "PidMode": "", "Privileged": false, "PublishAllPorts": false, "ReadonlyRootfs": false, "SecurityOpt": null, "UTSMode": "", "UsernsMode": "", "ShmSize": 67108864, "Runtime": "runc", "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "PHPIZE_DEPS=autoconf \t\tdpkg-dev \t\tfile \t\tg++ \t\tgcc \t\tlibc-dev \t\tmake \t\tpkg-config \t\tre2c", "PHP_INI_DIR=/usr/local/etc/php", "APACHE_CONFDIR=/etc/apache2", "APACHE_ENVVARS=/etc/apache2/envvars", "PHP_EXTRA_BUILD_DEPS=apache2-dev", "PHP_EXTRA_CONFIGURE_ARGS=--with-apxs2 --disable-cgi", "PHP_CFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", "PHP_CPPFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", "PHP_LDFLAGS=-Wl,-O1 -pie", "GPG_KEYS=42670A7FE4D0441C8E4632349E4FDC074A4EF02D 5A52880781F755608BF815FC910DEB46F53EA312", "PHP_VERSION=7.4.16", "PHP_URL=https://www.php.net/distributions/php-7.4.16.tar.xz", "PHP_ASC_URL=https://www.php.net/distributions/php-7.4.16.tar.xz.asc", "PHP_SHA256=1c16cefaf88ded4c92eed6a8a41eb682bb2ef42429deb55f1c4ba159053fb98b", "APP_ENV=demo", "DATABASE_URL=sqlite:///%kernel.project_dir%/uploads/app.db" ], "ConsoleSize": [ 0, 0 ], "Isolation": "", "CpuShares": 0, "Memory": 0, "NanoCpus": 0, "CgroupParent": "", "BlkioWeight": 0, "BlkioWeightDevice": null, "BlkioDeviceReadBps": null, "BlkioDeviceWriteBps": null, "BlkioDeviceReadIOps": null, "BlkioDeviceWriteIOps": null, "CpuPeriod": 0, "CpuQuota": 0, "CpuRealtimePeriod": 0, "CpuRealtimeRuntime": 0, "CpusetCpus": "", "CpusetMems": "", "Devices": null, "DeviceCgroupRules": null, "DiskQuota": 0, "KernelMemory": 0, "MemoryReservation": 0, "MemorySwap": 0, "MemorySwappiness": null, "OomKillDisable": false, "PidsLimit": 0, "Ulimits": null, "CpuCount": 0, "CpuPercent": 0, "IOMaximumIOps": 0, "IOMaximumBandwidth": 0, "MaskedPaths": [ "/proc/asound", "/proc/acpi", "/proc/kcore", "/proc/keys", "/proc/latency_stats", "/proc/timer_list", "/proc/timer_stats", "/proc/sched_debug", "/proc/scsi", "/sys/firmware" ], "ReadonlyPaths": [ "/proc/bus", "/proc/fs", "/proc/irq", "/proc/sys", "/proc/sysrq-trigger" ] }, "GraphDriver": { "Data": null, "Name": "aufs" }, "Mounts": [ { "Type": "bind", "Source": "/volume1/docker/nPart-DB/public_media", "Destination": "/var/www/html/public/media", "Mode": "rw", "RW": true, "Propagation": "rprivate" }, { "Type": "bind", "Source": "/volume1/docker/nPart-DB/uploads", "Destination": "/var/www/html/uploads", "Mode": "rw", "RW": true, "Propagation": "rprivate" } ], "Config": { "Hostname": "68108039e087", "Domainname": "", "User": "root", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "ExposedPorts": { "80/tcp": {} }, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "PHPIZE_DEPS=autoconf \t\tdpkg-dev \t\tfile \t\tg++ \t\tgcc \t\tlibc-dev \t\tmake \t\tpkg-config \t\tre2c", "PHP_INI_DIR=/usr/local/etc/php", "APACHE_CONFDIR=/etc/apache2", "APACHE_ENVVARS=/etc/apache2/envvars", "PHP_EXTRA_BUILD_DEPS=apache2-dev", "PHP_EXTRA_CONFIGURE_ARGS=--with-apxs2 --disable-cgi", "PHP_CFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", "PHP_CPPFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", "PHP_LDFLAGS=-Wl,-O1 -pie", "GPG_KEYS=42670A7FE4D0441C8E4632349E4FDC074A4EF02D 5A52880781F755608BF815FC910DEB46F53EA312", "PHP_VERSION=7.4.16", "PHP_URL=https://www.php.net/distributions/php-7.4.16.tar.xz", "PHP_ASC_URL=https://www.php.net/distributions/php-7.4.16.tar.xz.asc", "PHP_SHA256=1c16cefaf88ded4c92eed6a8a41eb682bb2ef42429deb55f1c4ba159053fb98b", "APP_ENV=demo", "DATABASE_URL=sqlite:///%kernel.project_dir%/uploads/app.db" ], "Cmd": [ "apache2-foreground" ], "Image": "jbtronics/part-db1:master", "Volumes": { "/var/www/html/public/media": {}, "/var/www/html/uploads": {} }, "WorkingDir": "/var/www/html", "Entrypoint": [ "docker-php-entrypoint" ], "OnBuild": null, "Labels": { "com.docker.compose.config-hash": "3e4b8be522b7c195e9e63c08ba387c8648c206110363a62e0a61d6d17f0c40ff", "com.docker.compose.container-number": "1", "com.docker.compose.oneoff": "False", "com.docker.compose.project": "npart-db", "com.docker.compose.project.config_files": "docker-compose-nPart-DB.yaml", "com.docker.compose.project.working_dir": "/volume1/docker/nPart-DB", "com.docker.compose.service": "npartdb", "com.docker.compose.version": "1.29.2", "org.opencontainers.image.created": "2021-03-14T22:46:53.727Z", "org.opencontainers.image.description": "[WIP] A new Part-DB experience based on Symfony4", "org.opencontainers.image.licenses": "AGPL-3.0", "org.opencontainers.image.revision": "7bdf4536a90ef3eda6c748a38d64062703bbf8c8", "org.opencontainers.image.source": "https://github.com/Part-DB/Part-DB-symfony", "org.opencontainers.image.title": "Part-DB-symfony", "org.opencontainers.image.url": "https://github.com/Part-DB/Part-DB-symfony", "org.opencontainers.image.version": "master" }, "StopSignal": "SIGWINCH", "DDSM": false }, "NetworkSettings": { "Bridge": "", "SandboxID": "286008a18a222a843d50ba362e67a69baaf69bf6935ef9a4f74714e5da5f2836", "HairpinMode": false, "LinkLocalIPv6Address": "", "LinkLocalIPv6PrefixLen": 0, "Ports": { "80/tcp": [ { "HostIp": "0.0.0.0", "HostPort": "8090" } ] }, "SandboxKey": "/var/run/docker/netns/286008a18a22", "SecondaryIPAddresses": null, "SecondaryIPv6Addresses": null, "EndpointID": "", "Gateway": "", "GlobalIPv6Address": "", "GlobalIPv6PrefixLen": 0, "IPAddress": "", "IPPrefixLen": 0, "IPv6Gateway": "", "MacAddress": "", "Networks": { "npart-db_default": { "IPAMConfig": null, "Links": null, "Aliases": [ "68108039e087", "npartdb" ], "NetworkID": "8c0f9cf055f784cf618c1cba0fa671b9579809edf2404e1be7608c2ffb36b851", "EndpointID": "768dfd2be13ec05e316387122f70cadc8802c9db6e532715fecc4c0709c286cc", "Gateway": "172.18.0.1", "IPAddress": "172.18.0.2", "IPPrefixLen": 16, "IPv6Gateway": "", "GlobalIPv6Address": "", "GlobalIPv6PrefixLen": 0, "MacAddress": "02:42:ac:12:00:02", "DriverOpts": null } } } } ]

microplayer commented 3 years ago

Wie oben erwähnt, läßt sich das Kommando zum Anlegen der SQLite-DB für den Docker Container leider nicht ausführen: "sudo docker exec --user=www-data partdb /var/www/html/bin/console doctrine:migrations:migrate". Mein Workaround, ausgeführt in der SSH-Console der Synology, funktioniert wie folgt:

sudo docker exec -it npartdb /bin/bash (Mein Container zum Testen heißt npartb) 1b. Zur Sicherheit: whoami (sollte "root" sein)
apt install vim (Der recht nackte Container enthält keinen Editor, daher VI nachinstalliert)
cd /etc/passwd
vi passwd
In der Zeile für den user www-data am Ende "/usr/sbin/nologin" durch "bin/bash" ersetzen
mit ESC, w, q die Änderung sichern
Environment-Variablen anzeigen mit "printenv"
Den String bzw. die Env-Variable "DATABASE_URL=sqlite:///%kernel.project_dir%/uploads/app.db" kopieren
Zum User www-data werden: su - www-data 9a. Zur Sicherheit: whoami (Leider habe ich keinen Weg gefunden, die Env-Variablen von root "mitzunehmen")
Auf der CLI deshalb eingeben: DATABASE_URL='sqlite:///%kernel.project_dir%/uploads/app.db'
Dann: export DATABASE_URL
Prüfen wieder mit printenv (Wir brauchen den Pfad zum korrekten Anlegen der SQLite-DB)
Wir stehen in /var/www/ - mit "cd html" eine Ebene tiefer, damit wir von dort aus direkt bin/console aufrufen können
Also nun als User www-data die DB anlegen: bin/console doctrine:migrations:migrate
Achtung: Das Passwort des Admins am Ende der Ausgabe kopieren! (Alternativ wie beschrieben mit "php bin/console app:set-password [username]" neu auf der Container CLI setzen
Per "ls -ahl uploads" überprüfen, das eine ca. 316kB große Datenbank app.db angelegt wurde
Diese initiale DB sicherheitshalber als ersten Backup in Sicherheit kopieren (Da bei mir public/media und uploads als Volume aus der Synology gemountet sind, geht das z.B. über Synology DSM)
Jetzt sollte der Login in Part-DB funktionieren.

Für mich scheint die DB jetzt immerhin so weit "vollständig" und reibungslos zu funktionieren, dass ich beim nächsten Fehler mit nicht unterstützten JPG-Files diese Dateien immerhin wieder problemlos mit dem Part-DB-GUI aus der DB löschen konnte. Und eben ohne das die ganze DB unbenutzbar wurde.

@Jan: Bitte überprüfe die in Github beschriebene Methode zum Anlegen der SQLite Datenbank. Ich sehe hier einen Fehler, der mich zu diesem recht aufwendigen Workaround getrieben hat. Sollte ich dagegen einen Fehler gemacht haben, so lerne ich gerne von Kundigeren.

Grüße, Microplayer

microplayer commented 3 years ago

UPDATE! - Nachfolgend die korrigierte Fassung. Habe versehentliche eine Experimentierfassung kopiert. 
---------------
Der Vollständigkeit noch mein "docker-compose-zPart-DB.yaml" angepasst für die Synology:

Der Container wird also als "admin" über die CLI auf der DiskStation per YAML erzeugt.
Bedingt natürlich SSH-Zugang auf die DiskStation. Das Image muss auch "irgendwie" auf die
Synology kommen... Mein Weg: "docker save" vom PC, TAR auf die SYNO kopieren, "docker load".

Grüße, Microplayer

--------------- docker-compose-zPart-DB.yaml ------------------

version: '3.3'
# Microplayer, 07.06.2021 - "Long Syntax" für Volumes hat auf der Synology bei mir nicht funktioniert
# Siehe: https://docs.docker.com/compose/compose-file/compose-file-v3/#volumes
services:
  zpartdb:
    container_name: zpartdb
    # By default zPart-DB will be running under Port 8092, you can change it here
    # Auf dem PC ist natürlich die Synology auf Port 8092 zu adressieren: http://192.168.98.40:8092
    ports:
      - '8092:80'
    volumes:
      # Den kompletten Pfad auf der Synology zum einzuhängenden Verzeichnis in den Container angeben
      - /volume1/docker/zPart-DB/uploads:/var/www/html/uploads
      - /volume1/docker/zPart-DB/public_media:/var/www/html/public/media
      # Ausführliche Darstellung der Volumes und Mountpoint von oben - Source=NAS-Pfad:Target=Pfad im Container

    restart: unless-stopped
    image: rzink-part-db1-image

microplayer commented 3 years ago

Hi everybody,

after two weeks with Part-DB 1.0.0, many hours on the CLI of my Synology, reading and testing and scripting with Docker, PHP, GitHub, docker build and others I seem to have made relevant progress on my personal learning curve ;-)

In retrospective, it looks like the issues that convinced me to open this case were caused by a coincidence of multiple quirks in the Part-DB installation on my side together with lack of knowledge about the inner workings of the "Part-DB package" as a whole. I will close this issue.

Sorry for any inconvenience,

Microplayer

Part-DB / Part-DB-server