Your message dated Fri, 3 Jan 2025 10:19:29 +0100
with message-id <[email protected]>
and subject line Fixed
has caused the Debian Bug report #1012415,
regarding keystone install fails
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1012415: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012415
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: keystone
Version: 2:21.0.0-3
I was trying to install a base instance of keystone (apt install
keystone and later apt upgrade keystone with repeated tries) with
everything synced to yoga. I've only done an install for keystone, so
perhaps if I was installing the whole openstack cloud architecture in
one go, this problem would have been avoided, but I'm only looking to
run a very select number of openstack components so was trying to just
install them by themselves as a test.
If a FQDN is specified as the identity source with https requested
during the pop up question and answer session (and the proper
certificates are provided after it fails the first time), installation
fails because keystone.postinst is hard coded to use
http:127.0.0.1:5000/v3/ as the identity url even though the correct
endpoint is provided on the keystone bootstrap command started by the
postinst script.
Output... Now doing: su keystone -s /bin/sh -c 'keystone-manage
bootstrap --bootstrap-role-name admin --bootstrap-service-name keystone
--bootstrap-region-id regionOne --bootstrap-admin-url https://FQDN:5000
--bootstrap-public-url https://FQDN:5000 --bootstrap-internal-url
https://FQDN:5000'
A curl command works after the fact to return something without
complaining, so the 5000 socket does get created properly by the
keystone-manage bootstrap above.
If the http://127.0.0.1:5000 instances in the post install script are
changed to https://FQDN:5000, everything works and the installation
completes. I realize that perhaps most people just do http and take the
defaults, converting to https once the install is done. But if it is
going to ask for the http vs https request type, then it should follow
through and work (hopefully asking for the locations of the certificates
as well so it doesn't fail the first time). I had done the https because
eventually this will be a multiple VM setup so we wanted https to the
identity server.
I had also tried specifying the OS_AUTH_URL and
OS_BOOTSTRAP_INTERNAL_URL as a test but these seem ignored or recreated
to the bad http://127.0.0.1:5000 values during the install process.
Pretty sure it doesn't matter but using Linux version
5.16.0-0.bpo.4-amd64 ([email protected]) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1
SMP PREEMPT Debian 5.16.12-1~bpo11+1 (2022-03-08) and libc6 2.33.7.
--- End Message ---
--- Begin Message ---
Hi,
I believe this was fixed when uploading 2:26.0.0-3. Please let me know
(by re-opening this bug) if it's not the case.
Cheers,
Thomas Goirand (zigo)
--- End Message ---
