We need to update our OPSI versions so they can make it work for the Windows 64-bit slaves. The outline of this work should be similar to this: - Update the opsi server processes (assuming this is the typical opsi debian platform, this means backing up, shutting opsi down, doing an apt-get update, then bringing opsi back up) - Update all of the core OPSI products from the OPSI guys, run a quick package install on them all to update the local repo - At this point the clients that are running an older preloginloader should work fine in a backward-compatible state.. So upgrading them is a choice that can be made or deferred. But yes, updating them is a matter of selecting the nodes and in the product listing mark preloginloader to update. The plan should something similar to this: - [IT] clone staging-opsi so we can test in that machine first NOTE: If we end up having cshields to work on this it would make sense to thave these the OPSI master and a slave outside of the Build-VPN - [IT] pull out a win2k3 machine out of the Build-VPN - [IT] pull out a win64 machine out of the Build-VPN - [releng] test update process on new cloned machine - update OPSI on cloned machine - test that Win64 works with this version of OPSI - test that win2k3 slave works with this version of OPSI - [releng] repeat tested update process on staging-opsi - [releng] repeat update process on production-opsi I believe the versions we are going to try are: http://download.uib.de/opsi3.4/produkte/essential/opsi-winst_126.96.36.199-1.opsi http://download.uib.de/opsi3.4/produkte/essential/preloginloader_3.4-69.opsi
I tried preloginloader 3.4-69 on win64-ix-ref and it didn't work. Did you have different results?
I never did try it. These were suggested on the forums. We will have to figure out what the right versions are supposed to be. Specially for the master.
I doubt we'll invest time into upgrading OPSI.