Default node name has changed between CouchDB 3.3.2 and 3.42
- Dominant language
- Erlang
- Stars
- 7k
- Forks
- 1.1k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 9
Description
I have recently attempted to upgrade an existing 3.3.2 installation to 3.4.2 on Windows 10.
The upgrade appeared successful, but Fauxton showed "database failed to load" for all my databases.
Upon inspecting `etc/vm.args` and comparing with another PC running 3.3.2, I noticed that 3.4.2 had changed the node name to
`-name couchdb@127.0.0.1`
I changed it to `couchdb@localhost` and then could no longer log in to Fauxton (incorrect credentials, although I was definitely using the same username and password!).
Reinstalling 3.4.2 and setting my original admin user and password did not help as part of the installer did not help. Editing `local.ini` to set my admin password did not work either:
```
[admins]
admin =
```
I'm now in the process of rolling back to 3.3.2 and reinstating my databases, but I can confirm that a completely fresh install of 3.4.2 has `-name couchdb@127.0.0.1` while a completely fresh install of 3.3.2 `-name couchdb@localhost`.
Having had no problems upgrading from 3.2.2 in the past, and also checking an older machine with 3.2.2 on it having `localhost` as the node name, I would suspect it has been `localhost` for some time on 3.x
I noted that the following wiki page indicated the change from `localhost` to `127.0.0.1` for 2.x to 2.1.1 but:
a) this is not mentioned when upgrading to 3.4.x
https://docs.couchdb.org/en/stable/whatsnew/3.4.html
b) why did it go from `127.0.0.1` in 2.1.1 back to `localhost` in 3.2.x/3.3.x and now back to `127.0.0.1` again in 3.4.x?
https://docs.couchdb.org/en/latest/whatsnew/2.1.html#upgrade-notes
Contributor guide
Research direction
Start by comparing etc/vm.args and local.ini between fresh and upgraded CouchDB 3.3.2 and 3.4.2 installations on Windows 10. Read the 3.4 upgrade notes and the linked 2.1 upgrade notes, then trace how the node name relates to Fauxton database loading and authentication. Done means the version change and its upgrade impact are explained and the relevant documentation is updated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- erlang
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100