Topics created by mrayzies

@mrayzies Good to hear. If you look at my very first post you can see a ref link to the current versions of the post install scripts. You might get some ideas on how to update yours.

@mrayzies I would suggest becoming standard. You can completely separate out all of fogs pieces as you wish, but storage nodes are best as a full Linux vm and setup with the fog installer.

@Sebastian-Roth @george1421

I’ll try to get a video/screenshots of the situation shortly.

As far as trying an updated FOG and/or a custom kernel… I’ll add it to my queue, but it may be a while before I can get to it; I’ll try to keep you posted.

Thanks for the reply Sebastian and sorry for the super long delay.

I am observing this behavior when using “ipxe.pxe” – I have not used any other one binary (not since I switched it to a production server a couple months ago).

Also, to clarify, the transfer rate is good once the transfer begins, it is only when it is “configuring net0” that it seems to be a slow link. However, I assume it is some hardware dependent issue as I just tried a random computer model and saw it was configuring at the expected 1Gb link speed.

So I guess the tl;dr is that this isn’t really a problem.

Sorry I’ve been unresponsive – I’ve been quite busy with tasks at work and probably wont’ update anytime soon. If you think it’s fixed, I’d say it’s fine to close this ticket ----- if/when I upgrade, I can re-open/comment if I still find it to be an issue.

@mrayzies THat’s exactly what it is. If you update a host’s primary mac, the update is the primary, and the original primary becomes an additional mac.

It seems to be the same end result, not sure if it is the same cause.

Feel free to close this though and I’ll watch the other one – sorry I didn’t find that one in my search 😞

One potential think to note is that it seems like you got to that state from quick/full host registration, whereas I got to this state by entering data directly into the web interface.

@Wayne-Workman said:

@jayphizzle said:

Can some mod mark the tread as unsolved?
Or should i open a new thread?

I’d say open a new thread, I’d call this a bug as it doesn’t work right if a different language is being used by the system.

@Jbob

Ok ‘new’ Bug reported here: https://forums.fogproject.org/topic/6934/endless-windows-key-activation-burning-oem-keys

@mrayzies said:

you must first have a KMS host running in your deployment

They are actually not too hard to setup. But the steps are easy to forget. I’ve only done it once.

@Jbob said:

@mrayzies not a problem. To answer those questions:

Yes, the client installs your servers’ certificate and ours. The “FOG Project” CA (made by us) servers 2 purpose. SYSTEM level services need to be digitally signed otherwise windows will throw security errors (I have seen this issue when imaging a machine with an unsigned client). This can also be used to ensure no tampering was done with the client files That certificate is used to “verify” upgrades. Lets say we release v0.9.10, the client will download the msi from your server and check if it was signed by us. If the msi was somehow tampered, the digital signature would no longer be valid. Using HTTP over HTTPS has no security benefit to the client. Why? Because all traffic is already encrypted. Here’s a very basic overview of how the new client communicates Each client has a security token. This is used to prove to the server that the client is the actual host and not an impersonator. This token gets cycled constantly. When the client first makes contact, it encrypts its token and a proposed AES 256 key using RSA 4096 using your server’s public key. (This public key is verified against the pinned server CA certificate by checking the x509 chain and fingerprints). If the server accepts the security token and the new AES key, all traffic from that point on is AES 256 encrypted using that securely transmitted key.

The whole point of our security model is to allow for secure communication over insecure medians.
Even then, the client installation has an HTTPS option, but it serves no real security benefit.

This stuff and a little other stuff has been added here:
https://wiki.fogproject.org/wiki/index.php/FOG_Client#Security_design