Seems you have quite a few with these thread titles.
I posted details of the installation in this thread some time ago. Haven’t had time too look at it until these days.
Been looking through the other threads with similar titles but find little or nothing that helps me.
It is only local, has no remote configuration and does not access anything, that I am aware of, outside my local network.
What information can I provide to aid resolving this matter?
Hi @RCanaveral and happy new year.
Your screenshot indicates that your browser is trying to access localhost (the PC where you have opened the browser) and that it cannot find the taiga service there.
There are services in taiga that communicate with each other and can be configured using localhost because they are on the same machine. But the front-end, at least, must be configured with the public IP so that it can make the appropriate calls when it is running in the user’s web browser (and it should call the api or open a websocket connection with taiga-events).
So It’s a configuration issue. You can’t use localhost and protected ips to configure taiga(-front) installation unless taiga and your web browser are running on the same machine (a scenario that doesn’t make much sense, taiga server and your desktop pc are the same).
You are using Portainer and I have never used it. I would need to know the settings you use to try to tell you what to change. I also need to know if there is a service acting as a proxy in front of taiga and what configuration it has.
Best regards
I did not install it via Portainer. Portainer picked up the existing images and containers and allows me to read the logs and some configuration in the Portainer interface.
I use http://192.168.1.12:9000/discover for browser access. That is the IP in my network for Taiga. The server has no UI, it is Ubuntu Server 22.04 LTE, so can’t browse the site from that machine, it is a virtual machine btw. Not a “normal” desktop. (I have like 10 different applications running this way, so it is not my first time, but, of course, every application has its quirks to get them running correctly)…
There is no proxy. There is no public IP, only private local. Can you explain what IPS would be in this context?
This is my .env that is pretty much unchanged.
POSTGRES_USER=taiga # user to connect to PostgreSQL
POSTGRES_PASSWORD=taiga # database user's password
# Taiga's SMTP settings - Variables to send Taiga's emails to the users
EMAIL_BACKEND=console # use an SMTP server or display the emails in the console (either "smtp" or "console")
EMAIL_HOST=smtp.host.example.com # SMTP server address
EMAIL_PORT=587 # default SMTP port
EMAIL_HOST_USER=user # user to connect the SMTP server
EMAIL_HOST_PASSWORD=password # SMTP user's password
EMAIL_DEFAULT_FROM=changeme@example.com # default email address for the automated emails
# EMAIL_USE_TLS/EMAIL_USE_SSL are mutually exclusive (only set one of those to True)
EMAIL_USE_TLS=True # use TLS (secure) connection with the SMTP server
EMAIL_USE_SSL=False # use implicit TLS (secure) connection with the SMTP server
# Taiga's RabbitMQ settings - Variables to leave messages for the realtime and asynchronous events
RABBITMQ_USER=taiga # user to connect to RabbitMQ
RABBITMQ_PASS=taiga # RabbitMQ user's password
RABBITMQ_VHOST=taiga # RabbitMQ container name
RABBITMQ_ERLANG_COOKIE=secret-erlang-cookie # unique value shared by any connected instance of RabbitMQ
# Taiga's Attachments - Variable to define how long the attachments will be accesible
ATTACHMENTS_MAX_AGE=360 # token expiration date (in seconds)
# Taiga's Telemetry - Variable to enable or disable the anonymous telemetry
ENABLE_TELEMETRY=False
You have to make modifications to the .env variable TAIGA_DOMAIN that you have not shared (it is at the beginning of the document).
# Taiga's URLs - Variables to define where Taiga should be served
TAIGA_SCHEME=http
TAIGA_DOMAIN=192.168.1.12:9000 # HERE, the "public" IP of server who serve taiga
SUBPATH=""
WEBSOCKETS_SCHEME=ws
(...)
Then, restart the service and it should be enough.
Best regards
Sorry, I thought I copied everything …
hmm, ok that sensitive eh… despite effectively running on localhost… ah well
Na, did not help.
Which one has logs related to this that I can check?
and still this, or similar:
I noticed localhost is called in the log for taiga-docker-taiga-events-1
2024-01-01T15:48:22.890841279Z
2024-01-01T15:48:22.890874179Z > taigaio-events@6.7.0 start:production
2024-01-01T15:48:22.890882279Z > NODE_ENV=production node ./src/index.js
2024-01-01T15:48:22.890887879Z
2024-01-01T15:48:24.431814915Z INF WS server is started | service=taiga-events timestamp=2024-01-01 15:48:24
2024-01-01T15:48:24.433225331Z INF Liveness / Readiness server was started in http://localhost:3023/healthz | service=taiga-events timestamp=2024-01-01 15:48:24
2024-01-02T13:48:19.439556404Z npm notice
2024-01-02T13:48:19.439600805Z npm notice New major version of npm available! 8.19.4 -> 10.2.5
2024-01-02T13:48:19.439615205Z npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.2.5>
2024-01-02T13:48:19.439622505Z npm notice Run `npm install -g npm@10.2.5` to update!
2024-01-02T13:48:19.439628005Z npm notice
2024-01-02T13:48:19.439636005Z npm ERR! path /taiga-events
2024-01-02T13:48:19.439640905Z npm ERR! command failed
2024-01-02T13:48:19.439646005Z npm ERR! signal SIGTERM
2024-01-02T13:48:19.439651506Z npm ERR! command sh -c -- NODE_ENV=production node ./src/index.js
2024-01-02T13:48:19.469978092Z
2024-01-02T13:48:19.470022492Z npm ERR! A complete log of this run can be found in:
2024-01-02T13:48:19.470030693Z npm ERR! /taiga-events/.npm/_logs/2024-01-01T15_48_22_674Z-debug-0.log
2024-01-02T13:49:41.728481130Z Starting Taiga events
2024-01-02T13:50:08.772057739Z
2024-01-02T13:50:08.772084039Z > taigaio-events@6.7.0 start:production
2024-01-02T13:50:08.772089039Z > NODE_ENV=production node ./src/index.js
2024-01-02T13:50:08.772092439Z
2024-01-02T13:50:14.920772773Z INF WS server is started | service=taiga-events timestamp=2024-01-02 13:50:14
2024-01-02T13:50:14.922451364Z INF Liveness / Readiness server was started in http://localhost:3023/healthz | service=taiga-events timestamp=2024-01-02 13:50:14
2024-01-02T14:05:19.029098521Z npm ERR! path /taiga-events
2024-01-02T14:05:19.031265339Z npm ERR! command failed
2024-01-02T14:05:19.031725443Z npm ERR! signal SIGTERM
2024-01-02T14:05:19.031995046Z npm ERR! command sh -c -- NODE_ENV=production node ./src/index.js
2024-01-02T14:05:19.033903462Z
2024-01-02T14:05:19.034118164Z npm ERR! A complete log of this run can be found in:
2024-01-02T14:05:19.034204865Z npm ERR! /taiga-events/.npm/_logs/2024-01-02T13_50_08_459Z-debug-0.log
2024-01-02T14:05:19.662922988Z Starting Taiga events
2024-01-02T14:05:20.178462535Z
2024-01-02T14:05:20.178492835Z > taigaio-events@6.7.0 start:production
2024-01-02T14:05:20.178498735Z > NODE_ENV=production node ./src/index.js
2024-01-02T14:05:20.178502435Z
2024-01-02T14:05:20.483893370Z INF WS server is started | service=taiga-events timestamp=2024-01-02 14:05:20
2024-01-02T14:05:20.484647776Z INF Liveness / Readiness server was started in http://localhost:3023/healthz | service=taiga-events timestamp=2024-01-02 14:05:20
and what about
/taiga-docker/taiga-gateway/taiga.conf
There are several http explicit entries in that file that is not the local IP address… nor localhost.
Well, there must be a cache somewhere that makes you use the old localhost value instead of the IP.
First, test that the changes have been applied correctly. if you access to http://192.168.1.12:9000/conf.json You should see a json file with the correct api url and not localhost.
if you have seen something like
{
"api": "http://192.168.1.12:9000/api/v1/",
"eventsUrl": "ws://192.168.1.12:9000/events",
(...)
}
Try to use the “incognito mode” of your browser. The browser may not refresh the conf.json file correctly and is using the cached version. You can clean the browser cache too.
If, on the other hand, you continue to see localhost instead of the IP, there is something that is causing docker not to read the new configuration. Maybe the server has not been restarted correctly, or there are some changed values directly in the docker-compose.yml file.
Did not make any changes in the composer yml files. Could not see in your 30-minutes instructions it said anything about that.
However, the json is reporting localhost.
I am aware of browser cache and use bot Edge and Firefox as backup browsers.
json
{
"api": "http://localhost:9000/api/v1/",
"eventsUrl": "ws://localhost:9000/events",
"baseHref": "/",
"eventsMaxMissedHeartbeats": 5,
"eventsHeartbeatIntervalTime": 60000,
"eventsReconnectTryInterval": 10000,
"debug": false,
"debugInfo": false,
"defaultLanguage": "en",
"themes": ["taiga"],
"defaultTheme": "taiga",
"defaultLoginEnabled": true,
"publicRegisterEnabled": false,
"feedbackEnabled": true,
"supportUrl": "https://community.taiga.io/",
"privacyPolicyUrl": null,
"termsOfServiceUrl": null,
"maxUploadFileSize": null,
"contribPlugins": [],
"gitHubClientId": "",
"gitLabClientId": "",
"gitLabUrl": "",
"tagManager": { "accountId": null },
"tribeHost": null,
"enableAsanaImporter": false,
"enableGithubImporter": false,
"enableJiraImporter": false,
"enableTrelloImporter": false,
"gravatar": false,
"rtlLanguages": ["fa"]
}
I did not only restart Taiga, I restarted the entire server since it had some updates to kernel I made at the same time.
Events on http://192.168.1.12:9000/events tell me
Upgrade Required
Well, the json file has not been generated correctly. Try deleting the containers so that they have to be regenerated again qhen you start the service.
This process of modifying variables is something we have done many times and it has never caused this problem. Normally the modifications are applied with a restart of the taiga services.
Where is that json located, I have terminal access to the containers…
The file is at /usr/share/nginx/html/conf.json
But I recommend that you try deleting the containers first. There may be other containers with configurations with urls containing “localhost”. For example, in taiga-events (docker compose exec -it taiga-events cat /taiga-events/.env).
I am not a fan of how one has so little control over them containers and their content… and 14 containers for one application… admittedly my experience with containers is not huge, but it does not feel right.
I will wipe this if I do not find all the right places for that… and perhaps take the longer road…
Of course you can do it however you prefer, it was just a recommendation.
docker compose rm taiga-front taiga-back taiga-events taiga-protected taiga-async taiga-gateway
On the other hand, from the number of containers you mention, I think you are running 2 applications, taiga and penpot, at the same time (using launch_all.sh instead of launch_taiga.sh). It is something that has no influence at all, but you can save those containers if it is something (penpot in this case) that you are not going to use.
I hope this can help
Yes. Both. I know those are “different”.
I can just click - delete in Portainer. Easy.
