fsweetser/netreg

netreg's Issues

Allow in-place editing of DNS resources

Currently, in order to modify the value of a DNS resource, it must be deleted and re-added with the new value. At best this is awkward, and at worst, may result in the record being completely missing depending on the extract run timing. Support should be added to allow these records to be edited in place directly via webint.

Allow any valid characters in DNS records and DHCP options

The DNS record and DHCP option values are currently heavily filtered. While this is good for security, it is bad for usability, as some use cases demand characters that are currently disallowed. This includes SPF DNS records, and TFTP boot options that include file windows file paths requiring double backslashes.

These options should - with extreme care - be modified to allow a greater range of legal values, while protecting both against SQL injection attacks and values that could break generated config files.

Make generated TXT record signatures optional in static zones

For each record that gets created in DNS, NetReg generates a matching TXT record to identify NetReg as the source of the record. This is essential for DDNS zones, where other entities such as DHCP may be simultaneously editing the zone contents.

For static zones, however, these TXT records should be made optional. Certain protocols, such as SPF, have been observed to be confused by the presence of these TXT records, causing mail routing issues. A per-zone option should allow them to be excluded from static zones when desired.

Add SPF/DKIM record support

SPF and DKIM DNS resources are a critical feature of any DNS deployment. Although they can be deployed as already supported TXT records, they have formatting requirements that are currently disallowed by the general webint input sanitization code. The code should be modified to allow these record types to be directly added in via webint, rather than requiring the database be directly modified by hand.

Make Operating Systems a managed list

Currently the operating systems field is stored as an enumerated type column. This means that adding or removing choices requires both schema and code changes. A better implementation would have a list of choices stored in a separate table, with a possible foreign key relationship from the machine table, allowing the list to be easily edited through the web interface.

Add support for IP Ranges

This feature would entail creation of IP ranges as first class objects. An IP range is an arbitrary contiguous range of IP addresses contained within a single subnet, not constrained by any bit boundaries. Users would then be presented with a list of ranges, either in addition to or instead of subnets, when registering a machine. This would allow machines to be kept within IP ranges that do not necessarily correspond directly to subnets, such as for IP filtering or QoS purposes.

This feature is already in use at WPI, and would require porting to the upstream code base.

SRV records resolving to CNAMEs

Currently, adding an SRV record to a host will always point the record at the primary hostname. In some cases, though, it may be more advantageous to have the SRV resolve instead to a CNAME associated to that host instead. For example, load balancers often require that a service CNAME be pointed at a hostname in a separate zone delegated to the load balancer. While most applications, like web browser, don't care, others, like OCS, get upset about the intermediate hostnames, especially if they're not all added to the certificates, adding additional expense.

The database format already allows for this by including both a record id for the machine table, as well as the hostname for each DNS resource. It should just be a matter of modifying code to support it.

• Allow pulldown list of hostname and all CNAMEs on SRV creation
• Update netdb add code to verify against CNAMEs
• Prevent a CNAME from being deleted if it would orphan an SRV
• Display the hostname the SRV resolves to when viewing a machine record

RPM packaging

Create a suitable RPM package. This includes:

• Moving file locations from ~netreg to standardized ones
• Creation of rpm spec file
• Creation of database versioning, including upgrade scripts

Allow viewing/editing of service group membership attributes from member view

When an entity (such as a machine or subnet) is added to a service group, that membership may have attributes added to it. However, while the service group membership list of an entity is viewable from the entity page, the attributes of that membership are only viewable or editable from the service group page. For greater convenience, the attributes should be both viewable and editable from the entity page as well.

SOA changes should propogate to DDNS zones

When service membership changes cause the effective SOA value of a zone to be changed, the change gets propogated to static zone files. However, the DDNS code currently fails to perform the same change to DDNS zones.

Aggregate standalone extract scripts into single framework

Currently all extract scripts run as separate standalone programs. While this makes adding in new extract scripts more straightforward, the lack of visibility between them leaves some deficiencies:

• It is not possible to ensure a consistent view of the database for all extract scripts in a given run. Machines may be added to DNS, but left of out DHCP until the next run.
• More calls to ssh/rsync than are necessary, as each script may cause its own file transfers and scripted actions. Bundling these together would allow for somewhat more efficient runs.
• Lack of introspection means it is not possible to view or manipulate the status of the individual extract scripts without per-script code in webint. A good framework would allow webint to query for all installed extract modules and their state.
• Addition of new scripts must be reflected in high level script management code.

For a good idea of what such a framework might look like, take a look at how the capture/collect modules are laid out in NetMon.

Enable SELinux

Current code base is highly unlikely to work with SELinux, due to various components all living in ~netreg. Through moving file locations to system standard ones such as /var/www and creation of any necessary custom SELinux policies, we should be able to run netreg on a system with SELinux configured in enforcing mode.

Allow searching of history by user

Allow the changelog history to be searched by the user who initiated the changes.