I'm trying to get the following script to run on a CentOS instance at start up on GCE.
I have the custom metadata "startup-script" set on the instance name and the following script as the value.
The script isn't executing on startup, reboot or when I run /usr/share/google/run-startup-scripts but does execute if I create it locally on the instance and execute there
What obvious thing am I missing?
#! /bin/bash
# Installs apache and a custom homepage
# 1234567 123456
#Get this servers name from the metadata server and use the header to authenticate
THIS_SERVER_NAME=$(curl http://metadata/computeMetadata/v1/instance/hostname -H "X-Google-Metadata-Request: True")
#Turn off IPtables firewall that comes installed
service iptables stop
#Install apache
yum install -y httpd
#start apache
service httpd start
#create custom default homepage for this server
cat <<EOF > /var/www/html/index.html
<html><body><h1>Hello World</h1>
<p>This is Server: $THIS_SERVER_NAME</p>
</body></html>
EOF
I was curious how's the situation with this today (6 years after original post) so I've created three VM's with CentOS 6,7 & 8 and put the startup script in place.
I used the script from the initial questions without modifications.
After VM's were created in all three cases httpd was installed and was running. Partial serial console outputs below.
Results for CentOS 6:
Installed:
httpd.x86_64 0:2.2.15-69.el6.centos
...
Complete!
Starting httpd: [ OK ]
exit status 0
Results for CentOS 7:
Installed:
httpd.x86_64 0:2.4.6-93.el7.centos
...
Complete!
centos7 systemd: Starting The Apache HTTP Server...
centos7 systemd: Started The Apache HTTP Server.
GCEMetadataScripts: startup-script exit status 0
Results for CentOS 8:
Installing:
httpd x86_64 2.4.37-21.module_el8.2.0+494+1df74eae
...
systemd[1]: Starting The Apache HTTP Server...
systemd[1]: Started The Apache HTTP Server.
GCEMetadataScripts: startup-script exit status 0
Whatever was causing the script not to run at the time this question was asked it is not the case now.
My personal experience was facing with two issues:
1) Commands that needed interaction, would not run properly on startup. For examples, apt-get install asks you to confirm the process (Y/n)? In that case, you can turn off interaction and pass "yes" by replacing
yum install foo
apt-get install foo
with
yum -y --assumeyes install foo
apt-get -y --force-yes install foo
Also, if you're using Debian, the following before any command would suppress the need for interaction:
sudo DEBIAN_FRONTEND=noninteractive <your command here, e.g., apt-get -y install foo>
2) The other obvious issue is sometimes you have to wait for the process to finish, and that may happen much later than your instance shows up as "running".
I used CentOS 7 as base image and install some libraries but it doesn't work. After switch to CentOS 6 and it works well (seems CentOS 7 has issue).
Related
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
I am trying to set up a Docker image (my Dockerfile is available here, sorry for the french README: https://framagit.org/Gwendal/firefox-icedtea-docker) with an old version of Firefox and an old version of Java to run an old Java applet to start a VPN. My image does work and successfully allows me to start the Java applet in Firefox.
Unfortunately, the said applet then tries to run the following command in the container (I've simply removed the --config part from the command as it does not matter here):
INFO: launching '/usr/bin/pkexec sh -c /usr/sbin/openvpn --config ...'
Then the applet exits silently with an error. While investigating, I've tried running a command with pkexec with the same Docker image, and it gives me this result:
$ sudo docker-compose run firefox pkexec /firefox/firefox-sdk/bin/firefox-bin -new-instance
**
ERROR:pkexec.c:719:main: assertion failed: (polkit_unix_process_get_start_time (POLKIT_UNIX_PROCESS (subject)) > 0)
But I don't know polkit at all and cannot understand this error.
EDIT: A more minimal way to reproduce the problem is with this Dockerfile:
FROM ubuntu:16.04
RUN apt-get update \
&& apt-get install -y policykit-1
And then run:
$ sudo docker build -t pkexec-test .
$ sudo docker run pkexec-test pkexec echo Hello
Which leads here again to:
ERROR:pkexec.c:719:main: assertion failed: (polkit_unix_process_get_start_time (POLKIT_UNIX_PROCESS (subject)) > 0)
Should I conclude that pkexec cannot work in a docker container? Or is there any way to make this command work?
Sidenote: I have no control whatsoever on the Java applet that I try to run, it is a horrible and very dated proprietary black box that I am supposed to use at work, for which I have no access to the source code, and that I must use as is.
I have solved my own problem by replacing pkexec by sudo in the docker image, and by allowing passwordless sudo.
Given an ubuntu docker image where a user called developer was created and configured with a USER statement, add these lines:
# Install sudo and make 'developer' a passwordless sudoer
RUN apt-get install sudo
ADD ./developersudo /etc/sudoers.d/developersudo
# Replacing pkexec by sudo
RUN rm /usr/bin/pkexec
RUN ln -s /usr/bin/sudo /usr/bin/pkexec
with the file developersudo containing:
developer ALL=(ALL) NOPASSWD:ALL
This replaces any call to pkexec made in a process running in the container, by a call to sudo without any password prompt, which works nicely.
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
I'm trying to create docker machine host using the following command in fedora OS version 25.
docker-machine create -driver=virtualbox host01
I get below error while executing the command.
Error with pre-create check: "We support Virtualbox starting with version 5. Your VirtualBox install is \"WARNING:
The vboxdrv kernel module is not loaded.
Either there is no module available for the current kernel (4.10.12-200.fc25.x86_64) or it failed to load.
Please try load the kernel module by executing as root
dnf install akmod-VirtualBox kernel-devel-4.10.12-200.fc25.x86_64 akmods --kernels 4.10.12-200.fc25.x86_64 && systemctl restart systemd-modules-load.service
You will not be able to start VMs until this problem is fixed.\\n5.1.26r117224\".
Please upgrade at https://www.virtualbox.org"
I have already virtualbox latest version installed. Running the command suggested by
sudo dnf install akmod-VirtualBox kernel-devel-4.10.12-200.fc25.x86_64 akmods --kernels 4.10.12-200.fc25.x86_64 && systemctl restart systemd-modules-load.service
I got the below error
Last metadata expiration check: 0:48:35 ago on Thu Aug 17 22:38:47 2017.
Package akmods-0.5.6-7.fc25.noarch is already installed, skipping.
No package --kernels available.
No package 4.10.12-200.fc25.x86_64 available.
Any suggestions?
I also had this problem and for this I upgrade Virtual box to 5.2 using following commands. This link help me
sudo apt-get remove virtualbox virtualbox-5.1
sudo sh -c 'echo "deb http://download.virtualbox.org/virtualbox/debian xenial contrib" >> /etc/apt/sources.list.d/virtualbox.list'
wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -
wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add -
sudo apt-get update
sudo apt-get install virtualbox-5.2
Hope this helps.
For windows users, in 2022 such problem still exists. So for those who use last build (now it is virtualBox-6.1.32-149290-Win), try to use version that starts with prefix 5. But not all '5' versions work. For example, for me worked only version 5.2.42 while versions: 5.2.18, 5.2.20, 5.2.44 didn't work
Helped for win 11 x64
I currently have similar images being built for virtualbox and digital ocean for dev and production (they're using packer and ansible to build). They're using Ubuntu 14.04.
I've created a docker version from the same scripts without any issue. This is going to be for a Gitlab CI environment.
When I come to install packages inside a container I get an error. Potentially to do with broken init systems? Something not running?
My initial command is /sbin/init and I've tried with and without phusion/base-image.
The error is msg: '/usr/bin/apt-get -y -o "Dpkg::Options::=--force-confdef" -o "Dpkg::Options::=--force-confold" install 'docker-engine'' failed: invoke-rc.d: unknown initscript, /etc/init.d/cgroup-lite not found.
dpkg: error processing package cgroup-lite (--configure):
(Yes, this is going to be a monolithic container rather than single-process and yes, I'm running docker from inside it - I'll be sharing docker.sock to make this work.)
So, I had a look at the code for invoke-rd.d and found this relevant snippet.
# If we're running on upstart and there's an upstart job of this name, do
# the rest with upstart instead of calling the init script.
if which initctl >/dev/null && initctl version | grep -q upstart \
&& [ -e "$UPSTARTDIR/${INITSCRIPTID}.conf" ]
then
is_upstart=1
elif test ! -f "${INITDPREFIX}${INITSCRIPTID}" ; then
## Verifies if the given initscript ID is known
## For sysvinit, this error is critical
printerror unknown initscript, ${INITDPREFIX}${INITSCRIPTID} not found.
if [ ! -e "$UPSTARTDIR/${INITSCRIPTID}.conf" ]; then
# If the init script doesn't exist, but the upstart job does, we
# defer the error exit; we might be running in a chroot and
# policy-rc.d might say not to start the job anyway, in which case
# we don't want to exit non-zero.
exit 100
fi
fi
A combination of docker replacing the init system, the inability to use upstart in an ubuntu docker container and the ubuntu package for cgroup-lite being built for upstart meant dpkg --configure was failing as the service couldn't be started.