Closed Bug 566449 Opened 15 years ago Closed 13 years ago

Investigate OPSI on 64-bit Windows 7

Categories

(Release Engineering :: General, defect, P3)

Product:
Release Engineering
Component:
General
Platform:
x86_64
Windows 7
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: coop, Unassigned)

References

Details

(Whiteboard: [win7][win64][opsi])

This doesn't necessarily block bug 553339, but if we can figure out whether OPSI works on 64-bit Windows 7 and get it deployed, we'd certainly rather deploy other software via OPSI than by hand. We'll need a wiki page to document the initial install, and can add OPSI to the base ref image.
Blocks: 566454
Whiteboard: [win7[win64][opsi] → [win7][win64][opsi]
I will need a snapshot of the latest opsi products being used right now (probably from bhearsum) so we can use that as a base. Let me know if this constitutes a new bug.
Status: NEW → ASSIGNED
Just a bit more on my last note.. I last pulled the repo from hg on Jan 7th, and updating today there are no changes. (http://hg.mozilla.org/build/opsi-package-sources) I presume that updates have been made and just not committed yet, so in the meantime I'll test around with what I have from the repo.
There's definitely updates since then, how are you trying to pull them?
Sorry, I just got them now.. Was doing an hg update without the hg pull first. <-- hg n00b hat
Quick update: Initially I'm not seeing any show stoppers to opsi on win7-64, but I've only spent a few hours on it. It installs and runs as a 32 bit app, and so far it is able to deploy products fine. I have yet to test whether autoit works appropriately (autoit is the app that allows you to script a GUI walk-through). One thing I was concerned about is registry changes. Take for example the lower-opsi-timeout product which adds a registry key to OPSI's registry tree. The registry tree it modifies is in HKEY_LOCAL_MACHINE\Software\opsi.org.. However, when you have a 32 bit app on Win64, it throws the HKLM\Software registry keys for that app into HKEY_LOCAL_MACHINE\Software\Wow6432Node (\opsi.org in this case).. So, I was expecting OPSI to set the key exactly the way it was told, and hence we would need to differentiate between a win32 and a win64 installation in order to get the key in the right place. This is not the case. The key gets installed in the HKEY_LOCAL_MACHINE\Software\Wow6432Node\opsi.org location. The mystery right now is: why does Windows redirect the registry edit to that location? It (and/or OPSI) is not smart enough to determine that opsi.org is a tree in the 32 bit location rather than the root HKLM\Software tree. I'm afraid that Win64 may be redirecting the key edit to that location by default since OPSI itself is a 32 bit app and their registry edit app is making the change. I need to figure this out. More later.
Depends on: 567289
Depends on: 569297
More updates: The password update product works fine as is mozillabuild works with the patch in 567289 autoit (32 bit) works with the product in 567046.. AutoIT can still be installed by hand per the instructions currently in the wiki but this can be pushed out through OPSI just fine (for both 32 and 64 bit, relying on the 32 bit bins) tools-repo works with the patch in 569297 hostkey product works as-is (using the python from mozillabuild) profilevars product works as-is python-scripts-path works as-is rename-vim-install works as-is The 3 registry "disable" products work as-is (disable-cad, disable-jit-debugger, disable-shutdown-tracker) nagios config product works, BUT the config is put into the literal place (c:\program files\nscp\nsc.ini). This may be an issue if the app is 32 bit, since windows will expect it all under c:\program files (x86)\.... Wrestling a bit with the java product right now.. Will you be using the 32 bit java product or going with a 64 bit run for the 64 bit machines?
I've been testing the preloginloader_3.4-27mozilla2.opsi in win7-64. Technically they added support in 3.4-47, so this is a bit hairy. However, I've got it pretty much working with these steps (a fresh install of win7-64): Mount the pcpatch directory copy the install\preloginloader\files\opsi\UAC_off file to the desktop run the UAC_off from the desktop reboot copy install\preloginloader\files\opsi\ip2mac\system\msvcr71.dll to c:\Windows\SysWOW64\ (not System32!) Run the install\preloginloader\opsi-prep script Run install\preloginloader\service_setup You will have to enter the OPSI server credentials, but aside from that you should see no visible errors, though some will get registered in the log. If you see errors from the opsi-prep or service_setup scripts then something isn't quite right. I'm going to test these steps from a clean install one more time tomorrow before wiki-fying them. The good news is that with an install like this, all of the opsi products mentioned in the last update to this bug install fine (but using the newer winst and autoit). The key here is keeping with the same mozilla-modified preloginloader product.
Were you able to install products with it? I did a very similar test install yesterday, but everything silently failed to install...
Yes, all of the products in comment 6 installed fine.
Per Ben's discovery, there is no need to copy the msvcr71.dll file if you run service_setup as administrator (right-click the file then click "run as administrator"). Windows security never ceases to amaze me. Also, tonight I tested a fresh install against winst 4.8.8.1_2 (what mozilla currently uses). Surprisingly everything worked. So, I'm having a hard time figuring out what they needed to do to officially "support" win7 (and 64 bit). I'm a bit nervous that running the old packages will bite us in the end, but for now it seems to be working. What other packages need testing? (refer to the list in comment 6)
No packages in particular need testing. However, I still haven't been able to get package installation working with any combination of installation user / winst version.
hrmm.. Which version of windows specifically, maybe I'm getting lucky.
Windows 7, Ultimate, 64-bit.
We're going to be minting the 64-bit win7 ref image soon. We should send you a copy of it, and have you test OPSI using it.
Great, let me know where I can pick it up.
Is this still worth investigating? Have we decided against using OPSI for this now?
No longer blocks: 553339
Assignee: cshields → nobody
Status: ASSIGNED → NEW
Looks like we're going with Group Policy for this.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.