No address associated with hostname inside docker container - docker

I am using a customized version of Ubuntu18.04 and I have a docker container where I tried to install a .deb package for the usage of a FLIR camera. To do so I downloaded from this website the file spinnaker-2.5.0.80-Ubuntu18.04-arm64-pkg.tar.gz, as suggested for Ubuntu18.04.
I followed those instructions to install everything, which basically means the following commands:
apt-get install libusb-1.0-0
tar xvfz spinnaker-2.5.0.80-Ubuntu18.04-arm64-pkg.tar.gz
cd spinnaker-2.5.0.80-arm64
./install_spinnaker_arm.sh
During this process the first errors arose, which I could fix through the installation of iputils-ping and lsb-release inside the docker container:
apt install iputils-ping
apt install -y lsb-release
However, afterwards another error arose:
/var/lib/dpkg/tmp.ci/preinst: 28 /var/lib/dpkg/tmp.ci/preinst: errmsg: not found
dpkg: error processing archive libspinnaker_2.5.0.80_arm64.deb (--install):
new libspinnaker package pre-installation script subprocess returned error exit status 127
ping: zone2.flir.net: No address associated with hostname
Errors were encountered while processing:
libspinnaker_2.5.0.80_arm64.deb
I though it is a nework issue inside the container but I do have internet connection, which I checked through:
ping www.google.com
Does anybody has a suggestion why I am not able to install the spinnaker SDK inside my docker container? Or has an explanation for me, what "no address associated with hostname" means? I am thankfull for every hint in any direction. Maybe it is an issue because I moved my docker data folder to an external SD card?

Related

Install valgrind on ubi8-minimal docker image

I want to install valgrind on a docker container based on ubi-8 minimal image. The problem is the tool doesn't seem to be available in any packages on the microdnf repository. I tried with gcc-toolset-11-valgrind, gcc-toolset-11-gcc-11, gcc-toolset-11-gcc-c++, gcc-toolset-11-runtime, etc to see if the tool is available in any package. There should be a package available for normal rpm: gcc-toolset-11-perftools, but it isn't available.
I also tried to download valgrind by hand and execute from a volume but the dependencies are not available. Is there a easier way to get running valgrind on a ubi8-minimal docker container?
Using rpm in combination with already download packages I finally managed to install valgrind, the process was:
download valgrind package and dependencies with yum in the host machine
yum install --downloadonly --downloaddir=./valgrindDownload gcc-toolset-11-valgrind
Find out missing dependencies (gcc-toolset-11-runtime-11, and perl)
Install local packages using rpm:
rpm --install ./valgrindDownload/gcc-toolset-11-valgrind-3.17.0-6.el8.x86_64.rpm
Find out valgrind instalation directory
In my case was under /opt/rh/gcc-toolset-11/root/usr/bin/valgrind
Finally run the full command:
sudo docker run -v `pwd`:/home/<container-dir> <docker-image>:<version> /bin/bash -c "microdnf install gcc-toolset-11-runtime-11.1-1.el8.x86_64 && microdnf install perl-5.26.3-421.el8.x86_64 && rpm --install ./valgrindDownload/gcc-toolset-11-valgrind-3.17.0-6.el8.x86_64.rpm && /opt/rh/gcc-toolset-11/root/usr/bin/valgrind --show-leak-kinds=all --track-origins=yes --verbose --log-file=valgrind-out.txt command <arguments>"
Doing so, the valgrind output gets redirected to valgrind-out.txt

error with dbus and gesettings inside docker container

after using the command RUN apt-get install -y dbus building and then running the container I try to change system proxy with the command gsettings set org.gnome.system.proxy.https host 'proxy-adress' but I get the output failed to commit changes to dconf: Failed to execute child process ?dbus-launch? (No such file or directory). I assume that dbus was not installed so I check the path with whereis dbus but the output is empty. is it uninstalling itself?.

unable to verify that docker engine is installed by reaching pull rate limit

I wanted to install docker on my laptop to test and run my web applications on it's containers instead of virtual environment (I am running ubuntu desktop version 20.04 LTS and using pipenv for virtual environment). After signing up at hub.docker I went to https://docs.docker.com/engine/install/ubuntu/(hub.docker manual to install docker on ubuntu), I decided to install using the repository and typed following commands in terminal
1.sudo apt-get update
2.sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
3.curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
4.apt-key fingerprint 0EBFCD88
after running last command I got desired result which was
" pub rsa4096 2017-02-22 [SCEA]
9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88
uid [ unknown] Docker Release (CE deb) docker#docker.com
sub rsa4096 2017-02-22 [S]"
As my system is amd64 I continued by
5.sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
6.sudo apt-get update
7.sudo apt-get install docker-ce docker-ce-cli containerd.io
8.sudo docker run hello-world
then at this point I got
"Unable to find image 'hello-world:latest' locally
docker: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit.
See 'docker run --help'."
Questions
Did I do anything wrong in installation process?
How can I run to pull rate limit when I have just installed it?
Have docker correctly installed on my laptop? (when I type docker --version in terminal I get "Docker version 20.10.2, build 2291f61"
What should I do now?
I just installed docker myself and encountered the same error.
I don't think you have installed it wrong (since I'm a newbie myself I cannot confirm it 100%), but I solved this error by creating an account in docker website and then logged-in from CLI.
to create an account go to: https://www.docker.com/pricing
and then use signup for free.
To login through CLI type:
docker login -u your-username
and then it asks for your password, and then you are good to go!

Newer version of Docker gives permission errors during build

I've created a Dockerfile to install IBM Rational Rhapsody on a 32bit Ubuntu image, which builds correctly with Docker 18.03.0-ce on Windows 7 but fails with Docker 18.09.2 on a Linux Mint 19 VM (Ubuntu Bionic repos). IBM's Java-based installer throws a permissions issue, and the Docker changelogs didn't show any obvious reasons for this.
The Dockerfile up to the failing command is as follows:
FROM i386/ubuntu:xenial-20181005 AS installation
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends unzip
COPY Rhapsody812Linux.zip .
RUN unzip -qq Rhapsody812Linux.zip -d Rhapsody812Linux
RUN cd Rhapsody812Linux/disk1/im/installer.linux.gtk.x86 \
&& ./installc input install-rhapsody.xml -acceptLicense
The failure I'm seeing is:
org.eclipse.core.runtime.CoreException: Failed to create artifact table of contents at '/var/ibm/InstallationManager/installRegistry/metadata'.
...IBM's library stack trace truncated by me...
Caused by: java.io.IOException: Permission denied
at sun.nio.ch.FileChannelImpl$1.release(FileChannelImpl.java:115)
at sun.nio.ch.FileChannelImpl$SimpleFileLockTable.removeAll(FileChannelImpl.java:1024)
at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:112)
at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:108)
...IBM's library stack trace truncated by me...
ERROR: Error restoring Installation Manager state.
ERROR: Failed to create InstallRegistry metadata repository: /var/ibm/InstallationManager/installRegistry/metadata.
I found a forum post stating this can happen if /tmp isn't accessible, which it seems to be:
drwxr-xr-x 2 root root 4096 Mar 18 20:35 /tmp
I ran an Ubuntu Xenial image interactively to see what I could find out, and the installer does create /var/ibm/InstallationManager/installRegistry/metadata so I'm not sure where the permission issue is coming from.
What could be different between these Docker versions, and how can I resolve this build failure in the newer version?
After running the installer multiple times consecutively, I got a "CRIMC1086E ERROR" and found an IBM Knowledge Center entry mentioning this code. It suggests disabling the IBM Installation Manager's repository locking, which resolved the issue for me.
To disable the repository lock, add cic.repo.locking=false to config.ini. In my case, I made the following addition to my Dockerfile:
# Disable repo lock to avoid potential permissions issue when lock is released
# Experienced with Docker 18.09.2 on a Linux Mint 19 VM
RUN cd Rhapsody812Linux/disk1/im/installer.linux.gtk.x86/configuration \
&& echo 'cic.repo.locking=false' >> config.ini

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

Resources