Replicating drivers across FOG servers

[Wayne Workman]

Two approaches here.

Create a fake image and make its path /images/drivers and setup the fake image so it’s shared with the other servers via groups or whatever way you have the images set up.

Script it with rsync & make it into a CRON job on the main server.

[THEMCV]

@Wayne-Workman Yep, #1 worked. Thanks Wayne.

[george1421]

@Wayne-Workman said in Replicating drivers across FOG servers:

Two approaches here.

Create a fake image and make its path /images/drivers and setup the fake image so it’s shared with the other servers via groups or whatever way you have the images set up.

This is the option we use. You should also be able to set this “fake image” to disable so someone won’t try to deploy it, but enable replication so the drivers will be sent to the remote fog/storage nodes.

[falko]

@george1421 said in Replicating drivers across FOG servers:

@Wayne-Workman said in Replicating drivers across FOG servers:

Two approaches here.

Create a fake image and make its path /images/drivers and setup the fake image so it’s shared with the other servers via groups or whatever way you have the images set up.

This is the option we use. You should also be able to set this “fake image” to disable so someone won’t try to deploy it, but enable replication so the drivers will be sent to the remote fog/storage nodes.

I also use this method

[Wayne Workman]

@george1421 said in Replicating drivers across FOG servers:

You should also be able to set this “fake image” to disable so someone won’t try to deploy it, but enable replication so the drivers will be sent to the remote fog/storage nodes.

If an image is disabled, I believe it won’t replicate. I remember asking Tom this before. Pinging @Tom-Elliott to be sure I’m not telling you wrong.

[Tom Elliott]

@Wayne-Workman you are correct.

@george1421 @Wayne-Workman @THEMCV If it’s disabled why should we replicate it? This relates namely to snapins and images though. Of course it’s possible to assign the definition, but it could be protected. This way deploys won’t work and an upload would not be allowed.

[george1421]

@Tom-Elliott The idea of disabling the “fake image” /images/drivers is to prevent someone from trying to deploy that “driver” image. We want the drivers in that folder so the FOG built in replicator will move them to the remote storage nodes/fog servers. The replicator won’t move them unless we create an image definition for them (right?).

While its a little off point, we also disable unapproved images before the go through a QC audit. We want them to replicate to the remote fog servers, but we don’t want anyone to image them until we release them. This also ensures the images make it to the remote nodes completely before they are released.

[Tom Elliott]

@george1421 correct. But disabling tells fog you want nothing to do with it. Protecting an image definition won’t prevent a user from deploying it, but it will also fail to deploy to the host trying to use it. It won’t be able to find the normal image files. It will also not be able to be uploaded over when I’m the protected state. The protected state is just a check box in the GUI, so you can still put new files in the “drivers” image. Replication will compare the files and update the files that need to be updated.

[george1421]

@Tom-Elliott said in Replicating drivers across FOG servers:

@george1421 correct. But disabling tells fog you want nothing to do with it.

Even to the point it won’t replicate the drivers to other storage nodes??

[Tom Elliott]

@george1421 when fog replicates it is not on a file basis…Persay. it’s on the location of the image which it replicates recursively.

A disabled image tells fog you don’t want to use it, as in its there for historical reasons, or maybe forensically speaking you want it contained

So a disabled image, or snapin, will not be replicated or used by any system. Server or client.

[george1421]

@Tom-Elliott I guess I misunderstood the function of that checkbox then. Or its probably more to the point I closed the door after the horses were already out. Because I did disable the drivers image after it already replicated to the remote locations, because I wanted to avoid the techs (remove the possibility) from assigning the drivers image to host computers. I guess the issue would have came up sooner or later when we updated the drivers on the master servers and they never appeared on the remote servers.

[Wayne Workman]

@george1421 You could change the fake image’s name to something along the lines of:

DO_NOT_DEPLOY_THIS

The image name and the image path don’t have to match, they are independent of each other.

[george1421]

@Wayne-Workman it would be way cooler if the checkbox worked as I invisioned it.

[Wayne Workman]

@george1421 This close to release, I’d rather change absolutely nothing at this point.