I'm using Salt (SaltStack) to install packages in Ubuntu 18.04. I want to install a formula for docker, for example. When I apply docker state, I get an error that a package can't be installed, because the package repository that is used in a formula isn't signed.
ID: docker package
Function: pkg.installed
Name: docker-engine
Result: False
Comment: An error was encountered while installing package(s): E: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-bionic/InRelease 403 Forbidden [IP: 13.33.98.216 443]
E: The repository 'https://apt.dockerproject.org/repo ubuntu-bionic InRelease' is not signed.
Same happens when I'm using another formula.
I found out that if I would install a package manually through a command-line, I would use a --allow-unauthenticated option.
But what is the way to solve this issue while using Salt and salt-formulas? How can I install a package from a not signed repository?
Disabling package verification is a very bad idea in any scenario. The Docker repository is perfectly compliant with Ubuntu package signing standards and publishes a GPG key to verify them. It can be added to the system manually:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
But this is not the primary problem here - it's that the Salt rule you're referring to is outdated and sets an incorrect Docker repo URL - in recent installation script they've changed it from https://apt.dockerproject.org/repo to https://download.docker.com/linux/ubuntu/ and while the old mirror seems to be working, the signature files for new releases don't seem to be available there, which confuses apt.
So using Ansible (sorry, I don't know Salt):
- apt_key:
url: https://download.docker.com/linux/ubuntu/gpg
- apt_repository:
repo: 'deb https://download.docker.com/linux/ubuntu/ bionic stable'
- apt: name=docker-ce
You can use skip_verify to avoid GPG verification check (e.g., --allow-unauthenticated, or --force-bad-verify),
httpd:
pkg.installed:
- fromrepo: mycustomrepo
- skip_verify: True
Related
I have a clean install of Centos 7 on a RaspberryPi3b+. I am trying to install nginx and am running into problems with each approach.
Most of the research I've done points to installing epel, and then installing nginx. When I run yum install epel-release, I get the error:
No package epel-release available.
Error: Nothing to do.
Some searching led me to wget it directly from fedora. I was able do that. I then ran rpm -ivh epel-release-latest-7.noarch.rpm successfully and then tried yum install nginx. That gave me this long error:
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:
1. Contact the upstream for the repository and get them to fix the problem.
2. 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).
3. Run the command with the repository temporarily disabled
yum --disablerepo=<repoid> ...
4. 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>
5. 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 retrieve metalink for repository: epel/armhfp. Please verify its path and try again
So, I found another method that doesn't require epel. I created a .repo file for nginx at /etc/yum.repos.d/nginx.repo, and added:
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1
I ran yum repolist and got an error:
http://nginx.org/packages/centos/7/armhfp/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
For laughs, I tried installing nginx anyway and got an error similar to the long one above that the nginx repo failed.
Finally, I tried going to nginx.org and finding the correct link and hard-coding it in the repo file. That didn't work either, and now I am well and truly stuck.
So, I'm a noob to Artifactory. I downloaded and installed the dockerized version of Pro - demo license, set up my first repository as a place to push internal packages we've developed for our ubuntu users.
However, when I upload a package and try to sudo apt-get update after adding a new ".list" file to my /etc/apt/sources.list.d, I get this message back:
W: The repository 'https://10.202.13.218/artifactory/ubuntu-dev-local xenial Release' does not have a Release file.
Do I have to gpg sign the packages? That seems like it would be a different error.
You can force artifactory to recreate the release.key file with the following API call:
curl -u admin:topsecret -X POST http://localhost:8081/artifactory/api/deb/reindex/debian-local
I am having an issue with Travis CI - the commits that I push all fail with the same error:
0.06s$ curl -sSL "http://llvm.org/apt/llvm-snapshot.gpg.key" | sudo -E apt-key add -
gpg: no valid OpenPGP data found.
The command "curl -sSL "http://llvm.org/apt/llvm-snapshot.gpg.key" | sudo -E apt-key add -" failed and exited with 2 during .
Your build has been stopped.
I tried to rebuild a previous commit that built successfully and the same error occurs. Any suggestions as to how to troubleshoot the issue?
http://llvm.org/apt/llvm-snapshot.gpg.key is returning 404 since about 2 days ago. And http://llvm.org/apt/ which is linked from their homepage returns 404.
The topic in the #llvm channel on IRC mentions:
APT repo temporary switched off. Check ML for the latest updates.
The ML announcement:
TL;DR: APT repo switched off due to excessive load / traffic
Recently we realized that APT repo generates almost 95% of I/O on
llvm.org and more than 40% of network bandwidth alone. During last 2
weeks the main services on llvm.org (svn, git, bugzilla) had serious
problems with overall connectivity.
We decided to temporary switch APT repo off to see if this would help.
Stay tuned for updates.
Temp solution
Since the llvm server still down I'm using the clang provided in the Ubuntu package.
addons:
apt:
sources:
- ubuntu-toolchain-r-test
#- llvm-toolchain-precise-3.7
packages:
- libgnome-keyring-dev
#- clang-3.7
- clang
Full example: https://github.com/sqlectron/sqlectron-gui/blob/master/.travis.yml#L35
The only problem is that installs the version 3.4 or 3.5. Which looks be much slower than the latest one available on llvm package.
The llvm server is still down. However, a very good idea from the people behind rust (https://github.com/rust-lang/rust) is to solve this issue by using Docker.
See the .travis.yml file here:
https://github.com/rust-lang/rust/commit/b1651fb4d2c0349ccca108b8d24210d688507936
You can find the travis build here:
https://travis-ci.org/rust-lang/rust/builds/134924068
I incorporated Docker into my builds with excellent results, but it took me a couple of days to do so. You can find my approach here: https://github.com/fuzzylite/fuzzylite/tree/master in files /Dockerfile and /.travis.yml
and the results here: https://travis-ci.org/fuzzylite/fuzzylite/builds/137058927
here is an example how to currently solve this and use clang 3.7.
sudo: required
dist: trusty
env:
global:
- LLVM_VERSION=3.7.0
- LLVM_ARCHIVE_PATH=$HOME/clang+llvm.tar.xz
before_install:
- wget http://llvm.org/releases/$LLVM_VERSION/clang+llvm-$LLVM_VERSION-x86_64-linux-gnu-ubuntu-14.04.tar.xz -O $LLVM_ARCHIVE_PATH
- mkdir $HOME/clang+llvm
- tar xf $LLVM_ARCHIVE_PATH -C $HOME/clang+llvm --strip-components 1
- export PATH=$HOME/clang+llvm/bin:$PATH
I'm doing the same for clang 3.5/3.6/3.7/3.8 and it works.
I call clang++ and not clang++-3.7 or whatever - it is prepended to the PATH.
On trying to install MySql on RHEL7 I came to know that we need to use MariaDB instead.
I tried the installation on my machine which is RHEL6 by adding MariaDB.repo file to /etc/yum.repos.d/ with following lines -
[mariadb]
name = MariaDB-5.5.39
baseurl=https://downloads.mariadb.com/files/MariaDB/mariadb-5.5.39/yum/rhel6-amd64/
# alternative: baseurl=http://archive.mariadb.org/mariadb-5.5.39/yum/rhel6-amd64/
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
https://mariadb.com/kb/en/mariadb/yum/
Thereafter I installed it successfully using following command -
sudo yum install MariaDB-server MariaDB-client
Now on an RHEL7 production box same steps failed with following conflict -
file /etc/my.cnf from install of MariaDB-common-5.5.39-1.el6.x86_64 conflicts with file from package maria-libs-1:5.5.44-2.el7.x86_64
So I understand I am pointing to rhel6 repo on rhel7 and probably some pre-installed files are in conflict.
But when I execute below mysql/mariadb gets installed successfully, what difference does case make here?
sudo yum install mariadb mariadb-server
I am not sure if it is linked to a different repository in background, I dont have access to the instance to dig further in repo settings, can anyone help me out here?
You can clarify that using yum search mariaDB
I executed that an ended up with same result as mariaDB and mariadb
============================= N/S matched: mariaDB =============================
mariadb-bench.x86_64 : MariaDB benchmark scripts and data
mariadb-devel.i686 : Files for development of MariaDB/MySQL applications
mariadb-devel.x86_64 : Files for development of MariaDB/MySQL applications
mariadb-libs.i686 : The shared libraries required for MariaDB/MySQL clients
mariadb-libs.x86_64 : The shared libraries required for MariaDB/MySQL clients
mariadb-server.x86_64 : The MariaDB server and related files
mariadb.x86_64 : A community developed branch of MySQL
mariadb-test.x86_64 : The test suite distributed with MariaD
Name and summary matches only, use "search all" for everything.
I'm seeking your help to install the Nginx GeoIP module, and all its dependencies.
Actually, i tried a lot if things to build Nginx with it, but failed each time on same error.
My config:
Debian 8.2, Nginx 1.9.7-1~jessie (last mainline), PHP7 RC7.
What i did:
Installed geoip-api-c 1.6.7 from source
Try apt-get install directly geoip-bin package, failed as "already uptodate").
Installed module libmaxminddb from git
A ldconfig -p | grep maxminddb command give me :
libmaxminddb.so.0 (libc6,x86-64) => /usr/local/lib/libmaxminddb.so.0
libmaxminddb.so (libc6,x86-64) => /usr/local/lib/libmaxminddb.so
Everything looks fine.
But on nginx dpkg-buildpackage -b, one libmaxminddb check fail with :
dh_shlibdeps
dpkg-shlibdeps: error: no dependency information found for /usr/local/lib/libmaxminddb.so.0 (used by debian/nginx/usr/sbin/nginx)
Hint: check if the library actually comes from a package.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/nginx.substvars debian/nginx/usr/sbin/nginx returned exit code 2
debian/rules:11: recipe for target 'binary' failed
I really tested everything, installed all lib again from source, tried to install from ubuntu PPA & didnt found any debian repo URL to add to my list.
Just to know, i tried :
apt-get install libmaxminddb0 libmaxminddb-dev mmdb-bin
Fail with packet not found.
Regarding this, i removed geoip --add-module before nginx build and the build-package worked perfectly.
Thanks a lot
You can ignore missing info warnings by using
dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info
This answer https://stackoverflow.com/a/14992359 solved same problem for me