nope, not in my env - and I believe I do a plain-vanilla
deployment with 'cephadm'
I might have:
-> $ ceph config-key get mgr/dashboard/key
Error ENOENT:
-> $ ceph config-key get mgr/dashboard/crt
Error ENOENT:
-> $ ceph config-key get mgr/dashboard/podster3.mine.priv/key
-----BEGIN PRIVATE KEY-----
MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCw7whSWhNzKln/
...
-> $ ceph config-key get mgr/dashboard/podster3.mine.priv/crt
-----BEGIN CERTIFICATE-----
MIIFIjCCA4qgAwIBAgIED/sABDANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlN
...
-> $ ceph config-key get mgr/dashboard/podster1.mine.priv/key
-----BEGIN PRIVATE KEY-----
MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDbKrY2d/Tsg3xG
...
-> $ ceph config-key get mgr/dashboard/podster1.mine.priv/crt
-----BEGIN CERTIFICATE-----
MIIFIjCCA4qgAwIBAgIED/sAAjANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlN
...
-> $ ceph mgr services
{
"prometheus": "http://10.1.1.63:9283/";
}
The moment I add/recreate "global" cert:
-> $ ceph dashboard set-ssl-certificate -i
/root/bin/podster1.mine.priv.crt
-> $ ceph dashboard set-ssl-certificate-key -i
/root/bin/podster1.mine.priv.key
dashboard starts and ! without fail/disable/enable:
-> $ ceph mgr services
{
"dashboard": "https://10.1.1.63:8443/";,
"prometheus": "http://10.1.1.63:9283/";
}
But that, as show above, as per my original, first message,
makes...
In this case: 10.1.1.63 is poster3 - makes poster3 report
"invalid" cert for it's poster1's cert.
I believe this is a bug and is easily reproducible - unless
it's intended behavior?
Since I reported, I moved to 'reef' from 'squid' - the same
(mis)behavior - I'm on Centos 9.
I merely deploy a cluster with:
-> $ cephadm bootstrap --mon-ip 10.1.1.61 --mon-id
podster1.mine.priv --allow-fqdn-hostname
which does its things. I add host, monitors, etc.
Everything else seems to be a ok, it reproduces every time.
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
