I've noticed that 1.9.1 (and just tried the same on 1.9.2) uses HTTP/8443
to collect/refresh the facts from discovered hosts regardless of what is
configured on a client. As I understand, it is supposed to be either
HTTP/8000 or HTTPS/8443, not plain HTTP over 8443. I've a generic cert for
all discovered hosts loading by default and wanted to use HTTPS between
Foreman and those hosts. If I use those certs in settings.yml on a client
side, I get the following error in Foreman UI while trying to refresh the
facts for already discovered node:
Oops, we're sorry but something went wrong
×
Warning!Could not get facts from proxy http://<IP>:8443: Connection reset
by peer
Interestingly enough, new hosts have no issues registering for the first
time while configured to use HTTPS, but after that Foreman tries to use
plain HTTP for the facts or reboot. More over, in
/etc/foreman-proxy/settings.yml I also have to enable HTTP port on 8443 as
8000 wouldn't be used by Foreman either.
In my pxeconfig file I have foreman.url=https://<fqdn>
Is this expected and by design and I should not be trying to use HTTPS
here? Otherwise, how do I enable it?
> Is this expected and by design and I should not be trying to use HTTPS
> here? Otherwise, how do I enable it?
Hello,
this is a new behavior I forgot to announce on the list, just added it
into our documentation:
Smart-proxy now listens on both HTTP/8448 and HTTPS/8443 ports and by
default, new self-signed certificate is generated on each discovered
node with common name set to IP address of the primary interface. Images
prior 3.0 were using HTTP/8443 combination.
Since we are changing the API on discovered nodes, I took this chance to
change the port from the misleading 8443 to 8448. Discovery 4.1+ is
aware of this change and if a node reports older version than 3.0 it
will attempt to reboot it using the old API and port.
In the future, it would be very useful to have any kind of
authentication on discovered nodes (Foreman signing certs or something).
If you implemented that already, patches are welcome!
There are no patches I had to implement and the reason is that I don't use
your discovery image. Instead, I'm installing smart-proxy packages on our
internally-developed (but Casper-based) netbooted OS.
There are several reasons for this approach for us and w/o going too deep
on that I can mention that we have more capabilities in our miniOS than
your current image. Those capabilities allowing us to run some scripts
(taken off git, not located on the image) to check HW compliance rules
we;ve set and auto-fix some of the known issues (for example BMC set to
static IP vs expected DHCP one, etc.
The other very important thing is the "command channel" I mentioned in
other thread (where we're discussing hooks for discovered nodes). That
channel allows us to execute tasks on the nodes through RESTful API. The
example would be RAID reconfiguration, FW upgrades, etc.
That's why I was so excited to see that you're planning FW upgrade
capabilities as well so wanted to see how that's going to implemented - on
top of some exec API, similar to "command channel" or something else. If
the former, I can see how that exec API can be reused for other tasks -
RAID reconfig that I already mentioned, image-base provisioning that you
plan to implement is most probably would be using the same channel. Anyway,
this is topic for other conversation I guess.
Back to HTTP/HTTPS. Since I use that miniOS image of ours, I have an
ability to place a generic signed SSL cert on it that is used by all nodes
loading that image. Not ideal, of course, but this is what it is right now.
I'm thinking about generating a real cert, but have to make sure such
implementation would not affect puppet-ca in our org.
In regards to 8448 - I have not seen such changes in 1.9.0 smart-proxy (the
one I use now). Which version is that introduced in?
> In regards to 8448 - I have not seen such changes in 1.9.0 smart-proxy (the
> one I use now). Which version is that introduced in?
This was introduced in the image 3.0.0 and discovery plugin 4.1.0. Make
a firewall rule to forward traffic from one to another as a workaround
perhaps.
Casper is Ubuntu LiveCD netbootable image. Basically it is a full-blown
Ubuntu OS, however there is a huge drawback - NFS is a requirement as
majority of OS data (files/binaries/libraries) is on read-only NFS share
some place.
> This was introduced in the image 3.0.0 and discovery plugin 4.1.0. Make
> a firewall rule to forward traffic from one to another as a workaround
> perhaps.
Does your 3.0.0 image uses standard Foreman smart-proxy package? Which
version?
I'll play around with new discovery and hooks plugins next week or
hopefully even sooner.
