Seahub's database connection fails when LDAP-related libs are removed

Seafile Server
1

I have a mostly working Seafile setup on an Ubuntu 20.04. I could reproduce the following with the releases 8.0.3 and 8.0.5.

As suggested in the manual, I have to remove the files …/seafile-server-latest/seafile/libs/{liblber-2.4.so.2,libldap-2.4.so.2,libsasl2.so.3} to get connections to the LDAP server working.

However, with these files removed Seahub stops working and guessing from the following stack trace, it seems that the database connection doesn’t work anymore:

seahub.log

2021-05-20 17:54:58,355 [ERROR] django.request:222 log_response Internal Server Error: /
Traceback (most recent call last):
  File "/opt/seafile/seafile-server-8.0.5/seafile/lib64/python3.6/site-packages/pysearpc/named_pipe.py", line 88, in _get_transport
    transport = self._pool.get(False)
  File "/usr/lib/python3.8/queue.py", line 167, in get
    raise Empty
_queue.Empty

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/seafile/seafile-server-8.0.5/seahub/thirdpart/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/opt/seafile/seafile-server-8.0.5/seahub/thirdpart/django/utils/deprecation.py", line 93, in __call__
    response = self.process_request(request)
  File "/opt/seafile/seafile-server-8.0.5/seahub/seahub/auth/middleware.py", line 33, in process_request
    if request.user.is_authenticated and not request.user.is_active:
  File "/opt/seafile/seafile-server-8.0.5/seahub/seahub/auth/middleware.py", line 23, in __get__
    request._cached_user = get_user(request)
  File "/opt/seafile/seafile-server-8.0.5/seahub/seahub/auth/__init__.py", line 120, in get_user
    user = backend.get_user(username) or AnonymousUser()
  File "/opt/seafile/seafile-server-8.0.5/seahub/seahub/base/accounts.py", line 573, in get_user
    user = self.get_user_with_import(username)
  File "/opt/seafile/seafile-server-8.0.5/seahub/seahub/base/accounts.py", line 544, in get_user_with_import
    emailuser = ccnet_api.get_emailuser_with_import(username)
  File "/opt/seafile/seafile-server-8.0.5/seafile/lib64/python3.6/site-packages/seaserv/api.py", line 896, in get_emailuser_with_import
    return ccnet_threaded_rpc.get_emailuser_with_import(email)
  File "/opt/seafile/seafile-server-8.0.5/seafile/lib64/python3.6/site-packages/pysearpc/client.py", line 126, in newfunc
    ret_str = self.call_remote_func_sync(fcall_str)
  File "/opt/seafile/seafile-server-8.0.5/seafile/lib64/python3.6/site-packages/pysearpc/named_pipe.py", line 100, in call_remote_func_sync
    transport = self._get_transport()
  File "/opt/seafile/seafile-server-8.0.5/seafile/lib64/python3.6/site-packages/pysearpc/named_pipe.py", line 90, in _get_transport
    transport = self._create_transport()
  File "/opt/seafile/seafile-server-8.0.5/seafile/lib64/python3.6/site-packages/pysearpc/named_pipe.py", line 83, in _create_transport
    transport.connect()
  File "/opt/seafile/seafile-server-8.0.5/seafile/lib64/python3.6/site-packages/pysearpc/named_pipe.py", line 47, in connect
    self.pipe.connect(self.socket_path)
ConnectionRefusedError: [Errno 111] Connection refused

I could verify that the LDAP connection is working as I could see an imported LDAP user in the web interface after undoing the file deletion and logging in with an admin user that is stored in the database.

I have checked the permissions of seafile-server-8.0.x/runtime/seafile.sock, they’re assigned to the user that runs the processes.

What’s irritating as well is that with the library files in place Seafile logs on startup in seafile.log:

0021-05-20 18:01:58 socket file exists, delete it anyway
2021-05-20 18:01:58 ../common/seaf-utils.c(333): Use database Mysql
2021-05-20 18:01:58 http-server.c(192): fileserver: worker_threads = 20
2021-05-20 18:01:58 http-server.c(207): fileserver: fixed_block_size = 8388608
2021-05-20 18:01:58 http-server.c(222): fileserver: web_token_expire_time = 3600
2021-05-20 18:01:58 http-server.c(237): fileserver: max_indexing_threads = 1
2021-05-20 18:01:58 http-server.c(252): fileserver: max_index_processing_threads= 3
2021-05-20 18:01:58 http-server.c(274): fileserver: cluster_shared_temp_file_mode = 600
2021-05-20 18:01:58 ../common/seaf-db.c(729): Failed to connect to MySQL: Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 11
2021-05-20 18:01:58 ../common/seaf-db.c(729): Failed to connect to MySQL: Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 11
2021-05-20 18:01:58 repo-mgr.c(3661): Failed to add branch.
2021-05-20 18:01:58 seafile-session.c(406): Failed to create system default repo.
2021-05-20 18:02:02 start to serve on pipe client

in contrast to the state where the files are removed, nothing is logged at all. except for the output of seafile.sh to stdout that is captured by journald.

i’d appreciate any suggestion for further troubleshooting and a solution to overcome this situation.

2

I think the best way is to use the Docker version to avoid library-dependency issues.

3

well, we have an older installation w/o Docker that we want to upgrade from eventually when the current version has proven to work.

is there a plan to publish Seafile as Docker images only? is there a guide how a ‘classical’ installation can be migrated to a Docker based one?

5

Docker version is our direction. But we will maintain the binary versions in the mean while.

6

@daniel.pan
Please keep providing binary versions until the docker images are proven to be super stable and you can offer test results from single instances to huge cluster setups. Which is currently not the case in a long shot (sorry to say, but it is what it is). We test the docker images from time to time and well, not enterprise ready even after years since the team started providing them. They make many things more complex in terms of performance tuning and resource limits.

Thanks!