I'm new with SaltStack.
I need to install NVIDIA on minion server running CentOS 7 with SaltStack only.
In the gpu/init.sls file:
install_nvidia:
cmd.script:
- source: salt://gpu/files/NVIDIA-Linux-x86_64-375.20.run
- user: root
- group: root
- shell: /bin/bash
- args: -a
I run:
sudo salt minion_name state.apply gpu
I get the error:
...
stderr:
Error opening terminal: unknown.
...
...
Summary for minion_name
------------
Succeeded: 0 (changed=1)
Failed: 1
How can I get more verbose information about the reason it failed?
I believe it wait to user input but I don't know what
Also how can I install NVIDIA on CentOS 7 with non interactive way?
Thanks.
You can get more verbose information about why a Salt state has failed by running it locally using salt-call -l debug.
salt-call -l debug state.apply gpu
In your case, you have to be aware that installing the NVIDIA driver on Linux will require you to run the installer without a graphical session present. The simplest way to do this will be to check if you're currently in a graphical session (with systemd) and then drop do multi-user.target if so:
enter-multiuser:
cmd.run:
- name: systemctl isolate multi-user.target
- onlyif: systemctl status graphical.target
Then, you can install the NVIDIA driver silently using something like
gpu-prerequisites:
pkg.installed:
- pkgs:
- kernel-devel
download-installer:
file.managed:
- name: /tmp/NVIDIA-Linux-x86_64-375.20.run
- source: salt://gpu/files/NVIDIA-Linux-x86_64-375.20.run
install-driver:
cmd.run:
- name: /tmp/NVIDIA-Linux-x86_64-375.20.run -a -s -Z -X
- require:
- file: download-installer
- pkg: gpu-prequisites
start-graphical:
cmd.run:
- name: systemctl start graphical.target
- unless: systemctl status graphical.target
- watch:
- cmd: install-driver
Related
For the automatic testing of my code I would like to add a microk8s in my docker-compose setup for testing. Hence, I'd like to install microk8s in docker environment
I got snap running in the docker container using the following commands from the web
FROM ubuntu:18.04
ENV container docker
ENV PATH /snap/bin:$PATH
ADD snap /usr/local/bin/snap
RUN apt-get update
RUN apt-get install -y snapd squashfuse fuse
RUN systemctl enable snapd
STOPSIGNAL SIGRTMIN+3
CMD [ "/sbin/init" ]
snap script
!/bin/sh -e
while ! kill -0 $(pidof snapd) 2>/dev/null; do
echo "Waiting for snapd to start."
sleep 1
done
/usr/bin/snap $#
and building docker
docker build -t snapd .
and run
docker run --name=snapd -ti -d --tmpfs /run --tmpfs /run/lock --tmpfs /tmp --privileged -v /lib/modules:/lib/modules:ro snapd
up to here everything is fine.
However if try to install microk8s via snap it fails
snap install microk8s --classic --channel=1.18/stable
2020-04-27T14:22:39Z INFO Waiting for restart...
error: cannot perform the following tasks:
- Run install hook of "microk8s" snap if present (run hook "install": execv failed: Permission denied)
checking snap systemctl status snapd.service gives me
Apr 27 15:14:32 8985fc7fc5cb snapd[489]: helpers.go:961: cannot retrieve info for snap "microk8s": cannot find installed snap "microk8s" at revision 1341: missing file /sn
ap/microk8s/1341/meta/snap.yaml
Apr 27 15:14:33 8985fc7fc5cb snapd[489]: helpers.go:105: error trying to compare the snap system key: system-key versions not comparable
Apr 27 15:14:33 8985fc7fc5cb snapd[489]: helpers.go:961: cannot retrieve info for snap "microk8s": cannot find installed snap "microk8s" at revision 1341: missing file /sn
ap/microk8s/1341/meta/snap.yaml
Apr 27 15:14:33 8985fc7fc5cb systemd[1]: Started Snappy daemon.
Apr 27 15:15:08 8985fc7fc5cb snapd[489]: handlers.go:495: Reported install problem for "microk8s" as e11fe0c4-8899-11ea-a8e2-fa163ee63de6 OOPSID
I found a (for me) somewhat satisfying answer is to use k3s
A German description can be found here
The key is the following docker-compose.yml
version: '3'
services:
server:
image: rancher/k3s:v0.8.1
command: server --disable-agent
environment:
- K3S_CLUSTER_SECRET=somethingtotallyrandom
- K3S_KUBECONFIG_OUTPUT=/output/kubeconfig.yaml
- K3S_KUBECONFIG_MODE=666
volumes:
- k3s-server:/var/lib/rancher/k3s
# get the kubeconfig file
- .:/output
ports:
- 6443:6443
node:
image: rancher/k3s:v0.8.1
tmpfs:
- /run
- /var/run
privileged: true
environment:
- K3S_URL=https://server:6443
- K3S_CLUSTER_SECRET=somethingtotallyrandom
ports:
- 31000-32000:31000-32000
worker:
image: rancher/k3s:v0.8.1
tmpfs:
- /run
- /var/run
privileged: true
environment:
- K3S_URL=https://server:6443
- K3S_CLUSTER_SECRET=somethingtotallyrandom
volumes:
k3s-server: {}
(Just for completeness but I don't accept this answer, if so it my own but suggested by #David Maze) You can use kind Kubernetes in Docker. it was primarily developed for testing docker itself.
I built a docker image that has suricata in, but when i'm trying to run suricata, there is an error below:
3/9/2018 -- 02:58:12 - - This is Suricata version 4.0.5 RELEASE
3/9/2018 -- 02:58:12 - - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'ens33': Operation not permitted (1)
3/9/2018 -- 02:58:12 - - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'ens33': Operation not permitted (1)
3/9/2018 -- 02:58:12 - - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'ens33': Operation not permitted (1)
3/9/2018 -- 02:58:12 - - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'ens33': Operation not permitted (1)
3/9/2018 -- 02:58:12 - - all 2 packet processing threads, 4 management threads initialized, engine started.
docker images: ttbuge/suricata:4.5.2
run command: docker run -it --net=host -v $PWD/logs:/var/log/suricata ttbuge/suricata:4.5.2 suricata -i ens33
Any tips? thanks!
Try to run it with --privileged option.
For example:
docker run --privileged -it --net=host -v $PWD/logs:/var/log/suricata ttbuge/suricata:4.5.2 suricata -i ens33
I'm testing two platforms, cento-7 & ubuntu-1604. Both converge successfully. But fail during verify.
Ubuntu:
System Package apache2
✔ should be installed
Service apache2
× should be running
expected that `Service apache2` is running
Command curl localhost
✔ stdout should match /hello/i
✔ exit_status should eq 0
Port 80
✔ should be listening
Test Summary: 4 successful, 1 failure, 0 skipped
Seems strange that it fails on apache2 running but curl localhost succeeds.
I did a kitchen login
$ sudo systemctl status apache2
Failed to connect to bus: No such file or directory
so I tried
$ ps -eo comm,etime,user | grep apache2
apache2 06:34:11 root
apache2 06:34:11 www-data
apache2 06:34:11 www-data
Looks like apache2 is running.
Centos-7
System Package httpd
✔ should be installed
Service httpd
✔ should be running
Command curl localhost
✔ stdout should match /hello/i
✔ exit_status should eq 0
Port 80
× should be listening
expected `Port 80.listening?` to return true, got false
Test Summary: 4 successful, 1 failure, 0 skipped
Strange that httpd is running and curl works but not listening on port 80?
So I logged in and ran netstat
$ sudo netstat -tulpn | grep :80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 562/httpd
Here are my tests:
package_name =
service_name =
case os[:family]
when 'redhat' then 'httpd'
when 'debian' then 'apache2'
end
describe package(package_name) do
it { should be_installed }
end
describe service(service_name) do
it { should be_running }
end
describe command('curl localhost') do
its('stdout') { should match(/hello/i) }
its('exit_status') { should eq 0 }
end
describe port(80) do
it { should be_listening }
end
Here is my .kitchen.yml
---
driver:
name: docker
privileged: true
provisioner:
name: chef_zero
verifier:
name: inspec
platforms:
- name: ubuntu-16.04
- name: centos-7
driver:
platform: rhel
run_command: /usr/lib/systemd/systemd
suites:
- name: default
run_list:
- recipe[hello_world_test::default]
- recipe[hello_world_test::deps]
verifier:
inspec_tests:
- test/integration/default
attributes:
Any idea why I get the failures when it seems, to me at least, that on the test machines they are working as they should.
Thanks,
Andrew
The first one is because systemd is not set up in your Ubuntu platform. By default, kitchen-docker doesn't set up systemd support (as you can see with how you set it up for centos).
The second issue is more likely something funky with ss, which is the modern replacement for netstat. InSpec does have some fallback logic to use netspec but check out https://github.com/inspec/inspec/blob/8683c54510808462c7f3df6d92833aff3b21fe42/lib/resources/port.rb#L385-L421 and compare to your running container.
I'm trying to setup the Concourse CI locally by following the documentation. Everything goes great until I try to run a sample hello-world pipeline. The job results in this error...
runc create: exit status 1: container_linux.go:264: starting container process caused "process_linux.go:339: container init caused \"rootfs_linux.go:56: mounting \\\"/worker-state/3.8.0/assets/bin/init\\\" to rootfs \\\"/worker-state/volumes/live/a8d3b403-19e7-4f16-4a8a-40409a9b017f/volume/rootfs\\\" at \\\"/worker-state/volumes/live/a8d3b403-19e7-4f16-4a8a-40409a9b017f/volume/rootfs/tmp/garden-init\\\" caused \\\"open /worker-state/volumes/live/a8d3b403-19e7-4f16-4a8a-40409a9b017f/volume/rootfs/tmp/garden-init: permission denied\\\"\""
Looks like I'm getting a permissions error but I've double-checked that the container is running in privileged mode.
$ docker inspect --format='{{.HostConfig.Privileged}}' concourse_concourse_1
true
Docker Compose File
version: '3'
services:
concourse-db:
image: postgres
environment:
- POSTGRES_DB=concourse
- POSTGRES_PASSWORD=concourse_pass
- POSTGRES_USER=concourse_user
- PGDATA=/database
concourse:
image: concourse/concourse
command: quickstart
privileged: true
depends_on: [concourse-db]
ports: ["8080:8080"]
environment:
- CONCOURSE_POSTGRES_HOST=concourse-db
- CONCOURSE_POSTGRES_USER=concourse_user
- CONCOURSE_POSTGRES_PASSWORD=concourse_pass
- CONCOURSE_POSTGRES_DATABASE=concourse
- CONCOURSE_EXTERNAL_URL
- CONCOURSE_BASIC_AUTH_USERNAME
- CONCOURSE_BASIC_AUTH_PASSWORD
- CONCOURSE_NO_REALLY_I_DONT_WANT_ANY_AUTH=true
- CONCOURSE_WORKER_GARDEN_NETWORK
Pipeline
---
jobs:
- name: job-hello-world
public: true
plan:
- task: hello-world
config:
platform: linux
image_resource:
type: docker-image
source: {repository: busybox}
run:
path: echo
args: [hello world]
Concourse Version
$ curl http://192.168.99.100:8080/api/v1/info
{"version":"3.12.0","worker_version":"2.0"}
Other Versions
$ docker --version
Docker version 18.04.0-ce, build 3d479c0
$ docker-machine --version
docker-machine version 0.14.0, build 89b8332
$ docker-compose --version
docker-compose version 1.21.0, build unknown
$ system_profiler SPSoftwareDataType
Software:
System Software Overview:
System Version: macOS 10.13.1 (17B1003)
Kernel Version: Darwin 17.2.0
Boot Volume: OSX
While everything on the surface may look like it's up to date. It's important to note that docker-machine runs docker inside of VMs which can get stale if you're not updating them on a regular basis and Concourse needs kernel 3.19 or higher.
Running docker info can shed some light on the situation from Docker server's perspective.
What worked for me was...
$ docker-compose down
$ docker-machine upgrade
$ docker-compose up -d
I want to build a docker image from a Dockerfile. I can do this by using the bash like this:
[root#srv01 ~]# docker build -t appname/tomcat:someTag /root/Documents/myDockerfiles/tomcat
The good thing about having the image build using the bash is, that it prints to stdout what it executes step-by-step:
Step 1 : FROM tomcat:8.0.32-jre8
8.0.32-jre8: Pulling from library/tomcat
fdd5d7827f33: Already exists
...
When using Ansible in the following fashion from bash:
[root#localhost ansiblescripts]# ansible-playbook -vvvvv build-docker-image.yml:
Where the file build-docker-image.yml contains this content:
- name: "my build-docker-image.yml playbook"
hosts: myHost
tasks:
- name: "simple ping"
ping:
- name: "build the docker image"
become: yes
become_method: root
become_method: su
command: /bin/docker build -t something/tomcat:ver1 /home/docker/tomcat
#async: 1
#poll: 0
It waits for the whole build command to finish and then prints all the stdout as verbose output together in one piece.
Commenting in async:1 and poll:0 doesn't solve my problem, since it doesn't print the stdout at all.