Configure MunkiServer Console

[rickychilcott]

After model-agnostic settings are complete, allow MunkiServer to operate in one of three modes:

1. Respond to computers and management console -- This would act how it currently does.
2. Respond to computers only -- this would allow us to
3. Do not respond to external requests -- this would be for a testing or to shut down a server temporarily for maintenance

We could also have a number 4) which would be management console only, but I'm not sure that is absolutely necessary

[jnraine]

If/when the munki client's are relegated to a different Rack instance serving manifests, catalogs, and packages, I want to keep things as simple as possible. Ideally, there are no "master" or "slave" instances with munkiserver – they would all be equivalent and would all run both interfaces.

Having said that, it is hard to say how clustering and scaling will work at this point. We'll need to discuss this further as we go along.

[rickychilcott]

I don't see them being masters or slaves, per say. The problem, is that we need to minimize the exposure to the MunkiServer web console on the public facing machines, and to do that, we need to be able to turn it off. Do you see any way to achieve that without developing a feature?

[jnraine]

Perhaps we are viewing the infrastructure differently. I imagine our clustering to be multiple instances of munkiserver connecting to shared filespace and database, behind a load balancer. Access to the management UI is, for example, on port 443 over SSL while access to the munki client UI is on port 4443 over SSL. This delineates the code on the server and allows admins to limit access to a server from the firewall or load balancer.

What infrastructure and access controls do you imagine?

[rickychilcott]

Sorry for the long delay in response.

So, then we are splitting the app in two? I know I had suggested that a while back, but I've re-thunk the problem. What Casper's JAMF does is have the ability to make an instance (talking to a shared database) either be a full system (mgmt UI and client UI) or a stripped down (client UI system only). #3, which I defined above, would not need to exist, but might be helpful -- this could be achieved with a very simple before_filter on the application controller.

We will need the ability to allow a full system available to only certain IP ranges (or through VPN) and potentially many instances which only have a client UI accessible.

http://stackoverflow.com/questions/6755332/one-rails-app-serving-multiple-urls-can-it-be-done shows that a single rails app responding to multiple ports, would be possible, but it would be recommended to split the app in two. To solve it now, what I'm suggesting is essentially conditionally defining routes for the management UI upon app start, if the system is for a full system. If not, only define client UI routes.

Do you think that could solve the problem?