Error happened during creating seafile admin

When spinning up a fresh container, I receive the following error halfway through the initial setup script:

seafile  | Starting seahub...
seafile  | + echo 'Starting seahub...'
seafile  | + ./seahub.sh start-fastcgi
seafile  |
seafile  | LANG is not set in ENV, set to en_US.UTF-8
seafile  | LC_ALL is not set in ENV, set to en_US.UTF-8
seafile  | ./seahub.sh: line 209: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
seafile  | Starting seahub (fastcgi) at 127.0.0.1:8000 ...
seafile  |
seafile  | Error happened during creating seafile admin.

This is a snippet from the logs. The container starts fine, and I can actually get to the login page, but since the admin account has not been created, I cannot log in.

I’ve been digging through the Seafile codebase to find out where this pops up, and it looks like the check_init_admin.py file is where the exception is thrown, which is called by seahub.sh.

I’m creating the container using the following docker-compose:

version: '3'

services:
  cloud:
    container_name: seafile
    image: stonemaster/docker-seafile-server
    volumes:
      - /containers/Seafile:/data
    expose:
      - "80"
    environment:
      - SEAFILE_EXTERNAL_PORT=80
      - SEAFILE_HOSTNAME=localhost
      - SEAFILE_SERVER_NAME=test
      - SEAFILE_ADMIN_EMAIL=actual@email.com
      - SEAFILE_ADMIN_PASSWORD=password

networks:
  default:
    external:
      name: nginx-proxy

There is another reverse proxy in front of this container. I’m assuming this won’t interfere with the admin creation process, but I’m still mentioning it just in case.

By the way: thanks for creating this. It is much, much better than the strange dockerfile wrapper script presented by the Seafile devs themselves.

Источник

Содержание

Creation of initial seafile admin fails #5
Comments
http://host:8000 after seafile-admin start #743
Comments
It’s the first time you start the seafile server. Now let’s create the admin account
Successfully created seafile admin
it is supposed to trig to build all dependencies (including ccnet, libsearpc, and seafile)
The default install directory is under /usr/local/www/haiwen/
User have to manually copy linux server version seahub/thirdpart contents because I don’t know whether the
freebsd port system allows me to hold another tar there
I also don’t want to deal with every python modules
make sure that you have the following in the above directory
You should following the manual book to change path, and config
You should following the manual book to change path, and config

Creation of initial seafile admin fails #5

When spinning up a fresh container, I receive the following error halfway through the initial setup script:

This is a snippet from the logs. The container starts fine, and I can actually get to the login page, but since the admin account has not been created, I cannot log in.

I’ve been digging through the Seafile codebase to find out where this pops up, and it looks like the check_init_admin.py file is where the exception is thrown, which is called by seahub.sh .

I’m creating the container using the following docker-compose :

There is another reverse proxy in front of this container. I’m assuming this won’t interfere with the admin creation process, but I’m still mentioning it just in case.

By the way: thanks for creating this. It is much, much better than the strange dockerfile wrapper script presented by the Seafile devs themselves.

The text was updated successfully, but these errors were encountered:

Could you give some information on the Docker and Docker-compose versions used?

I have a similar setup in use with an NGINX Reverse proxy and that definitely doesn’t interfer.

This indeed is a strange bug because the Travis Build runs some unit tests and the admin creation is essential for anything to work.

Is there maybe a permission problem of some sort with the host mount /containers/Seafile ?
And could you check dmesg / syslog output to problems related to SELinux or other things interfering with docker?
What happens without the host mount (not persitent of course)?
EDITED: What distribution do you use?

My Docker host is an Ubuntu server 17.10 machine, with Docker version 17.12.0-ce and Docker-compose version 1.18.0 .

I’ve been testing around some more (also based on your questions). Not mounting the volume still gives the same creation error, so it does not seem to be a permission error on the volume itself. As far as any dmesg logs, there are no things out of the ordinary. I tried looking into some other logging, but Seafile itself does not log a lot regarding the python bootstrap scripts they are providing, so it seems like a dead end there.

However, I found something interesting. Executing the docker run equivalent of my compose file does work. So that would be the following (minus the volume, still for testing purposes):

So this seems to be an issue related to Docker-compose?

This is super weird. To my understanding docker-compose is just wrapper for docker and shouldn’t do any extra stuff. I have docker 1.13 and docker-compose 1.8 , so much older versions than you. I am also using Ubuntu but 16.04.

Could you post the logs of Docker after trying to create the container using docker-compose ? You should be able to get the logs using journalctl -u docker -n 1000 on Ubuntu.

The following is the resulting log of specifically creating the container.

And using docker run :

They seem identical regarding the operations themselves. The moment the creation error pops up, there is no log entry created by Docker.

Could it be a rights issue, that UID and GID need to be passed into the container to properly work when using docker-compose ? I’m guessing here, as it seems to be a longshot.

Just encountered similar with a manual build on Ubuntu 20.04 and Seafile 7.1.5

Starting seahub.sh asks for admin email and password then gives the above error «Error happened during creating seafile admin»

Except in my case I cannot access the site at this point and on server curl 127.0.0.1:8000 returns nothing

Of note I did need to install libmemcached-dev via apt before I could install pylibmc and django-pylibmc via pip3

Источник

http://host:8000 after seafile-admin start #743

I am porting the 3.0.4 to FreeBSD 9.2 Release. I understand that you have no support. Although some ports dependencies are not fully written, the build, installation, and init runs for major components seem fine. I have a question, without setting apache or Ngix, what I should expect to http://host:8000 just after

I hit 500 Internal Server Error, does it mean httpserver has problem? Which log file I can triage what happens.

The text was updated successfully, but these errors were encountered:

It is quite interesting for me to find out that someone installed seafile sucessfully under freebsd.
I believe you forgot execute ./manage.py syncdb in seahub directory before you start seafile. Or you can reference our manual

You might want to turn on django’s debug mode to get more information by adding a line to seahub_setting.py :

PS: I spent some hours compiling seafile under FreeBSD, and only found out I got stuck with libevent2. I referenced some old issues with BSDs support (e.g. haiwen/ccnet#4 ) . I thought it is non-trivial work and I will look into the BSDs support of seafile once I get some free time. And it would be very awesome if you can contribute back to seafile.

I would contribute to a bounty on this. big-grizzly will your work help us get the server running on FreeNAS?

Somehow the above issue is resolved because I know there is something missing for FreeBSD code. Now the important problem in front of me is all the servers are running. But the downloading file size is always 0 byte, although the file size show in main web interface is 200+K bytes. When uploading, connection is always failed.

Yes, if possible, I would like to help FreeBSD, and FreeNAS community to port this project.

big-grizzly, you might want to comment here —> http://forums.pcbsd.org/showthread.php?t=22607
you might get some support, if others know you are working on the project already. I put in a ticket with ixsystems asking them what it would take to get this into FreeNAS.

Hi @big-grizzly @stephenhoos
It sounds coooooooool to get seafile into FreeNAS.
If there is anything I can help with, please don’t hesitate to cc me, or email me rwindz0 AT gmail DOT c0m.

I am not a programmer just a sysadmin, so I can help with testing, but not programming. I run a few FreeNAS boxes, and I can spin up VMs too, so let me know if you need help with testing or anything like that.

big_grizzly, you do not have permission to access this page. This could be due to one of several reasons:
1. Your user account may not have sufficient privileges to access this page. Are you trying to edit someone else’s post, access administrative features or some other privileged system?
2. If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

It seems that I hit some issue to post reply.

On Monday, August 11, 2014 10:55 AM, stephenhoos notifications@github.com wrote:

big_grizzly, where are you having the problem? It looks like your reply
showed up on github

On Wed, Aug 13, 2014 at 3:06 PM, big-grizzly notifications@github.com
wrote:

big_grizzly, you do not have permission to access this page. This could be
due to one of several reasons:

Your user account may not have sufficient privileges to access this
page. Are you trying to edit someone else’s post, access administrative
features or some other privileged system?
If you are trying to post, the administrator may have disabled your
account, or it may be awaiting activation.

It seems that I hit some issue to post reply.

On Monday, August 11, 2014 10:55 AM, stephenhoos notifications@github.com
wrote:

I am not a programmer just a sysadmin, so I can help with testing, but not
programming. I run a few FreeNAS boxes, and I can spin up VMs too, so let
me know if you need help with testing or anything like that.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#743 (comment).

some patches for FreeBSD(or FreeNAS, untested though)

sadly, seafile (seaf-daemon) requires additional support for fs change watch via kqueue, so building seafile-client (gui) would be quite tough.

Now the major parts work, and libsearpc, and ccnet can pass poudriere in freebsd ports. I am working on finalize sea file ports. There could be small script issue because one script still hangs somewhere.

My working version is on 9.3-release amd64 (the uploading and downloading issues are gone)

On Friday, August 22, 2014 11:13 AM, Chilledheart notifications@github.com wrote:

some patches for FreeBSD(or FreeNAS, untested though)
* ccnet https://github.com/Chilledheart/ccnet/tree/bsd_support
* seafile https://github.com/Chilledheart/seafile/tree/bsd_support
sadly, seafile (seaf-daemon) requires additional support for fs change watch via kqueue, so building seafile-client (gui) would be quite tough.
—
Reply to this email directly or view it on GitHub.

root@freebsd93:/usr/local/www/haiwen/seafile-server # ./seahub.sh restart

Seahub is not running
Starting seahub at port 8000 .

It’s the first time you start the seafile server. Now let’s create the admin account

What is the email for the admin account?
[ admin email ] yan_jingfeng@yahoo.com

What is the password for the admin account?
[ admin password ]

Enter the password again:
[ admin password again ]

Successfully created seafile admin

Loading ccnet config from /usr/local/www/haiwen/ccnet
Loading seafile config from /usr/local/www/haiwen/seafile-data

Seahub is started

Created libevhtp (initial in freebsd already, need some correction), libsearpc, ccnet, sea file, and sea hub ports. Will submit to ports within one-two days.

On Friday, August 22, 2014 11:13 AM, Chilledheart notifications@github.com wrote:

bug list 193132,193133,193134,and 193135 to freebsd port tree (libevhtp has been committed, should be 1.2.9_1 soon)

it is supposed to trig to build all dependencies (including ccnet, libsearpc, and seafile)

make install
make clean

The default install directory is under /usr/local/www/haiwen/

User have to manually copy linux server version seahub/thirdpart contents because I don’t know whether the

freebsd port system allows me to hold another tar there

I also don’t want to deal with every python modules

make sure that you have the following in the above directory

[files]
drwxr-xr-x 6 root wheel 25 Aug 28 05:54 wsgidav
drwxr-xr-x 5 root wheel 5 Aug 28 05:54 Djblets-0.6.14.dev-py2.6.egg
drwxr-xr-x 4 root wheel 10 Aug 28 05:54 seafobj.orig
drwxr-xr-x 4 root wheel 4 Aug 28 05:54 gunicorn-0.16.1-py2.6.egg
drwxr-xr-x 4 root wheel 4 Aug 28 05:55 python_daemon-1.5.5-py2.6.egg
drwxr-xr-x 4 root wheel 4 Aug 28 05:55 lockfile-0.9.1-py2.6.egg
drwxr-xr-x 4 root wheel 4 Aug 28 05:55 chardet-2.1.1-py2.6.egg
drwxr-xr-x 4 root wheel 4 Aug 28 05:55 flup-1.0-py2.6.egg
drwxr-xr-x 4 root wheel 4 Aug 28 05:55 Django-1.5.1-py2.6.egg
-rwxr-xr-x 1 root wheel 326 Aug 28 05:55 gunicorn_django
-rw-r—r— 1 root wheel 397 Aug 28 05:55 easy-install.pth
-rwxr-xr-x 1 root wheel 191 Aug 28 05:55 django-admin.py
-rwxr-xr-x 1 root wheel 190 Aug 28 05:55 chardetect.py
-rw-r—r— 1 root wheel 2362 Aug 28 05:55 site.py
-rwxr-xr-x 1 root wheel 343 Aug 28 05:55 seafdav.orig
-rwxr-xr-x 1 root wheel 326 Aug 28 05:55 gunicorn_paster
-rwxr-xr-x 1 root wheel 312 Aug 28 05:55 gunicorn
-rw-r—r— 1 root wheel 1767 Aug 28 05:55 site.pyc
drwxr-xr-x 3 root wheel 5 Aug 28 05:55 six-1.4.1-py2.6.egg
drwxr-xr-x 4 root wheel 21 Aug 28 06:12 rest_framework
drwxr-xr-x 4 root wheel 9 Aug 28 06:12 registration
drwxr-xr-x 4 root wheel 10 Aug 28 06:12 captcha
[files]

mount -t procfs proc /proc
cd /usr/local/www/haiwen/seafile-server/seahub
for file in makemessages.sh.template run-seahub.sh.template send_user_notifications.sh.template setenv.sh.template; do
cp $ $
done

You should following the manual book to change path, and config

source seahub/setenv.sh
./setup-seafile.sh
./seafile.sh start
./seafile.sh stop

On Friday, August 22, 2014 11:13 AM, Chilledheart notifications@github.com wrote:

@big-grizzly I am not sure, but you might want to reference the python’s requirements.txt for thirdpart stuff, notably django
and djblets. Perhaps port www/py-django15 and www/py-djblets would fit this gap.

Yeah, I just found them in the freebsd bugzilla. List the links here for convenience :

First of all, I definitely will make try on python module requirement. I think that my original struggling experience with python modules on my 9,2 box is quite bad, especially for django15. The above two modules are still some starts. Gunicorn also make some trouble at that time. Honestly, that 9.2 box has some trouble of python version selection, and some other unclear issue in port mgmt.

Now, I fully work on a new 9.3-rel box, and I will try to fill in the gap as much as possible for sure. The bugs filed in freebsd port tree provide me a baseline that the server side can work on BSD system.

Secondary, I have finished building ccnet 3.1.4, seafile 3.1.4, latest libsearpc now. During the weekend, I will try to make python module into pkg as many as possible.

Finally, I guess turning ports to PBIs should be relatively «easy». Then, stephenhoos can have something tests on PC-BSD.

BTW, libevhtp has fix with bugid 191931 (seafile port needs it), which create shared object by default. It should be in the port tree soon.

On Friday, August 29, 2014 9:56 PM, Chilledheart notifications@github.com wrote:

The port efforts for 3.1.5 has been done, which reach similar situ with porting 3.0.4. I will try to update the bug ids listed in previous post.

Now the steps are simplified to be:

(1) build seahub
(2) mount -t procfs proc /proc
(3)
cd /usr/local/www/haiwen/seafile-server/seahub
for file in makemessages.sh.template run-seahub.sh.template send_user_notifications.sh.template setenv.sh.template; do
cp $ $
done
(4)
cd /usr/local/www/haiwen/seafile-server

You should following the manual book to change path, and config

source seahub/setenv.sh
./setup-seafile.sh
./seafile.sh start
./seahub.sh start

(other detail settings should follow the manual)

There are 2 issues for porting.

(1) requirements.txt
is not part of release 3.1.5, and some of the requirements are not show in 3.1.5 third party packages. For example, pt-selenium. I added it into 3.1.5 port for future reference.

(2) Now the trouble maker is python djblets. The seafile chooses the combination of django and djblets in an interesting way. djblets 0.6.14 requires newer than django 1.1.1, and using django 1.5.1, which fit for the requirement of djblets. System like debian removes djblets package. while FreeBSD has djblets 0.7.28 port. However, the port follows egg requirement strictly, which uses django 1.4.x.

If I want to following normal way to install djblets 0.6.14 by ports, or packages, it will blocks to use existing djblets 0.7.28. I anyway will submit py-djblets06 ports. I don’t prefer to this way.

Let me know if there is any suggestion. Thank you.

Finally, start to work on PBI for PC-BSD.

Best,
Jingfeng
On Saturday, August 30, 2014 2:48 AM, Jingfeng Yan yan_jingfeng@yahoo.com wrote:

Secondary, I have finished building ccnet 3.1.4, seafile 3.1.4, latest libsearpc now. During the weekend, I will try to make python module into pkg as many as possible.

Finally, I guess turning ports to PBIs should be relatively «easy». Then, stephenhoos can have something tests on PC-BSD.

BTW, libevhtp has fix with bugid 191931 (seafile port needs it), which create shared object by default. It should be in the port tree soon.

Источник

Cub0n

Environment variable
Tests. Either write a new test scenario, which will extend test duration probably unnecessary, or activate for all scenarios and assume if it works with memcached, it works without.

Just check UI should work.

Two tests in mind:

Check login page (only static content available, as far as I know) can be fetched and login is successful (because we can)
Check media folder accessibility

Implementation ideas:

CSRF=$(curl -s -c cookies http://$HOST:$PORT/accounts/login/ | sed -n 's/.* name="csrfmiddlewaretoken" value="([^"]*).*/1/p')

curl -is -b cookies -d "csrfmiddlewaretoken=$CSRF&login=$SEAFILE_ADMIN_EMAIL&password=$SEAFILE_ADMIN_PASSWORD" http://$HOST:$PORT/accounts/login/ | grep 302

# Something more relevant can be to retrieve avatar URL from previous test
curl -s http://$HOST:$PORT/media/favicons/favicon.png | sha1sum - | grep 71a42c2032dedfe7c6a066ed2296a8db2b120155

Tests should probably be added to current API tests (renamed to Seahub tests) since more in deep UI tests need ton of javascript execution.

Title. Will complete API tests for now.

Environment variable
Test

Environment variable
Tests. Note: Need a new test case as for update and new instance

As briefly discussed in #35, running init step with a container which was previously used leads to conflicts.

Following symlinks should be cleaned before initialization (relative to /opt/seafile):

seafile-server-<version>/seahub/media
seafile-server-latest
conf
seafile-data
seahub-data
logs
ccnet
seahub.db

hello,
in my rock64 debian the container seafile have the init error:

2022-10-07T20:35:11+02:00 [Init] Cleaning media folder
2022-10-07T20:35:12+02:00 [Init] Exposing media folder in the volume
ln: failed to create symbolic link './seafile-server-9.0.9/seahub/media': File exists
2022-10-07T20:36:16+02:00 [Entrypoint] Local time set to Europe/Paris
2022-10-07T20:36:16+02:00 [Entrypoint] Checking permissions

my .env :

PUID=1000
PGID=1000
TZ=Europe/Paris
URL=rock64
SEAFILE_ADMIN_EMAIL=***************
SEAFILE_ADMIN_PASSWORD=**********
USE_HTTPS=0
MYSQL_HOST=db
MYSQL_USER_PASSWD=secret
MYSQL_ROOT_PASSWD=secret
SEAFILE_CONF_DIR=./seafile/conf
SEAFILE_LOGS_DIR=./seafile/logs
SEAFILE_DATA_DIR=./seafile/seafile-data
SEAFILE_SEAHUB_DIR=./seafile/seahub-data
DATABASE_DIR=./db
SEAFILE_SQLITE_DIR=./seafile/sqlite
SWAG_DIR=./swag

Sometimes, I’m getting following log output:

2021-10-31T14:49:31+00:00 [Entrypoint] Local time set to Atlantic/Canary
2021-10-31T14:49:31+00:00 [Entrypoint] Checking permissions
2021-10-31T14:49:31+00:00 [Entrypoint] PUID not set, using current
2021-10-31T14:49:32+00:00 [Entrypoint] GUID not set, using current
2021-10-31T14:49:32+00:00 [Entrypoint] Adjusting identifiers
usermod: no changes
2021-10-31T14:49:35+00:00 [Entrypoint] Running launch script
2021-10-31T14:49:37+00:00 [Launch] Making symlink to latest version
2021-10-31T14:49:37+00:00 [Launch] Linking internal configuration and data folders with the volume
2021-10-31T14:49:37+00:00 [Launch] Launching seafile
Starting seafile server, please wait ...
** Message: 14:49:40.529: seafile-controller.c(536): No seafevents.
Seafile server started
Done.
LANG is not set in ENV, set to en_US.UTF-8
./seafile-server-latest/seahub.sh: line 210: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
LC_ALL is not set in ENV, set to en_US.UTF-8
Starting seahub at port 8000 ...
----------------------------------------
It's the first time you start the seafile server. Now let's create the admin account
----------------------------------------
What is the email for the admin account?
[ admin email ] 
Error happened during creating seafile admin.
Seahub is started
Done.
2021-10-31T14:50:23+00:00 [Launch] Done
2021-10-31T14:50:23+00:00 [Entrypoint] Waiting for termination

These lines in particular:

...
Starting seahub at port 8000 ...
----------------------------------------
It's the first time you start the seafile server. Now let's create the admin account
----------------------------------------
What is the email for the admin account?
[ admin email ] 
Error happened during creating seafile admin.
Seahub is started
...

Also, sometimes only shows these (without interactive messages, but with the error line):

...
Starting seahub at port 8000 ...
Error happened during creating seafile admin.
Seahub is started
...

I’m not sure about the cause, but it appears randomly. Service is properly configured to use mysql/mariadb database, with admin user and pass set at environment variables and using volumes for persistence. My deployment configuration is published at: https://gitlab.com/pedroetb-projects/seafile/-/blob/master/docker-compose.yml (docker-compose.yml and .env for defaults).

Despite this, service is working fine, thanks! Only sharing this because it may be helpful.

Which license is applicable/wished for the source code in this repository?

There are a few different licenses to choose from for a community-oriented project, but clarifying this might be a good idea.

https://choosealicense.com/

./build_image.sh -l arm/v7 -v 8.0.7
Loading environment…
installing: mips64le qemu-mips64el already registered
installing: mips64 qemu-mips64 already registered
Restarting builder container..
4487d90d7044
[+] Building 5.2s (12/33)
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 3.31kB 0.1s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/debian:bullseye-slim 2.7s
=> [internal] load metadata for docker.io/library/debian:bullseye 2.7s
=> [internal] load build context 0.2s
=> => transferring context: 81.72kB 0.1s
=> [stage-1 1/7] FROM docker.io/library/debian:bullseye-slim@sha256:b0d53c872fd640c2af2608ba1e693cfc7dedea30abcd8f584b23d583ec6dadc7 0.3s
=> => resolve docker.io/library/debian:bullseye-slim@sha256:b0d53c872fd640c2af2608ba1e693cfc7dedea30abcd8f584b23d583ec6dadc7 0.3s
=> [builder 1/21] FROM docker.io/library/debian:bullseye@sha256:2906804d2a64e8a13a434a1a127fe3f6a28bf7cf3696be4223b06276f32f1f2d 0.3s
=> => resolve docker.io/library/debian:bullseye@sha256:2906804d2a64e8a13a434a1a127fe3f6a28bf7cf3696be4223b06276f32f1f2d 0.3s
=> CACHED [stage-1 2/7] RUN apt-get update && apt-get install —no-install-recommends -y sudo procps sqlite3 libmariadb3 libmemcached11 python3 python3-setuptools python3-ldap python3-sqlalchem 0.0s
=> CACHED [stage-1 3/7] WORKDIR /opt/seafile 0.0s
=> CACHED [stage-1 4/7] RUN groupadd -g 999 runtime && useradd -ms /bin/bash -G sudo,runtime seafile && echo ‘%sudo ALL=(ALL) NOPASSWD:ALL’ >> /etc/sudoers && chown seafile:runtime . && chmod g+w . 0.0s
=> CACHED [builder 2/21] RUN apt-get update -y && apt-get install -y wget sudo libmemcached-dev golang 0.0s
=> ERROR [builder 3/21] RUN wget https://raw.githubusercontent.com/haiwen/seafile-rpi/master/build3.sh 0.7s

[builder 3/21] RUN wget https://raw.githubusercontent.com/haiwen/seafile-rpi/master/build3.sh:
#11 0.343 —2021-12-31 07:49:04— https://raw.githubusercontent.com/haiwen/seafile-rpi/master/build3.sh
#11 0.423 Resolving raw.githubusercontent.com (raw.githubusercontent.com)… 185.199.108.133, 185.199.109.133, 185.199.110.133, …
#11 0.434 Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443… connected.
#11 0.478 HTTP request sent, awaiting response… 404 Not Found
#11 0.637 2021-12-31 07:49:05 ERROR 404: Not Found.
#11 0.637

Dockerfile:16

14 |
15 | # Retrieve seafile build script
16 | >>> RUN wget https://raw.githubusercontent.com/haiwen/seafile-rpi/master/build3.sh
17 | RUN chmod u+x build3.sh
18 |

error: failed to solve: process «/bin/sh -c wget https://raw.githubusercontent.com/haiwen/seafile-rpi/master/build3.sh» did not complete successfully: exit code: 8

yuppox

I set the UID/GID because the files are owned by an ID other than the default 1000. Apparently, when the container starts that triggers a chown -R user:user /opt/seafile step.

This may have something to do with my hardware but it’s extremely slow. It might take an hour (or more) for the container to start. I think the problem is that there are tens of thousands of files.

Is there a way to change the default 1000 to something else? Can I update the image, somehow? I can’t have it take this long every time it starts.

As discussed in #13 starting Seahub with a given port only affect display.

What matters is the binding in gunicorn.conf.py which is handled fine.

Nevertheless it’s still a bug and could be confusing, but it’s really far from my priorities so it will stay as wontfix atm.

Context

Install failed once due to the edge case of the db restarting to initialize at first launch.

In case of early fail (example below) no database is created thus there’s nothing to clean.

seafile_1        | verifying password of user root ...  
seafile_1        | Failed to connect to mysql server using user "root" and password "***": Can't connect to MySQL server on 'db' (115)

Expected

Nothing. The cleaning script has to silently do nothing.

Got

seafile_1        | 2021-07-02T10:39:37+02:00 [Init] Cleaning old databases
seafile_1        | Traceback (most recent call last):
seafile_1        |   File "<stdin>", line 6, in <module>
seafile_1        |   File "/opt/seafile/seafile-server-8.0.5/seahub/thirdpart/MySQLdb/cursors.py", line 206, in execute
seafile_1        |     res = self._query(query)
seafile_1        |   File "/opt/seafile/seafile-server-8.0.5/seahub/thirdpart/MySQLdb/cursors.py", line 319, in _query
seafile_1        |     db.query(q)
seafile_1        |   File "/opt/seafile/seafile-server-8.0.5/seahub/thirdpart/MySQLdb/connections.py", line 259, in query
seafile_1        |     _mysql.connection.query(self, query)
seafile_1        | MySQLdb._exceptions.OperationalError: (1008, "Can't drop database 'ccnet_db'; database doesn't exist")
seafile_1        | 2021-07-02T10:39:37+02:00 [Init] Retrying install

Fixes to evaluate

Put a try catch, probably the cleanest way
Redirect to null. Why not.

Context

When using a clean MySQL container in version 8, the following error occurs at first launch:

 Error happened during creating seafile admin.

And in seafile.log:

../common/seaf-db.c(709): Failed to connect to MySQL: Plugin caching_sha2_password could not be loaded: /usr/lib/x86_64-linux-gnu/mariadb19/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory

Fix attempts

Tried to use default-libmysqlclient-dev instead of libmariadb-dev, with no visible improvement.

Actual fix will come in the future.

Workaround

A more detailed procedure here. In a nutshell:

Connect to db container:

$ docker exec -it mysql_container_name /bin/bash

Update authentication plugin:

$ mysql -u root -p
mysql>  ALTER USER 'seafile' IDENTIFIED WITH mysql_native_password BY 'secret';

Come back on the host and set the credentials in interactive mode:

$ docker exec -it seafile_container_name seafile-server-latest/seahub.sh restart

Then everything should work fine.

Add required dependencies
Add USE_SQLITE env var
Check which env vars have to be used in install script
Check how to expose the data in the volume
Upgrade init script
Do some testing
Update doc (should probably do a table for each install to avoid a big mess)
Study the usefulness of a 2-pipelines way to avoid useless dependencies? -> no needs
- Check deps installed by the build script
- Check deps installed by the dockerfile
- Remove all useless deps
- Check size difference between images
- Evaluate the need of a 2-pipelines way

FILESERVER_PORT probably yes since it’s written in a config file.

SEAHUB_PORT probably not since seahub.sh isn’t started with any specific port.

Need to do some testing.

Источник

Creation of initial seafile admin fails #5

Comments