Random concept ideas. this could get huge and complex real quick.. but here are some ideas to consider.
A new table for tracking services. That information would show up on at least hosts (probably silly to go to subnet and beyond)
Attributes that would be useful to track under service:
name
listen port(s)
listen ip/interface(s) (likely associate to existing interface on host but do we want to require that)
source ips (possible link to a subnet could be done here?)
destination ips (possible link to a subnet could be done here?)
Possible custom attribute tracking
Possible tag tracking
should there be a 'type'? seems overly complex but the desire is to know if this service is say a vhost or specifically an apache vhost? Should that just be part of the name in some way?
relationships and requirements of other services.
It would seem that a service within ONA is strictly a service that utilizes network connectivity.
Try to flesh out the idea more. Then provide a path to incrementally adding the features while providing good bang for the buck at the beginning.
Current needs have been:
needed a way to flag which ip/interfaces on a host were used within apache configuration for vhosts.
similarly, we needed to know which ips were vhosts to add firewall rules for port 80/443, not all ips on a host needed to be part of that fw rule.
Any time a configuration with an IP was needed, there could be more information about the usage of that IP beyond that it is associated with a particular host and what its mac or interface name was.
It'd be nice to have enough info in the system to generate most firewall rules from.
Random concept ideas. this could get huge and complex real quick.. but here are some ideas to consider.
A new table for tracking services. That information would show up on at least hosts (probably silly to go to subnet and beyond)
Attributes that would be useful to track under service:
It would seem that a service within ONA is strictly a service that utilizes network connectivity.
Try to flesh out the idea more. Then provide a path to incrementally adding the features while providing good bang for the buck at the beginning.
Current needs have been: