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

docker-entrypoint.sh #1081

Closed
tarky363 opened this issue May 15, 2024 · 7 comments
Closed

docker-entrypoint.sh #1081

tarky363 opened this issue May 15, 2024 · 7 comments
Labels
deployed in reference validator Solution deployed in production
Milestone

Comments

@tarky363
Copy link

Commands in docker-entrypoint.sh are not suitable for alpine version of linux

@DanielMartinPerezdeLeon
Copy link
Collaborator

Dear @tarky363,

Thank you for pointing out this issue.

Indeed, there are some instructions docker-entrypoint.sh that are not suited to Alpine Linux.
While these commands do not affect the functionality or validation of the Docker container, we acknowledge that their presence in the file is not appropriate, so the docker-entrypoint.sh file will be updated in the next release accordingly.

Thank you for your contribution to improve the project.

Regards,

@jenriquesoriano jenriquesoriano added this to the v2024.2 milestone May 21, 2024
@stempler
Copy link

stempler commented Jul 2, 2024

What I can observe in the current alpine based image is that

  • squid won't start (ERROR: cannot start squid as hostname would not start)
  • related to that, as squid is configured by default as proxy for HTTP, requests to http:// resources fail

Does anyone else experience the same problem?

I tried to work around that by using none for the HTTP proxy, which works, at least in most cases.
But open issues still remain in some tests, for instance here:

image

The resource trying to be accessed in this example exists, but it redirects to HTTPS. The error message hints at that whatever tries to access it can't handle the redirect (hint is that the redirect response is HTML including an <hr> tag and it is tried to be loaded as XML).

Based on that it seems right now using squid is required to work around the issue that redirects are not supported at least in some cases. Any hints on how to resolve that?

Thank you!

@petbod-lm
Copy link

petbod-lm commented Jul 3, 2024

Hi,
We found the same problem yesterday - squid and apache2 services cannot be started in the container.
Investigating further we found

_/var/lib/jetty# rc-service squid start

Starting networking ...
ifquery: could not parse /etc/network/interfaces

ERROR: networking failed to start
ERROR: cannot start squid as networking would not start_

So we then created the /etc/network/interfaces file (as shown below)

/var/lib/jetty# cat /etc/network/interfaces
auto eth0

In the Dockerfile we added the following:

# Configure /etc/network/interfaces
RUN echo 'auto eth0' >> /etc/network/interfaces

Now squid and apache2 start correctly in the container.

Also be aware that the Inspire Registry is not currently available so any tests that try to download a codelist will fail as the codelist cannot be accessed.
(I have raised an issue in the Registry Helpdesk INSPIRE-MIF/helpdesk-registry#101)

Hope this helps
/Pete

@stempler
Copy link

stempler commented Jul 3, 2024

Thanks @petbod-lm for the hint!

For me it at first still failed with the hostname service:

hostname: sethostname: Operation not permitted
 * Setting hostname ... [ !! ]
 * ERROR: hostname failed to start
 * ERROR: cannot start networking as hostname would not start
 * ERROR: cannot start squid as hostname would not start

I only got it to run in my case in Kubernetes by adding a securityContext configuration for the container.

With

securityContext:
  privileged: true

both squid and apache could start, with this configuration only squid:

securityContext:
  capabilities:
    add:
      - SYS_ADMIN

Not ideal, but works for now. Not sure why that was not necessary with the previous debian based base image.

@stempler
Copy link

Both problems (hostname and networking service) remain the same for me with the current 2024.2 Docker image.

@fabiovinci fabiovinci added solved Solution developed and accepted, not yet deployed and removed under development labels Jul 12, 2024
@fabiovinci fabiovinci reopened this Jul 17, 2024
@DanielMartinPerezdeLeon
Copy link
Collaborator

Dear everyone,

We acknowledge that the issues raised by @stempler and @petbod-lm are different from the one originally reported by @tarky363.

We believe we have successfully removed the commands incompatible with the new Alpine Linux distribution from the docker-entrypoint.sh script, resolving the related errors. Therefore, we will be closing this issue.

For the issues @stempler and @petbod-lm are experiencing, please open a new issue if the problem persists with the new Docker image. These errors might be specific to your network configurations. However, if you need assistance with setting up the VALIDATOR or have any other questions, feel free to reach out to us.

Best regards,

@jenriquesoriano jenriquesoriano added the deployed in reference validator Solution deployed in production label Aug 8, 2024
@jenriquesoriano jenriquesoriano removed the solved Solution developed and accepted, not yet deployed label Aug 8, 2024
@github-project-automation github-project-automation bot moved this to Production: latest release in Validator issues Aug 28, 2024
@stempler
Copy link

For me it generally was not clear what is in the scope of the ticket, since the description is not very clear on what it covers. For me the issues mentioned also seemed to stem from the change of the base image. But in any case, now there is a new ticket for the problems with #1107

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed in reference validator Solution deployed in production
Projects
Archived in project
Development

No branches or pull requests

6 participants