that is great news!
will there also be updated linux clients in the official repo? they’re still at 8.0.7, released a year ago, and from what you write are unable to use the notification feature, thus not reducing any load.
1 Like
Hi! Thank you for your work!
Since i’ve upgrading to 10.0.1 i’ve several messages in syslog:
seafile.sh[454351]: 2023/04/11 11:51:51 http: superfluous response.WriteHeader call from main.appHandler.ServeHTTP (server.go:309)
What does it mean?
Greetings
Mario
Upgraded two servers, one went fine, the other has errors now: “502 Bad Gateway”
Log simply says:
2023/04/11 15:52:16 [error] 744#744: *559 connect() failed (111: Connection refused) while connecting to upstream, client: 100.200.100.0, server: server.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "server.com"Do you have seafile / seahub log files with some errors ? If yes, can you share the output here ?
I’m not seeing much more in mine. When I start Seafile I do see this, which I don’t see on my other server:
/opt/seafile/seafile-server-10.0.1/upgrade# /etc/init.d/seafile-server start
** Message: 16:17:00.130: seafile-controller.c(621): No seafevents.
Traceback (most recent call last):
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/bin/gunicorn”, line 5, in
from gunicorn.app.wsgiapp import run
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/gunicorn/app/wsgiapp.py”, line 9, in
from gunicorn.app.base import Application
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/gunicorn/app/base.py”, line 11, in
from gunicorn import util
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/gunicorn/util.py”, line 25, in
import pkg_resources
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/pkg_resources/init.py”, line 88, in
from pkg_resources.extern import platformdirs
File “”, line 971, in _find_and_load
File “”, line 955, in _find_and_load_unlocked
File “”, line 658, in _load_unlocked
File “”, line 571, in module_from_spec
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/pkg_resources/extern/init.py”, line 52, in create_module
return self.load_module(spec.name)
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/pkg_resources/extern/init.py”, line 37, in load_module
import(extant)
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/pkg_resources/_vendor/platformdirs/init.py”, line 5
from future import annotations
^
SyntaxError: future feature annotations is not defined
have you updated the python modules?
@daniel.pan there seems to be a small mistake in the config with:
proxy_set_header Upgrade $http_upgrade.
After i removed the backslash in \$http_upgrade everything started working fine.
Currently Linux client cannot use notification server. The websockets library we use (libwebsockets) is too old on most distributions.
what is the plan for linux clients? they’re stuck at version 8.0.7, current is 9.0.1, so linux users are already missing out on some fixes and features. the 2FA issue that the clients have with non-root installations is unsolved for one year now. how are you planning to handle this in the future? will there ever be updates to the linux clients?
1 Like
Hi drmartin,
I’ve seen that same error on one of my servers. After much research and troubleshooting, in my case upgrading from Python 3.6 to something higher (3.9 in my case) fixed the problem.
This was not super easy as my Linux distro defaults to 3.6 and upgrading to 3.9 meant manually changing the symbolic link for /usr/bin/python3 to point to python3.9 instead of the default of 3.6.
My understanding from my research is “future feature annotations” is a feature/command in pythons >= 3.7, but I’m not a python person, so I could be wrong.
The linux clients will continue to upgrade. The notification server support is disabled for Linux clients since the 3rd party library is unavailable. Other updates are not affected.
We didn’t notice the non-root 2FA problem. We’ll look into it.
1 Like
ideally, there should simply be a check for the installed version of the libwebsockets library during configure before the build. the notifiation feature could then be activated automatically depending on the result. if users manage to manually update the library, they could simply rebuild the client locally to also get that feature.
i’m looking forward to getting updated deb packages, thank you 
the changelog for seafile client 9.0.2 states it adresses an UI issue for 2FA, were you able to fix the problem i described?
however, the linux clients have still not been updated since 8.0.7, which happened one year ago. when will there be up-to-date linux clients?
It’s not fixed yet.
The debian packages will be updated recently.
Has anybody got the new notification server to work?
I’ve added the relevant blocks to my NGINX config, as described above, and the following to seafile.conf
[notification]
enabled = true
host = 127.0.0.1
port = 8083
log_level = info
jwt_private_key = 'xxx'
After restarting the docker container, if I access /notification/list/, I get “Sorry, but the requested page could not be found.” Any ideas?
I may have missed something, but I don’t see what you’re looking at this endpoint.
There is the /notification/ping endpoint you can access from your browser, which should answer {"ret": "pong"}. I suppose it’s designed to be enough to test the notification server.
Now if you want a more in depth test, you can open a websocket, for example in your browser console.
ws = new WebSocket('ws://127.0.0.1/notification')
Then generate a valid jwt token signed with your jwt_private_key (you’d better to set a dummy key without fancy characters). I used this tool (have I to say you shouldn’t copy production secrets to some random web app?) to build the token with the following payload:
{
"repo_id": "<<some repo id>>",
"username": "<<some user email>>",
"iat": 1684333194,
"exp": 2684333194
}
Then send the subscription message:
ws.send('{"type":"subscribe", "content":{"repos":[{"id":"<<same repo id>>", "jwt_token":"<<the jwt token>>"}]}}')
Edit or create some files in the library and, finally, get a notification event:
{"type":"repo-update","content":{"repo_id":"6d2bb74f-5312-4e2d-a4f9-6a4c3dd753a0","commit_id":"7e4bec64d1bb74f49b41defa6068841d7724f97e"}}
And you’re 100% sure the notification server is working fine.
1 Like
Have you checked notificationserver.log for messages?
I have the same problem tried it with the manual without success.
No pong or anything else
notification-server.log
2023/05/17 14:23:38 notification server started.
2023/05/17 14:29:14 notification server started.
2023/05/17 14:50:36 notification server started.
2023/05/17 19:29:00 notification server started.
2023/05/17 19:31:06 notification server started.
2023/05/17 19:47:47 notification server started.
nginx error log
2023/05/17 19:29:45 [error] 365884#0: *37 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 11.22.33.44, server: xxx.yyy.zz, request: “GET /notification/ping HTTP/2.0”, upstream: “http://127.0.0.1:8083/ping”, host: “xxx.yyy.zz”
2023/05/17 19:29:45 [error] 365884#0: *37 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 11.22.33.44, server: xxx.yyy.zz, request: “GET /notification/ping HTTP/2.0”, upstream: “http://127.0.0.1:8083/ping”, host: “xxx.yyy.zz”
nginx.config
location /notification/ping {
proxy_pass http://127.0.0.1:8083/ping;
access_log /var/log/nginx/notification_access.log seafileformat;
error_log /var/log/nginx/notification_error.log;
}
location /notification {
proxy_pass http://127.0.0.1:8083/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
access_log /var/log/nginx/notification_access.log seafileformat;
error_log /var/log/nginx/notification_error.log;
}
docker-compose
ports:
- "127.0.0.1:80:80"
- "127.0.0.1:8080:8080"
- "127.0.0.1:8083:8083"
Found the problem
with docker use that without the host part and it works.
Hope that helps.
[notification]
enabled = true
port = 8083
log_level = info
jwt_private_key = ‘xxx’