[GELÖST]Sametime 8.5.2:ProxyServer lässt sich nicht mittels stopServer stoppen

[Tode]

Ich bin hier fast am verzweifeln, fürchte aber, dass das hier das falsche Forum sein könnte (ist doch ne sehr spezifische Websphere- Frage)...

Habe eine Komplette Infrastruktur anhand der "From Zero To Hero" aufgebaut. Beim Proxy (andere Maschine als Console) ist irgendwas schief gelaufen, und ich musste mehrmals neu anfangen. Und jetzt habe ich das Problem, dass STProxyServer und nodeagent sich zwar als Service starten lassen, danach aber nicht mehr stoppen.

Stoppt man die Dienste, laufen die java- Prozesse weiter. Stoppt man via "stopServer" kommt die Meldung, man sollte doch den korrekten -username und -password Parameter mitgeben (was ich aber tue) und im stopServer.log kommt die Fehlermeldung mit der Fehlernummer "ADMU3007E", dass ich nicht genügend Rechte hätte, den Server zu stoppen...

Wo kann ich denn nun prüfen, was mit meinem wasadmin (der überall sonst funktioniert) nicht in Ordnung ist...
Thanx

EDIT: Hier mal die Fehlermeldung, die StopServer auswirft... google grade nach den Fehlern, hatte bisher nur nach dem Fehler direkt in der stopServer.log gesucht...

Code

ADMU0111E: Das Programm wird mit dem folgenden Fehler beendet:
           javax.management.JMRuntimeException: ADMN0022E: Der Zugriff der
           Operation stop auf die MBean Server wurde verweigert, weil die
           Berechtigungsnachweise unzureichend oder leer sind.
ADMU4113E: Vergewissern Sie sich, dass Benutzername und Kennwort korrekt sind.
           Wenn Sie das Tool in der Befehlszeile ausfhren, bergeben Sie mit
           -username und -password gltige Werte. Alternativ k”nnen Sie die
           Datei <Verbindungstyp>.client.props aktualisieren.

[stoeps]

Hi Thorsten,

ich würde die beiden Dienste löschen und mittels wasservice neu anlegen. Dabei kannst du die Parameter für wasadmin und passwort mit angeben.

Nach dem löschen der Dienste kannst du auch mittels start|stopServer testen, ob alles in Ordnung ist, dann dann direkt und nicht über den Dienst gestartet wird. Hatte das Problem bei Connections auch schon, da war der wasservice.bat|sh (in WAS_ROOT/bin) eine gute Hilfe!

Hast du in soap.client.properties die Daten des wasadmin etc eingetragen? Wenn ja, dann da das Kennwort nochmal verschlüsseln.

[Tode]

Die Dienste habe ich in der zwischenzeit schon so oft per wasservice gelöscht / neu angelegt, dass das schon im Schlaf funktioniert. Das Problem ist ja: Auch wenn ich die Dienste entferne, und die Server "normal" starte, kann ich sie danach nicht mehr beenden (auch nicht mit Angabe -username xxx -password yyy)
Irgendwo scheint der sich einen anderen Benutzer / Kennwort gemerkt zu haben als der, der sonst auf allen anderen Servern (und eben auch auf der Sametime System Console) funktioniert...

Habe den Proxy jetzt erneut deinstalliert, nochmal alle Installations- Voraussetzungen (zum wiederholten Male) überprüft und versuche es ein weiteres Mal... wünscht mir Glück.
Über die soap.client.properties habe ich gelesen, dass die Angaben dort durch Angabe der username und password- Parameter überschrieben werden und damit in diesem Fall nicht ziehen...

[stoeps]

Ich würde den stopServer mal ohne Angabe von User und Passwort versuchen, wenn dann ein Abfragefenster kommt passt es, wenn nicht hat er wohl doch was gespeichert. Ich bin mir leider nicht sicher in welcher Reihenfolge da Files für die Credentials gefragt werden.

[Tode]

Auch wenn ich ohne Benutzer und Passwort stoppe und ich die Abfrage wahrheitsgemäss ausfülle sagt er "nene... falscher Benutzer / Passwort"... Schon wieder... hatte grade komplett neu installiert... Ich verzweifle noch...

[Tode]

hmmm... seltsam: Es gab plötzlich unter "Benutzer und Gruppen" -> Benutzer verwalten einen weiteren Benutzer "wasadmin" zusätzlich zu dem vom System angelegten... Ist das normal?

[stoeps]

Ich würde behaupten nein! Das könnte dein Problem sein, da der fileBased wasadmin nicht mehr eindeutig ist.

[Tode]

habe den mal gelöscht... jetzt muss ich nur rausfinden, wo das "verlinkt" ist, also woher der STProxyServer weiss / glaubt zu wissen, dass er auf den falschen wasadmin gelinkt ist... Habe weder in den nodes noch in den nodeagents noch in der Serverconfig irgendwo einen Hinweis auf "das ist mein Admin" gefunden...

[stoeps]

Unter Linux steht es hier:

/opt/IBM/WebSphere/AppServer/profiles/cnxSrv01/config/cells/cnxwas1Cell01/security.xml:  <userRegistries xmi:type="security:WIMUserRegistry" xmi:id="WIMUserRegistry_1" serverId="" serverPassword="{xor}" realm="defaultWIMFileBasedRealm" ignoreCase="true" useRegistryServerId="false" primaryAdminId="wasadmin" registryClassName="com.ibm.ws.wim.registry.WIMUserRegistry"/>

Also in den jeweiligen security.xml files.

Solltest du dich nicht mehr anmelden können, dann würde ich die Security auf Off stellen (siehe http://www.kbild.ch) und dann über die ISC aktivieren, dann fragt er USER/PASSWORT ab.

[Tode]

Danke für den Hinweis, dann prüfe ich das mal... Weil der Proxy weigert sich nun auch, die nodes zu synchronisieren mit der selben Fehlermeldung...
Dann schaue ich mal in die security.xml

[Tode]

ich trete das Drecksding gleich in die Tonne... in der security.xml der cell steht der richtige Benutzer mit dem richtigen Passwort- Hash... trotzdem behauptet das Ding beharrlich, ich würde den falschen Benutzer / Kennwort angeben... ARGH!

[m3]

Wie hast Du denn den ST Proxy installiert? Standalone und hinein foederiert oder "normal" mit Deployment profile.

Kannst Du von der SSC einen Nodesync mit dem Proxy machen?

[Tode]

Ich habe schön einen Deploymentplan erstellt, dann den Proxy unter Verwendung desselben installiert. Beim nodesync kommt genau die selbe Fehlermeldung wie beim Versuch den Server zu stoppen... Aber irgendwas scheint Ihm mit den Authorizations nicht zu passen... muss mal schauen: u.U. findet der Proxy den LDAP- Server nicht, und dann schlägt die komplette authentication fehl, obwohl der user ja aus dem "defaultWIMFileBasedRealm" kommt...

[Tode]

zu allem Überfluss fehlen mir jetzt Plötzlich die Menupunkte für die Sametime System Console in der Managementconsole... Was ist denn da schon wieder kaputt gegangen?

verdammt... wenigstens die Ursache hierfür habe ich gefunden: Der doppelte Eintrag für "wasadmin" war wohl doch ok... siehe hier...

[Tode]

Kleiner Erfolg... Der Proxy steht in ner DMZ... Da hat er zwar Zugriff auf alle Internen Server, aber keinen internen DNS. Ich hatte gedacht, ich hätte alle beteiligten Server in der HOSTS hinterlegt, aber ich hatte einen der LDAP- Server vergessen... Nun habe ich den hinzugefügt, und der Dienst wird wieder beendet.

Jetzt muss ich nur das reparieren, was bei den Reparatur- Versuchen für den Proxy kaputt gegangen ist... Den fehlenden Eintrag für den wasadmin habe ich inzwischen mittels wsadmin- Tool und

Code

$AdminTask mapUsersToAdminRole {-roleName "All Authenticated Users" -userids {wasadmin }}

wieder hergestellt. Jetzt bootet die Kiste gerade neu, mal sehen, ob ich danach die Einträge für die Sametime- Administration wieder sehe...