Just to share what problem I got after update of Ghost and Ubuntu 22.04
What happened:
Update of Linux (Ubuntu 22.04.3 LTS)
apt-get update
apt-get upgrade
Update of node:
Ghost update
Ghost-CLI version: 1.25.3
Error during the update and roleback
The problem
Ghost was starting but didn’t work.
Message: connect ECONNREFUSED ::1:3306
and
Bad gateway Error code 502
Fix
I found fix here:
So what you need to do is:
sudo nano /etc/hosts
Remove/comment this line from the file: - ::1
127.0.1.1 ubuntu-8gb-ash-1 ubuntu-8gb-ash-1
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
#::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
This seems to be a quick workaround if anyone face it.
2 Likes
@daniellockyer There are multiple reports recently of the same kind of IPv6 related breakage on what looks like a supported stack.
The other report recently was:
Thanks again for reply.
I am able to login MySQL with the credentials used.
Looking at IPV4, doesn’t it default to IPV6?
The trigger seems to be the same: users ran an update of either Ghost or Ubuntu and some connections start defaulting to IPv6 instead of IPv4. In turn, this fails if the right entries aren’t in /etc/hosts.
I’m not sure if:
This should be considered a regression, so Ghost should just try to default to IPv4 for now because it doesn’t need an IPv6 connection on localhost.
The behavior was intentional and desirable, so the “fix” is update some documentation.
I’m guessing it’s #1 , and there’s some place in the Ghost stack where it can be configured to explicitly keep using IPv4 for localhost connections.
1 Like
I think it’s a breaking change between node16 and node18. Further reading:
opened 09:12PM - 20 Oct 21 UTC
closed 09:36PM - 20 Oct 21 UTC
### Version
v17.0.0
### Platform
Darwin pink.local 20.6.0 Darwin Kernel Versi… on 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64
### Subsystem
_No response_
### What steps will reproduce the bug?
```js
var http = require('http')
var server = http.createServer(function (req, res) { /* ... */ })
server.listen(3000, 'localhost', function (_err) {
console.log('server listening: %s', server.address())
})
```
I'm not sure what the underlying mechanism is, but it looks to me like the resolution of "localhost" for `server.listen(PORT, HOST, ...)` and for `http.request('http://localhost/...', ...)` changed from favouring IPv4 in node v16 and earlier, to favouring IPv6. The result is some possibly confusing breakages when using IPv4 values such as `127.0.0.1` and `0.0.0.0`. For example, the following script errors with node v17, but succeeds with node v16:
```js
// example-localhost-means-which-ipv.js
var http = require('http')
var server = http.createServer(function (req, res) {
req.on('data', function (chunk) {
console.log('server req data: %s', chunk)
})
req.on('end', function () {
console.log('server req end')
res.end('pong')
})
})
// Listen on IPv4 address.
var theHost = '127.0.0.1'
server.listen(3000, theHost, function (_err) {
console.log('server listening: %s', server.address())
// GET from localhost.
var theUrl = 'http://localhost:3000/ping'
console.log('client req: GET %s', theUrl)
http.get(theUrl, function (res) {
console.log('client res:', res.statusCode, res.headers)
res.on('data', (chunk) => {
console.log('client data: %s', chunk)
})
res.on('end', () => {
console.log('client end')
server.close()
})
})
})
```
```
% node --version
v17.0.0
% node example-localhost-means-which-ipv.js
server listening: { address: '127.0.0.1', family: 'IPv4', port: 3000 }
client req: GET http://localhost:3000/ping
node:events:368
throw er; // Unhandled 'error' event
^
Error: connect ECONNREFUSED ::1:3000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16)
Emitted 'error' event on ClientRequest instance at:
at Socket.socketErrorListener (node:_http_client:447:9)
at Socket.emit (node:events:390:28)
at emitErrorNT (node:internal/streams/destroy:164:8)
at emitErrorCloseNT (node:internal/streams/destroy:129:3)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -61,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '::1',
port: 3000
}
Node.js v17.0.0
% nvm use 16
Now using node v16.11.1 (npm v8.0.0)
% node example-localhost-means-which-ipv.js
server listening: { address: '127.0.0.1', family: 'IPv4', port: 3000 }
client req: GET http://localhost:3000/ping
server req end
client res: 200 {
date: 'Wed, 20 Oct 2021 21:01:56 GMT',
connection: 'close',
'content-length': '4'
}
client data: pong
client end
```
Similarly, if we reverse things to listen on `'localhost'` and GET from `'http://[::1]:3000/ping'` (IPv6), then it fails on node v16 and passes on node v17.
As I said above, I don't know the mechanism for selecting IPv4 or IPv6. I suspect this isn't a "bug", except perhaps a lack of documentation? I don't see any mention of localhost of IPv6 in the changelog. Thanks.
### How often does it reproduce? Is there a required condition?
Everytime. While I tested mostly on macOS, I believe I was seeing this in GitHub Action tests running on linux containers.
### What is the expected behavior?
_No response_
### What do you see instead?
_No response_
### Additional information
_No response_
nodejs:master ← treysis:verbatim-true-v17
opened 08:29PM - 03 Sep 21 UTC
Switch the default from false (reorder the result so that IPv4 addresses
come b… efore IPv6 addresses) to true (return them exactly as the resolver
sent them to us.)
After having the option to manually override the default behavior, this is another attempt at changing the default behavior.
Fixes: nodejs#31566
Refs: nodejs#6307
Refs: nodejs#20710
Refs: nodejs#38099
Reissue of nodejs#31567
Reissue of nodejs#37681
Reissue of nodejs#37931
<!--
Before submitting a pull request, please read
https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md.
Commit message formatting guidelines:
https://github.com/nodejs/node/blob/HEAD/doc/guides/contributing/pull-requests.md#commit-message-guidelines
For code changes:
1. Include tests for any bug fixes or new features.
2. Update documentation if relevant.
3. Ensure that `make -j4 test` (UNIX), or `vcbuild test` (Windows) passes.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
-->
@vikaspotluri123 I agree.
The question is whether it should also be a breaking change for Ghost, or whether Ghost should smooth over the difference.
I imagine nearly everyone connecting from Ghost to MySQL via a “localhost” lookup supports IPv4 lookups and and likely already using IPv4 resolution.
For the less common case with remote databases, I’m less sure what’s ideal.
There are probably a lot more domains that have IPv4 resolution setup but not IPv6, then the other way around.
This is a place where some telemetry would be useful, to better understand how many sites break Ghost forced the resolution back to IPv4 for all DNS lookups for now. I expect it may fix more than it would break.
Yeah, I guess this is a “bug” that was introduced when Ghost added support for node18. Now that node16 is EOL’d, I guess a lot more people are running into this issue.
1 Like
Immediately, a note could be added to not upgrade to node 18 till this is sorted out, or have upgrade docs which mention the issue.
1 Like
thanks for posting this! I could not figure out why my first ghost prod install was not working and thought I was going crazy
1 Like
block
October 30, 2023, 10:56am
8
Had the same problem, solved by removing that line. Is this a long term fix or there is gonna be something else to do in the future?
This should be a long term fix, assuming major distro updates don’t override your hosts (you have to explicitly perform a major distro upgrade, and explicitly tell the upgrade utility to pick the distro-suggested version over your own)
2 Likes