I tried to install the latest version of Juniper.junos on my Mac :
sudo ansible-galaxy install Juniper.junos
-downloading role 'junos', owned by Juniper
-downloading role from https://github.com/Juniper/ansible-junos-stdlib/archive/2.0.2.tar.gz
[ERROR]: failed to download the file: Failed to validate the SSL certificate for github.com:443. Make sure your managedsystems have a valid CA certificate installed. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/ansible, /usr/local/etc/openssl. The exception msg was: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:590).
[WARNING]: - Juniper.junos was NOT installed successfully.
ERROR! - you can use --ignore-errors to skip failed roles and finish processing the list.
ansible-galaxy --version
ansible-galaxy 2.5.0
I already tried with different ansible versions, but the error is still the same.
We are facing this issue sometimes, it’s connectivity issue to install module via ansible-galaxy, not related to Juniper ansible module.
Kindly use below command for installation, it will work well.
sudo ansible-galaxy install git+https://github.com/Juniper/ansible junos-stdlib.git,,Juniper.junos
[abc#hostname /homes/abc] sudo ansible-galaxy install git+https://github.com/Juniper/ansible-junos-stdlib.git,,Juniper.junos
- extracting Juniper.junos to /homes/babud/.ansible/roles/Juniper.junos
- Juniper.junos was installed successfully
Related
When opening a SQL script with VS Code on Windows I get the messages:
Initializing SQL tools service for the mssql extension. Note: mssql
commands will be available after installing the service.
Platform: win32, x86_64 (Windows)
Installing SQL tools service to
c:\Users\BRITTG2.vscode\extensions\ms-mssql.mssql-1.8.0\sqltoolsservice\1.8.0\Windows.
Downloading
https://download.microsoft.com/download/e/7/8/e781cf8f-9c3f-4ad5-bd0c-f3c62b8bc6bd/microsoft.sqltools.servicelayer-win-x64-netcoreapp2.2.zip
[ERROR] Error: Request error: UNABLE_TO_GET_ISSUER_CERT_LOCALLY
How do I resolve this error? Note I am behind a corp. fw
You can turn off File -> Preferences -> Settings, search for property http.proxyStrictSSL and turn it off.
Close visual studio and open again, it worked for me.
I faced this problem today when VSCode was running from WSL2 with Ubuntu 20-04 distro. Not your case exactly, but could be useful to others.
In my case the root cause is that our corporate network requires two custom CA certificates from ZScaler. You can easily verify whether your case is similar - google for the exact procedure, it is not complicated.
Anyway, I saved the certificates in a pem file and then followed the instructions on https://ubuntu.com/server/docs/security-trust-store to install them:
$ sudo apt-get install -y ca-certificates
$ sudo cp local-ca.crt /usr/local/share/ca-certificates
$ sudo update-ca-certificates
After that I closed and reopened VS Code and the SQL tools service installed just fine.
I am currently unable to install gems from 'https://rubygems.org/'
I recently updated to Mojave and updated and upgraded brew in order to get mysql running again.
Now I discovered that I am unable to install gems from rubygems.
When trying to install gem
[REPRO]$ gem install rdoc-data -v 3.12
ERROR: Could not find a valid gem 'rdoc-data' (= 3.12), here is why:
Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: tlsv1 alert protocol version (https://api.rubygems.org/specs.4.8.gz)
I tried already this, but it did not work.
Trying to update RVM
[REPRO]$ rvm get stable
Downloading https://get.rvm.io
Downloading https://raw.githubusercontent.com/rvm/rvm/master/binscripts/rvm-installer.asc
Verifying /Users/MYACCOUNT/.rvm/archives/rvm-installer.asc
gpg: Signatur vom Sat Mar 31 23:47:44 2018 CEST
...
GPG verified '/Users/MYACCOUNT/.rvm/archives/rvm-1.29.4.tgz'
Upgrading the RVM installation in /Users/MYACCOUNT/.rvm/
RVM PATH line found in /Users/MYACCOUNT/.mkshrc /Users/MYACCOUNT/.profile /Users/MYACCOUNT/.zshrc.
RVM PATH line not found for Bash, rerun this command with '--auto-dotfiles' flag to fix it.
RVM sourcing line found in /Users/MYACCOUNT/.profile /Users/MYACCOUNT/.bash_profile /Users/MYACCOUNT/.zlogin.
Upgrade of RVM in /Users/MYACCOUNT/.rvm/ is complete.
* RVM 1.30 simplifies behavior of 'rvm wrapper' subcommand
RVM reloaded!
Trying to update CERTs
[REPRO]$ rvm osx-ssl-certs update all
Selected SSL certs for: ruby-2.3.4
cURL certificate bundle /usr/share/curl/curl-ca-bundle.crt not found
Updating certificates bundle /usr/local/etc/openssl/cert.pem: Already up to date.
Updating certificates bundle /etc/openssl/cert.pem: Updating certificates bundle '/etc/openssl/cert.pem'
MYACCOUNT password required for 'command tee /etc/openssl/cert.pem':
Updated.
Updating certificates bundle /System/Library/OpenSSL/cert.pem: Updating certificates bundle '/System/Library/OpenSSL/cert.pem'
tee: /System/Library/OpenSSL/cert.pem: Operation not permitted
Failed.
Updating certificates bundle /System/Library/OpenSSL/cert.pem: Updating certificates bundle '/System/Library/OpenSSL/cert.pem'
tee: /System/Library/OpenSSL/cert.pem: Operation not permitted
Failed.
Updating certificates bundle /usr/local/etc/openssl#1.1/cert.pem: Already up to date.
Trying to update RVM
[REPRO]$ rvm rubygems latest
Installed rubygems 2.6.8 is newer than 2.0.17 provided with installed ruby, skipping installation, use --force to force installation.
Trying to install gem
[REPRO]$ gem install rdoc-data -v 3.12
ERROR: Could not find a valid gem 'rdoc-data' (= 3.12), here is why:
Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: tlsv1 alert protocol version (https://api.rubygems.org/specs.4.8.gz)
I have two openssl installed through brew:
[REPRO]$ brew info openssl
openssl: stable 1.0.2p (bottled) [keg-only]
SSL/TLS cryptography library
https://openssl.org/
/usr/local/Cellar/openssl/1.0.2o_1 (1,791 files, 12.3MB)
Poured from bottle on 2018-04-17 at 00:25:36
/usr/local/Cellar/openssl/1.0.2o_2 (1,792 files, 12.3MB)
Poured from bottle on 2018-06-22 at 06:37:09
/usr/local/Cellar/openssl/1.0.2p (1,793 files, 12MB)
Poured from bottle on 2018-09-25 at 07:30:55
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/openssl.rb
==> Dependencies
Build: makedepend ✘
==> Options
--without-test
Skip build-time tests (not recommended)
==> Caveats
A CA file has been bootstrapped using certificates from the SystemRoots
keychain. To add additional certificates (e.g. the certificates added in
the System keychain), place .pem files in
/usr/local/etc/openssl/certs
and run
/usr/local/opt/openssl/bin/c_rehash
openssl is keg-only, which means it was not symlinked into /usr/local,
because Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries.
If you need to have openssl first in your PATH run:
echo 'export PATH="/usr/local/opt/openssl/bin:$PATH"' >> ~/.bash_profile
For compilers to find openssl you may need to set:
export LDFLAGS="-L/usr/local/opt/openssl/lib"
export CPPFLAGS="-I/usr/local/opt/openssl/include"
For pkg-config to find openssl you may need to set:
export PKG_CONFIG_PATH="/usr/local/opt/openssl/lib/pkgconfig"
==> Analytics
install: 556,733 (30d), 1,491,119 (90d), 4,803,757 (365d)
install_on_request: 75,928 (30d), 212,774 (90d), 546,010 (365d)
build_error: 14,735 (30d)
and
[REPRO]$ brew info openssl#1.1
openssl#1.1: stable 1.1.1 (bottled) [keg-only]
Cryptography and SSL/TLS Toolkit
https://openssl.org/
/usr/local/Cellar/openssl#1.1/1.1.0h (6,587 files, 15.6MB)
Poured from bottle on 2018-04-17 at 00:24:57
/usr/local/Cellar/openssl#1.1/1.1.1 (7,821 files, 17.9MB)
Poured from bottle on 2018-09-25 at 07:31:15
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/openssl#1.1.rb
==> Options
--without-test
Skip build-time tests (not recommended)
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
/usr/local/etc/openssl#1.1/certs
and run
/usr/local/opt/openssl#1.1/bin/c_rehash
openssl#1.1 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.
If you need to have openssl#1.1 first in your PATH run:
echo 'export PATH="/usr/local/opt/openssl#1.1/bin:$PATH"' >> ~/.bash_profile
For compilers to find openssl#1.1 you may need to set:
export LDFLAGS="-L/usr/local/opt/openssl#1.1/lib"
export CPPFLAGS="-I/usr/local/opt/openssl#1.1/include"
For pkg-config to find openssl#1.1 you may need to set:
export PKG_CONFIG_PATH="/usr/local/opt/openssl#1.1/lib/pkgconfig"
==> Analytics
install: 0 (30d), 0 (90d), 0 (365d)
install_on_request: 0 (30d), 0 (90d), 0 (365d)
build_error: 13 (30d)
I have 'PATH="/usr/local/opt/openssl/bin:$PATH"' in my ~/.bash_profile
Everything used to work before the system update, but now my dev system is broken. Can anyone help? I can set http;//rubygems.org in gem file and therefore install gems through bundle install, but this is no solution.
Update:
I found out some more details: on a second machine everything is working as it is supposed to. On both systems RVM relies on openssl, which in both cases is brew/openssl or brew/openssl#1.1. On the first machine I get:
$ rvm osx-ssl-certs status all
Selected SSL certs for: ruby-2.3.4
cURL certificate bundle /usr/share/curl/curl-ca-bundle.crt not found
Certificates bundle /usr/local/etc/openssl/cert.pem is up to date.
Certificates bundle /etc/openssl/cert.pem is up to date.
Certificates bundle /System/Library/OpenSSL/cert.pem is old.
Certificates bundle /usr/local/etc/openssl#1.1/cert.pem is up to date.
on the second I get:
$ rvm osx-ssl-certs status all
Selected SSL certs for: ruby-1.8.7-head
cURL certificate bundle /usr/share/curl/curl-ca-bundle.crt not found
Certificates bundle /usr/local/etc/openssl/cert.pem is up to date.
Why does does the first machine check also in /System/Library/? How can I configure it to not do so?
I was able to install gems. I had to recompile all rubies:
$ ram uninstall ruby-1.8.7-p374
$ rvm install ruby-1.8.7-p374 --with-gcc=clang
$ rvm use ruby-1.8.7-p374#openssl-test01 --create
$ gem install rdoc-data -v 3.12
After this I was able to install although the link to /System/openssl is still shown in rvm osx-ssl-certs status all.
Pip always fails ssl even when I do pip install dedupe or pip install --trusted-host pypi.python.org dedupe
The output is always the same no matter what:
Collecting dedupe
Retrying (Retry(total=4, connect=None, read=None,
redirect=None, status=None)) after connection broken by
'SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate
verify failed (_ssl.c:777)'),)': /simple/dedupe/
Retrying...
skipping
Could not find a version that satisfies the requirement dedupe (from versions: ) No matching distribution found for dedupe
So I uninstalled anaconda and reinstalled it. Same thing.
Do you think the problem is that my _ssl.c file (which I have no idea where it is) must be corrupt or something? Why would pip need to reference that if I'm telling it to bypass ssl verification anyway?
It may be related to the 2018 change of PyPI domains.
Please ensure your firewall/proxy allows access to/from:
pypi.org
files.pythonhosted.org
So you could give a try to something like:
$ python -m pip install --trusted-host files.pythonhosted.org --trusted-host pypi.org --trusted-host pypi.python.org [--proxy ...] [--user] <packagename>
Please see $ pip help install for the --user option description (omit if in a virtualenv).
The --trusted-host option doesn't actually bypass SSL/TLS, but allows to mark host as trusted when (and only when) it does not have valid (or any) HTTPS. It shouldn't really matter with PiPY because pypi.org (formerly pypi.python.org) does use HTTPS and there is CDN in front of it which always enforces TLSv1.2 handshake requirement regardless of the connecting pip client options.. But if you had your own local mirrors of pypi.org with HTTP-only access, then --trusted-host could be handy. Oh, and if you are behind a proxy, please also make sure to also specify: --proxy [user:passwd#]proxyserver:port
Some corporate proxies may even go as far as to replace the certificates of HTTPS connections on the fly. And if your system clock is out of sync, it could break SSL verification process as well.
If firewall / proxy / clock isn't a problem, then check SSL certificates being used in pip's SSL handshake. In fact, you could just get a current cacert.pem (Mozilla's CA bundle from curl) and try it using the pip option --cert:
$ pip --cert ~/cacert.pem install --user <packagename>
where --cert argument is system path to your alternate CA bundle in PEM format. (regarding the --user option, please see below).
Or, it's possible to create a custom config ~/.pip/pip.conf and point the option at a valid system cert (or your cacert.pem) as a workaround, for example:
[global]
cert = /etc/pki/tls/external-roots/ca_bundle.pem
(or another pem file)
It's even possible to manually replace the original cacert.pem found in pip with your trusty CA bundle (if your pip is very old for example). Older pip versions knew to fallback between pip/_vendor/requests/cacert.pem and system stores like /etc/ssl/certs/ca-certificates.crt or /etc/pki/tls/certs/ca-bundle.crt in case of cert issues, but in recent pip it's no longer the case, as it seems to rely solely on pip/_vendor/certifi/cacert.pem
Basically, pip package uses requests which uses urllib3 which, among other things, verifies SSL certificates; and all of them are shipped (vendored) within pip, along with the certifi package (also included, since pip 9.0.2) that provides current CA bundle (cacert.pem file) required for TLS verification. Requests itself uses urllib3 and certifi internally, and before 9.0.2, pip used cacert.pem from requests or the system. What it all means is that actually updating pip may help fix the CERTIFICATE_VERIFY_FAILED error, particularly if the OS and pip were deployed long ago:
The OP used anaconda, so they could try:
$ conda update pip - because issues can arise if conda and pip are both used together in the same environment. If there's no pip version update available, they could try:
$ conda config --add channels conda-forge; conda update pip
Alternatively, it's possible to use conda alone to directly install / manage python packages: it is a tool completely separate from pip, but provides similar features in terms of package and venv management. Its packages come not from PyPI, but from anaconda's own repositories.
The problem is, if you mix both and run conda after pip, the former can overwrite and break packages (and their dependencies) installed via pip, and render it all unusable. So it's recommended to only use one or the other, or, if you have to, use only pip after conda (and no conda after pip), and only in isolated conda environments.
On normal Linux Python installations without conda:
If you are using a version of pip supplied by your OS distribution, then use vendor-supplied upgrades for a system-wide pip update:
$ sudo apt-get install python-pip or: $ sudo yum install python27-pip
Some updates may not be readily available because distros usually lag behind PyPI. In this case, it's possible to upgrade pip at your user level (right in your $HOME dir), or inside a virtualenv, like:
$ python -m pip install --user --trusted-host files.pythonhosted.org --trusted-host pypi.org --trusted-host pypi.python.org --upgrade pip
(omit --user if in a virtualenv)
The --user switch will upgrade pip only for the current user (in your home ~/.local/lib/) rather than for the whole OS, which is a good practice to avoid interfering with the system python packages. It's enabled by default in a pip distributed in recent Ubuntu/Fedora versions. Be aware of how to solve ImportError if you don't use this option and happen to overwrite the OS-level system pip.
Alternatively (also at a user level) you could try:
$ curl -LO https://bootstrap.pypa.io/get-pip.py && python get-pip.py --user
The PyPA script contains a wrapper that extracts the .pem SSL bundle from pip._vendor.certifi.
Otherwise, if still no-go, try running pip with -vvv option to add verbosity to the output and check if there is now another SSLError caused by tlsv1 alert protocol version.
This worked for me, try this:
pip install --trusted-host=pypi.org --trusted-host=files.pythonhosted.org --user {name of whatever I'm installing}
My way is a simplification of #Alex C's answer:
python -m pip install --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --trusted-host pypi.org --upgrade pip
I experienced the same issue because I have Zscaler (a cloud security software) installed and was causing:
URL host for python packages being blocked
invalid SSL certificate warnings popping up
SSL inspection certificate not trusted
As mentioned by others, the below will fix individual package installations. pypi.python.org is not required since it has been replaced by pypi.org.
pip install --trusted-host pypi.org --trusted-host files.pythonhosted.org <package to install>
I permanently fixed the issue by creating pip.ini file (pip.conf in Unix) and adding the below:
[global]
trusted-host = pypi.python.org
pypi.org
files.pythonhosted.org
See pip configuration files for how to locate your pip.ini, or where to put it if you need to create one.
The error above or one like it was caused by the virtual machine (VM) not be time synchronized, my guest Ubuntu VM was several days in the past.
I ran this commend to get the VM to pick up the correct network time:
sudo timedatectl set-ntp on
This makes the Ubuntu guest OS get the network time. (You may have to provide a network time source... I used this article: Digital Ocean - How to set time on Ubuntu)
Check the time is correct:
timedatectl
Re-run the failing pip command.
For every yum command it will return SSL certificate error
Loaded plugins: fastestmirror, rhnplugin, security
The SSL certificate failed verification.
My SSL cert if valid.
I checked rhel site for https://access.redhat.com/solutions/93313 but the problem is i cannot reinstall rhn-client-tools since yum is actually not working and for some other reasons i cannot boot it from DVD/image.
Any tips on this?
Before trying to reinstall, have you also checked your firewall settings and the time and date setting on your server ?
If the firewall is not the issue, I would suggest a simpler approach, just by going to RH's site and downloading the appropriate rhn-client-tools RPM package, copying it to your server and installing it.
"What about the possible dependencies?" I foresee you asking...
Use a different server (or VM) with the same OS version that has access to the internet.
use yum with the download only plugin to only download all the needed dependencies (you must have the yum-plugin-downloadonly package installed beforehand) in a local directory like so:
yum install --downloadonly --downloaddir=<directory> <package>
Copy the packages downloaded at step #2 to your affected machine and install them using the rpm utility as so: rpm -ivh /path/to/yum/download/dir/*
I need Apache2.4 with ssl.
AWS RHEL server I am using already has Apache2.2 and openssl 0.9 installed. I configured my Apache,apr,apr-util and pcre packages at /opt/products/apache2. everything is fine except the option
--enable-ssl
fails due to a dependency failure (openssl > 0.9.8a). No problem. I downloaded openssl 1.0.2a from open ssl and configured and installed it at /opt/openssl without problem.
Now I need to configure Apache with
--enable-ssl --with-ssl=/opt/openssl
but the configure command returns the error
"invalid variable name 'with-ssl'".
configure -help shows that with-ssl is an option.
Is this a bug or something? I don't find any reference on the internet.
Just wanted to update for anyone looking at this later.
Installing all the pre-requisites before configuring apache solves the problem of apache giving version error. So this command before the apache configuration solved the problem:
yum install gcc libxml2-devel gcc-c++ libicu-devel libxslt-devel bzip2 bzip2-devel libjpeg-devel libpng libpng-devel freetype freetype-devel curl curl-devel t1lib-devel unixODBC-devel openssl-devel openssl
and I did not have to install openssl separately.