Sunday, August 25, 2024 8:08 PM
After installing Rocky Linux 9, I ran into the following error:
Could not fetch URL https://pypi.org/simple/wheel/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /simple/wheel/ (Caused by SSLError("Can't connect to HTTPS URL because the SSL module is not available.")) - skipping
ERROR: Could not find a version that satisfies the requirement wheel (from versions: none)
ERROR: No matching distribution found for wheel
WARNING: pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.
Running python3 -m ssl resulted in the following:
Traceback (most recent call last):
File "/home/ibarwick/.pyenv/versions/3.9.16/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/home/ibarwick/.pyenv/versions/3.9.16/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/home/ibarwick/.pyenv/versions/3.9.16/lib/python3.9/ssl.py", line 99, in
import _ssl # if we can't import it, let the error propagate
ImportError: libssl.so.1.1: cannot open shared object file: No such file or directory
Executing dnf provides */"libssl.so.1.1" reveals that this is provided by the package compat-openssl11, which is not installed by default. Installing that resolved the issue.
Saturday, May 28, 2022 5:14 PM
So I have this big-ish Samsonite suitcase which many years ago suffered a partial failure of the telescopic handle, specifically the inner telescopic tube on one side would no longer slide out of the outer tube, so the whole assembly would only partially extend, like this:
Wednesday, June 16, 2021 6:19 AM
Ran into an error like the following when trying to build etcd as a CentOS 7 package:
go: github.com/prometheus/client_golang@v1.0.0 requires
github.com/prometheus/common@v0.4.1 requires
github.com/prometheus/procfs@v0.0.0-20181005140218-185b4288413d: invalid version: git fetch --unshallow -f origin in /root/go/pkg/mod/cache/vcs/0ab7c7bc964e6f4054247fed3ac8d636309918420efe8a7cabef12d9f9904311: exit status 128:
fatal: git fetch-pack: expected shallow list
or sometimes this:
go: golang.org/x/crypto@v0.0.0-20200622213623-75b288015ac9 requires
golang.org/x/net@v0.0.0-20190404232315-eb5bcb51f2a3 requires
golang.org/x/crypto@v0.0.0-20190308221718-c2843e01d9a2: invalid version: git fetch --unshallow -f origin in /root/go/pkg/mod/cache/vcs/f72f7a6f267d2fe79b1e174efab21a591b07c84ef53364f65b8281fda7000b49: exit status 128:
fatal: git fetch-pack: expected shallow list
The mysterious thing was, the build had previously completed without issue many times, and there were no obvious changes in any of the build elements involved.
This issue does resemble that described in golang GitHub issue #38373; the workaround suggested by the poster involves resolving version references in the go.mod file. However that did not seem feasible for this build, which indirectly pulls in a large number of golang modules from various git repositories, which would make tracking down any version reference issues a somewhat Herculean task.
It was however possible to resolve the error (as suggested in a comment on the issue) by upgrading the git package to a more recent one, as the default CentOS 7 version is a very dated 1.8.x (released in 2014 or earlier).
Recent git packages for CentOS 7 can be obtained from the Endpoint repository here: https://packages.endpoint.com/rhel/7/os/x86_64/.
Monday, June 7, 2021 5:51 AM
Ran into this error when trying to build the PostgreSQL documentation as a PDF file on CentOS 8:
$ make postgres-A4.pdf
/usr/bin/xmllint --path . --noout --valid postgres.sgml
/usr/bin/xsltproc --path . --stringparam pg.version '14beta1' --stringparam img.src.path './' --stringparam paper.type A4 -o postgres-A4.fo stylesheet-fo.xsl postgres.sgml
Making portrait pages on A4 paper (210mmx297mm)
/bin/sh ../../../config/missing fop -fo postgres-A4.fo -pdf postgres-A4.pdf
***
ERROR: `fop' is missing on your system.
***
make: *** [Makefile:178: postgres-A4.pdf] Error 1
As with many things, there doesn't appear to be a CentOS package for this (and given recent developments there might never be). However as fop is a Java-based tool, it's simple enough to install locally.
- Download the latest distribution from https://xmlgraphics.apache.org/fop/download.html
- create a directory (say
~/fop/)
- Extract the following files/directories from the downloard
.tar.gz file to ~/fop/:
fopbuild/lib/
Then ensure ~/fop/ is included in the PATH variable when performing any tasks where it is required.
Note: for the PostgreSQL documentation build, both the top-level source ./configure and make (in the doc/ directory) need to be run again so the build system detects the location of fop.
DISCLAIMER: there is probably a more elegant way of doing this, but the above sufficed for a quick workaround in the heat of the moment.
Friday, January 29, 2021 12:28 AM
I was recently stumped by the following error emitted from deep within a build process:
fd:4: hClose: resource vanished (Broken pipe)
It turned out to be coming from an invocation of pandoc with the --filter option, where the filter script was failing due to missing package dependencies (an artefact of the python2 → python3 transition, aargh).
Friday, January 24, 2020 6:07 AM
When logged into a server via SSH, usually any attempt to decrypt a file with GPG results in an unhelpful error message like:
gpg: cancelled by user
...
gpg: decryption failed: No secret key
with no attempt made to ask for a password.
Fix for this is simply to execute: export GPG_TTY=`tty`,
Note that if pinentry-program in ~/.gnupg/gpg-agent.conf is set to /usr/bin/pinentry-gtk, and this is an alias for /usr/bin/pinentry-gtk-2, set pinentry-program to the latter (/usr/bin/pinentry-gtk-2), which appears to change the behaviour (pinentry-gtk-2 should be able to automatically detect whether to execute in GUI or text mode, whereas the original pinentry-gtk is GUI-only.
See also "Forcing GPG passphrase input in the terminal".
Sunday, January 12, 2020 10:09 PM
My email client suddenly became unable to log in to my Gmail account with the error message:
Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure)
However I was logged in via my web browser on two different devices, and even when providing the email client with definitively the correct password, the above error recurred.
The provided link wasn't very helpful.
Tuesday, September 24, 2019 11:12 PM
I started getting intermittent sets of error messages like this:
error: rpmdb: BDB0113 Thread/process 26154/140393252489024 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 - (-30973)
error: cannot open Packages database in /var/lib/rpm
when deploying changes to a bunch of AWS EC2 instances.
The error messages are misleading as (in this case at least) the RPM database is not corrupted; the underlying issue was this:
[67897.740241] Out of memory: Kill process 28759 (yum) score 330 or sacrifice child
[67905.749492] yum invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
i.e. simply a lack of memory (the instances were just too small).
Thursday, September 5, 2019 1:31 AM
The Prometheus PostgreSQL storage adapter does not seem amenable to being executed directly from a systemd service file.
As a workaround I created a wrapper script like this (adjust parameters as required):
#!/bin/bash
# Wrapper to launch prometheus-postgresql-adapter, as calling
# it directly from the systemd service file doesn't seem to work.
#
# Disclaimer: there is probably a better way of doing this.
nohup /usr/local/bin/prometheus-postgresql-adapter \
-pg-host=... \
-pg-port=... \
-pg-database="..." \
-pg-user="..." \
>> /var/log/prometheus-postgresql-storage-adapter/prometheus-pg-adapter.log 2>&1
and a service file like this:
[Unit]
Description=Prometheus PostgreSQL Storage Adapter
Documentation=https://github.com/timescale/prometheus-postgresql-adapter
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/usr/local/bin/prometheus-postgresql-adapter-wrapper
Restart=on-failure
[Install]
WantedBy=multi-user.target
which works fine (YMMV of course).
There may of course be a more elegant way of solving this issue, if so feel free to share.
Tuesday, August 27, 2019 10:25 PM
Recently I had to work with some Python code which needs to be compatible with both the hopefully-soon-to-be-finally-deprecated Python 2.7 and recent 3.x versions.
String handling can be a tricky issue, particularly if the string in question needs to be cast to a Unicode object. Take the following example:
#!/usr/bin/env python
import ipaddress
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
for address in addresses:
print(address)
This does of course fail in Python 3.x with an error like:
Traceback (most recent call last):
File "./python.py", line 5, in
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
NameError: name 'unicode' is not defined
Remove the unicode() wrapper and it fails in Python 2.x with:
ipaddress.AddressValueError: '192.168.1.0/24' does not appear to be an IPv4 or IPv6 network. Did you pass in a bytes (str in Python 2) instead of a unicode object?
The solution is to use the "six" compatibility layer and add the following directive, which reassigns unicode() to a mutually compatible function:
#!/usr/bin/env python
import ipaddress
from six import u as unicode
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
for address in addresses:
print(address)
Note that the "six" compatibility layer may need to be installed separately, in RedHat et al via the packages python2x-six and python3x-six respectively.
Useful links
Tuesday, January 10, 2017 3:25 AM
Spent a lot of time working out why openvpn wouldn't connect from a Vagrant virtual machine (running Ubuntu 14.04 LTS):
Tue Jan 10 02:51:25 2017 Control Channel Authentication: tls-auth using INLINE static key file
Tue Jan 10 02:51:25 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 10 02:51:25 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 10 02:51:25 2017 Socket Buffers: R=[212992->200000] S=[212992->200000]
Tue Jan 10 02:51:25 2017 UDPv4 link local: [undef]
Tue Jan 10 02:51:25 2017 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Tue Jan 10 02:51:25 2017 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx::1194, sid=92749f62 ced33a12
Tue Jan 10 02:52:25 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jan 10 02:52:25 2017 TLS Error: TLS handshake failed
Tue Jan 10 02:52:25 2017 SIGUSR1[soft,tls-error] received, process restarting
Tue Jan 10 02:52:25 2017 Restart pause, 2 second(s)
Turns out the openvpn version (2.3.2) is outdated; 2.3.4 or later is needed.
