Justin Sherrill wrote: > Michael DeHaan wrote: > >> Justin Sherrill wrote: >> >> >>> Hi All, >>> >>> Currently when you specify a port for koan it: >>> >>> 1. Tries port 80, if that fails: >>> >>> >>> >> Yes, specifically it tries http://$server:80/cobbler_api_rw first, which >> is the Apache proxied endpoint. >> >> If that fails, the usage of port is for a direct connection, not using >> Apache proxying. >> >> (Also, if --server=DISCOVER is set it will try looking through Avahi >> before doing either) >> >> >> >> >>> 2. Tries the port you specified. >>> >>> >>> >> >> >> >>> I'm changing it such that it will: >>> >>> 1. Try the port you specify, if that fails: >>> 2. Tries port 80. >>> >>> >>> Also, I'm adding support for SSL. Would koan users prefer: >>> >>> a. A '--ssl' option that tries on SSL if specified >>> >>> >>> >> I am not sure there is a good reason at all to let koan use SSL. All of >> the data koan retrieves is available over non-secured protocols (TFTP >> for starters, and HTTP) so there is nothing to hide. I think trying the >> specified port first makes sense. >> >> > For spacewalk integration this is a requirement IMHO. > Spacewalk/satellite as it is today allows provisioning over pure SSL > which is a requirement for many of our customers. I've heard many > hair-brained network security schemes from customers that require this > (not provisioning specifically, but just their traffic in general). >
Kind of. (A) PXE is the way a vast majority of users bring up bare-metal systems. This is not authenticated by design so that it is actually usable for automation :) (B) Anaconda does not support authentication, the kickstart file transfer and tree downloads are always exposed. If the contents of those files are exposed, there is nothing to encrypt. At best you are limiting the ability of someone to MITM a koan transaction when it is /impossible/ to do the same for a PXE transaction, and at this point you have greater problems. If we do want that level of security, we also want to check certificates between the server and the client, which a simple anonymous SSL solution won't do. In this case, what you really want is a low level API call to func that transfers a kickstart file (remember, all kickstart files are public) at which point the only thing that is really protected is making sure certain metadata parameters are accurate -- such as not providing a guest with extra RAM. > If you look at what just koan is doing, i agree there isn't any reason > for it to be encrypted. If you look what koan could be a part of then > there is benefit of having the entire process be encrypted. > That's exactly my point -- The entire process is unencryptable, so an attempt to encrypt small parts of koan result in an illusion of security when it's not there. This is not a problem as the ability to provision bare metal guests requires this. > -Justin > > >> >> >>> b. if 443 is passed in try on 443 with SSL, if that fails try on port >>> 80 w/o SSL >>> >>> >>> >>> >> How about if the XMLRPC port connection fails because the port is >> encrypted (with an appropriate exception which I suspect the XMLRPC >> module should raise), trying to treat the port as an SSL connection? >> >> --Michael >> >> >> >>> -Justin >>> _______________________________________________ >>> cobbler mailing list >>> [email protected] >>> https://fedorahosted.org/mailman/listinfo/cobbler >>> >>> >>> >> _______________________________________________ >> cobbler mailing list >> [email protected] >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > > _______________________________________________ > cobbler mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
