Seafile community edition 9.0 is ready for test!

We are glad to announce that Seafile community edition 9.0 is ready for test!

Here are major changes in version 9.0:

  • Upgrade Django to 3.2
  • Rewrite HTTP service in seaf-server with golang and move it to a separate component (turn off by default)
  • Upgrade PDFjs to new version, support viewing of password protected PDF
  • Use database to store OnlyOffice cache keys
  • Supporting converting files like doc to docx using OnlyOffice for online editing
  • Move SERVICE_URL configuration from ccnet.conf to seahub_settings.py

The new file-server written in golang serves HTTP requests to upload/download/sync files. It provides three advantages:

  • 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.
  • Now file zipping and downloading can be done simultaneously. When zip downloading a folder, you don’t need to wait until zip is done.
  • Support rate control for file uploading and downloading.

You can turn golang file-server on by adding following configuration in seafile.conf

[fileserver]
use_go_fileserver = true

Another major change is we will no longer prepare a tarball for CentOS system.

Since 2014, Red Hat sponsored and supervised the development of the popular
enterprise-grade Linux distribution CentOS. In December 2020, CentOS 8 was announced to be the last stable release. New releases
would be made through CentOS Stream, a rolling-release distribution and
upstream development branch of Red Hat Enterprise Linux (RHEL).
Additionally, Red Hat cut official support for CentOS 8 (from 10 years) to two years with support ending Dec 31, 2021.

The CentOS install packages for existing Seafile
releases will remain available in the official repositories. If you want to
install a Seafile version released in 2022 and later, use the Docker image
which we provide for Seafile Community Edition and Professional Edition.
(Since Seafile 8.0, Docker is the recommended deployment method.) This
applies equally to CentOS clones such as RockyLinux and AlmaLinux that have
emerged since Red Hat’s December announcement.

We will also prepare a docker image for ARM based system.

13 Likes

This are some wonderful improvements! Thanks to you. Especially the last sentence provides great news!

Could you share with the community: The golang HTTP server offers significant benefits. Why is it not the default HTTP server?

Hi
I can’t login in Seahub.
I put my my user and password correct.

But i got
CSRF verify failure

Reason given for failure:

Referer checking failed - https://xxx.xxxx.de/accounts/login/?next=/ does not match any trusted origins.

In Seahub.log
[WARNING] django.security.csrf:224 log_response Forbidden (Referer checking failed - https://xxx.xxxx.de/accounts/login/?next=/ does not match any trusted origins.): /accounts/login/

Maybe issue by me.
Should work now.
Something was wrong with my apache2 config

Arg ! No more CentOS install tarball is really a bad, bad new :frowning:

3 Likes

Will you stick with CentOS despite RedHat’s change of heart with CentOS?

3 Likes

I’ve switched to AlmaLinux, which is a drop-in replacement (but Rocky, or CentOS Stream are also valid alternatives). Docker is really great for quick prototyping, but for production workload, it just makes things much more complicated, and I avoid it as far as possible. It just makes networking a mess, it consumes much (much) more disk space, makes it harder to integrate with an existing infra (I already have MySQL, memcached, nginx running), makes backup more painful etc.

3 Likes

much more disk space?

just how? this doesn’t make any sense

harder to integrate?

just point your seafile container to your existing MySQL server etc.

backups more painful?

quite the opposite

Sorry, but I think you might just not fully understand the topic… Containerization is the future. How do you think Google, Netflix, etc. run their systems? They all use Kubernetes.

When it is stable enough, we will make it default.

1 Like

@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)

2 Likes

One important thing you seem to miss is that containers are made up of layers. These layers can be shared across images. Let’s say you have two images using the same Ubuntu base image. Then this base image will only occupy storage space once. For instance, I just checked one of my nodes, which currently has 21 images stored and they only take up 5GB of space. Even if you would buy that amount of SSD storage on a cloud service, it would cost you a couple of cents per month.
By the way, I have created an unofficial docker deployment, which allows you to hook up external databases. You can find it on Github. I already have a branch for 9.0.0, which I am testing right now and release later that day.

I’m not missing the layer stuff. It’s only effective if a lot of containers are sharing the same base images (which might or might not be the case). In any case, it still consume a lot more disk space than dockerless equivalent (for seafile alone, its nearly 4GB, vs a few hundreds MB). I’ll probably also build a container with such possibility (and without nginx). But still, I really regret not having CentOS tarballs anymore.

1 Like

@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.

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.

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.

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.

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.

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

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

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

image

1 Like

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

@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.