On 05/07/16 18:20, Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Mon, 04 Jul 2016, lejeczek wrote:

On 04/07/16 07:59, Petr Spacek wrote:
On 1.7.2016 16:29, lejeczek wrote:

On 01/07/16 12:41, Petr Vobornik wrote:
On 06/30/2016 04:56 PM, lejeczek wrote:
... its own FQHN and its IP ?

hi users,

I'm fiddling with rewrites but being an amateur cannot figure it out,
it's on a multi/home-IP box. Is it possible?

many thanks,


Hi L.

Could you describe your environment and use case in more details.
It is
not clear to me what you are trying to achieve or what doesn't work
for you.

Thank you
gee, I though my scenario would be quite common among users, take a box with more then one net ifs, or even multiple IPs - what
would be
nice to have is fIPA webui resides/runs only on that FQHN and that
IP to which
hostname resolves. Eg, here is one single system:
box1.my.dom.local (eg, I go to
currently I get fIPA's webui everywhere, but I'd like it to be only at ipa.my.dom.local (either if I URL via hostname or IP)
I think it would be great to have included (maybe as
comments/options) this in
Apache's configs of IPA furure releases, if possible.
Is it possible to construct such rules? Or there is different,
simpler way?
I'm still trying to understand your use-case. Why exactly you need to
the web UI to one 'host name' while keeping it on the same box?

I'm sorry I cannot explain this better, I my mind it's really simple, if I installed an instance of IPA on a ipa.my.dom.local and the system is a multi-homed/IP host I'd like webui to run only on that host/IP This should not even be a matter of "image a situation where...." but rather assume that IPA's are deployed on such installations and then - why would fIPA have to monopolize all the IP's/IFs there are? Me, I'd like to be able to use httpd under a root of host's other
FQHN/IPs with other things.
Your IPA masters hold passwords and keys to your company's
infrastructure. We recommend to avoid sharing the servers used for running IPA masters with any other applications because any compromise of those applications can and will be used for taking over your infrastructure as you have so nicely given the keys to its heart by
co-sharing the same system.

It is up to you on how you make up your system defense. We as FreeIPA upstream developers put considerate effort in ensuring our default setup is secure enough to avoid such breaches. If you want to co-locate other applications, you need to understand what you are doing and how that affects your security. Effectively, you are on your own on this path.

FTR, I think this is mostly controlled in ipa-rewrite.conf. If the requested host is not the IPA host or the port is not 443 or the request is for / then ALL requests are redirected to the https://IPAHOST/ipa/ui

This file should have enough comments to figure out what part is doing what if you wanted to tweak it. I have to agree with Alexander though. Running multiple services on what should be the core of your infrastructure isn't recommended.

I know chaps, yes, safety is when paranoia next to it, together does look like normal wording, I understand. yes, that I think is the config and seems that to control this behaviour is that one rewrite rule. However, you must also realize that fIPA admins rarely do install on a separate, dedicated boxes, instead I believe these are "heavy, bulky" and fast and multi-role/connected systems. So having an easy way to control fIPA webui config as an option(if not as default) is great, and it seems it's there.

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to