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
[…] […]
did you find a solution?
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“.
The bad thing about this is that psaadm has root-rights, which is in general a bad thing to do.
Absolutely! But: it works for the moment.