Damn tar is kinda weird .. usually, you specifiy excludes in the manner of –exclude=”/path/to/exclude”. But tar needs to do things differently.
|
1 2 |
tar -cvpf /xen-dom0.tar --exclude "/proc/*" --exclude "/sys/*" --exclude "/dev/*" --exclude "/xen-dom0.tar" / |
Finally, after about 6 months (I last talked about that on February 25th, when Virtual Center 2.5U4 was released) our troubles with our “custom” certificates seems to be resolved! As it turns out, it really was our fault and not VMware’s.
When generating the pfx from the signed certificate and the key-file, you need to supply a password, otherwise the vCenter service is unable to utilize the private key of the pfx, since it’s unable to access the PFX with the default password (testpassword is the default for Virtual Center as well as vSphere).
As noted in the Replacing VirtualCenter Server Certificates document for Virtual Infrastructure 3, as well as through our Customer support, you need to specify the password when exporting the signed crt/Private key into the pfx:
|
1 2 |
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx |
After successfully doing so, you just need to replace the original files (hopefully move them away beforehand) with the ones generated. And afterwards, you should be able to utilize your new certificates! When you now try to clone a template and customize it using an existing customization spec, you’re gonna see this:
After clicking on “OK“, you’re gonna get the normal customization specification edit frame, where you should be able to skip ahead to “Workgroup or Domain“, where you’re gonna have to reenter the domain administrator password.