Beiträge von ap24

Email ist raus ([LC#2019082234000024]), das Problem scheint nur bei neu erstellten Subdomains zu bestehen, wenn z.B. bei einer bereits vorhandenen Subdomain ein neues Zertifikat angelegt wird, läuft die Zertifikatserstellung ohne Probleme.

Zitat von kk

Können Sie bitte kurz beschrieben, wie exakt Sie diese Domain angelegt und das SSL-Zertifikat dafür bestellt haben?
Die Fehlermeldung sagt sinngemäß, dass die Datei für die Domainvalidierung erfolgreich erstellt wurde, LiveConfig aber keinen offenen Bestellvorgang fand und daher den Auftrag nicht weiter verarbeitet hatte.
Lässt sich das mit anderen (Sub-)Domains reproduzieren?

Genau so wie im anderen Beitrag beschrieben:

- die Sudomain erstellt und aktiviert (Hosting - Domains - neue Subdomain)
- unter "SSL-Zertifikate - neues Zertifikat" das Zertifikat angelegt

Das Problem besteht auch bei anderen Subdomains, solange bis ein Neustart von LiveConfig erfolgt.

Die Hauptdomain besteht schon länger und wurde nicht erst kürzlich registriert/angelegt.

Leider werden die SSL-Aufträge auch nicht bearbeitet:

Name		Überprüft		Methode	Status
demo2.domain.de	00.00.0000 00:00:00	http-01	pending

[2019/08/22 11:22:06.731115] [12849|12855] ACME2: loading authorization details from https://acme-v02.api.letsencrypt.org/acme/authz/F-nfbK0HWU0K138xIm_5HoHKzCxjwcanfaUGmQv5rds
[2019/08/22 11:22:06.988983] [12850|12851] [LUA] Created SSL/TLS domain-validation file '/var/www/.well-known/htdocs/acme-challenge/demo2.domain.de.epyj8O-rY4fkX1zH5j4--7F5IlDfMPZQmn8iVmoJF74'
[2019/08/22 11:22:06.992495] [12849|12859] Got LC.web.addValidation.status for unknown domain 'demo2.domain.de' at '/.well-known/acme-challenge/epyj8O-rY4fkX1zH5j4--7F5IlDfMPZQmn8iVmoJF74'
[2019/08/22 11:22:27.432283] [12850|12852] [LUA] LC.exec(/sbin/service httpd reload): error output: Redirecting to /bin/systemctl reload httpd.service

Erst nach einem Neustart von LiveConfig wird das Zertifikat dann angelegt.

CentOS Linux release 7.6.1810 (Core)
LiveConfig 2.8.0-r5579

Hallo zusammen,

vielleicht kann mir bitte einer mal die neue "völlig überarbeitete SSL/TLS-Integration" erklären, für mich ist das eher eine Verschlimmbesserung.

Wenn ich für eine neue Subdomain z.B. forum.domain.de ein SSL-Zertifikat erstellen möchte muss ich erst:

- die Sudomain erstellen
- die Sudomain erst aktivieren (da diese standardmäßig deaktiviert ist und somit kein Zertifikat erstellt werden kann)
- unter dem Punkt "SSL-Zertifikate" das Zertifikat anlegen
- wieder zurück in die Domainverwaltung
- die Subdomain auswählen und das Zertifikat aktivieren (da es keine Möglichkeit mehr gibt die HTTPS Weiterleitung direkt beim Anlegen des Zertifikats zu aktivieren)

Muss das wirklich so umständlich erfolgen???

Vielen Dank
Alex

dürfte das gleiche Problem wie unter https://www.liveconfig.com/de/…3337&viewfull=1#post13337 sein...

Wir lassen einfach ein kleines Script unter /var/cache/liveconfig/installer laufen, welches die PHP-Überprüfung löscht, seitdem treten keine Probleme mehr auf.

Sollte in Kürze möglich sein:

https://www.liveconfig.com/de/…462-Reseller-l%C3%B6schen

Ich habe den Part

if ($row['dns'] == 1) {
              # auf eigenem DNS anlegen
              $d_data['dnstemplate'] = $OPTS['dnstemplate'];
              if (isset($row['lastchange'])) {
                $d_data['serial'] = date('Ymd') . '01';
                if ($d_data['serial'] <= $row['lastchange']) $d_data['serial'] = $row['lastchange'] + 1;
              }
            }

im Migrations-Tool mal entfernt, der Import hat nun soweit ohne Fehler funktioniert.

Ich verwende weder eine DNS-Vorlage, noch ist in der Serververwaltung der DNS-Dienst aktiviert:confused:

Guten Tag,

beim Ausführen des Migrationsscriptes erhalte ich folgende Fehlermeldung:

----------SOAP-Request:----------
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="urn:LiveConfig"><SOAP-ENV:Body><ns1:HostingDomainAdd><ns1:auth><ns1:login>admin</ns1:login><ns1:timestamp>2017-08-10T21:17:26.000Z</ns1:timestamp><ns1:token>LvncRuI1foZr25iVsJJFbwumXb0=</ns1:token><ns1:customer>cFNsgU1GkpW7</ns1:customer></ns1:auth><ns1:subscription>web118</ns1:subscription><ns1:domain>web118.serverdomain.de</ns1:domain><ns1:mail>1</ns1:mail><ns1:web>/</ns1:web><ns1:dnstemplate>Standard</ns1:dnstemplate><ns1:serial>2017081001</ns1:serial></ns1:HostingDomainAdd></SOAP-ENV:Body></SOAP-ENV:Envelope>


----------SOAP-Response:----------
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
                   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
                   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <SOAP-ENV:Fault>
      <faultcode>SOAP-ENV:Server</faultcode>
      <faultstring>Invalid DNS template or not permitted</faultstring>
    </SOAP-ENV:Fault>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


Error while calling Web Service HostingDomainAdd: Invalid DNS template or not permitted

Parallels Confixx Version 3.3.9
LiveConfig Version 2.4.1-r4635
openSUSE 42.3

Wie kann das Problem behoben werden?

Vielen Dank
Alex

Ist man doch langsam gewöhnt wie "zuverlässig unzuverlässig" solche Termin-Aussagen sind....

paar Tage = paar Monate
paar Monate = paar Jahre
paar Jahre = ∞

Zitat von kk

Nennen wir es "die Ruhe vor dem Sturm"

War wohl nur ein laues Lüftchen

Seit knapp einem halben Jahr keine Updates und das beim zum Teil schweren Bugs...

Naja scheint ganz so als hätte man keine große Lust mehr - egal wir haben die meisten Server eh schon wieder von LiveConfig abgezogen...

Es nervt langsam.....

Wann kann man endlich mit einem Update oder wenigstens mit einem Workaround rechnen!!!

Der Fehler wurde vor über 4 Monaten gemeldet, langsam fehlt mir das Verständis wenn durch LiveConfig der Webserver abgeschossen und keine Lösung angeboten wird.....

LiveConfig hat nun erneut den Apache-Webserver abgeschossen:

[Mon Nov 21 10:54:08.504448 2016] [ssl:emerg] [pid 19619] AH02562: Failed to configure certificate www.DOMAIN.de:443:0 (with chain), check /etc/apache2/ssl.crt/98a3095b43ea73f4.crt
[Mon Nov 21 10:54:08.504479 2016] [ssl:emerg] [pid 19619] SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line (Expecting: TRUSTED CERTIFICATE) -- Bad file contents or format - or even just a forgotten SSLCertificate
KeyFile?
[Mon Nov 21 10:54:08.504487 2016] [ssl:emerg] [pid 19619] SSL Library Error: error:140DC009:SSL routines:SSL_CTX_use_certificate_chain_file:PEM lib
AH00016: Configuration Failed
lclogsplit: got TERM signal
[Mon Nov 21 10:55:33.624178 2016] [ssl:emerg] [pid 20101] AH02562: Failed to configure certificate www.DOMAIN.de:443:0 (with chain), check /etc/apache2/ssl.crt/98a3095b43ea73f4.crt
[Mon Nov 21 10:55:33.624209 2016] [ssl:emerg] [pid 20101] SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line (Expecting: TRUSTED CERTIFICATE) -- Bad file contents or format - or even just a forgotten SSLCertificate
KeyFile?
[Mon Nov 21 10:55:33.624218 2016] [ssl:emerg] [pid 20101] SSL Library Error: error:140DC009:SSL routines:SSL_CTX_use_certificate_chain_file:PEM lib

Bitte um Behebung!!!

Vielen Dank

Naja es geht hier nicht hauptsächlich um die installierte Distributionsversion, sondern mehr um die eingesetzte bzw. installierte PHP-Version.

PHP 5.4 ist seit dem 3. September 2015 auch end-of-life, warum wurde die Prüfung der PHP-Version im Installer-Script seit Kurzem eingefügt?

Ich verstehe wie gesagt den Sinn hier nicht wirklich:

a) wenn schon eine Überprüfung erfolgt, warum nicht mit der eingestellten LiveConfig PHP-Version?

b) PHP 5.4 ist ebenfalls "end of life"

Entweder man führt eine korrekte PHP-Überprüfung beim Installer-Script ein oder man lässt es (wie vorher ja auch) ganz weg.

Auf dem betreffenden Server läuft openSuse12.3.

Warum werden die Installer-Scripte nicht mit der eingestellten LiveConfig PHP-Version ausgeführt/installiert?
Die entsprechende CLI-Version wurde mit installiert (siehe Beitrag #10).

Ich verstehe den Sinn nicht warum das Installer-Script nur die Version unter /usr/bin/php prüft, nicht aber die (Standard) PHP-Version welche in LiveConfig eingestellt wurde :confused:

Wenn im Installer die folgende Zeile auskommentiert wird:

if (!version_compare(PHP_VERSION, "5.4.0", ">=")) { die("ERROR PHP < 5.4.0 is not supported! (Current Version: ". PHP_VERSION .")"); }

ist eine Installation wieder ohne Probleme möglich.

Wie bereits erwähnt wird für die Domain/Subdomain auf welche die Anwendung installiert werden soll PHP 5.6 bzw. 7.0 verwendet, ich bitte daher nochmals um Überprüfung warum das Installer-Script unter /var/cache/liveconfig/installer anscheindend nicht die korrekte PHP-Version erkennt.

Vielen Dank

Alex Prodner

Es betrifft nicht nur die Anwendung "Gallery" sondern zum Teil auch noch andere (Joomla, Roundcube).

Bitte daher nochmals um Prüfung, die Anwendungen konnten vor LiveConfig 2.2.x ohne Probleme installiert werden.

/usr/bin/php -v

PHP 5.3.22 (cli)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies
with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH

/opt/phpfcgi-5.6.24/bin/php -v

PHP 5.6.24 (cli) (built: Aug 10 2016 11:48:54)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.1.2, Copyright (c) 2002-2016, by ionCube Ltd.
    with Zend Guard Loader v3.3, Copyright (c) 1998-2014, by Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

/opt/phpfcgi-7.0.9/bin/php -v

PHP 7.0.9 (cli) (built: Aug  8 2016 13:53:35) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.9, Copyright (c) 1999-2016, by Zend Technologies

Zitat von kk

Der AppInstaller für Gallery liegt aktuell in Version 3.0.9-4 vor, nicht 3.0.9-3.
Welche LiveConfig-Version genau nutzen Sie, und unter welcher Distribution?
Das App-Repository sollte LiveConfig täglich aktualisieren - in /var/log/liveconfig/liveconfig.log finden Sie dann folgende Meldung:

Code

[...] Updating AppInstaller repository (https://update.liveconfig.com
/repo-v3.json)...

Es wird LiveConfig 2.2.2-r4304 verwendet als Distributionen OpenSuse 42.1/13.2/12.3

Eine Fehlermeldung etc. erscheint nicht:

[Blockierte Grafik: http://fs5.directupload.net/images/160919/ikylyfmy.jpg]

Es wird PHP 5.6 bzw. 7 verwendet:

- PHP 5.6.24 [DEFAULT] (code='php5', bin='/opt/phpfcgi-5.6.24/bin/php-cgi', SAPI=CGI/FastCGI)
   default php.ini: '/opt/phpfcgi-5.6.24/bin/php.ini'
  - PHP 7.0.9 (code='php709', bin='/opt/phpfcgi-7.0.9/bin/php-cgi', SAPI=CGI/FastCGI)

Die Anwendungen werden teilweise seit der Liveconfig Version 2.2 überhaupt nicht mehr installiert bzw. heruntergeladen, es erfolgt entweder die o.g. Fehlermeldung bzw. es erscheint nach Auswahl der Anwendung (Liveconfig > Anwendungen > App installieren) nur eine leere weiße Seite.