Re: Issue with de-activing server after re-build (913 Views)
Reply
Regular Visitor
Gareth77
Posts: 3
Registered: ‎10-24-2013
Message 1 of 6 (1,016 Views)
Accepted Solution

Issue with de-activing server after re-build

Hi,

 

We have appox 100 VMware images running Windows 2008 R2 and registered in the SA Console. Once a week the servers are restarted and rebuilt from a gold PXE image.

 

When trying to re-install the agent on any of these server, the install runs but returns the error:

 

"INFO: Initially registering hardware and operating system information...
Chassis ID: VMware-42 00 16 c2 cd 66 c3 e5-ca 05 70 75 9a ed 5b 31
UUID: 420016c2-cd66-c3e5-ca05-70759aed5b31
TRACE: Connecting to 'https://spin:1004/spinrpc.py'...
[FATAL] The agent has been unable to initially register hardware with server at 'https://spin:1004/spinrpc.py'. More error information regarding this failure may follow.
INFO: Encountered Fatal registration error, see errors above for possible cause
TRACE: Rolling back any mid/crypto file changes
ERROR: spin.permissions - The agent installer detected an existing device record 'Server ID 133710001 (server.domain)' in the core that has the same chassis ID; the installer attempted to reclaim this device record but failed to because the device record is not configured to accept a request to issue a certificate.

To solve this problem, please refer to knowledge base article: http://support.openview.hp.com/selfsolve/document/KM546387

[ERROR] RunCommand('""C:\Program Files\Opsware\agent\lcpython15\python.exe" "C:\Program Files\Opsware\agent\pylibs\cog\agent_initial_registration.pyc"  "C:\Program Files\Common Files\Opsware\crypto\agent\agent.srv""') exited with code 3

[WARN] Full server registration failed (See above for explanation). When started, the Opsware agent will remain in dormant mode until server registration succeeds."

 

This is due to the server not being de-activated on the SA console prior to the re-install.

 

As this is going to affect approx 100 servers, manually de-activating the servers is not an option for us

 

I have tried the hb_hardware to try and re-register but this reports the same error as above.

 

Has anyone else had this issue and knows a way to resolve this?

Valued Contributor
LarsB
Posts: 28
Registered: ‎03-23-2010
Message 2 of 6 (1,005 Views)

Re: Issue with de-activing server after re-build

If the Opsware IDs are set values for these 100 servers you could create a quick bash script that does launches a URL (be sure to have your browser use the spin certificate):

 

Replace 123001 with your Server Opsware ID's

 

https://occ:1004/spinrpc.py?method=Device.update&id=123001&allow_recert=1

 

 

You could also write a spinwrapper (no longer supported?) python script to go in and set allow_recert to true for every device in a device group.  

 

 

-- Lars
http://www.augustschell.com
Regular Visitor
Gareth77
Posts: 3
Registered: ‎10-24-2013
Message 3 of 6 (988 Views)

Re: Issue with de-activing server after re-build

Hi Lars,

 

Thanks for the reply.

 

A couple of quick questions following that.

 

Does this script need to be run on the machine where the agent is running or on the server?

 

The reason I ask is that I have tried running that command directly from a browser and from within a .bat file and it doesn't find the site https://occ:1004/...

 

I have tried changing the site to https://spin:1004/... as per the error that is being displayed by the install, should this be set to spin or occ?

 

I'm still relatively new to server automation, where is the spin certificate to use with the web browser to run this?

 

Regards

 

Gareth

Valued Contributor
LarsB
Posts: 28
Registered: ‎03-23-2010
Message 4 of 6 (981 Views)

Re: Issue with de-activing server after re-build

Gareth,

To gain access to most of the HPSA components individual UI's, such as spin, you need to present a cert when accessing the URL.

The cert created when your HPSA core was deployed is located here: '/var/opt/opsware/crypto/spin/spin-developer.p12' the password can be found in your response file. Look for the value under '%decrypt_passwd'.


The spin calls can be launched from any browser with access to that URL. The DNS name doesn't matter as long as it is pointing to the IP of your Spin server.
-- Lars
http://www.augustschell.com
C_M
Occasional Contributor
C_M
Posts: 7
Registered: ‎08-13-2013
Message 5 of 6 (975 Views)

Re: Issue with de-activing server after re-build

Gareth

 

I think you should be fully removing any reference to the servers before re-registering by deactivating and deleting. If not I think you will end up with lots of unreachable agents with duplicate names using up object IDs. This can be done through a script in OGSH using the 'decommission' and 'remove' methods:

 

/opsw/Server/@/${serverName}/method/decommission
/opsw/Server/@/${serverName}/method/remove

 

So you could just feed the list of 100 servers into a loop with those two commands.

 

Chris

Regular Visitor
Gareth77
Posts: 3
Registered: ‎10-24-2013
Message 6 of 6 (913 Views)

Re: Issue with de-activing server after re-build

I have found a workaround to this issue:

 

When the server is not registered on the server, we have to uninstall the agent after boot, as its part of the PXE boot image.

I have then written a script that runs the initial install, once the install of the HPSA agent is complete and registered against the core, it will copy the following files to a safe area that isn’t cleared on restart of the server:

“c:\program files\common files\opsware\etc\agent\mid”
“c:\program files\common files\opsware\crypto\agent\bootstrap”
“c:\program files\common files\opsware\crypto\agent\admin-ca.crt”
“c:\program files\common files\opsware\crypto\agent\agent.srv”
“c:\program files\common files\opsware\crypto\agent\agent-ca.crt”
“c:\program files\common files\opsware\crypto\agent\opsware-ca.crt”

On subsequent reboots, the HPSA agent is set not to start on boot up, a script then copies the above files from the safe area to the correct areas in the HPSA file structure replacing the files already there. The agent then starts, and due to it using the files from a successful install and registration the agent connects correctly

Bit of a long winded way of resolving the issue but it works.

 

Thanks for all the suggestions, it did point me in the right direction.

 

Gareth

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.