auto-learn networks for wake-on-lan

[mbenkmann]

From matthias...@gmail.com on November 23, 2012 17:58:04

In order to wake up a machine, go-susi needs to know that machine's network's broadcast address. If the machine's fully qualified name is known, it can be resolved to an IP from which the network is easy to derive. If only the plain name of the machine is known this fails if the machine is on a different subdomain than the server. One way to overcome this is to use the [ServerPackages]/domains config option. However this is not easy to configure automatically.

go-susi should be able to learn about possible networks automatically through the following means:

client addresses from messages like new_server, new_foreign_client as well as communications received from clients are used to get

1) the possible numeric networks 2) by reverse lookup the names of domains

When a machine needs to be woken up, go-susi tries the following

1) try to resolve the cn of the machine (note that this is NOT what db.PlainnameForMAC() returns) 2) try to resolve the plain name (i.e. without a domain if the cn has a domain) 3) try a reverse lookup of ipHostNumber and match that against the plain name. If the reverse lookup yields plain name "." something, then use the ipHostNumber 4) for each of the known domain names, try to look up plain name "." domain. 5) If none of the above yielded an IP address, spam all known numeric networks' broadcast addresses with the WOL packet.

Original issue: http://code.google.com/p/go-susi/issues/detail?id=30

[mbenkmann]

From matthias...@gmail.com on November 23, 2012 09:19:45

The learned networks should be stored in a persistent file separate from the clientdb, because someone might want to delete the clientdb but we don't want to lose the learned networks because WOL would regress.

[mbenkmann]

From matthias...@gmail.com on December 04, 2012 13:05:40

Current state of the implementation:

"2) try to resolve the plain name" has been dropped. There's not really a justification for assuming that if "foo.bar.com" fails to resolve we should use "foo.otherdomain.org" just because the name happens to start with "foo". If a system is stored in LDAP with a fully qualified domain name that's a strong statement by the admin that he wants to identify the system with precision.

Most of the algorithm is contained in db.SystemFullyQualifiedNameforMAC(). Step 5), the numeric network spamming is contained directly in action.Wake()

The following parts are still missing:

1) Add learned numeric networks to db.SystemNetworksKnown()

1.1) Learn numeric networks from (confirm_)new_server messages' elements

1.2) Learn numeric networks from new_foreign_client messages

1.3) Learn numeric networks directly from incoming connections' TCPConn.RemoteAddr(). This takes care of learning server peers as well as client peers, so there's no need to parse elements on new_server or here_i_am.

NOTE: Learning ipHostNumber networks is not included in this list because I believe it offers no additional benefit over the above set.

2) Learn domains for being returned by db.SystemDomainsKnown()

2.1) Learn domains from peer servers listed in DNS (config.ReadNetwork())

2.2) From reverse lookup, whenever we learn a NEW numeric network from an address in 1) above.

[mbenkmann]

From matthias...@gmail.com on February 18, 2013 10:04:37

=> Bonus

Labels: -Priority-Normal Priority-Bonus

[mbenkmann]

From matthias...@gmail.com on February 18, 2013 10:57:49

Status => Accepted

Status: Accepted