Beiträge von weltmeister

Update: falls jemand das selbe Problem hat:

Zitat

mysql_upgrade -u root -p

... und das Problem ist erledigt! LiveConfig läuft nun tadellos mit der neuen Version.
Manchmal ist man eben schon betriebsblind

Folgendes Problem: beim anlegen neuer Datenbanken fehlen diverse Rechte, siehe Bild rot umrahmt.

http://www.bilder-upload.eu/upload/505b56-1491906643.png

D.h. die Datenbanken werden zwar angelegt, jedoch ist nur ein root-Login möglich.

Das Problem trat nach dem Update des MySQL-Servers heute auf die o.g. Version auf.
Ergänzt man die fehlenden Rechte manuell, kann sich auch der "normal-Benutzer" (Kunde) einloggen.

Von LiveConfig selbst wird die Datenbankversion unter Serververwaltung ---> Datenbanken anerkannt Auch unter LiveConfig --diag wird die neue Version angezeigt. Liegt hier ein Bug vor?

Zitat von suppenuser

Ziehst Du alle Kunden um oder nur einen Teil?

Nur einen Teil.

Mal eine Frage: Umzug von 20 Kunden mit 50 SSL-Zertfikaten. Müssen diese allesamt manuell neu angelegt werden?

Hier würde ich für die Zukunft definitv soetwas wie eine "Export-Import"-Funktion wünschen, so wie es hier vor 5 Jahren schon einmal angekündigt worden ist.

Gibt es hier schon etwas neues?

Ich bin auch ein wenig enttäuscht darüber, das es bei derartigen Bugs wie aktuell Bekannt keine kleineren Updates zwischendurch gibt.

Auch ich habe mir Plesk angeschaut - bei dem derzeitigen Funktionsumfang hängt LiveConfig noch sehr, sehr weit hinterher. (Backups auf Knopfdruck, Kopieren auf fremden FTP-Server und und und... das sind Dinge, die einem Kunden das leben leichter machen)

Ein Wechsel auf Plesk kommt aber trotzdem nicht in Frage (zu überladen, zu unübersichtlich). Die Kunden haben sich nun an diese Oberfläche gewöhnt. Ich schwöre auf LiveConfig und hoffe auf eine alsbaldige veröffentlichung des nächsten Updates und das es künftig noch viele neue Funktionen geben wird.

Also langsam macht das echt keinen Spaß mehr, vor 6 Monaten, also einem halben Jahr (!!!) wurde dieses Problem gemeldet, passiert ist noch immer nichts! Warum gibt es zwischendurch nicht mal ein kleines Update, welches genau solche Probleme behebt? Ständig ist irgend ein Server nicht erreichbar und es muss genau wegen diesem Problem jedesmal manuell eingegriffen werden... Ich will nicht meckern, weil ich sonst zufrieden mit dem Produkt bin, wollte das aber einmal loswerden.

Gibt es hier bald eine Lösung? Auf dauer kann das so nicht weitergehen!

Zitat von lebenszeit

und der Provider wäre glücklich, der Kunde würde seine Software auf PHP 5.6 oder PHP 7 updaten. Vielleicht wäre das ein Weg?

Bei unserem Kunden leider nicht!

... wir nutzen das ganze ausschließlich aus diesen Quellen, Debian 7: https://www.liveconfig.com/wiki/de/multiphp

Wenn man das noch nachträglich "einbauen" könnte, wäre der Kunde glücklich

Siehe oben - wie stellt man das am besten für PHP 5.5 an?
Mit PHP 5.4. gibt es keine Probleme - die Datei imagick.ini sorgt im entsprechenden Verzeichnis dafür, dass die Erweiterung funktioniert, nur mit PHP 5.5. will das nicht klappen. Ich stehe anscheinend gerade etwas auf dem Schlauch...

Auch ich muss leider etwas "drängeln": heute wieder selbiges Problem!

Auch wenn das Problem bereits bekannt ist: ich bitte um ein rasches Update, auch ich kann diese plötzlichen und vor allem unerwarteten Abstürze nur bestätigen, genau so wie oben beschrieben.

Blacklist/Whitelist pro E-Mail-Adresse

---> würde ich auch begrüßen!

Mal noch eine Frage: gibt es eigentlich eine richtige ausführliche (empfehlenswerte) Cronjob-Anleitung, die auch normale Endkunden ohne weiteres verstehen?

Das sind Dinge, die ein normaler Kunde gar nicht wissen kann.
Ich selbst ging immer davon aus, dass Cronjobs in der PHP-Version ausgeführt werden, welche man für den jeweiligen Account hinterlegt hat.

Zitat von Nosxxx

Bindest du auch die ConfigDatei ein?

/usr/bin/php -c /var/www/webxxx/conf/php5 /var/www/webxxx/htdocs/cron.php

Wenn man es so einbindet, verschwinden die Fehlermeldungen.

Bisher war der Cronjob so angelegt: /usr/bin/php -q /var/www/webxxx/htdocs/cron.php

Zitat von antondollmaier

Code

/usr/bin/php -c /var/www/VERTRAG/conf/php5 /var/www/VERTRAG/htdocs/cron.php

Die Kunden haben keine Möglichkeit, die PHP-Einstellungen selbst zu bearbeiten. Ich dachte, es wird grundsätzlich auf die globale php.ini zugegriffen?

Zitat von Nosxxx

Wird den der IonCube Loader bei ner PHP-Info Datei ausgegeben?

Redest du jetzt von der CLI oder CGI?

Ja wird korrekt angezeigt. Die Rede war hier von CLI, wegen dieser Aussage:

Zitat

IonCube might be configured fine for apache but it has to be also configured for "command-line interface"(CLI). CLI uses different php.ini file than apache and therefore it may be working fine for the actual installation but not working for the CLI on your server.

Durch einen Cronjob kommt leider nach wie vor noch diese Fehlermeldung:

Zitat

Site error: the file <b>/var/www/webxx/xxx</b> requires the ionCube PHP Loader ioncube_loader_lin_5.4.so to be installed by the website operator. If you are the website operator please use the <a href="http://www.ioncube.com/lw/">ionCube Loader Wizard</a> to assist with installation.

Die normale Websiete funktioniert, es geht nur um den Cronjob und PHP-CLI.

D.h. entweder habe ich einen Denk- oder Einstellungsfehler oder es liegt noch ein kleiner Bug vor.

Was sagt der Chef (KK) dazu?

Nachtrag: auch das ändern der Ladereihenfolge bringt leider keine Abhilfe.