Ahoj,
Dňa Mon, 16 Mar 2026 22:02:57 +0100 "Alexandre Rossi"
<[email protected]> napísal:
> https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/415799b093779922c259449a3fee77c322417a6f
I read resulted uwsgi-core.README.Debian of that PR and here are my
suggestions (attached as patch too, be free to adjust as
appropriate/nedded):
diff -u uwsgi-core.README.Debian uwsgi-core.README.Debian.new
--- uwsgi-core.README.Debian 2026-03-21 09:43:45.445511676 +0100
+++ uwsgi-core.README.Debian.new 2026-03-21 10:21:01.242001910 +0100
@@ -34,9 +34,9 @@
(aka one service per app)
-Another approach is to let systemd handle starting individual apps while taking
-advantage of systemd template unit files, and of course socket activation. Each
-app will run under its own user.
+Modern approach is to let systemd handle starting individual apps while taking
+advantage of systemd template unit files and socket activation. Each app will
+run under its own dynamic user.
Adding a new app to your system is a matter of enabling the socket and
the service. For instance, if one were to configure cgit:
@@ -58,16 +58,16 @@
plugins = 0:cgi
cgi = /usr/lib/cgit/cgit.cgi
-This will configure a socket activated uwsgi app running as www-cgit user
-and made available to the frontend HTTP server via the uWSGI protocol
-at the UNIX socket located at /var/run/uwsgi/cgit.socket .
+This will configure a socket activated uwsgi app running as www-cgit (dynamic)
+user and made available to the frontend HTTP server via the uWSGI protocol
+at the UNIX socket located at /run/uwsgi/cgit.socket .
And last, if applicable, configure your HTTP server the usual way.
-The provided template unit use `DynamicUser=yes` which locks down many
-things the uwsgi app instance can do. Here are some adjustments you might
-require. They can be implemented using a systemd unit override
-(e.g. systemctl edit uwsgi-app@<confname>.service):
+The provided template unit uses templated user `User=www-<confname>` with
+`DynamicUser=yes` which locks down many things the uwsgi app instance can do.
+Here are some adjustments you might require. They can be implemented using
+a systemd unit override (e.g. systemctl edit uwsgi-app@<confname>.service):
- Change the StateDirectory (instead of the default
`/var/lib/uwsgi/<confname>`):
@@ -91,6 +91,13 @@
[Service]
User=radicale
+ - There might be a need to restore old behaviour and use a www-data user
+ (instead of the default `www-<confname>`):
+
+ [Service]
+ User=www-data
+ DynamicUser=no
+
- You may not want to use socket activation and start uwsgi app with
system startup:
@@ -107,10 +114,10 @@
If you want to migrate from the legacy initscript provided by the uwsgi
binary package, the following manual steps are required:
- 1. Change your HTTP server to point to /var/run/uwsgi/<confname>.socket
- (instead of /var/run/uwsgi/app/<confname>/socket)
- 2. Enable and start socket unit, apply required adjustments, as described
+ 1. Enable and start socket unit, apply required adjustments, as described
in the previous section.
+ 2. Change your HTTP server to point to /run/uwsgi/<confname>.socket
+ (instead of /var/run/uwsgi/app/<confname>/socket)
3. (optional) Add the following lines to
/etc/uwsgi/apps-available/<confname>.ini to stop the instance if
not used:
@@ -121,7 +128,7 @@
Please note that:
- /etc/uwsgi/apps-enabled is not used anymore.
- - /etc/uwsgi/apps-available/default.ini settings are not used anymore,
+ - /usr/share/uwsgi/conf/default.ini settings are not used anymore,
you might want to adjust your app configuration.
Note to Debian package maintainers depending on uwsgi regarding systemd
IMO my changes are self-explanatory, if not just ask ;-)
One final note, in this readme you have:
4. (optional) apt purge uwsgi (not used anymore)
Please, for next stable, consider to rework package to have:
+ rename uwsgi package to uwsgi-sysv (or so)
+ rename uwsgi-core package to uwsgi
regard
--
Slavko
https://www.slavino.sk
--- uwsgi-core.README.Debian 2026-03-21 09:43:45.445511676 +0100
+++ uwsgi-core.README.Debian.new 2026-03-21 10:21:01.242001910 +0100
@@ -34,9 +34,9 @@
(aka one service per app)
-Another approach is to let systemd handle starting individual apps while taking
-advantage of systemd template unit files, and of course socket activation. Each
-app will run under its own user.
+Modern approach is to let systemd handle starting individual apps while taking
+advantage of systemd template unit files and socket activation. Each app will
+run under its own dynamic user.
Adding a new app to your system is a matter of enabling the socket and
the service. For instance, if one were to configure cgit:
@@ -58,16 +58,16 @@
plugins = 0:cgi
cgi = /usr/lib/cgit/cgit.cgi
-This will configure a socket activated uwsgi app running as www-cgit user
-and made available to the frontend HTTP server via the uWSGI protocol
-at the UNIX socket located at /var/run/uwsgi/cgit.socket .
+This will configure a socket activated uwsgi app running as www-cgit (dynamic)
+user and made available to the frontend HTTP server via the uWSGI protocol
+at the UNIX socket located at /run/uwsgi/cgit.socket .
And last, if applicable, configure your HTTP server the usual way.
-The provided template unit use `DynamicUser=yes` which locks down many
-things the uwsgi app instance can do. Here are some adjustments you might
-require. They can be implemented using a systemd unit override
-(e.g. systemctl edit uwsgi-app@<confname>.service):
+The provided template unit uses templated user `User=www-<confname>` with
+`DynamicUser=yes` which locks down many things the uwsgi app instance can do.
+Here are some adjustments you might require. They can be implemented using
+a systemd unit override (e.g. systemctl edit uwsgi-app@<confname>.service):
- Change the StateDirectory (instead of the default
`/var/lib/uwsgi/<confname>`):
@@ -91,6 +91,13 @@
[Service]
User=radicale
+ - There might be a need to restore old behaviour and use a www-data user
+ (instead of the default `www-<confname>`):
+
+ [Service]
+ User=www-data
+ DynamicUser=no
+
- You may not want to use socket activation and start uwsgi app with
system startup:
@@ -107,10 +114,10 @@
If you want to migrate from the legacy initscript provided by the uwsgi
binary package, the following manual steps are required:
- 1. Change your HTTP server to point to /var/run/uwsgi/<confname>.socket
- (instead of /var/run/uwsgi/app/<confname>/socket)
- 2. Enable and start socket unit, apply required adjustments, as described
+ 1. Enable and start socket unit, apply required adjustments, as described
in the previous section.
+ 2. Change your HTTP server to point to /run/uwsgi/<confname>.socket
+ (instead of /var/run/uwsgi/app/<confname>/socket)
3. (optional) Add the following lines to
/etc/uwsgi/apps-available/<confname>.ini to stop the instance if
not used:
@@ -121,7 +128,7 @@
Please note that:
- /etc/uwsgi/apps-enabled is not used anymore.
- - /etc/uwsgi/apps-available/default.ini settings are not used anymore,
+ - /usr/share/uwsgi/conf/default.ini settings are not used anymore,
you might want to adjust your app configuration.
Note to Debian package maintainers depending on uwsgi regarding systemd
