Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange behaviour when default port binding is changed #41

Closed
Dzordzu opened this issue Jun 20, 2020 · 16 comments
Closed

Strange behaviour when default port binding is changed #41

Dzordzu opened this issue Jun 20, 2020 · 16 comments
Assignees

Comments

@Dzordzu
Copy link

Dzordzu commented Jun 20, 2020

The task ":start" ended with a failure

On server I'm using Centos8. command returned non-zero exit status 1 is reported. Naturally, container is down when :start is triggered. With the identical config, on Arch everything works fine.

Dunno if it's associated with it, but Taiga seems NOT loading ldap configuration (Error connecting to LDAP server: port must be an integer appears, even when I change it manually in the container)

@Dzordzu
Copy link
Author

Dzordzu commented Jun 20, 2020

In terms of logs, we've got no logs

@Dzordzu
Copy link
Author

Dzordzu commented Jun 20, 2020

Ok It seemed to be a changed docker port binding. I've been using 5280:80 instead of 80:80. It caused strange errors. After change to default binding everything works fine.

I'll keep this issue open, till I get to know why changing port caused such a uncommon error

@Dzordzu Dzordzu changed the title The task ":start" ended with a failure Strange behaviour when default port binding is changed Jun 20, 2020
@blackandred
Copy link
Contributor

Hi @Dzordzu, possibly Taiga expects running on 80 port, it may be set somewhere or hardcoded in the frontend part of application.
I may try to make it configurable. At first I would need to reproduce it.

@Dzordzu
Copy link
Author

Dzordzu commented Jun 21, 2020

Strange. After changing exactly a one option in .env, the entire container is corrupted. Even taking back a config doesn't work. But sourcing virtualenv file solves the issue...

@blackandred
Copy link
Contributor

I see the frontend is behaving weird, when a port is changed. I'm checking this now.

@blackandred
Copy link
Contributor

image

I managed to run it on custom port, like I said - the frontend needs to be aware of your custom port.

You need to set this variable, example: TAIGA_HOSTNAME=taiga.localhost:8002

@blackandred
Copy link
Contributor

Updated README

@blackandred
Copy link
Contributor

Regarding:

Dunno if it's associated with it, but Taiga seems NOT loading ldap configuration (Error connecting to LDAP server: port must be an integer appears, even when I change it manually in the container)

@zicklag, do you have an idea?

@Dzordzu
Copy link
Author

Dzordzu commented Jun 21, 2020

It's quite strange, because when started from virtualenv, everything works fine. It seems to be missing package or something like this. But still - I see no reason why simple docker-compose sommand fails without certain packages.

Also on my Centos8 rdk fail to start taiga. Only starting using docker-compose works

@blackandred
Copy link
Contributor

blackandred commented Jun 21, 2020

@Dzordzu Could you paste logs? 😉
RKD is used there in early release, I will bump to 1.0+. Possibly you have problems with pip packages required.

Virtual Env is recommended because it will make sure you will have proper versions of docker-compose and other libraries - in different OS'es, especially in CentOS the packages may be outdated.

@blackandred
Copy link
Contributor

And a note on RKD - we use it because it's our build system to build container manually, to build container on CI, to start project. Also inside of container we use RKD in lightweight form to eg. wait for database (RKD has a few very handy utils to use in docker containers eg. waiting for health check, waiting for database, manipulating configuration files, rendering configuraton files basing on JINJA2 templates)

@zicklag
Copy link
Contributor

zicklag commented Jun 21, 2020

Taiga seems NOT loading ldap configuration (Error connecting to LDAP server: port must be an integer appears, even when I change it manually in the container)

I don't know what that is. I'm using LDAP and just have the port set to a number in the yaml file:

  environment:
     LDAP_PORT: 12345

I'm using an older version of the container, though: quay.io/riotkit/taiga:4.2.12. I just haven't updated it in a while.

@blackandred blackandred self-assigned this Jun 21, 2020
@Dzordzu
Copy link
Author

Dzordzu commented Jun 21, 2020

@Dzordzu Could you paste logs?
RKD is used there in early release, I will bump to 1.0+. Possibly you have problems with pip packages required.

Virtual Env is recommended because it will make sure you will have proper versions of docker-compose and other libraries - in different OS'es, especially in CentOS the packages may be outdated.

In terms of logs, we've got no logs

Really. There is just an info about return code 1. And that's all

@Dzordzu
Copy link
Author

Dzordzu commented Jun 22, 2020

Taiga seems NOT loading ldap configuration (Error connecting to LDAP server: port must be an integer appears, even when I change it manually in the container)

I don't know what that is. I'm using LDAP and just have the port set to a number in the yaml file:

  environment:
     LDAP_PORT: 12345

I'm using an older version of the container, though: quay.io/riotkit/taiga:4.2.12. I just haven't updated it in a while.

@Dzordzu Dzordzu closed this as completed Jun 22, 2020
@Dzordzu Dzordzu reopened this Jun 22, 2020
@blackandred
Copy link
Contributor

You mean it's return code 1 from starting or from docker logs taiga_taiga_1? 😉

@Dzordzu
Copy link
Author

Dzordzu commented Jun 24, 2020

No, no, no. It's not a docker issue ;) It was an error during the execution of the rdk tool.
I will close this issue, because both problems seem to be resolved. On of them is fixed by upgrading the documentation, the other one, that awkward and rare, seems to be resolved by running in virtualenv.

Maybe, one day, I will get to know why the hell it's not working on my CentOS without virtenv. Then I will make pull request with solution to this, or add explanation why it wasn't working

@Dzordzu Dzordzu closed this as completed Jun 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants