Seafile community edition 9.0 is ready for test!

[ggogel]

@daniel.pan I have an issue with OnlyOffice after the update. When I open a document, I’m getting the “Document could not be saved.” error message. Seahub logs the following error:

2021-11-12 08:55:25,551 [ERROR] django.request:224 log_response Internal Server Error: /onlyoffice/editor-callback/
Traceback (most recent call last):
  File "/opt/seafile/seafile-server-latest/seahub/thirdpart/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/opt/seafile/seafile-server-latest/seahub/thirdpart/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
 File "/opt/seafile/seafile-server-latest/seahub/thirdpart/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/opt/seafile/seafile-server-latest/seahub/seahub/onlyoffice/views.py", line 98, in onlyoffice_editor_callback
    doc_info_from_cache = cache.get("ONLYOFFICE_%s" % doc_key)
NameError: name 'cache' is not defined

When I manually open the callback URL back to seafile .../onlyoffice/editor the response is {"error": 1}.

Can anybody reproduce this issue or is this specific to my setup? It worked with 8.0.7, without changing any configuration.

[ggogel]

Yes because the official seafile image is sadly quite bad. Hence I created my own images.

I’ve split the deployment into seahub and seafile and both images take up about 230 MB in total.

[ggogel]

I’ve found the reason:
/opt/seafile/seafile-server-latest/seahub/seahub/onlyoffice/views.py is missing this import from django.core.cache import cache

After adding it I can see status 200 in seahub log and no exception is thrown:
10.0.9.137 - - [12/Nov/2021:09:44:47 +0000] "POST /onlyoffice/editor-callback/ HTTP/1.1" 200 12 "-" "Node.js/6.13"

But OnlyOffice still can’t save and is giving the error.

[TomE991]

After update to 9.0
Im unable to write files with webdav.
I got
"PROPFIND /Cloud/hhhh.txt" length=210, depth=0, elap=0.037sec -> 404 Not Found

No issue on 8.0.7
I dont touch my Nginx config or share_name

Edit.
I have remove and add again my login in Webdav client.
Looks it works now.
Dont now what the issue was.

[Martin]

I got this error when starting Seahub:

Starting seahub at port 8000 ...
Traceback (most recent call last):
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/bin/gunicorn", line 8, in <module>
sys.exit(run())
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/app/wsgiapp.py", line 67, in run
WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]").run()
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/app/base.py", line 231, in run
super().run()
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/app/base.py", line 72, in run
Arbiter(self).run()
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/arbiter.py", line 58, in __init__
self.setup(app)
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/arbiter.py", line 118, in setup
self.app.wsgi()
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/app/base.py", line 67, in wsgi
self.callable = self.load()
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/app/wsgiapp.py", line 58, in load
return self.load_wsgiapp()
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
return util.import_app(self.app_uri)
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/gunicorn/util.py", line 359, in import_app
mod = importlib.import_module(module)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/opt/seafile/seafile-server-9.0.0/seahub/seahub/wsgi.py", line 25, in <module>
application = get_wsgi_application()
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/django/core/wsgi.py", line 12, in get_wsgi_application
django.setup(set_prefix=False)
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/django/__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/django/apps/registry.py", line 114, in populate
app_config.import_models()
  File "/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/django/apps/config.py", line 301, in import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/captcha/models   .py", line 4, in <module>
from django.utils.encoding import python_2_unicode_compatible
ImportError: cannot import name 'python_2_unicode_compatible' from 'django.utils.encoding' (/opt/seafile/seafile-server-9.0.0/seahub/thirdpart/django/utils/encoding.py)

I’m on Debian 11 - unsupported, I know - and haven’t checked for outdated python libraries yet. Just wanted to leave this as a reference if someone is experiencing the same. Will investigate further.
8.0.7 is running flawlessly on the very same server.

[TomE991]

Issue with webdav i try to loggin with mount -t davfs

  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/error_printer.py", line 51, in __call__
    app_iter = self.next_app(environ, sub_app_start_response)
  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/http_authenticator.py", line 250, in __call__
    return self.handle_basic_auth_request(environ, start_response)
  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/http_authenticator.py", line 301, in handle_basic_auth_request
    auth_value = compat.to_native(auth_value)
  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/compat.py", line 107, in to_native
    s = str(s, encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 16: invalid start byte

2021-11-13 08:53:57.525 - <140420166199040> wsgidav.error_printer       ERROR   :  Caught HTTPRequestException(HTTP_INTERNAL_ERROR)
Traceback (most recent call last):
  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/error_printer.py", line 51, in __call__
    app_iter = self.next_app(environ, sub_app_start_response)
  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/http_authenticator.py", line 250, in __call__
    return self.handle_basic_auth_request(environ, start_response)
  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/http_authenticator.py", line 301, in handle_basic_auth_request
    auth_value = compat.to_native(auth_value)
  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/compat.py", line 107, in to_native
    s = str(s, encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 16: invalid start byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/seatile/seafile-server-9.0.0/seahub/thirdpart/wsgidav/error_printer.py", line 88, in __call__
    raise as_DAVError(e)
wsgidav.dav_error.DAVError: DAVError(500 Internal Server Error: An internal server error occurred
    Source exception: ''utf-8' codec can't decode byte 0xff in position 16: invalid start byte')

2021-11-13 08:53:57.526 - <140420166199040> wsgidav.error_printer       ERROR   :  e.src_exception:
'utf-8' codec can't decode byte 0xff in position 16: invalid start byte
2021-11-13 08:53:57.526 - <140420166199040> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - (anonymous) - [2021-11-13 07:53:57] "OPTIONS /" elap=0.573sec -> 500 Internal Server Error

[jobenvil]

@daniel.pan

Move SERVICE_URL configuration from ccnet.conf to seahub_settings.py

Unfortunatedly migratiing script not working as expected. The script takes the first match for SERVICE_URL even the match is a commented one:

Example of ccnet.conf:

 [General]
 USER_NAME = myusername
 ID = <redacted>
 NAME = myname
 #SERVICE_URL = https://mydomain.de/seafile    <== LINE IS COMMENTED
 SERVICE_URL = https://cloud.mydomain.de
 ...

The commented line and not the uncommented line appears now on at the bottom of the seahub_settings.py file:

...
...
SERVICE_URL = https://mydomain.de/seafile

[jobenvil]

@Martin

I’m on Debian 11 - unsupported, I know - and haven’t checked for outdated python libraries yet. Just wanted to leave this as a reference if someone is experiencing the same. Will investigate further.
8.0.7 is running flawlessly on the very same server.

@Martin Just to share with you: fresh compilation on Debian 11 for armv7 works fine. Not having such errors starting Seahub.

[jobenvil]

@ggogel Regarding OnlyOffice-Integration: having same issue like you on the seahub logfiles and on the GUI getting following message:

@dani

@ggogel Yes, much more disk space. That’s easy to understand. Instead of installing Seafile, you’ll now install Seafile + a nearly full blown OS in the container. When you run lots of apps, like I do, it’s very noticeable.
I which I could point the container to my existing MySQL server. Unfortunatly, the container is hardcoded to use the root user, we can only pass the password via en env var. So clearly, this is not an option. Yes, I could create my own Docker based on the official image (and this would just negate most of the advantages of using a container in the first place, and would be more work than working with the tarball). Then there’s also nginx to remove etc.
Looks like you don’t know me, but you’re wrong. I perfectly understand the topic. Having advantages in containers doesn’t mean everyone should use them everywhere. And if I did want to use container, I’d build my own (based on the tarball)

@dani I understand totally your point here, regarding space, integration, environment variables, container using elevated privileges, etc.

@ggogel It’s easy to spin up a container for testing and don’t get me wrong, I use it in many applications, but not all them are secure proof integrated and what it starts as just for testing, it remains under the hook until somebody expert rise those concers and it will get amended This is pita point for containers and maintainers if they don’t create the properly environment from the beginning and educate users to follow dificult paths, but secure one, instead of the easier, but unsecure.There are tons of such issues after created dockerized applications which at somepoint afronts those concerns. I’m pro containers (well integrated with or without embebed nginx, with or w/o mariadb, unprivileged, with properly capabilities and automatically deployabel with zerotouch effort, etc) but if that is not the case, I will stick to the lightweight binary well integrated and secured solution.

[celene]

@daniel.pan

The performance is better in a high-concurrency environment and it can handle long requests. Now you can sync libraries with large number of files.

I’ve read before that 100,000 files per library is the recommended maximum.

Is the recommended maximum larger now? (If so, about how much?)

[sawdog]

None of that really makes sense. I suspect is because how that seafile dock images are crafted. That is a problem, if there is any issues with them they can be a major PITA. I digress… but it really can be overcome and shouldn’t be so hard to get beyond. If they were willing. Sounds like docker is their preferred method of some degree. I hope if they are putting work into them, there is not a repeat of what was what id worked through with v7 and 8. If we could get some traction to improve that without hardforks, it would be ideal.

[shoeper]

I also synced libraries with half a million files in older versions. May require the increase of inotify limits on Linux clients, but that’s it.

[sawdog]

I feel your pain here; I thought I had things sorted out. Those of us managing Docker images should get together and unify a baseline and see how we can push back a good solution to the team at Seafile. I don’t like having to hard fork that, but there was no alternative at the time. I suspect with release 9.0 it’ll be back to the drawing board anyhow. Maybe not.

[300481]

I like your comment.
IMHO the official container image is extremely overloaded.
It contains too much packages and layers.
I would suggest to build 2 images, one for the server, one for the hub.
They shouldn’t contain any other parts, only exactly this.
All the sophisticated scripts should be removed / replaced by very simple ones.
Other parts like the database, the webserver, the Lets Encrypt certbot etc. should run
in their own containers and MUST be removed from the Seafile container.
This makes the overall update and maintenance process much more easy
and able to automate.
And it would be the perfect preparation for a Kubernetes deployment.
See my current seafile helm chart on Artifacthub (dr300481 / seafile).
And if not Kubernetes, then at least docker compose.
It would be a dream to get this to a new level.
But I’m in time pressure, this is just my hobby.
Working together with lets say 4-8 good skilled people can make this a real success.

[ggogel]

It was relatively easy to make my Dockerfiles compatible with 9.0.0

[ggogel]

Check out ggogel/seafile-containerized on github

If you could provide your helm charts for this it would be amazing, since Kubernetes deployment is on my list but I haven’t the time for it yet. I think my Dockerfiles are very much suited for a Kubernetes deployment.

[sawdog]

I don’t have any kube stuff setup. Might be interesting to take a look at …
I’ll take a look at your Dockerfiles; I was striving for minimal and no multiple services in an image. Mine are in github/sawdog

[ggogel]

This exactly what my deployment does.

[sawdog]

@ggogel

ggogel/seafile-containerized

Quick glance - Not sure what some of you’ve got going on there. Is this your design or is it based on new stuff from seafile for Docker in 9.0?
There’s awfully lot of opinion that at first glance I wouldn’t be interested in.
I want something that is simple, should work for basic needs out of the box, but be flexible for those who want to take part and implement or use a replacement component. For example use traefik over nginx for proxy or reusing an existing proxy over having one running in the same container as seahub. etc.
I hope we’re not required to use this caddy http server. I know I saw the sync was rewritten in go – but I’d be surprised having to have that forced on users to run things.
I think by the time I saw the details mentioned related to storage I was done for the moment. I just don’t know why that’s being opinionated in Dockerfiles. Maybe I jumped to quick - but I just don’t want the tail wagging the dog. I’m using MariaDB and that sits on a ZFS filesystem – but that shouldn’t make it’s way into the Dockerfile layer unless is a default configuration or the like IMHO. I’m not sure what’s the impact of your storage bits, but if I’m spending time there, i’d rather be running on Postgresql and bag MariaDb and family
I’d be interested in your words, as my impression was docker wasn’t really to your liking – but what I saw doesn’t suggest that.

[ggogel]

It is my design, which I started with version 8.0. It doesn’t have anything to do with changes in 9.0.

Can you explain what is unclear or complicated? You simply need to take the compose file, make some changes and deploy it. The storage part, for instance, is specifically for Docker Swarm and doesn’t apply for a normal Docker Compose setup. Hence, this whole part is labeled as Additional Information, nothing is opinionated on anybody there. Those are just advice for more complicated deployments.

I don’t understand why you write me this lengthy answer instead of reading the document. For example, what you say about Nginx, is exactly what my deployment does, which is described in the first two sections.

Just read the first three sections properly…