Alarcón, On 5/6/15 11:56 AM, Alarcón Vladimir wrote: > As requested, I will do a write-up of the high-level architecture, > and a list of features in phases. > > In terms of security I think the command-line interface could be > secured by definition since it will be only available on the prod > environment (or qa, or test, or dev respectively). In prod I only use > vlans. The whole set of machines is isolated from other network > segments all the time. To access them the firewall only allows me to > get into the machines through a specific port, but this will depend > on the security on each environment. > > The web interface is probably a little bit different. We will > probably like to allow users to connect remotely, but from a secured > net segment only available though a vpn or similar. In any case, it > will be available over HTTPS only and will need to have user/pass > security at the very least. Other options can be considered.
Were you envisioning a web-based interface to this tool, or are you talking about some other kind of UI? I personally don't need any web-based UI for something like this, but others may appreciate a point-and-click interface. The good news about command-line tools is that they are usually trivially scriptable via GUIs. > On the "Informing the LB question", the tool architecture as I see it > will include "hooks" (related to events), so custom scripts could be > added to suit specific needs of each installation/environment. This > way the end user could the hooks to implement integration points to > other systems. Perfect. I happen to use a fleet of httpds with mod_jk as my load-balancers, but others may use something else. Providing hooks to listen for various events would be the perfect way to customize this kind of tool for a particular environment. -chris
signature.asc
Description: OpenPGP digital signature
