I had considered virtualisation, but it's another learning curve to go through and until we have a product, all time spent getting the infrastructure in place is pushing back the product delivery. If we are successful then getting new servers won't be an issue. If we aren't it doesn't matter, except as an intellectual exercise. Ironically, if we are successful the problems go away anyway as I will no longer need to fit stuff around my day job and so won't need to access the systems the from the train, etc. and will be able to work on the local network most of the time!
Regards Simon Williams On Oct 8, 2012 3:37 PM, "Petr Spacek" <pspa...@redhat.com> wrote: > Hello, > > Did you consider virtualization for host accessible from public networks? > > Performance degradation is usually small nowadays and you can save some > headaches (and create different one :-)). > > Petr^2 Spacek > > On 10/08/2012 04:19 PM, Simon Williams wrote: > >> I understand exactly where you are coming from Alexander and in an ideal >> world >> the web sites that I want to get at externally would be on a different >> server. >> I am not the normal type of FreeIPA user, being a very small business >> with >> only a couple of users and half a dozen or so machines and, currently, >> very >> limited resources. IPA makes it so easy to administer the network however >> that I would be loathed not to use it! We are developing software and I >> only >> have one server that I can dedicate to being a stable host. I have two >> other >> machines on the network that are currently always on and both are used for >> development both running Fedora, one x64 and one Arm. Neither of these >> machines could be considered stable. The other machines are a mix of >> Windows >> and Fedora laptops, soon to have a Mac added if my partner gets her way. >> I >> currently restrict access to the IPA name virtual server by not having a >> publicly accessible name for it (and using "deny all", "allow /local >> network/", but I don't think that does anything as the incoming packets >> are >> routed using NAT, but it costs nothing to have it there!). I realise that >> this is insecure as a request on port 443 that does not have a host name >> will >> be handled by the default and therefore IPA name virtual server. That is >> something I still have to address, but was intending to make the default >> name >> virtual server just redirect to a 404 error page. >> >> I had already found, read and tried the guide at the link you sent, that >> is >> how I discovered that mod_ssl and mod_nss wouldn't co-exist. >> >> Your comment Rob has started me thinking along different lines than I >> was. If >> the mod_ssl/mod_nss incompatibility only exists if the same port and IP >> address is used, since I specifically don't want the IPA server to be >> available outside the local network, I could either use a different port >> for >> the non-IPA name virtual servers (the gateway could still present 80 and >> 443 >> to the outside world since the gateway is redirecting the packets >> anyway). Or >> a different virtual IP address on the server for the non-IPA sites (only >> one >> NIC on the server and no free slots, so couldn't be physically separate). >> This would kill two birds with one stone (ie. make the IPA instance more >> secure and solve the certificate problem). It would also make it easier >> to >> put the non-IPA web servers on a different machine when I am in a >> position to >> do that. >> >> Thank you both for your help. I think that you have prodded me in the >> right >> direction for a workaround. >> >> Regards >> >> Simon Williams >> >> On Mon, Oct 8, 2012 at 1:45 PM, Rob Crittenden <rcrit...@redhat.com >> <mailto:rcrit...@redhat.com>> wrote: >> >> Alexander Bokovoy wrote: >> >> On Mon, 08 Oct 2012, Simon Williams wrote: >> >> I have found a problem with mod_nss that appears to have been >> reported in >> 2010, but I cannot find any further reference to it. The 2010 >> reference >> contains a comment saying that it is an issue and needs to be >> fixed. I >> have not been able to find any issue tracking system for >> mod_nss >> and so >> haven't been able to check on the status. >> >> The problem is that mod_nss does not appear to respond with >> the >> correct >> certificate when multiple name virtual servers are configured >> on an >> instance of Apache. It always responds with the certificate >> of >> the first >> name virtual server defined. It does process the other sites' >> configurations because it complains if certificates with the >> aliases used >> are not in the database. This would not be an issue (for me) >> if >> mod_ssl >> could be used for virtual servers other than the IPA server, >> but they >> cannot co-exist. If you try to mix them, mod_ssl complains >> that >> port 443 >> is being used for the IPA server, but it is not SSL aware. I >> suppose it >> would be possible to reconfigure the IPA name virtual server >> to use >> mod_ssl >> bu exporting the certificate, but I really don't like to muck >> around with >> the directory server configuration more than is necessary as >> it is >> vital >> that it remains stable and secure. >> >> Could anyone enlighten me as to whether this issue is being >> looked >> at or >> even if it is fixed and the CentOS people (CentOS 6.3 standard >> repositories >> all packages up to date as of yesterday) just aren't >> supplying a new >> enough >> version of mod_nss. At the moment, I can use my SSL secured >> sites >> as the >> encryption works okay, but I cannot open them up as they >> report >> the wrong >> host name in the certificate. >> >> I assume all this comes because you run these virtual servers on >> the >> same instance as FreeIPA master itself, thus conflicting mod_ssl >> and >> mod_nss. >> >> Here is description how to make name-based SSL virtual hosts >> working in >> FreeIPA environment using mod_ssl. This howto assumes you are >> using a >> separate server than FreeIPA master to provide actual hosting for >> the virtual hosts which also makes sense because one would need >> to apply >> greater security protection to the KDC which runs on the same >> FreeIPA >> host. >> >> >> http://freeipa.org/page/__**Apache_SNI_With_Kerberos<http://freeipa.org/page/__Apache_SNI_With_Kerberos> >> >> <http://freeipa.org/page/**Apache_SNI_With_Kerberos<http://freeipa.org/page/Apache_SNI_With_Kerberos> >> > >> >> >> >> mod_nss doesn't support SNI because NSS doesn't support SNI >> server-side >> yet >> (https://bugzilla.mozilla.org/**__show_bug.cgi?id=360421<https://bugzilla.mozilla.org/__show_bug.cgi?id=360421> >> >> <https://bugzilla.mozilla.org/**show_bug.cgi?id=360421<https://bugzilla.mozilla.org/show_bug.cgi?id=360421> >> >). >> >> The mod_nss bug tracker is bugzilla.redhat.com < >> http://bugzilla.redhat.com>. >> >> mod_ssl and mod_nss can co-exist but not on the same port (which is >> true >> of any two servers). mod_ssl and mod_nss cannot co-exist on an IPA >> server >> though, because mod_proxy only provides a single SSL interface and >> mod_ssl >> always registers it, locking mod_nss out. This is being worked on in >> mod_proxy. >> >> Switching to mod_ssl wouldn't require any changes to the directory >> server. >> >> rob >> > > ______________________________**_________________ > Freeipa-users mailing list > Freeipaemail@example.com > https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users> >
_______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users