Plesk 10 Fehlermeldung: ERROR: SWKeyExFatalError / cannot open file

[E-Commerce] IT-Consulting and Development in Mühldorf am Inn

Plesk 10 Fehlermeldung: ERROR: SWKeyExFatalError / cannot open file

Jeden morgen wieder ist das Parallels Pleskpanel unter http://my.domain.de:8443 nicht mehr zu erreichen bzw. präsentiert sich mit einer Fehlermeldung auf dem Bildschirm:
[code]ERROR: SWKeyExFatalError
error: Cannot open file

0: common_func.php3:4758
of_get_key_by_product(string ‚plesk-unix‘)
1: common_func.php3:4758
getPleskKey()
2: common_func.php3:4833
getKeyProp(string ‚demo‘)
3: auth.php3:81[/code]

Was das Problem ist

Ich kann im Moment noch nicht wirklich sagen, was wirklich das Problem verursacht.
Plesk 10.0.1 hat aber definitiv Probleme mit dem täglichen CronJob der unter /etc/cron.daily/50plesk-daily abgelegt ist, da diese Fehlermeldung täglich wieder kommt.

Dieser CronJob frägt unter /opt/psa/admin/plib/DailyMaintenance/update-keys.php ab, welches nicht einsehbare Dinge verrichtet, da diese Datei leider verschlüsselt ist.
Was aber das Problem auslöst sind mangelnde Zugriffsrechte auf die /etc/sw/keys/registry.xml

Da ich in diesem Zusammenhang noch auf eine Antwort vom Parallels Support Team abwarte, möchte ich die folgenden Lösungsansätze als reine Hacks bezeichnen, welche nur temporär verwendet werden sollten, bis eine richtig akzeptable Lösung gefunden wurde.

Mögliche Dauerhafte Lösung

Viele Benutzer berichten, dass ein einfaches Löschen von /etc/sw/keys/registry.xml geholfen haben sollte. Da das Problem im Prinzip nur in mangelnden Leserechten auf diese Datei besteht, kann es schon möglich sein, das neue generieren einer registry.xml helfen mag – Bei mir brachte es zumindest keinen Erfolg.
[code]rm /etc/sw/keys/registry.xml
service psa restart[/code]

Hacks

Temporär hilft natürlich immer einfach für die nötigen Zugriffsrechte zu sorgen.
Dies erreicht man, indem man die schnell allen Benutzern Leserechte gibt.
[code]chmod 664 /etc/sw/keys/registry.xml[/code]

Da der CronJob täglich ausgeführt wird und somit täglich die registry.xml überschrieben wird, ist dies nur immer maximal für 24 Stunden eine Lösung.

Eine dauerhafte, dafür aber umso schlechtere Lösung ist, den Benutzer psaadm temporär in die Gruppe root zu setzen – Dies sorgt zwangsweise für die nötigen Rechte.
[code]usermod -aG root psaadm[/code]

Abschließend

Sobald das Problem eindeutig identifiziert und gelöst ist, wird eine dauerhafte angemessene Lösung nachgerecht.

 

5 Responses

  1. Volker sagt:

    did you find a solution?

  2. i’m very sorry, but unfortunately i didn’t come to a solution.

    what’s helping is delegating the user „psaadm“ root privileges. Just put him into the root group and you’re fine
    usermod -aG root psaadm

    Anyhow it does work for me, i don’t know of any possible drawbacks with this „solution“.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.