Re: [lmi] debian chroot in redhat

[Greg Chicares]

On 2019-10-02 23:34, Vadim Zeitlin wrote:
> On Wed, 2 Oct 2019 22:08:53 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Please help--I'm stuck.
> GC> 
> GC> What I've done so far is here:
> GC>   https://git.savannah.nongnu.org/cgit/lmi.git/tree/install_centos.sh
> GC> which gives me a working centos chroot, closely following your
> GC> instructions here:
> GC>   http://www.tt-solutions.com/en/articles/install_centos_in_debian_chroot
> GC> except that I'm using centos-7.7 instead of 7.6 because the handful of
> GC> US mirrors I checked don't offer 7.6 .
> GC> 
> GC> After running that script as root on my debian-10.1 base system, I log in
> GC> and install curl and ca-certificates:
> GC> 
> GC> #schroot --chroot=centos7 --user=root --directory=/tmp
> GC> [root@ugolyok]/tmp# yum --assumeyes install ca-certificates curl
> GC> ...
> GC> Installed:
> GC>   ca-certificates.noarch 0:2018.2.22-70.0.el7_5             curl.x86_64 
> 0:7.29.0-54.el7            
> GC> ...
> GC> Complete!
> GC> 
> GC> But now I observe this failure on the command to install EPEL:
> GC> 
> GC> [root@ugolyok]/tmp# rpm -ivh 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
> GC> Retrieving 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
> GC> curl: (77) Problem with the SSL CA cert (path? access rights?)
> GC> error: skipping 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - 
> transfer failed
> 
>  This is very strange. I've just retried from my CentOS 7.6 chroot and it
> worked just fine. With --verbose option I get (among other output) the
> following:
> 
>       % curl -v 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm 
> >|/dev/null
>       * About to connect() to dl.fedoraproject.org port 443 (#0)
>       *   Trying 209.132.181.23...
>       * Connected to dl.fedoraproject.org (209.132.181.23) port 443 (#0)
>       * Initializing NSS with certpath: sql:/etc/pki/nssdb
>       *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>         CApath: none
>       * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>       * Server certificate:
>       *       subject: CN=*.fedoraproject.org,O=Red Hat 
> Inc.,L=Raleigh,ST=North Carolina,C=US
>       *       start date: Feb 01 00:00:00 2017 GMT
>       *       expire date: May 01 12:00:00 2020 GMT
>       *       common name: *.fedoraproject.org
>       *       issuer: CN=DigiCert SHA2 High Assurance Server 
> CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> 
>  And the certificate is indeed present in the system certificate bundle:
> 
>       % fgrep -A2 'DigiCert High Assurance' /etc/pki/tls/certs/ca-bundle.crt
>       # DigiCert High Assurance EV Root CA
>       -----BEGIN CERTIFICATE-----
>       MIIDxTCCAq2gAwIBAgIQAqxcJmoLQJuPC3nyrkYldzANBgkqhkiG9w0BAQUFADBs
> 
>  Could they really remove it in 7.7? This seems very unlikely, it's the
> only explanation I see right now. Could you please check if it's still
> there?

/home/greg[0]#schroot --chroot=centos7 --user=root --directory=/tmp 
[root@ugolyok]/tmp# curl -v 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm 
>|/dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* 
About to connect() to dl.fedoraproject.org port 443 (#0)
*   Trying 209.132.181.25...
* Connected to dl.fedoraproject.org (209.132.181.25) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM 
certificates will not work.
* Closing connection 0
curl: (77) Problem with the SSL CA cert (path? access rights?)

My results differ from yours at that "WARNING".

But the certificate matches:

[root@ugolyok]/tmp# fgrep -A2 'DigiCert High Assurance' 
/etc/pki/tls/certs/ca-bundle.crt
# DigiCert High Assurance EV Root CA
-----BEGIN CERTIFICATE-----
MIIDxTCCAq2gAwIBAgIQAqxcJmoLQJuPC3nyrkYldzANBgkqhkiG9w0BAQUFADBs

>  Another possible explanation is that you are using some HTTP proxy doing
> something strange (i.e. bad) with the certificate.

Not to my knowledge. Certainly not because of anything I've knowingly done.

> In this "curl -v" should
> tell you something different. And you could always use openssl to show even
> more details. Here is what it shows here, if you'd like to compare your
> output:
> 
>       % echo | openssl s_client -showcerts -connect dl.fedoraproject.org:443
[...snip your output...]

[root@ugolyok]/tmp# echo | openssl s_client -showcerts -connect 
dl.fedoraproject.org:443
zsh: command not found: openssl

Hmmm. I guess I'd better install that:

[root@ugolyok]/tmp# yum install openssl
...
Installed:
  openssl.x86_64 1:1.0.2k-19.el7                                                
                   
Complete!

Now retrying:

[root@ugolyok]/tmp# echo | openssl s_client -showcerts -connect 
dl.fedoraproject.org:443
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High 
Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 
High Assurance Server CA
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat Inc., CN = 
*.fedoraproject.org
verify return:1
---
Certificate chain
 0 s:/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc./CN=*.fedoraproject.org
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
-----BEGIN CERTIFICATE-----
MIIGaDCCBVCgAwIBAgIQBgAdcIAphhlAa5cCvBVVJTANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xNzAyMDEwMDAwMDBaFw0yMDA1MDExMjAwMDBa
MG0xCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Ob3J0aCBDYXJvbGluYTEQMA4GA1UE
BxMHUmFsZWlnaDEVMBMGA1UEChMMUmVkIEhhdCBJbmMuMRwwGgYDVQQDDBMqLmZl
ZG9yYXByb2plY3Qub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
37LQjTJywmLXo+XygC/0A4BnhIxTxVSyvDfeUefjLga9HmG+/V0E5AsRCORJJIg9
0Coe7n6GM8gZMb9zCX/FlEd3SibbNHHLN7lijd6sT75ZiRYYrcfOPvx/EFvqUOZ7
kOV65ecFR8TiI2znPHcXEXgiRQwCXUY11NH5s/2PVwORUeEr+ZPGTfqIqjD0lcqv
Ls2jNx1Lce1bNNSug2ReMXfdPm59j/dmhMdqOrSyr74JFCYwIuBHneH41YLshBml
WZE3dQGqwpKezVTFFNqT7frozhlQrvd4gXgB+3ULZynnkFfVnSMfGLZpE3zk2LAB
5rEG8cQ+Nu9VH7PjavrRZkVmmoosB0AZ5iXYdJdwc2lknA72jkajVVvljFDEfn9Y
KDdoXJlhfX4OyVzO2ab6tjt5ZY0gBGLVN2soTfXbeoCR4ErnKD9pxjqKWm9OFgLI
ETEAxS0Y+dASTYFVZOvujbELlilQp0Ixmbs2WRwHsfKzZKvR1upqzOpnqd4ljYHY
dtUA5WyTdUTSlKv3NjD3FAQw8xByHtI/Hyf7RVIRlWy/9di7CoEsOsdq4NGps+9s
I42W4sd9gFXDCQzylX5MqZlgteIlW8wG/63s0O/dJW8U6BFuAN166PH0uYXT5k4W
QED2HDoie8JQy7Y1inDBhDo+zA7eqWrZIO9/8h9D+ZUCAwEAAaOCAf8wggH7MB8G
A1UdIwQYMBaAFFFo/5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBTf0GV/3Qey
/Q4CMu7XrW3kk4OtJjAxBgNVHREEKjAoghMqLmZlZG9yYXByb2plY3Qub3JnghFm
ZWRvcmFwcm9qZWN0Lm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYB
BQUHAwEGCCsGAQUFBwMCMHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRp
Z2ljZXJ0LmNvbS9zaGEyLWhhLXNlcnZlci1nNS5jcmwwNKAyoDCGLmh0dHA6Ly9j
cmw0LmRpZ2ljZXJ0LmNvbS9zaGEyLWhhLXNlcnZlci1nNS5jcmwwTAYDVR0gBEUw
QzA3BglghkgBhv1sAQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNl
cnQuY29tL0NQUzAIBgZngQwBAgIwgYMGCCsGAQUFBwEBBHcwdTAkBggrBgEFBQcw
AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tME0GCCsGAQUFBzAChkFodHRwOi8v
Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEySGlnaEFzc3VyYW5jZVNl
cnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQBiAwx1
DjSBQoum+ZDbX57ZHWvOAtausc6oMk5j02jco8c5Cc3fZoNHrhAxmCxLdGgdWz5q
CeyWrsNl2+znX3iTUUUsjOPPjOjDDfZKkphKW7dFA0ec6tW6bZ+5BeRfjos1ZlqO
d0Yey/Hti5T3sVN5jwBGJCXyb8PxLDfi5XEccP8DMIa91EdmERyblTotMyQ8O1He
P3VNdGG7tJY53IFr5gRZ/BuQe99k+P5eQ7iHMv6K8DjR6apRY+LJ/Li0y2bwlF1x
GzQz5B4XCOHC23A+11tH1tW/LSUF0g5RaQxldVrRBn74ec9Sc1NkFsZC1bn4FYYt
DWfhteUyLpUczjDE
-----END CERTIFICATE-----
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV 
Root CA
-----BEGIN CERTIFICATE-----
MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowcDEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEvMC0GA1UEAxMmRGlnaUNlcnQgU0hBMiBIaWdoIEFzc3Vy
YW5jZSBTZXJ2ZXIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2
4C/CJAbIbQRf1+8KZAayfSImZRauQkCbztyfn3YHPsMwVYcZuU+UDlqUH1VWtMIC
Kq/QmO4LQNfE0DtyyBSe75CxEamu0si4QzrZCwvV1ZX1QK/IHe1NnF9Xt4ZQaJn1
itrSxwUfqJfJ3KSxgoQtxq2lnMcZgqaFD15EWCo3j/018QsIJzJa9buLnqS9UdAn
4t07QjOjBSjEuyjMmqwrIw14xnvmXnG3Sj4I+4G3FhahnSMSTeXXkgisdaScus0X
sh5ENWV/UyU50RwKmmMbGZJ0aAo3wsJSSMs5WqK24V3B3aAguCGikyZvFEohQcft
bZvySC/zA/WiaJJTL17jAgMBAAGjggFJMIIBRTASBgNVHRMBAf8ECDAGAQH/AgEA
MA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
NAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybDQuZGlnaWNlcnQuY29t
L0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWUm9vdENBLmNybDA9BgNVHSAENjA0MDIG
BFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQ
UzAdBgNVHQ4EFgQUUWj/kK8CB3U8zNllZGKiErhZcjswHwYDVR0jBBgwFoAUsT7D
aQP4v0cB1JgmGggC72NkK8MwDQYJKoZIhvcNAQELBQADggEBABiKlYkD5m3fXPwd
aOpKj4PWUS+Na0QWnqxj9dJubISZi6qBcYRb7TROsLd5kinMLYBq8I4g4Xmk/gNH
E+r1hspZcX30BJZr01lYPf7TMSVcGDiEo+afgv2MW5gxTs14nhr9hctJqvIni5ly
/D6q1UEL2tU2ob8cbkdJf17ZSHwD2f2LSaCYJkJA69aSEaRkCldUxPUd1gJea6zu
xICaEnL6VpPX/78whQYwvwt/Tv9XBZ0k7YXDK/umdaisLRbvfXknsuvCnQsH6qqF
0wGjIChBWUMo0oHjqvbsezt3tkBigAVBRQHvFwY+3sAzm2fTYS5yh+Rp/BIAV0Ae
cPUeybQ=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc./CN=*.fedoraproject.org
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance 
Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3799 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 805FA9A9379697A2A6DA2B3B8C58F3ABDFFE709B4944E0811A1A640D0864346F
    Session-ID-ctx: 
    Master-Key: 
5DBDD41338064E71B428591F04936738A91A2DDC1D852EC8493DD580D175125A48D6E819362183F60EE6C24120BBCED6
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 06 33 14 9d 9c fd 19 70-a7 60 dd df 31 ef 34 bc   .3.....p.`..1.4.
    0010 - 69 cc 4e 8d b3 ec af 6c-fe d5 fb 52 2e 1d 20 9a   i.N....l...R.. .
    0020 - 6f 71 c3 22 c9 da ea c7-62 82 5c b0 04 2f d1 5e   oq."....b.\../.^
    0030 - 44 f5 5a 71 31 da 8e 4a-78 91 60 7a 02 f6 f0 38   D.Zq1..Jx.`z...8
    0040 - 9f 37 92 79 75 b2 fb dd-dc 5a 79 e6 77 f2 6c f8   .7.yu....Zy.w.l.
    0050 - cf a2 47 8d b2 cb ed c8-6e 5f cb 1e f4 19 9c b5   ..G.....n_......
    0060 - 86 de 98 0a 4a 8a 08 68-e8 c4 15 c5 24 7f ff d9   ....J..h....$...
    0070 - 13 bc 8a a2 8e ee 33 be-e6 ad 5e d3 ee 86 29 54   ......3...^...)T
    0080 - 2f eb 6e e4 d8 f1 c3 57-41 2f b3 34 0b 2b 7f cb   /.n....WA/.4.+..
    0090 - 73 e2 b6 25 aa 1c 09 f2-0c ec 91 99 7a 3b 57 54   s..%........z;WT
    00a0 - 74 71 7a e0 64 49 80 7a-aa 62 a4 46 a2 66 bf b7   tqz.dI.z.b.F.f..
    00b0 - 91 09 92 f8 7a 33 18 75-96 c1 48 d5 53 36 bf 91   ....z3.u..H.S6..

    Start Time: 1570059986
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

I hope that helps. I see some differences between yours and mine,
but nothing jumps out at me as particularly interesting.

> GC> I wasn't sure whether I needed to be in an 'scl enable' shell,
> 
>  No, this is definitely irrelevant here.

Okay, thanks.

Let's retry the command that failed, to see whether installing openssl
made a difference:

[root@ugolyok]/tmp# rpm -ivh 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Retrieving 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
curl: (77) Problem with the SSL CA cert (path? access rights?)
error: skipping 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - 
transfer failed

Nope, same failure as before.

> GC> I tried the following suggestions:
> GC> 
> GC> # 
> https://stackoverflow.com/questions/27987091/ssl-ca-cert-path-access-rights
> GC> # doesn't help:
> GC> rm -f /etc/ssl/certs/ca-bundle.crt && yum reinstall -y ca-certificates
> 
>  BTW, /etc/ssl/certs is just a symlink to /etc/pki/tls/certs, which
> explains why a different certificate store is shown above.

And it fails the same way again if I retry it after reinstalling 
ca-certificates:

[root@ugolyok]/tmp# yum --assumeyes reinstall ca-certificates

> GC> Any other ideas?
> 
>  Well, you could use "curl --insecure" to download the package and then
> "rpm -i" to install it (I don't know how to pass extra curl options
> directly via rpm, or even if it's possible at all). But this shouldn't be
> necessary, of course...

Let me try 'wget' because I'm more familiar with it than with 'curl'.
I'll follow the instructions here:
  https://serverfault.com/questions/811179/disable-ssl-check-rpm

[root@ugolyok]/tmp# yum --assumeyes install wget
...Complete!

[root@ugolyok]/tmp# wget 
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
--2019-10-03 00:04:23--  
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Resolving dl.fedoraproject.org (dl.fedoraproject.org)... 209.132.181.23, 
209.132.181.25, 209.132.181.24
Connecting to dl.fedoraproject.org 
(dl.fedoraproject.org)|209.132.181.23|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15264 (15K) [application/x-rpm]
Saving to: 'epel-release-latest-7.noarch.rpm'

100%[=========================================================>] 15,264      
--.-K/s   in 0.1s    

2019-10-03 00:04:24 (148 KB/s) - 'epel-release-latest-7.noarch.rpm' saved 
[15264/15264]

That seems good: I didn't need '--no-check-certificate'. Continuing:

[root@ugolyok]/tmp# ls -1
epel-release-latest-7.noarch.rpm
setup0.sh
[root@ugolyok]/tmp# rpm -ivh epel-release-latest-7.noarch.rpm                   
                  
warning: epel-release-latest-7.noarch.rpm: Header V3 RSA/SHA256 Signature, key 
ID 352c64e5: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:epel-release-7-12                ################################# [100%]

That seems really encouraging. However, when I move on to the next step,
it fails as posted at the end of this message. Options 3, 4, and 5 seem
to suggest suppressing this EPEL repository, but AFAICS that can't help.
Option 1 doesn't look like a winner, either: I've followed many links on
the web, and found no evidence that this is fedora's problem. Is option 2
worth trying, and if so, how, specifically?

[root@ugolyok]/tmp# yum install -y debootstrap.noarch
Loaded plugins: fastestmirror, keys, protectbase
Loading mirror speeds from cached hostfile


 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/x86_64. Please verify its path 
and try again