Unable to sign up, error "Unknown error: NetworkError when attempting to fetch resource."

[CooperatusTeam]

Attempting to sign up with a new user upon first install, I get the cryptic error shown below:

The docker logs do not show any activity at all when this occurs. I'm not sure what exactly is going wrong here, but I assume it's a firewall issue, perhaps?

I see a bunch of ports configured in the compose template provided in this repo, but I haven't yet been able to find documentation about which ones are actually required to be exposed externally, or how to change them if needed (which I would probably need to do since some of them might be used by other services on my machine).

(Edit: of course, I can just change the port mappings in the compose file, but presumably the other huly service definitions would need to have those public ports passed to them as well through environment variable.)

[CooperatusTeam]

Ahh, I see the various environment variables under the front service in the compose file:

      - ACCOUNTS_URL=http://${SERVER_ADDRESS}:3000
      - REKONI_URL=http://${SERVER_ADDRESS}:4004
      - CALENDAR_URL=http://${SERVER_ADDRESS}:8095
      - GMAIL_URL=http://${SERVER_ADDRESS}:8088
      - TELEGRAM_URL=http://${SERVER_ADDRESS}:8086
      - UPLOAD_URL=/files
      - TRANSACTOR_URL=ws://${SERVER_ADDRESS}:3333
      - ELASTIC_URL=http://elastic:9200
      - COLLABORATOR_URL=ws://${SERVER_ADDRESS}:3078
      - COLLABORATOR_API_URL=http://${SERVER_ADDRESS}:3078

I'll need to spend some time on this composefile to make it easier to customize the ports without needing to edit a bunch of things. My assumption is that this is the cause of the issue here, and it'll resolve once I get these worked out to use ports I actually have free.

Also going to see if I can get everything to use subpaths instead, so I can (hopefully) expose the whole stack with a single external port.

If I have good results, maybe I'll submit a pull request; assuming y'all are open to that kind of thing?

[kokoali-bima]

Hi @CooperatusTeam , did you solve the problem? May I have information, How did you fix it?

[CooperatusTeam]

@kokoali-bima I have not yet, had to break for sleep, but I'll be fiddling with it some more today during my downtime. I'll show my work here in some way though if I figure it out!

[josselinlbe]

Yes, it would be great to simplify to test more quickly because you have to touch the docker-compose a bit.

The same goes for SSL, a few complications on my side.

[aonnikov]

@CooperatusTeam this is probably because of ports being used by other services on your machine. I assume it is accounts service (3000 port) or transactor service (3333 port).

If I have good results, maybe I'll submit a pull request; assuming y'all are open to that kind of thing?

We are open to any contributions that improve our product!

[hexblend]

@josselinlbe @CooperatusTeam if any of you guys have had a successful deployment over HTTPS please share with us the findings 🙌

[josselinlbe]

@scalipsum maybe soon on coolify https://github.com/coollabsio/coolify/issues/2543

[zaroot]

All those settings in your docker compose are mappings for the services, ie:

      - ACCOUNTS_URL=http://${SERVER_ADDRESS}:3000
      - REKONI_URL=http://${SERVER_ADDRESS}:4004
      - TRANSACTOR_URL=ws://${SERVER_ADDRESS}:3333
      - COLLABORATOR_URL=ws://${SERVER_ADDRESS}:3078
      - COLLABORATOR_API_URL=http://${SERVER_ADDRESS}:3078

and I'm only including here the ones that I consider relevant for the base product to run.

The problem you are having is that when you open the front service (main huly url) in your browser the browser does not know all those hostnames as they are only defined inside docker.

If that ${SERVER_ADDRESS} is accessible from your browser environment than you should be ok I guess.

But I'd recommend you setup a reverse proxy in front of those services so that the front service code running in your browser will be able to access all those additional services required for huly to run properly.

Long story short , try to open the "Inspect" tool in your browser and check your console and network tabs to see what URLs huly is trying to access and make sure they are reachable from the machine on which you are browsing the huly front service.

Note that by default all traffic is plain text, there's no SSL but you can fix that with the reverse proxy and if you switch to SSL make sure you also switch the websockets to SSL (ie: wss://)

You can check the branch veryCrunchy linked here that does most of this automatically.

You have an example for rev.proxy in this repo: https://github.com/hcengineering/huly-selfhost/blob/main/nginx/huly.nginx but you need to also update your docker compose to match those URLs, ie:

      - ACCOUNTS_URL=http://${SERVER_ADDRESS}/_accounts
      - REKONI_URL=http://${SERVER_ADDRESS}/_rekoni
      etc

Hope this helps

[CooperatusTeam]

Things have been very hectic for our little team, and I forgot about updating this with our changes. We ended up using caddy as a reverse proxy which terminates SSL, instead of nginx (caddy is much simpler syntax IMO), and customizing a bunch of places in the composefile such that ultimately there is only one externally exposed port (external to the compose network, that is), port 80.

I'll try to share what we've got when I can, assuming it all fits neatly into a pull request. I assume that our caddy config will be undesirable here since Huly uses nginx, but hopefully it'll be helpful to someone.

Edit: ahh, just saw #36 is linked above, sounds like it does similar things as our changes, so maybe I'll just wait longer at this point.