Data Protector 8.10: Für die Data Protector 8.10 ist es besonders wichtig die Namensauflösung zu kontrollieren. Lässt sich der Cell Server nicht mit dem FQDN (und short und reverse) auflösen, so sieht man beim Öffnen der GUI nur eine Anmeldemaske (LDAP Anmeldung als alternative Anmeldemöglichkeit) und danach die Meldung „Permission denied“. Die funktionsfähige Namensauflösung wird auch ausdrücklich als Voraussetzung für DP 8.10 aufgelistet. Falls die Installation von DP 8.10 ohne funktionierende Namensauflösung durchgeführt wurde, so ist derzeit nur eine Neuinstallation nach der Fehlerbehebung möglich; ein neu generiertes Zertifikats wurde nicht akzeptiert. Hintergrund: Mit DP 8.10 werden Zertifikate für den Zugriff auf die GUI verwendet, das erstellte Zertifikat muss beim ersten Aufrufen der GUI akzeptiert werden. Wenn der Systemname abweichend vom Zertifikatsnamen ist, so ist eine Anmeldung nicht möglich, da TLS nur mit FQDN arbeitet.
Update: Für den Fall, dass der Data Protector auf einem deutschen bzw. nicht englischem Linux System installiert wird, kann die Erstellung der Zertifikate fehlschlagen. Grund hierfür ist, dass die Rückgabewerte auf Englisch erwartet werden. Als Workaround setzt man die locale vor dem Upgrade auf zum Beispiel ‚en_gb-UTF-8‘.
Update: Für den Fall, dass der Data Protector im Cluster läuft, wird unter Umständen das Zertifikat für den physikalischen Host, statt dem virtuellen Namen ausgestellt. Hier gibt es die Möglichkeit mit dem Perl Programm omnigencert.pl ein Zertifikat für den virtuellen Namen des Clusters auszustellen. Die genaue Anleitung findet man in der Hilfe bei der Suche nach ‚To generate CA, client, and server certificates in the SG-CLUSTER environment‘.
Data Protector 8.00: Beim Verwenden von Granular Recovery Extension for Microsoft Exchange kann es zu „User does not have required roles“ Meldungen kommen. Grund hierfür ist dass die „Mailbox Import Export“ Rolle direkt dem GRE Benutzer zugeordnet werden muss. Mehr Details können unter http://support.openview.hp.com/selfsolve/document/KM00482317 (HP Passport Account benötigt) nachgelesen werden.
My GUI is asking for a username/logon. I can nslookup the CM FQDM, shortname, and IP address. I can do the same from the CM to my PC. I have uninstalled and reinstalled the GUI and re-accepted a new certificate from the CM but it still asks for a name. ideas? I am un HP-UX 11.31. My Windows system is v 7.
Hi Vince,
does complete name resolution work for your client too?
Best regards
Daniel
This what you mean? From my client to the server:
C:\Users\vlaure>nslookup
Default Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
> sapbck.ssmhc.com
Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
Name: sapbck.ssmhc.com
Address: 165.104.137.39
> sapbck
Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
Name: sapbck.ssmhc.com
Address: 165.104.137.39
> 165.104.137.39
Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
> 165.104.137.39
Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
Name: sapbck.ssmhc.com
Address: 165.104.137.39
BTW, I think I got past the username/password by adding the DPWINBDL_00813 patch to my work station. Now I am getting an SSL 7116 error. And yes, I have regenerated a credential.
perl omnigencert.pl -server_id FQDN -server_san ip:1.2.3.4 -user_id hpdp -store_password PASSWORD
thanks for toy reply…
After finally getting higher up in the HP food chain for help an engineer discovered ONE string that was wrong in the database. He had me export it, change it, reimport it. All is happy.
Would LOVE to get that kind of support each time!
Thanks for all your replies too!
Hi Vince,
can you please share what was done?
Best regards
Daniel
There was an incorrect value in the database. So the engineer had me export the database and change the value to a new one.
1. Stop omniback (omnisv -stop)
2, Save a copy of /var/opt/omni/server to another place
3. start omniback (omnisv -start)
4. Change it to maintence mode (omnisv -maintenance 1)
5. Wait the 300 seconds then export the database (omnidbutil -writedb /spacewhereIcanputit)
6. Change the incorrect value to the default. cat dpidb.dat | sed ‚/s/badvalue/newvalue/‘ > temp.idb
7. rm dpidb.dat ; mv temp.idb dpidb.dat
8. reimport the database and say yes to overwrite (omnidbutil -readdb /spacewhereIcanputit)
9. Exit maint mode (omnisv -maintenance -stop)
The issue that makes this solution unique it the corrupt value that needed to be replaced.
Hope this helps someone though.