Open AloisMahdal opened 7 years ago
and someone would wants ::1 ip addr too.
We have a downstream test for updates; while it's meant for preupg -u
mode (and this bug is in -ui component), it should be easy to extend it and sneak in more forms of host specification. (We should write UI-targeted test in the future; not sure if it's possible now, though.)
The forms tested should include:
localhost
,localhost4
,localhost6
,localhost.localdomain
,127.0.0.1
,::1
.On a second thought, we should review the decision to use hostname-based VirtualHost. I'm no expert on Apache, but I think our use case is not what it's meant for. In other words, since we already use unique port, we should not require Host:
to be set to a particular value; this is meant for cases when you run multiple different sites on same host.
The problem with our "private" setup is that we don't know what the value of Host:
will be. There's at least 127.*
(256^3 ways), plus the above listed ways (which might not even be complete) to address local host. And if you use e.g. SSH tunnelling, the Host:
could be actually anything.
If people want to run a permanent preupgrade-assistant-ui instance, they can always use reverse proxy; I think that is the standard solution these days anyway.
(The qa_ack comment remains valid, though.)
localhost
works fine for me (2.4.4-1.201708291731Z.master.el6_8). However I needed to put http://
in front.
# preupg -u http://localhost:8099/submit/ -r /root/preupgrade-results/preupg_results-170830085339.tar.gz
The report submitted successfully. You can inspect it at http://localhost:8099/1/detail/.
Oh, I see, I've used the 99-preup-httpd.conf.public
, not the private
one.
The virtual host config in 99-preup-httpd.conf.private prevents
http://localhost:8099/...
to work; theHost
has to be127.0.0.1
.(I'm not sure now what should be changed there.)