FOG client with dual boot image

[tomhtil]

I’ve got a problem I can’t seem to work around. I have a dual boot Win 7 / Ubuntu image tested working. I’ve installed the FOG client on both OS’s and individually they work fine.

However, the first OS that gets booted after imaging gets the correct token from the server and works as expected. When rebooted into the other OS (in either direction) the FOG client fails to connect as the encryption data has already been registered. Resetting the encryption data works but this becomes a manual process every time the other OS is loaded.

Is there any way around this restriction?

[Tom Elliott]

I guess what is the use case of the client for both OSs? The fog client is meant to be secure. To maintain this security and for both the server and the client to trust each other, this isn’t something that can be automated easily.

The client and server reestablish this trust relationship every 30 minutes.

I suppose you could create a script on the Linux side to reset the encryption on boot up as well as reset it when Linux is about to restart. Or similarly on the windows side.

This isn’t the clients intended mode of operation though.

I don’t have a script readily available to do such a thing as this isn’t a very common thing.

[Sebastian Roth]

@tomhtil Thanks for bringing this up. As Tom said, the fog-client maintains a strict security trust relationship to the server. This design has the obvious drawback of not being able to maintain two trust relationships for one MAC address at the same time. Probably something Joe left out when he initially created the fog-client. But I can see why people want to use it this way and I will look into this.

Be aware, this will probably take some major changes in the code and won’t be fixed in a matter of a few days.

There might be some kind of quick fix (copy token from one OS to the other) but I have not looked into this. Will do so.

[Daniel Miller]

We actually have a related issue in some of our student labs with a configuration management product (Deep Freeze) that discards changes to the filesystem; the machines in question lose their trust relationship whenever they are rebooted. I’ve mulled the issue over a bit and have some testing slated to attempt using junctions to offload the token storage location to a non-managed volume. I think the same approach might be viable for a dual-boot system through the use of junctions and symbolic links to tie the file locations containing the token in each operating system to a 3rd commonly readable file system. Thoroughly untested, mind you, but should be a viable workaround.

[EduardoTSeoane]

Have you try to delete the token.dat on each boot from each S.O.?

Something drastic is configure linux (maybe from udev or another way before de FOGService boot) to change the mac address and register the computer as another diferent?.

[EduardoTSeoane]

@Daniel-Miller said in FOG client with dual boot image:

We actually have a related issue in some of our student labs with a configuration management product (Deep Freeze) that discards changes to the filesystem; the machines in question lose their trust relationship whenever they are rebooted. I’ve mulled the issue over a bit and have some testing slated to attempt using junctions to offload the token storage location to a non-managed volume. I think the same approach might be viable for a dual-boot system through the use of junctions and symbolic links to tie the file locations containing the token in each operating system to a 3rd commonly readable file system. Thoroughly untested, mind you, but should be a viable workaround.

Try to add correct exceptions to Deep Freeze (files, folders and registry keys), take a lot of care with installation paths and other changes, On my last update the client break to malfunction on a lot of freezed computers that have the client installed on non default path, a little problem with the updaterhelper.

[Sebastian Roth]

@tomhtil Thinking about this a bit more I can only suggest to copy token.dat from Windows to Linux and back as a quick solution. I opened an issue on github for this so we won’t forget about it. I see it as a major change we’d need to make in the client and it’s not something we can do quickly.

@EduardoTSeoane said in FOG client with dual boot image:

On my last update the client break to malfunction on a lot of freezed computers that have the client installed on non default path, a little problem with the updaterhelper.

Can you give us some more details on this? I have to admit that I have not looked into the updatehelper code yet. Does it use default install path even if you had it installed in a different location?

[EduardoTSeoane]

@Sebastian-Roth said in FOG client with dual boot image:

@tomhtil Thinking about this a bit more I can only suggest to copy token.dat from Windows to Linux and back as a quick solution. I opened an issue on github for this so we won’t forget about it. I see it as a major change we’d need to make in the client and it’s not something we can do quickly.

@EduardoTSeoane said in FOG client with dual boot image:

On my last update the client break to malfunction on a lot of freezed computers that have the client installed on non default path, a little problem with the updaterhelper.

Can you give us some more details on this? I have to admit that I have not looked into the updatehelper code yet. Does it use default install path even if you had it installed in a different location?

Yes, I can… And Yes, I think so on my system.

We have a set of computers freezed, Because We don’t want to add another Freezer exception more, we install the fog client in D:\ Volume that we have unfreezed.

When i update my server from 1.4.2 (client 0.11.12) to 1.5.6 (client 0.11.16). We don’t prevent the computers to update the client, then the update uninstall the old client and try to install the new version, on next reboot the fog client was not there, my conclusion was that it was installed on freezed partition. The result all freezed computers with that client installation path goes down.

But I was thinking about that was a incident with my specific installation and custom configurations and system customizations, so I was thinking that it was not a FOGService problem, but I like to Advertise about take care with own customizations.

If you need more details…

[Sebastian Roth]

@EduardoTSeoane said in FOG client with dual boot image:

we install the fog client in D:\ Volume that we have unfreezed

Looking through the code I can’t even find an option that allows for installing FOG in a different location than. Did you modify the MSI installer to achieve that or using other special tools?

[EduardoTSeoane]

@Sebastian-Roth No, the installer is the msi version supplied by installation, the upgrade was from 0.11.12 to 0.11.16 and the server from 1.4.2 to 1.5.6

[Sebastian Roth]

@EduardoTSeoane Ok, seems like I got a bit confused about the custom install path. Now I got it. Opened an issue on github for this so we won’t loose it: https://github.com/FOGProject/fog-client/issues/117

[EduardoTSeoane]

@Sebastian-Roth said in FOG client with dual boot image:

@EduardoTSeoane Ok, seems like I got a bit confused about the custom install path. Now I got it. Opened an issue on github for this so we won’t loose it: https://github.com/FOGProject/fog-client/issues/117

Hehe, that has name, is too much work…, I was thinking that it was a problem with our Windows Customizations, I had no time to investigate it.