3.5 http://box.lan/sugarizer should work if associated with the wifi, but http://192.168.0.1/sugarizer will not-- because apache proxies to http://box.lan/ which will not resolve.

@georgejhunt do you know why http://192.168.0.123/sugarizer works (also at http://10.8.0.10/sugarizer) today, and has worked to date on many if not all machines — but if I'm understanding you correctly this will no longer be possible going forward?

Building off PR #814 for Sugarizer 1.0 on RPi (and possibly also on Ubuntu 18.04 later...)

re local_vars, can you confirm the contents of /etc/iiab/config_vars.yml if present? The setting there will override the setting in vars/local_vars.yml. That has been a long standing flaw that I have argued against since the introduction of config_vars.yml

Any reason to move to proxypass in place of rewrite that has been working for wan clients since the early days of sugarizer for apache?

/opt/iiab/sugarizer-server s/b {{ sugarizer_location }}/{{ sugarizer_server_version }}
box.lan s/b {{ iiab_hostname }}.{{ iiab_domain }}
I don't understand the need to explicitly enable ipv4 as the service is bound to all addresses anyway, even if the service only shows ipv6 when viewed with netstat.

Any reason to move to proxypass in place of rewrite that has been working for wan clients since the early days of sugarizer for apache?

Excellent question. Articulating a clear and actionable guideline for all IIAB services/apps would be a fantastic end goal.

Towards giving us+all the ability to restore many memorable/mnemonic short URL's like http://box/books but usable in local languages too.

Aiming to resolve bugs like #529 = Calibre 2.x images & Calibre 3.x books unfortunately don't appear @ http://box/books and http://box/libros (but http://box:8080 works!)

@georgejhunt & @llaske do you know why Sugarizer 1.0 fails on RPi Zero W as follows?

root@box:~# systemctl restart sugarizer

root@box:~# systemctl status sugarizer
● sugarizer.service - Node.js Sugarizer Server
Loaded: loaded (/etc/systemd/system/sugarizer.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: signal) since Wed 2018-06-27 16:13:13 EDT; 2s ago
Process: 4096 ExecStart=/usr/bin/node /opt/iiab/sugarizer-server/sugarizer.js (code=killed, signal=SEGV)
Main PID: 4096 (code=killed, signal=SEGV)

Jun 27 16:13:13 box.lan systemd[1]: sugarizer.service: Failed with result 'signal'.

(The "naive" answer is of course that 512MB RAM is never enough! But I was wondering if more specific evidence of this [or other root cause explanations] might be possible...)

Sugarizer 1.0 fails to install at all on Ubuntu 18.04 — this is very unfortunate as it threatens IIAB testing (where we've made massive improvements in recent months, popularizing general testing of {MIN, MEDIUM, BIG} installations among a broadening public!) suddenly much more complicated now:

TASK [mongodb : enable services] ***********************************************
failed: [127.0.0.1] (item={u'name': u'mongodb'}) => {"changed": false, "item": {"name": "mongodb"}, "msg": "Unable to start service mongodb: Warning: The unit file, source configuration file or drop-ins of mongodb.service changed on disk. Run 'systemctl daemon-reload' to reload units.\nJob for mongodb.service failed because the control process exited with error code.\nSee "systemctl status mongodb.service" and "journalctl -xe" for details.\n"}

Conclusion: Even if there's no immediate fix, let's look hard into even rudimentary workaround(s) for the above !

Another Sugarizer 1.0 issue — possibly affecting Debian 9 only: #869

FYI a prototype of Sugarizer 1.0+ was manually installed on IIAB 6.6/master and has now been demonstrated (on Ubuntu 18.04/Server (#814 (comment)) using "intranet" URL's like http://192.168.0.x:8089

Clean/compact/mnemonic URL's that teachers and students are used to from Sugarizer 0.9 still aren't working (http://192.168.0.x/sugarizer) but at least we're a whole lot closer now-

Clean/compact/mnemonic URL's that teachers and students are used to from Sugarizer 0.9 still aren't working (http://192.168.0.x/sugarizer) but at least we're a whole lot closer now

Creating a http://x.x.x.x/sugarizer alias to http://x.x.x.x:8089 is very easy with Nginx. I'm doing similar thing on the server.sugarizer.org server. See below the Nginx setting file that should do that:

server {
       listen 80;
       server_name _;
       location /sugarizer {
               proxy_pass http://localhost:8080;
       }
}

Same thing should be doable with Apache redirection if you don't have Nginx installed.

@georgejhunt mentioned in our July call that this can be closed if it's no longer relevant.

FYI its techniques might still be relevant for #923 "Failing URL's—parent tkt to consolidate diverse issues"

@tim-moody, @jvonau, @arky this was rebased to current master — plz review and let us know if this appears to solve most all issues with http://box/sugarizer, Thanks!

@georgejhunt as you hoped this would work, here is what I tried on IIAB 6.6/master on Ubuntu 18.04:

git checkout -b georgejhunt-izer master
git pull https://github.com/georgejhunt/iiab.git izer
./runrole sugarizer
systemctl restart apache2

The result is that http://box/sugarizer now does (kind of!) load, with the word "Sugarizer" appearing as the title of an all white (blank) web page, attached here: sugarizer-blank.html.txt

Rebooting did not help. You can log in and also see the very same page live here: http://10.8.0.38

What else should we try?

@georgejhunt I tried your latest from 15min ago, again on IIAB 6.6/master on Ubuntu 18.04, using:

git checkout -b georgejhunt-izer master
git pull https://github.com/georgejhunt/iiab.git izer
./runrole sugarizer
systemctl restart apache2

http://10.8.0.38/sugarizer then fails as follows:

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.4.29 (Ubuntu) Server at 10.8.0.38 Port 80

Worse, this seems to have broken Sugarier, with http://10.8.0.38:8089 no longer loading anything at all !?

(Feel free to intervene directly, to hopefully recover 10.8.0.38 here :-)

PS @georgejhunt feel free to reboot 10.8.0.38 as nec.

@georgejhunt: @jvonau asks...

wonder if localhost would work in place of box.lan in the apache config file

wonder if localhost would work in place of box.lan in the apache config file

I've confirmed the above works after changing both instances (of box.lan over to localhost) in roles/sugarizer/templates/sugarizer.conf

So I'm going to go ahead and change the PR now and then merge — hope that's OK with you @georgejhunt ?

Fantastic that we have something that works now after 4 tough months, which is really tremendous. (And if anything needs to be fixed or cleaned up after merging, please let us all know!)

Tested on Ubuntu 18.04 and Raspbian.

Fixes #898 sufficiently for now — let's improve later en route!