Starting ssh service through ENTRYPOINT not working - docker

I'm having a lot of difficulties running an linux container with SSH service on it. To skip the details, SSH is not optional, I must have it.
I installed the openssh-server with:
RUN
echo "**** Setting up openssh-server ****" &&
apt-get install -y openssh-server &&
sed -i "s|# PasswordAuthentication yes|PasswordAuthentication yes|g" /etc/ssh/sshd_config &&
mkdir /var/run/sshd
And am trying to open the service with:
ENTRYPOINT service ssh restart && bash
However it does not work. I tried in multiple way to get it started, by using CMD, by making a script that would start the service, and it's not working. What's worse is that this seems to have worked for others (pull access denied repository does not exist or may require docker login)
The image that I am using as base is ubuntu:18.04. However I switched to jre/systemd-ubuntu:18.04 as I thought the lack of systemd could prevent the service from running however that did not work either. Any suggestions what the possibly issue could be?

I managed to get my service to run, as a first advice I recommend making sure that the service runs by itself before putting it together with other services. In my case it seems the ssh service was not being started because a previous non-returning service was started which would keep the shell occupied and would not let it continue it's ENTRYPOINT execution to start the SSH.
One other thing that I had done previously and could have been part of the solution is that I manually created the folder /var/run/sshd. It seems some ssh service versions need that to exist otherwise they won't run. At this point I can't verify though if that was the only issue, as I've tried multiple solution at once.

Related

Socket bind failed while configuring apache and renderd

I am trying to build a custom map server tile server by following this tutorial on switch2osm.
Instead of using ubuntu as described in the tutorial, I am using docker for everything (postgis, apache, etc)
I am trying to build an image where apache and renderd are configured (I followed the instructions found here)
Here is my Dockerfile :
FROM httpd:2.4
RUN apt-get update && \
apt-get install -y libapache2-mod-tile renderd
RUN a2enmod tile
RUN a2enconf renderd
CMD ["renderd", "-f", "&&", "httpd-foreground"]
I keep having this error after building and creating the container :
renderd[1]: Initialising unix server socket on /run/renderd/renderd.sock
socket bind failed for: /run/renderd/renderd.sock
I know that's a user right issue but I dont see how to fix it.
Please can anyone help me solves this issue ?
I saw the same problem. I've partially resolved it by changing the owner of /run/renderd via sudo chown -R osm:osm /run/renderd
Then restarting the renderd process.
I've further tried (and failed) to make this permanent by modifying the file:
/etc/systemd/system/multi-user.target.wants/renderd.service
and specify the user there as well
[Service] ExecStart=/usr/bin/renderd -f User=osm
I do believe the above 'fix' has worked in the past, but doesn't seem to work now on Ubuntu 22.04

PHP Composer & other Docker services start-up sequence problem

sp-composer is a one-time service that builds the PHP Composer vendor volume into a volume composer; this takes a few minutes as it downloads the packages. As I (partly) understand it, dependent services in the same composer/stack file don't wait for the RUN task to complete, so they start up with an empty composer volume and they never see it subsequently as populated (for some reason).
The current work-around is an 8 second sleep in the production start-up sequence, with the Swarm stack file split into one just for Composer, and the other for the rest. Occasionally we need to increase the delay. This is of course terrible and should be fixed.
There are many posts about using a healthcheck to delaying a service based on a dependency such as a network service (e.g. a database) but sp-composer is a service that just runs and then exits.
We just need to delay the rest of the sequence starting until sp-composer has exited. It occured to me that docker wait (should?) solve half the problem, but we still need the stack file split into two parts, and two times docker stack deploy.
What is the current best practice to fix this situation?
For reference, this is the Dockerfile in question:
FROM php:7.1
RUN apt-get update \
&& DEBIAN_FRONTEND=noninteractive \
&& apt-get install -y libxml2-dev zlib1g-dev \
&& docker-php-ext-install soap zip
COPY . /composer
WORKDIR /composer
RUN php ./composer.phar install --no-dev --no-interaction --optimize-autoloader
I think the proper approach is editing the Dockerfiles of the containers that depend on the PHP Composer container so that they wait a little before running.
The easy solution would be to add sleep to the RUN command (e.g. RUN sleep 5s; entrypoint.sh).
A cleaner solution is to periodically verify inside the entrypoint script that the volume is populated correctly. Something like:
$VOLUME_POPULATED = false
while [[ $VOLUME_POPULATED != true ]]
do
# check if volume is populated
sleep 5s
done
# execute rest of command
Using either method, you won't need two Swarm files since the containers are built to wait for the prerequisites to be completed.
Also, if you are open to trying other orchestrations tools, I would suggest giving Kubernetes a try as it's de facto standard for container orchestration. In particular, init containers are built for the problem you are facing.

ngrok failing to launch

Trying to run ngrok, I get the following warning:
WARN[04-19|17:54:51] failed to get home directory, using $HOME instead err="user: Current not implemented on linux/amd64" $HOME=/root
It occurs whether I try to start a tunnel or merely run ngrok help.
If I do try to start a tunnel (e.g.: ngrok http -host-header=rewrite bilingueanglais.local:80), I get an empty screen, instead of the usual tunnel information.
It used to work fine, I'm not sure what changed. If I remember right, I got the exact same error in the past, but things went back to normal on their own. I'd then assumed the service was down.
However, this time, ngrok is clearly up but the error remains.
Environment:
Running ngrok on ubuntu:16.04 inside of Docker.
ngrok is version 2.2.8 (the latest available version at the time of posting.)
$HOME is /root
I installed Docker this way inside of my Dockerfile:
RUN apt-get install -y unzip
ADD https://bin.equinox.io/c/4VmDzA7iaHb/ngrok-stable-linux-amd64.zip /ngrok.zip
RUN set -x \
&& unzip -o /ngrok.zip -d /bin \
&& rm -f /ngrok.zip
I'm able to run ngrok on the same computer on OS X instead of Docker, but would like to get things working again for Docker.
I'm confused by the error message and also, to some extent, by the docs where it mentions $HOME. Is the issue with my path? What does ngrok expect?
Any help welcome.

Yum update fails -Centos 7 - dockerbuild

I have frequently built docker container using centos 7 as base image. But now I am getting error when I run,
RUN yum update add \
bash \
&& rm -rfv /var/cache/apk/*
ERROR:
Loaded plugins: fastestmirror, ovl
One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
Contact the upstream for the repository and get them to fix the problem.
Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
Run the command with the repository temporarily disabled
yum --disablerepo=<repoid> ...
Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable <repoid>
or
`subscription-manager repos --disable=<repoid>`
Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Cannot find a valid baseurl for repo: base/7/x86_64 Could not retrieve
mirrorlist
http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container
error was 14: curl#6 - "Could not resolve host: mirrorlist.centos.org;
Name or service not known" The command '/bin/sh -c yum update add
bash && rm -rfv /var/cache/apk/*' returned a non-zero code: 1
I also saw few resolutions to use "dhclient" but this error happens when i do docker-compose build.
I ran into this problem attempting to run the same Dockerfile, which fetched several software packages using yum, on two different platforms; one macOS, the other an Ubuntu 16.04-based Linux OS (elementaryOS Loki), both using the official packages from docker.com.
My theory is that the Linux package is just more restrictive out of the box, security-wise, than the macOS one. Maybe this is configurable with some kind of /etc/something config file, but I don't have the expertise with Docker to say for sure. EDIT: See my comment below.
What I can say is there was no additional configuration required for me on macOS (10.11 El Capitan); just docker build . worked fine, and yum processes from the Dockerfile were able to reach all the remote repositories.
In the Ubuntu-derived Linux distro, however, it was necessary to use
docker build --network host .
followed by
docker run -it --network host <image> <command>
when I wanted to run a process inside that image which required internet access.
This may be the case for other Debian-derived systems as well.
There are, of course, security considerations which need to be taken into account when allowing a long-running Docker container to communicate through the host network adapter, unrestricted, and one would do well to review the appropriate documentation in that regard.
My assumption is that for some reason network behavior in docker varies based on distribution.
Try to use:
docker run -d --net mybridge centos
or
docker network create -d bridge mybridge
docker run -d --net mybridge centos
It should start working. Or just edit /etc/hosts and add mirror address
Name: mirrorlist.centos.org
Address: 67.219.148.138
root cause of the issue is, container proxy settings were wrong. Just corrected the proxy settings at the below location and worked.
/root/.docker/config.json

initctl too old upstart check

I am trying to do a syntax check on an upstart script using init-checkconf. However when I run it, it returns ERROR: version of /sbin/initctl too old.
I have no idea what to do, I have tried reinstalling upstart but nothing changes. This is being run from within a docker container (ubuntu:14.04) which might have something to do with it.
I just ran into the same issue.
Looking in the container:
root#puppet-master:/# cat /sbin/initctl
#!/bin/sh
exit 0
I haven't tested it completly yet, but I added the following to my Dockerfile:
# Fix upstart
RUN rm -rf /sbin/initctl && ln -s /sbin/initctl.distrib /sbin/initctl
I thought this link explained it pretty good:
When your Docker container starts, only the CMD command is run. The only processes that will be running inside the container is the CMD command, and all processes that it spawns. That's why all kinds of important system services are not run automatically – you have to run them yourself.
Digging around some more, I found an official Ubuntu image containing a working version of upstart:
https://registry.hub.docker.com/_/ubuntu-upstart/

Resources