Installation on raspberrypi / raspbian

[pawamoy]

I'm struggling to get isso to work on my raspberry pi.

The OS is raspbian. I've been able to install it with sudo apt install isso. It installed /etc/init.d/isso which reads variables from /etc/default/isso and expects to find the config file in /etc/isso.d/enabled.

So I updated the variables in /etc/default/isso:

# Use "yes" (without quotes) to make /etc/init.d/isso start the Isso service.
# The Gunicon WSGI server is required.
START_DAEMON=yes

# IP address and TCP port used by Gunicorn
ISSO_ADDRESS_PORT=0.0.0.0:11550

# Path to load isso configuration files from.
ISSO_CONF_FILES_DIR="/etc/isso.d/enabled"

...as well as created the config file:

[general]
; database location, check permissions, automatically created if not exists
dbpath = /var/lib/isso/comments.db
; your website or blog (not the location of Isso!)
host = https://pawamoy.github.io/
[server]
listen = http://localhost:11550

I then started the service with sudo systemctl start isso.

Now when I check the gunicorn logs with tail /var/log/isso/isso.log, I see that gunicorn is "listening at http://127.0.0.1:8000". What happened? It seems gunicorn did not pick my settings telling it to listen at 0.0.0.0 :11550? Even if I setup my ports redirection on my router, since it's served at 127.0.0.1 and not at 0.0.0.0, I'll not be able to reach it from the internet.

Am I missing something?

---

I also tried this Docker image, but it was not built for an ARM system so it will not work. I could try to build the image from the isso sources by tweaking the Dockerfile maybe, but I'd like to find an easier solution 😅

I've also tried to run isso directly with isso -c /etc/isso.d/enabled/isso.cfg run, and it starts correctly, but it seems to be served at 127.0.0.1:8000 again, so will not be accessible from the internet. Is isso running the gunicorn server itself? Maybe I need to setup an nginx reverse proxy?

[jefft]

(edit: clarify suggestions)

@pawamoy, yes, the Debian packaging looks slightly broken there. Please run systemctl edit --full isso and specify the host+port to bind to with the --bind argument like this:

ExecStart=/usr/bin/gunicorn3 -n gunicorn-isso --log-file /var/log/isso/isso.log isso.dispatch --bind=localhost:11550

(incidentally, I feel this debian bug report is required reading)

@jelmer, looks like isso's Debian package systemd script needs a few tweaks:

• /etc/default/isso (isso.default) sets ISSO_CONF_FILES_DIR="/etc/isso.d/enabled", which is later used in isso.init and isso.service. isso.service then defines a second variable, ISSO_SETTINGS, to exactly the same value, used in the same way in the Python source: https://github.com/posativ/isso/blob/f4d2705d4f1b51f444d0629355a6fcbcec8d57b5/isso/dispatch.py#L54-L65. I think these variables serve the same purpose, and ISSO_CONF_FILES_DIR could simply be renamed ISSO_SETTINGS.
• Once ISSO_SETTINGS is set in /etc/default/isso, then you need two tweaks to the systemd script:
  • Replace Environment=ISSO_SETTINGS=/etc/isso.d/enabled with EnvironmentFile=/etc/default/isso
  • Use the ISSO_ADDRESS_PORT variable in the ExecStart line:

  ExecStart=/usr/bin/gunicorn3 -n gunicorn-isso --log-file /var/log/isso/isso.log isso.dispatch --bind=${ISSO_ADDRESS_PORT}
  

[pawamoy]

@jefft thank you very much, I will try that.

About the ISSO_CONF_FILES_DIR variable, it is used in the init script:

    # Exit if the configuration directory is missing.
    if [ ! -d "$ISSO_CONF_FILES_DIR" ]; then
         echo "The directory $ISSO_CONF_FILES_DIR is missing - exiting."
         exit 0
    fi

    # Exit if there are no configuation files
    [ -z "$(find "$ISSO_CONF_FILES_DIR" -maxdepth 1 -name '*.cfg')" ] && \
        echo "No configuration files found in $ISSO_CONF_FILES_DIR - exiting." && exit 0

    export ISSO_SETTINGS="$ISSO_CONF_FILES_DIR"

Maybe Isso expects ISSO_SETTINGS to actually point to a config file and not the directory it's contained in?

I also have this in the script:

    # Add IP address / TCP port for Gunicorn to listen on
    if [ -n "$ISSO_ADDRESS_PORT" ]; then
        DAEMON_ARGS="$DAEMON_ARGS --bind $ISSO_ADDRESS_PORT"
    fi

And then the DAEMON_ARGS are used here:

    start-stop-daemon --start --quiet \
        --make-pidfile \
        --pidfile $PIDFILE \
        --background \
        --exec $DAEMON -- $DAEMON_ARGS \
        || return 2

...so I don't understand why it's not already working as expected 😕

[jefft]

About the ISSO_CONF_FILES_DIR variable, it is used in the init script:

Yes it is certainly used in the systemd and sysvinit startup scripts. But ISSO_SETTINGS appears to have the same value and function, and is used in the Python code:

https://github.com/posativ/isso/blob/f4d2705d4f1b51f444d0629355a6fcbcec8d57b5/isso/dispatch.py#L54-L65

(notice it can be a directory or a config file)

So my suggestion (to the Debian maintainer -- it's unrelated to your problems) is to just use ISSO_SETTINGS everywhere. I've updated my last comment to be clearer.

And then the DAEMON_ARGS are used here:

start-stop-daemon --start --quiet \

Debian uses systemd these days, not sysvinit, so although the isso Debian package may install an /etc/init.d/isso sysvinit script, it will be completely unused. I wish they'd remove it to avoid the sort of confusion it's just caused you. Instead of /etc/init.d/isso, the relevant script is /lib/systemd/system/isso.service, which can be edited by systemctl edit --full isso.

But you've pointed out the packaging flaw: the old sysvinit script sets --bind, whereas the systemd script doesn't, and should.

[pawamoy]

Oh, okay, it's much clearer now, thank you again @jefft 🙂

[EchedelleLR]

Thank you @pawamoy for reporting this issue and @jefft for pointing the mess here.

I am newbie trying to configure Isso for first time in Debian and got into issues trying to understand how the maintainer structured and set the configs as I got the gunicorn server started but Isso didn't work.

Seems it is better to install Isso from PyPi after all.

[ix5]

@pawamoy has your issue been resolved? To my eyes, this seems like an issue with debian's packaging and as such, their bugtracker is the correct place for any further issues.
Would you mind closing this then?

[pawamoy]

I was never able to serve Isso from my Raspberry Pi (didn't try that hard, and eventually went with Utterrances), so not sure the issue is resolved, though I will not investigate more, so I guess we can close the issue.

[EchedelleLR]

@pawamoy would be better to leave it open for other people which experiment the same issue or check it and get it solved