The tale of two client programs

[sudburr]

It would be nice to have a server-agnostic heartbeat client that could be pre-installed to an image, instead of the full-blown server-tied client.

Then the FOG server on that subnet would pick up that ping and list those machines that don’t have the full client installed. This would then allow the technician to be able to push the client on to those machines via the web interface at their convenience.

[Joe Schmitt]

Nope. If it was server agnostic then what we have created is a rootkit capable of being hijacked by anyone.

What would be better is if you setup your certificate heirachy. In an ideal world (I.e. fog 2.0) storage nodes would receive a key from the server that allows clients to connect directly to it. For 1.3.0 you would need to manually set it up so all storage nodes have the same root CA keg and then call the SSL regen command. You could also setup intermediate CA keys for the storage nodes if you wanted to do it properly and remove some of the security issues of the desribed method above.

[Wayne Workman]

@Joe-Schmitt a write up on that would be great. I want to do this at work, I’ll work on it.

[sudburr]

So the server name is entirely irrelevant to the key data that is saved to the client ? The name is only used to direct the installer to where to fetch the key from?

[Wayne Workman]

@sudburr Yep. Name or IP.

[sudburr]

@Joe-Schmitt What if the heartbeat responder was password protected ?

[Joe Schmitt]

At that point it would be adding complexity for the sake of complexity. If you could mass deploy the heartbeat then you can mass deploy a script to install the client.

[sudburr]

This post is deleted!

[Wayne Workman]

@sudburr I can see that post you removed, It uses TCP.

Also, see here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

That is oriented for migrating to a new server, but it’s the same thing to just move certs to another server for use there too.