Beiträge von weltmeister

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.

Zitat von HBO

Wieso so kompliziert? Die Extension muss einfach nur zuerst geladen werden, ergo sieht eine Konfiguration in LC wie folgt aus:

Name: zend_extension
Typ: Erweiterung
Wert (zBsp): /usr/lib/php5/20121212/ioncube_loader_lin_5.5.so
Lade-Reihenfolge: 1
PHP Version: ≥ 5.5 , < 5.6

Name: zend_extension
Typ: Erweiterung
Wert (zBsp): /usr/lib/php5/20121212/ioncube_loader_lin_5.6.so
Lade-Reihenfolge: 2
PHP Version: ≥ 5.6 , < 5.7

usw usw

Wichtig ist nur, dass die Ladereihenfolge aller anderen "extensions" größer ist als die der Ioncube Loader.

Wir nutzen mittlerweile gar keine globale php.ini mehr sondern verwalten sämtliche Einstellungen über LC, funktioniert wunderbar.

Alles anzeigen

So ist es, wir wollen das künftig auch komfortabel über diese Oberfläche verwalten.

Mein "Fehler" ist hier tatsächlich die Ladereihenfolge, hier stand überall die "1".
Ggf. sollte das in der Dokumentation mit erwähnt werden, oder habe ich da etwas falsch verstanden?

Hier die Antwort des Scriptherstellers:

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.

D.h. es kommt hier zu einer Fehlfunktion, wenn man die Sache über die LiveConfig-Oberfläche einbindet, da die php.ini für CLI nicht aktualisiert wird?

ich muss das "alte" Thema nochmals ausgraben:

3 PHP-Versionen, für jede wurde Ioncube gemäß Anleitung eingebunden, trotzdem...

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.

----> http://img5.fotos-hochladen.ne…ads/ioncubef3la8sq096.png

Wo ist der Fehler?

Also ich kann machen was ich will, es funktioniert einfach nicht. "Die Domain 82.xxx.xx.xxx ist nicht verfügbar."

Trotz zuweisung einer "exclusiven IP" unter Serververwaltung ---> Web

Woran kann das noch liegen?

Zitat von nicht_der_max

Aber: Hab das Ganze in der Apache-Konfiguration nochmal nachgeprüft und dort die Erleuchtung bekommen, dass ich natürlich für die Domain 12.34.56.78 auch DIESE IP zuweisen muss! Grrr.... So nahe dran gewesen.
Danke aber ManDal, Du hast mich dennoch auf die richtige Spur gebracht

Marc

Hat das bei dir funktioniert?
Ich habe das eben auch einmal wie oben beschrieben probiert, da ich diese Funktion ebenso benötige. Hat jedoch nicht funktioniert....

Grundlage: Debian Wheezy mit "liveconfig-meta" und MySQL 5.5.

Wie geht man da am besten vor?

Reicht es, die alte Version zu entfernen und die neue zu Installieren?

Hier lese ich z.B. noch, dass einige Tabellen manuell ergänzt werden müssen? ---> https://blog.bastelfreak.de/20…pgrade-von-5-5-5-6-fixen/

Freue mich über Tipps und Vorschläge!

Zitat von kk

Ich finde kein einziges offenes Ticket von Ihnen.

Ich erinnere an meine mehrfachen Anrufe. Sie wollten die beiden besprochenen Punkte damals notieren / als Ticket anlegen...

Zur Erinnerung:

- Direkter Login aus einer internen Verwaltungsoberfläche heraus, z.B. einem Kundenloginbereich / Kundenverwaltungsbereich, ohne dort die Passwörter im Klartext hinterlegen zu müssen.
- Aufruf der Inhalte eines Webspace, direkt per Einzel-IP, z.B. http://198.33.22.43 (war mit Confixx möglich)

Auch wenn das keine "extrem wichtigen" Dinge sind, diese hatten wir bereits im Dezember 2013 und in einem oder zwei wiederholten Telefonaten ausführlich besprochen.

LiveConfig finde ich gut, schade ist jedoch, dass der Support in der Tat etwas schleppend ist.

Komfortabel wäre hier die Einstellungsmöglichkeit, direkt in der Oberfläche.
Ich kann es nur unterstreichen: die Kunden "vergessen" den Spamfilter zu aktivieren und beschweren sich anschließend über den ganzen Spam. Es ist wie ein Kreislauf ohne Ende.

Hallo!

Ist eigentlich schon einmal über ein Rabattmodell für Abnehmer sehr vieler LiveConfig-Lizenzen nachgedacht worden?

Hier stehe ich auf dem Schlauch... wenn ich ein neues Zertifikat in Form von servername.meinedomain.de anlegen will, sehe ich folgende Fehlermeldung: Domainname nicht gefunden

Gibt es eine Anleitung dafür?

Hier noch die ganz blöde Frage: wo legt man dieses Zertifikat konkret an?

Vielen Dank für den Tipp, der austausch des Zertifikates hat schon abhilfe geschaffen.

Da fällt mir doch gleich folgende Frage an den Chef ein: wie sieht es aus mit der Verwaltung der Serverzertifikate, erstellt und verlängert durch Let's Encrypt?

Mit ProFTPD?

Nachtrag: der SSH-Zugriff funktioniert, nur der normale Zugriff per FTP auf die einzelnen Accounts nichts, was vor dem Filezilla-Update problemlos auf allen Servern funktionierte.

Hat schon mal jemand versucht, mit der aktuellen Filezilla-Version eine FTP-Verbindung zu einem Kundenaccount herzustellen? Auf allen Servern ist das nach dem Update auf Version 3.20 leider nicht mehr möglich:

Zitat

Status: Auflösen der IP-Adresse für xxxx.de
Status: Verbinde mit xx.xx.xx.xx:21...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Status: Initialisiere TLS...
Fehler: Empfangene Zertifikatskette konnte nicht verifiziert werden. Verifizierungsstatus ist 66.
Fehler: Herstellen der Verbindung zum Server fehlgeschlagen
Status: Nächsten Versuch abwarten...
Status: Auflösen der IP-Adresse für xxxx.de
Status: Verbinde mit xx.xx.xx.xx:21...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort: 220 ::ffff:xx.xx.xx.xxFTP server ready
Befehl: AUTH TLS
Antwort: 234 AUTH TLS successful
Status: Initialisiere TLS...
Fehler: Empfangene Zertifikatskette konnte nicht verifiziert werden. Verifizierungsstatus ist 66.
Fehler: Herstellen der Verbindung zum Server fehlgeschlagen

Alles anzeigen

Kann das jemand bestätigen?

Nein, in keiner der beiden.

Weder in
/htdocs/.htaccess
noch
/htdocs/sites/default/files/.htaccess