I don’t know ngix and other tech in use here but I am not sure why you would use “/” or “/;” at the end of the address.
Another minor update, but with some progress:
To have my nginx server using IPv6 I learn, from https://ma.ttias.be/enable-ipv6-connectivity-for-nginx/:
Next to:
server {
listen 443 ssl;
…add:
listen [::]:443 ssl;
The syntax for that is new to me, and a quick hunt under nginx failed me, so this is obviously another cargo-cult swing. But it works here.
So: is it now reasonable to leave the tiddlywiki side as-is, with:
[…]
host=localhost \
port=[whatever] \
[…]
…? No reason here to specify the IP version? When I hit this problem to begin with it was only because Node.JS had been updated; so, maybe, if I just tell nginx to talk v6, the change will happen automatically. Right?
Nope. Not yet anyhow. On my nginx I now have:
[…]
server {
listen 443 ssl;
listen [::]:443 ssl;
[…]
…for the relevant section of one of my TW’s, and I’ve updated Node.JS.
The relevant TW instance changes as I now expect, seems to claim it’s talking to the local network:
[…]
syncer-server-filesystem: Dispatching ‘save’ task: $:/StoryList
Serving on http://::1:8083 ← THIS PART HERE, whee
(press ctrl-C to exit)
[…]
…but, when I try to reach that instance over a web browser, I get the “bad gateway” error.
Correction, update here: when I tested the newest version of Node.JS, I had a syntax error in my nginx config file. That fixed, the newest Node.JS works.
(My latest mistake was in the nginx configs, I updated the “server” section, but not the “proxy_pass” section. The proxy_pass section is really what matters talking to Node.JS, not the “server” part.)
Latest version of Node.JS is 18.3.0, nginx is adjusted for all proxy_pass entries to use its IPv6 address:
proxy_pass http://[::]:8083/;
(that trailing “/” might be just noise, but it isn’t causing any problems currently on IPv4 or IPv6 so I’m leaving it as I found it for now.)
Minor gripe: with Node.JS updated, I do have to make that switch in all the configs for all the TW’s under the nginx config, then restart all of their sessions. I’m guessing there must be some fallback for IPv4 there, but I haven’t found it.
Other minor gripe: with the newest Node.JS in place, web sessions have gotten slow. Could improve after there have been more of them – hooray for caching. We’ll see.
LTS … Long Term Support version of Node.js. See: Releases | Node.js … Every even version number becomes an LTS version, so I don’t have to change it so often.
does --listen host=127.0.0.1 not work?
Sort of. Here’s a rundown of what happened, as I understand it:
On my setup, we updated our NodeJS instance. On this OS, that was a jump from version 14.29.3 to 18.3.0. Somewhere along the way, the NodeJS default format for web traffic changed from IPv4 to IPv6.
I didn’t see that coming, so didn’t prepare for it, and that traffic was severed.
Traffic from the client reaches the web server (nginx in this case), is passed along to a tiddlywiki instance, then handed off to node; or the other way back, node → tiddlywiki → nginx → client.
I have now learned: tiddlywiki doesn’t care directly whether we’re sending data via IPv4 or IPv6. That section of a packet doesn’t matter on the section where tiddlywiki functions. It acts (right, correct me) as a filter: watches for pieces pertinent to tiddlywiki; does whatever; and passes the results along.
Transit format of the process, however, does matter between the web server and node. Either way we have:
proxy_pass http://[ADDRESS]:[PORT];
…where “ADDRESS” refers to the IP format of the packet. “PORT” format doesn’t change from v4 to v6 – I guess – so that’s where the web server distinguishes among sets of traffic.
Since my host handles all traffic between web server and node, we can handle it on the localhost address, for example, on instance “8083”:
proxy_pass http://127.0.0.1:8083;
So far so good. Then:
With the upgrade of NodeJS, the format of the “ADDRESS” section had to change, from IPv4, “127.0.0.1”, to IPv6: still local, so simple, and any setup similar to mine should be able to use the same one…
proxy_pass http://[::]:8083;
…tweak for each instance of course.
So! Simple! Once you know what just happened.
Caveat: I haven’t found any way to do this “one wiki at a time,” since NodeJS didn’t seem to provide any switch to choose, at each transit, between IPv4 and v6. So instead we had to do all at once: take the server down; update NodeJS, tweak the proxy_pass line on each; then bring it back up again.
Hope this helps.
Detail I left out, maybe relevant, not sure:
Within the “tiddlywiki” process call, suppose we have a tiddlywiki named “foo”; format for our script calls would be something like:
tiddlywiki foo --listen host=[HOST_NAME] port=[PORT]
How we write this could vary. I think that we can leave out the “host=[…]” part entirely, if we’re able to distinguish among instances by port only. That aside, suppose we have something like:
tiddlywiki foo --listen host=127.0.0.1 port=8081
In my case this would have failed, because the “host=” format here is specific to IPv4.
I think one option is to use:
[…] host=0.0.0.0 […]
…where “0.0.0.0” is equivalent to “all”, or “any”. I haven’t tried that.
To switch to handling traffic in IPv6, we’d need, I think:
[…] host=[::] […]
…so:
tiddlywiki foo --listen host=[::] port=8081
There again I’m only guessing, BECAUSE! Luckily, the name “localhost” still works on both IPv4 and IPv6. All my calls to tiddlywiki were written that way, so I didn’t need to make any changes on any of them in the IPv4 → IPv6 project:
tiddlywiki foo --listen host=localhost port=8081
…didn’t have to change.
Corollary: if we do have a larger setup, where it makes sense to have the services and their data stored in separate hosts, using the host name in that case makes sense as well. Maybe more so; switchovers can then be handled quickly within DNS. Details left as an exercise for whoever.
@Michael_Jinks I expect that the Webmaster of a such a setup needs to determine if they are happy adapting to IPv6, reconfiguring to continue with IPv4, or ensuring a hybrid environment. this all depends on the LAN or Network it needs to operate on.
So thanks for starting us on this journey with NodeJS defaults changing to IPv6.