During deployment, I am trying to install a package.
It works fine on some environment and does not work on others.
I added a flag, that will get the value True when I'm on one of the problematic environments, and I want it to add the tag --allow-unauthenticated when the flag is on, I found out that when I install it that way manually, the problem is solved, now I need to happen automatically.
This is the command that makes it work proparly when installing manually:
sudo salt <minion name> cmd.run "sudo apt-get -y --allow-unauthenticated install zabbix-agent"
This is the package installation during deployment:
zabbix-agent-installed:
pkg.installed:
- name: zabbix-agent
- zabbix-agent: '>=4.0.0'
- ignore_epoch: True
<Add here>:
{% if flag == 'True' %}
- ** allowing unauthenticated syntax **
{% endif %}
- require:
- pkgrepo: zabbix-agent-repo-added
what is the right way to do it there?
Have you tried the skip_verify option?
- skip_verify: True
skip_verify (bool) -- Skip the GPG verification check for the package to be installed
--allow-unauthenticated
Ignore if packages can't be authenticated and don't prompt about it.
If that doesn't work, then you need to convert the pkg.installed state into a cmd.run state so that you can give the extra arguments for apt-get.
I should add that skipping verification checks is dangerous and you should fix the cause of the verification failures instead of skipping the check.
Related
I'm attempting to edit the yum.repos.d file in order to disable unwanted repos and enable wanted repos without using the vi editor. Each time I use the method I know of it fails to make the changes. Does anyone know what I'm missing?
See Below:
yum-config-manager --disable \therepoid,anotherrepoid
Note: I'm not executing this from the yum.repos.d directory
First you need to run the command as root
Then you should get the list of repos:
yum repolist all
And then you can enable or disable particular repo(s) by repo_id from previous command
yum-config-manager --enable repo_id
For reference you can use RedHat documentation
When using VirtualBox with a Centos6 image I cannot do yum udpate anymore, I have checked on the internet and it looks that Centos6 is deprecated.
[root#centos69 ~]# yum makecache
Failed to set locale, defaulting to C
Loaded plugins: fastestmirror, refresh-packagekit, security
Determining fastest mirrors
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/repo/arch combination/
removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/base/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: base
[root#centos69 ~]# yum update
Failed to set locale, defaulting to C
Loaded plugins: fastestmirror, refresh-packagekit, security
Setting up Update Process
Loading mirror speeds from cached hostfile
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/repo/arch combination/
removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/base/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: base
There could be two possible solutions to solve this issue:
Edit the CentOS-Base.repo file with vim
vim /etc/yum.repos.d/CentOS-Base.repo
Delete or comment every line that starts with 'mirrorlist'.
And add the following line to every [section] of the file like [base], [updates]...
baseurl=https://vault.centos.org/6.10/os/$basearch/
Another solution could be running this command on an image that comes from this repo https://vault.centos.org/
/scripts/autorepair centos6_base_repo_is_no_more
More information about these solutions:
https://support.cpanel.net/hc/en-us/articles/360058490254--CentOS-6-End-of-Life-Notice
https://forums.cpanel.net/threads/yumrepo-error-and-cannot-find-valid-baseurl.682465/
Yes, like red hat 6.x centos 6 did go EOL in november 2020, hope you don't have anything sensitive stuff in that vm.
https://forums.centos.org/viewtopic.php?t=72710
You can change to use the vault at vault.centos.org. First you should disable any repo that no longer work. You can get a list of repos with
yum repolist
then you can disable them with
yum-config-manager --disable {reponame} {reponame}
like
yum-config-manager --disable base update
or just disable all of them
yum-config-manager |grep ^\\[|tr -d ']['|xargs yum-config-manager --disable
Once the broken repos are disabled you need to add the vault repo.
yum-config-manager --add-repo=https://vault.centos.org/6.10/os/x86_64/
After that you can install packages as needed but remember - it's no updates to anything so if security is a concern you need to change os to something newer that is supported.
followed this post and it worked.
https://www.getpagespeed.com/server-setup/how-to-fix-yum-after-centos-6-went-eol
The alternative method in the post:
vi /etc/yum.repos.d/CentOS-Base.repo
and replace the content with this:
[C6.10-base]
name=CentOS-6.10 - Base
baseurl=http://vault.epel.cloud/6.10/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=1
metadata_expire=never
[C6.10-updates]
name=CentOS-6.10 - Updates
baseurl=http://vault.epel.cloud/6.10/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=1
metadata_expire=never
[C6.10-extras]
name=CentOS-6.10 - Extras
baseurl=http://vault.epel.cloud/6.10/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=1
metadata_expire=never
[C6.10-contrib]
name=CentOS-6.10 - Contrib
baseurl=http://vault.epel.cloud/6.10/contrib/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=0
metadata_expire=never
[C6.10-centosplus]
name=CentOS-6.10 - CentOSPlus
baseurl=http://vault.epel.cloud/6.10/centosplus/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=0
metadata_expire=never
I wrote a small test project for Singularity Compose, consisting of a small server application, with the following YAML file:
version: "1.0"
instances:
server:
build:
context: ./server
recipe: server.recipe
ports:
- 9999:9999
When I call singularity-compose build, it successfully builds server.sif. Calling singularity-compose up also seemingly works without error, and calling singularity-compose ps results in something that looks just fine:
+ singularity-compose ps
INSTANCES NAME PID IMAGE
1 server 4176911 server.sif
However, the server application does not work, calling my test client results in it saying that there is no answer from the server.
But if I run server.sif directly without compose, everything works just fine.
Also, I tripple checked, my test application listens to port 9999, thus should be reachable from the outside.
What did I do wrong?
Edit:
I also checked whether there actually is any process listening at port 9999 by calling sudo lsof -i -P -n | grep LISTEN, this is not the case. Only when I manually start server.sif without compose it shows me the process listening.
Edit:
I went into the Singularity Compose shell and tried to start the Server application directly in there, just as a test, and it resulted in Permission denied. Not sure if that means anything.
Edit:
I now gave the application execution rights within the shell and called in there, this works. Am now trying to add execution rights in the recipe. If that works, it would be kind of strange, as the executable was build right there, and thus should already have execution rights.
Edit:
I added chmod +x in my recipe both after building Server and before executing it. Doesn't work either.
Also checked whether any bridges exist using brctl show, this is not the case.
Edit: My recipe, adjusted by the input of tsnowlan in his answer below:
Bootstrap: docker
From: ubuntu:20.04
%files
connection.cpp
connection.h
main.cpp
server.cpp
server.h
server.pro
%post
# get some basics
apt update
apt-get install -y wget
apt-get install -y software-properties-common
# get C++ compiler
apt-get install -y g++
apt-get install -y build-essential
apt-get install -y build-essential cmake
# get Qt
apt-get install -y qt5-default
# compile
qmake
make
ls
%runscript
/Server
%startscript
/Server
Again, note that the application works just fine both when compiled and startet normally and when started within a Singularity image (but without Singularity Compose).
The ls at the end of the %post block is used to verify that the Server application was build successfully.
Please share the server.recipe, as it is difficult to identify should be/is happening without it.
Without having that, my guess is that you have a %runscript in your definition file, but no %startscript. When the image is executed directly or via singularity run image.sif, the contents of %runscript determine what happens. To emulate the docker-compose style, the singularity images are started as persistent instances. In this case, the %startscript block determines what runs. If it is empty, it will just start up and sit there doing nothing. This would explain why when run by hand it works but not when using compose.
On my Gitlab CI / CD, I have a terraform code that requires Python installed to use an external module.
When running terraform plan via Gitlab pipelines, I get the following error:
module.notify_slack.module.lambda.data.aws_caller_identity.current[0]: Refreshing state...
Error: can't find external program "python3"
on .terraform/modules/notify_slack.lambda/terraform-aws-lambda-1.6.0/package.tf line 3, in data "external" "archive_prepare":
3: data "external" "archive_prepare" {
ERROR: Job failed: exit code 1
What image do I need to use that contains Terraform and Python? Will I need to create my own docker image?
I know this is a bit of an old post, but I'll share my solution in case anyone else stumbles upon this problem too.
Choose an existing python image and install terraform manually - this seems to me to be the easiest solution, if pragmatism is important to you.
This is the relevant section of my .gitlab-ci.yml file:
default:
image: python:latest
before_script:
- python -V # Display version for debugging purposes only
- apt-get update -y
- apt-get install unzip wget -y
- wget https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip
- unzip terraform_${TERRAFORM_VERSION}_linux_amd64.zip
- mv terraform /usr/local/bin/
- terraform --version # Display version for debugging purposes only
The environment variable was set up in the GitLab CI/CD settings, otherwise just change it for the specific version of Terraform you want.
I was pleasantly surprised at the speed in which this installation takes place, as this clearly isn't an optimal way to do it - the best performing runner will probably use your own custom image with all of your required dependencies pre-installed - I'll leave you to decide whether its worth it for your own purposes. Nonetheless, this solution doesn't appear to be prohibitively slow.
I try to install dropbox on Centos8, however Terminal gives strange errors. Tried different commands, same error.
Firstly downloaded *.rpm file from dropbox website, currently trying to install it.
Commands I tried:
rpm -ivh nautilus-dropbox-2020.03.04-1.fedora.x86_64.rpm
yum localinstall nautilus-dropbox-2020.03.04-1.fedora.x86_64.rpm
Error:
Last metadata expiration check: 0:18:27 ago on Thu 12 Mar 2020 03:46:17 PM EET
Error:
Problem: conflicting requests
nothing provides libgnome >= %{gnome_version} needed by nautilus-dropbox-2020.03.04-1.fc21.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root#localhost Downloads]
Also tried --skip-broken and --nobest - but no luck.
Also tried sudo yum install libgnome but it gives error:
Last metadata expiration check: 9:51:39 ago on Thu 12 Mar 2020 02:42:06 PM UTC.
No match for argument: libgnome
Error: Unable to find a match: libgnome
I have:
[adminuser#localhost ~]$ cat /etc/centos-release
CentOS Linux release 8.1.1911 (Core)
Tried to google this mistake, but no luck. Could you please give me any hint how I could overcome this?
Thank you
This is a bug in packaging. Contact Dropbox support and report it as a bug.
Technical details (just in case you are Dropbox employee):
During building rpm, when you use macro then it is expanded. Try yoursel:
$ rpm --eval '%{_bindir}'
/usr/bin
However, when the macro is not defined, you get original value:
$ rpm --eval '%{some_bullshit}'
%{some_bullshit}
So the macro gnome_version should likely contain some version, but this macro was not defined.
nothing provides libgnome
"libgnome" is about libgnome-2 → https://linux.dropbox.com/fedora/ → I.e. Fedora only packages. CentOS 8 has no libgnome* available.
https://www.dropbox.com/install-linux → Compile from source → CentOS 8
# dnf install nautilus-devel-3.28.1-10.el8.x86_64 python3-docutils
tar xvf nautilus-dropbox-2020.03.04.tar.bz2
cd nautilus-dropbox-2020.03.04/
./configure && make
# make install
Result : nautilus-dropbox-2020.03.04-1.el8.x86_64.rpm https://drive.google.com/file/d/1AcxlVdbWOzQvcoVOFYCiaVny9MzgC-Ea/view?usp=sharing
# rpm -Uvh nautilus-dropbox-2020.03.04-1.el8.x86_64.rpm : No issues.
First, realize that the command showing at the install page is for the headless installation. It will probably work, but my preference is to use Dropbox with nautilus integration.
This instructions assumes a installation of Dropbox with Nautilus integration.
We need to compile the installer from source.
a. Download last package
wget https://linux.dropbox.com/packages/nautilus-dropbox-2020.03.04.tar.bz2
b. Extract tarball
tar xjf ./nautilus-dropbox-2020.03.04.tar.bz2
c. Try to compile
cd nautilus-dropbox-2020.03.04; ./configure;
Then you get an Error:
Erro:
Problema: conflicting requests
- nothing provides libgnome >= %{gnome_version} needed by nautilus-dropbox-2020.03.04-1.fc21.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Now we need to install nautilus-devel and python3-docutils
NOTE: You will get configure: error: couldn't find docutils if forget python3-docutils.
This command will enable the PowerTools repository and install what is needed:
dnf --enablerepo=PowerTools install nautilus-devel python3-docutils
Now you can run ./configure && sudo make install
That's it. Go for the start menu type "Dropbox", it will start the installer.
Restore a local backup of Dropbox (optional)
If you have a local backup, turn of the network after you see the Dropbox folder created. Then copy all your files to that folder and turn it on after copy.
This solution worked for me running CentOS Linux release 8.2.2004 (Core).