Bug#932484: isso gives 404 when started via systemd
That sounds great. On 22 November 2019 08:27:12 GMT-08:00, Jonathan Watt wrote: >Perhaps it would be best to have separate 'isso' and 'isso-multi' >systemd units? > >Additionally, is there somewhere that documents setting up Isso with >the current >unit? I guess maybe the man page (although that doesn't really contain >anything >useful right now)? How would I go about submitting changes for that?
Bug#932484: isso gives 404 when started via systemd
Perhaps it would be best to have separate 'isso' and 'isso-multi' systemd units? Additionally, is there somewhere that documents setting up Isso with the current unit? I guess maybe the man page (although that doesn't really contain anything useful right now)? How would I go about submitting changes for that?
Bug#932484: isso gives 404 when started via systemd
Ignore what I said previously. I believe I've figured out why both Tiger!P and I have been having problems. I had assumed isso would be set up for normal use. However, it appears that the systemd unit is set up for the "Multiple Sites" method documented here: https://posativ.org/isso/docs/setup/multiple-sites/ The consequences of this are that any .cfg files in /etc/isso.d/enabled must set the 'name' value in the 'general' section. The knock-on consequence of that is that any URLs to Isso files must be prefixed by that name. For example, if you set the name to "bob", then instead of: you would use: Or, if like me you are using the "Sub-URI" method (https://posativ.org/isso/docs/setup/sub-uri/) to host Isso from a "subdirectory" of your site instead of from a sub-domain, then instead of; you would use: These path changes also apply to the 'data-isso' attribute on the
Bug#932484: isso gives 404 when started via systemd
The fix seems to be trivial. I changed the arguments passed to gunicorn3 to be as recommended on the official Isso docs for gunicorn here: https://posativ.org/isso/docs/extras/deployment/#gunicorn Specifically, I changed the ExecStart line in isso.service to the following: ExecStart=/usr/bin/gunicorn3 -n gunicorn-isso -b localhost:8080 -w 4 --preload --log-file /var/log/isso/isso.log isso.run (I've no idea why Debian ships without the -b, -w and --preload args, or why it's invoking isso.dispatch instead of isso.run)
Bug#932484: isso gives 404 when started via systemd
Package: isso Version: 0.12.2-2 Severity: important Dear Maintainer, * What led up to the situation? I tried to use isso by starting is via systemd. * What exactly did you do (or not do) that was effective (or ineffective)? I started isso via systemd (systemctl start isso) which then listens on 127.0.0.1:8000 and then I tried to get the /js/embed.min.js from that process by using wget. * What was the outcome of this action? The wget resulted in a http 404. * What outcome did you expect instead? I would expect to get the embed.min.js from isso. When I start isso manually (su -s /bin/bash -l isso -c "isso -c /etc/isso.d/enabled/example.cfg") it listens on 127.0.0.1:8080 and when I do a wget to get /js/embed.min.js from that process it works. Please let me know if you need more information. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages isso depends on: ii lsb-base 10.2019051400 ii python3 3.7.3-1 ii python3-bleach3.1.0-1 ii python3-html5lib 1.0.1-1 ii python3-itsdangerous 0.24+dfsg1-2 ii python3-jinja22.10.1-1 ii python3-misaka1.0.2-5+b3 ii python3-werkzeug 0.14.1+dfsg1-4 Versions of packages isso recommends: ii gunicorn3 19.9.0-1 ii libjs-jquery 3.3.1~dfsg-3 ii libjs-underscore 1.9.1~dfsg-1 isso suggests no packages. -- no debconf information
