Dynamic group matching of system types

[chris]

I have been thinking of extending the groups to be dynamically configurable to the type of host they will execute on.

Currently, groups are very basic; groups are only used if the group name either matches the system hostname, or one of the CLASSes. I have been thinking about extending them to use a type of rule to examine which will define what types of hosts they will execute on. Here are some examples of what I am thinking of:

    group my_solaris_servers:
	# This group will execute on all Solaris/SunOS systems
	match="system=='SunOS'"

	..directives follow..


    group my_solaris9_servers:
	# This group will execute on Solaris 9 systems only
	match="system=='SunOS' and revision=='5.9'"

	..directives follow..


    group my_intel_linux_servers:
	# This group will execute on Linux/Intel systems only (ie, not Linux on Alpha or Sparc)
	match="system=='Linux' and machine[-2:]=='86'"

	..directives follow..


    group my_Linuxlike_servers:
	# This group will execute on Linux systems and the host 'fred'
	match="system=='Linux' or hostname=='fred'"

	..directives follow..


    group my_Redhat_servers:
	# This group will execute on Redhat Linux systems only
	match="system=='Linux' and redhat_release!=None"

	..directives follow..


    group my_Redhat8_servers:
	# This group will execute on Redhat Linux 8.0 only
	match="system=='Linux' and redhat_release=='8.0'"

	..directives follow..


    group my_Redhat7etc_servers:
	# This group will execute on Redhat Linux 7.0 or higher
	match="system=='Linux' and redhat_release!=None and float(redhat_release)>=7.0"

	..directives follow..


    group my_Web_and_DNS_servers:
	# This group will only execute on hosts in the webserver or dnsserver CLASSes
	match="class=='webserver' or class='dnsserver'"

	..directives follow..

These are just ideas, but should give an idea of the type of implementation I am thinking of. match is an expression to be evaluated (like rules) which give a lot of flexibility in the types of matches that can be defined.

If match is defined for a group, then that group is only effective if match evaluates to true.

The idea would be that Eddie defines the available variables for the 'match rule' from the system itself. These would be defined from the likes of 'uname' and /etc/redhat-release for redhat, etc.

Roughly:

hostname = uname -n
system = uname -s
revision = uname -r
machine = uname -m
processor = uname -p
redhat_release = release value from /etc/redhat-release
redhat_name = release codename from /etc/redhat-release, e.g., "Valhalla" for 7.3

If any value is unavailable (e.g., redhat values from non-Redhat systems) it would be set to Python None.

This allows a globally shared configuration to be customized per server based on the system type, without having to manually setup CLASSes. CLASSes can still be used for custom groups.

[chris]

A shortcut for matching hostnames would be useful too.

Currently group names cannot contain certain characters that hostnames can contain, such as a dash "-", so the following example is invalid:

group Chris-Miles-Mac.local:
    ...directives...

(actually a hack exists in the current version to substitute "-" for "_" to provide a workaround for this type of problem).

Adding a hostname parameter, which would be a shortcut for a match parameter, would be much better. Example:

group mymac:
    hostname="Chris-Miles-Mac.local"
    ...directives...

Perhaps also some list fancyness such as:

group mymac:
    hostname in ("host1", "host2", host3")
    ...directives...