Debian 8
LC 2.9.3
Magento und Appinstaller könen nicht installiert werden.
liveconfig.log:
wai-modified-shop-1.06-r4642-SP2-p1-3.php: ERROR in download sha1 check failed
wai-magento-1.9.3.8-1.php: ERROR in download sha1 check failed!
Debian 8
LC 2.9.3
Magento und Appinstaller könen nicht installiert werden.
liveconfig.log:
wai-modified-shop-1.06-r4642-SP2-p1-3.php: ERROR in download sha1 check failed
wai-magento-1.9.3.8-1.php: ERROR in download sha1 check failed!
Debian Jessie
LC 2.8.4-r5653
Hallo liebe Wissende,
folgendes Problem:
DomainA mit PHP 7.1.33 liefert einen 500er und hat folgende .htaccess
# BEGIN GZIP
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE "application/atom+xml" \
"application/javascript" \
"application/json" \
"application/ld+json" \
"application/manifest+json" \
"application/rdf+xml" \
"application/rss+xml" \
"application/schema+json" \
"application/vnd.geo+json" \
"application/vnd.ms-fontobject" \
"application/x-font-ttf" \
"application/x-javascript" \
"application/x-web-app-manifest+json" \
"application/xhtml+xml" \
"application/xml" \
"font/eot" \
"font/opentype" \
"image/bmp" \
"image/svg+xml" \
"image/vnd.microsoft.icon" \
"image/x-icon" \
"text/cache-manifest" \
"text/css" \
"text/html" \
"text/javascript" \
"text/plain" \
"text/vcard" \
"text/vnd.rim.location.xloc" \
"text/vtt" \
"text/x-component" \
"text/x-cross-domain-policy" \
"text/xml"
</IfModule>
# END GZIP
Alles anzeigen
Ursache:
[[core:alert] ...... /.htaccess: Invalid command
'text/css', perhaps misspelled or defined by a module not
included in the server configuration
Kommentiert man 'text/css' aus, läuft die Seite.
DomainB mit PHP 7.0.33 hat dieselbe .htaccess und erzeugt auch mit 'text/css' keinen 500er.
Stellt man Domain B auf PHP 7.0.33 um, darf man auch 'text/css' benutzen.
Ich nutze die PHP-Pakete von Keppler-IT.
Kennt jemand die Ursache für dieses Verhalten?
Guten Morgen,
Debian Jessi
LC-Version: 2.8.4-r5653
Aktuell lassen sich in LC Weiterleitungziele an der Domain einstellen, die zu lang sind und beim Apache restart des Webservers verhindern.
Beispiel aus der /etc/apache2/sites-available/schuldiger_kundenvertrag.conf:
ProxyPass "/" "http://education.ti.com/XXXXXXXX/en/ed-tech/XXXXXXXXXXF44D55B9BBF65E5A62E7F1/3136434A5B2D4E8C84E09DCB582FD59C/TI-XXXXXXXXXX-4.0.0.218.exe"
ProxyPassReverse "/" "http://education.ti.com/XXXXXXXX/en/ed-tech/XXXXXXXXXXF44D55B9BBF65E5A62E7F1/3136434A5B2D4E8C84E09DCB582FD59C/TI-XXXXXXXXXX-4.0.0.218.exe"
(Über Sinn oder Unsinn dieser Proxy-Weiterleitung bitte nicht diskutieren, das hat ein Kunde so eingestellt.)
Fehlermeldung:
Nov 20 06:20:35 serverxyz apache2[10159]: AH00526: Syntax error on line 50 of /etc/apache2/sites-enabled/schuldiger_kundenvertrag.conf:
Nov 20 06:20:35 serverxyz apache2[10159]: ProxyPass worker name (http://education.ti.com/XXXXXX…BF65E5A62E7F1/3136434A5B2...) too long
Nov 20 06:20:35 serverxyz apache2[10159]: Action 'configtest' failed.
LC sollte hier vielleicht DRINGEND die Stringlänge überprüfen im GUI und so etwas abfangen. Das bedeutet ja immer, manuell in die /etc/apache2/sites-available/schuldiger_kundenvertrag.conf eingreifen um den Quatsch händisch auskommentieren zu müssen und den Indianer neu zu starten. Solange warten alle Kunden auf dem Server brav, denn nichts geht mehr.
Ich muss das Thema auch noch einmal hochholen. In Vorbereitung eines Betriebssystemupgrades habe ich alle Verträge von suphp auf fastcgi umgestellt:
Dazu habe ich in der LC-Datenbank die entsprechenden Werte in HOSTINGPLANS und HOSTINGCONTRACTS geändert:
mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGPLANS SET HP_PHP=2;"
mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGCONTRACTS SET HC_PHP=2;"
mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGCONTRACTS SET HC_REFRESHCFG=1;"
Danach mit einem beherzten service liveconfig restart die Änderungen durchschreiben lassen und die vhosts neu erstellt.
Danach hatte ich genau das beschriebene Problem, dass der Indianer bei einigen Kunden plötzlich 500er feuerte mit Log-Einträgen:
(104)connection reset by peer: mod_fcgid: error reading data from fastcgi server
Premature end of script headers ... index.php
Die Ursache lage letztlich darin, dass die php-ini-Verzeichnisse unter /var/www/<vertrag>/conf falsche Rechte hatten. Das aber auch nicht durchgehend: einige hatten 0777er Rechte, andere die korrekten 0555er Rechte. Dazu kam, dass bei einigen dieser Verzeichnisse das immutable flag gesetzt war, bei anderen nicht. Alles sehr verworren, zumal ich dort händisch nie eingegriffen habe, sondern LiveConfig immer ganz normal upgegraded habe. Die Lösung war letztlich das immutable flag durchgehend zu entfernen und die Rechte neu zu setzen:
chattr -i /var/www/*/conf/php5
chattr -i /var/www/*/conf/php53
chattr -i /var/www/*/conf/php55
chattr -i /var/www/*/conf/php56
chattr -i /var/www/*/conf/php70
chattr -i /var/www/*/conf/php71
chattr -i /var/www/*/conf/php72
chmod 0555 /var/www/*/conf/php53
chmod 0555 /var/www/*/conf/php55
chmod 0555 /var/www/*/conf/php56
chmod 0555 /var/www/*/conf/php70
chmod 0555 /var/www/*/conf/php71
chmod 0555 /var/www/*/conf/php72
service liveconfig restart
Ich kann das Problem auf allen Servern mit Liveconfig >= 2.6.1 nachvollziehen.
Bei der Installation von Owncloud 10.0.9 über den App-Installer erhält man eine Fehlermeldung:
Error while downloading web application installer - please contact your administrator.
LC-Version ist 2.6.3 auf Debian.
Error while downloading web application installer - please contact your administrator.
Es scheint, als ob die Datei
/var/cache/liveconfig/installer/wai-owncloud-10.0.9-1.php
fehlt.
Erzeuge ich diese als Kopie von /var/cache/liveconfig/installer/wai-owncloud-10.0.7-1.php läuft die Installation durch.
Deine Frage kann ich leider nicht beantworten, aber Du kannst Dich recht einfach selbst "entsperren": Lösche einfache die Einträge in der Tabelle IPBLOCK der LC-Datenbank. Dann funktioniert die Anmeldung wieder.
Hallo,
[*]vereinfachte (automatische) Registrierung von unseren PHP-Paketen für Debian/Ubuntu (keine Anpassung der custom.lua mehr notwendig)
[/LIST]
Müssen die dafür früher erfolgten Anpassungen an der custom.lua zwingend vor dem Update rückgängig gemacht werden?
Moin,
So das zb. Managed Hosting /Selfhosting und Freehosting getrennt sind.
Viele Grüße
Und warum brauchst du dafür verschiedene IP - interessehalber nachgefragt? *kopfkratz*
Guten Morgen,
ich setze gerade einen neuen LC-Server auf.
Zunächst
Danach quota installiert und aktiviert.
Dann
wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -
cd /etc/apt/sources.list.d
wget http://repo.liveconfig.com/debian/liveconfig.list
aptitude update
aptitude install liveconfig-meta
Die Installation bricht mit Fehlermeldung ab:
cat /etc/debian_version
9.4
~ # aptitude install liveconfig-meta
The following partially installed packages will be configured:
liveconfig-meta
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up liveconfig-meta (0.5.6) ...
Module actions already enabled
Considering dependency mime for include:
Module mime already enabled
Module include already enabled
Module rewrite already enabled
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Module socache_shmcb already enabled
Module ssl already enabled
Module suexec already enabled
/var/lib/dpkg/info/liveconfig-meta.postinst: 35: /var/lib/dpkg/info/liveconfig-meta.postinst: /usr/bin/a2enmod: not found
dpkg: error processing package liveconfig-meta (--configure):
subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
liveconfig-meta
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up liveconfig-meta (0.5.6) ...
Module actions already enabled
Considering dependency mime for include:
Module mime already enabled
Module include already enabled
Module rewrite already enabled
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Module socache_shmcb already enabled
Module ssl already enabled
Module suexec already enabled
/var/lib/dpkg/info/liveconfig-meta.postinst: 35: /var/lib/dpkg/info/liveconfig-meta.postinst: /usr/bin/a2enmod: not found
dpkg: error processing package liveconfig-meta (--configure):
subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
liveconfig-meta
Alles anzeigen
Aktuell ist das Drupal-Installationsscript unbrauchbar. Die Installation bricht ab:
Drupal
Name: xyz
Verzeichnis: /apps/xyz
Datenbank: xyz
Status: Fehler: failed to open dir!
Domains: xyz.xy
Der Fehler läßt sich wie folgt beheben:
In der Datei /var/cache/liveconfig/installer/wai-drupal-7.59-1.php alle "7.58" durch "7.59" ersetzen.
Vielen Dank für die Info Herr keppler. Bleibt die Frage: WANN ist denn nun endlich Release der 2.6? Versprochen ist das ja schon länger.
Nein, da die Kontakte ja die des Widerverkäufers sind und der Wiederverkäufer ja schon gelöscht wurde.
Version: LiveConfig 2.5.3-r4805
Der Vertrag eines Wiederverkäufers, der Kunden und Verträge angelegt hatte, soll gelöscht werden.
Das Löschen schlägt zunächst fehl, wenn noch Verträge, die der Wiederverkäufer selbst angelegt hatte, vorhanden sind - was schon mal EXTREM suboptimal ist. Löscht man die dann einzeln in einer Klick-Orgie, kann man den Wiederverkäufer-Vertrag und auch den Wiederverkäufer selbst löschen.
Leider beiben jedoch die Kunden, die der Wiederverkäufer angelegt hat, als Datenmüll in der LiveConfig-Datenbank in der Tabelle USERS als Datenmüll liegen. Diese müssten auch mit gelöscht werden.
Vorschlag: Beim Löschen eines Kunden, sollten generell nach entsprechendem "Sind sie sicher - Sie löschen damit folgende Verträge die folgende Domains enthalten" gelöscht werden:
alle Verträge des Kunden (Mein Hosting)
alle Kunden des Kunden
alle Verträge von Kunden des Kunden
Danke für den Schnipsel!
Ich muss Anton vom Ansatz her Recht geben - es mag tatsächlich LC-User geben, die solche Ausnahmen unkompliziert setzen möchten. In der Sache an sich bin ich jedoch - gerade auch bei T-Offline - knallhart: da würde ich niemals und unter keinen Umständen eine Ausnahme machen, denn das tun die Großen für uns "Kleine" auch nicht. Ganz im Gegenteil - die agieren oft so, als wären sie die Hüter von Recht und Ordnung des Internet. Und wenn ich da noch an die schöne Option "Liste der sicheren E-Mail-Server" im Speedport von T-Offline denke (hab ich quasi jede Woche Anfragen von Neukunden, die keine Mails versenden können, weil unsere Mailserver da natürlich nicht in der Liste stehen), dann bestärkt mich das nur in meiner Meinung. Sollen denen ihre Kunden mal schön Dampf machen, wenn Sie geblacklistet wurden. Wir müssen schließlich auch selbst handeln, wenn uns das passiert und die "Großen" kommen uns auch nicht entgegen. Auch das musste mal raus
lebenszeit Absolute Zustimmung.
Ich sehe das auch so. Wir haben auch immer dieselben Anfragen und deswegen ausufernde FAQ. Jeder Neukunde erhält von uns eine mehrseitige Erst-Anleitung, die die wichtigsten Eigentümlichkeiten von LC thematisiert. Das LC-Handbuch ist ja auch keine wirkliche Hilfe, da es eben kein ENDKUNDEN-Handbuch ist. Viele Kapitel sind für Endkunden absolut irrelevant. Warum koppelt man den Endkundenteil nicht vernünftig aus dem Handbuch aus? Bei Confixx gab es z.B. 3 Handbücher: Administrator, Reseller, Endkunde.