docker-entrypoint.sh

[tarky363]

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

[DanielMartinPerezdeLeon]

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,

[stempler]

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:

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]

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]

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.