auto-learn networks for wake-on-lan

[GoogleCodeExporter]

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 reported on code.google.com by matthias...@gmail.com on 23 Nov 2012 at 4:58

[GoogleCodeExporter]

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.

Original comment by matthias...@gmail.com on 23 Nov 2012 at 5:19

[GoogleCodeExporter]

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' <client> 
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 <source> 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.

Original comment by matthias...@gmail.com on 4 Dec 2012 at 9:05

[GoogleCodeExporter]

=> Bonus

Original comment by matthias...@gmail.com on 18 Feb 2013 at 6:04

• Added labels: Priority-Bonus
• Removed labels: Priority-Normal

[GoogleCodeExporter]

Status => Accepted

Original comment by matthias...@gmail.com on 18 Feb 2013 at 6:57

• Changed state: Accepted