Hallo,
wäre es möglich ab demnächst die PHP 7.2 und 7.3 Pakete mit Argon2 zu bauen?:
TYPO3 setzt darauf standardmäßig mittlerweile:
https://wiki.typo3.org/Exception/CMS/1533822084
Siehe auch: https://wiki.php.net/rfc/argon2_password_hash
Configure benötigt: --with-password-argon2
Ist das eigentlich gewollt, dass der sendmail_path quasi leer ist?:
~# /opt/php-7.2/bin/php -r 'phpinfo();'|grep sendmail_path
sendmail_path => -t -i => -t -i
Dadurch kann die mail() Funktion nicht ohne weiteres genutzt werden. Ich dachte das wäre nur bei der Ubuntu Version so, ist aber auch bei der Buster PHP 7.2 Version der Fall
Super, vielen Dank!
Hallo,
Debian 10 Buster kommt dieses Wochenende raus. Wir wollten mal fragen, zu wann wir mit dem PHP Repo von euch dafür rechnen können? 
Guten Tag,
wenn man bei einem Debian Buster Server den Dovecot konfiguriert und die Config abspeichert gibt es einen LUA Fehler beim Status:
[2019/02/08 09:15:30.188174] [23575|23579] LC.popimap.configure() failed: /usr/lib/liveconfig/lua/dovecot.lua:705: attempt to compare number with nil
stack traceback:
/usr/lib/liveconfig/lua/dovecot.lua:705: in function 'configure'
/usr/lib/liveconfig/lua/popimap.lua:207: in function </usr/lib/liveconfig/lua/popimap.lua:180>
Die betroffene Zeile ist diese:
if LC.distribution.name == "Debian" and tonumber(v) >= 9 then
Wenn ich temporär "and tonumber(v) >= 9" funktioniert es erst einmal.
Guten Tag,
nach dem Upgrade von einem Debian Server mit LC, der Standard PHP Installation von Debian und MultiPHP von LC kam es zu folgendem:
* PHP 5.4 (vorher Standard) hat ioncube_5.4 in der Config gesetzt, 5.6 natürlich 5.6
* Nach dem Upgrade wurde PHP 5.6 Standard, die Konfigurationen wurden aber beibehalten
* Bei 5.4 => 5.6 gibt es ja jetzt keine großartigen Optionen, die heraus geflogen sind, allerdings ging erstmal ioncube nicht, bzw. es kam überall zu den Loader Warnungen
Da LiveConfig für den Apache und PHP kein "schreibe Konfigurationen neu" besetzt, mussten wir uns als einzelner Benutzer überall einloggen und ein Update der Konfiguration anstossen
Ähnlich war es auch bei der Apache und Dovecot Konfiguration. Hier wäre - wie beim FTP Dienst - ebenso ein Button in der Serververwaltung "schreibe Konfiguration neu" sehr erwünscht
Guten Tag,
nach einem Server Upgrade sind ein paar alte PHP Versionen entfallen.
Entwas unschön ist es, dass für nicht mehr vorhandene / registrierte PHP Versionen weiterhin die Konfigurationen in /var/www/*/conf/ liegen, das führt dazu, dass zB das Skript /usr/lib/liveconfig/cron.php.sh unnötig länger läuft und auch Warnungen / Fehler wirft
Haben Sie schon eine Idee? Ansonsten können sie sich auch gerne telefonisch melden und dann schauen wir mit zB Teamviewer einmal direkt uns das an
Nope:
root@config:~# find / -type f -name custom.lua
root@config:~#
Guten Tag,
auf der Liveconfig Hauptinstanz liegt auch unserer VHost für das Autodiscover. web10 hier. Da das SSL Zertifikat sich nicht die letzten Wochen mit aktualisiert hatte wohl hab ich das einmal geprüft. Immer wenn man eine Änderung an der Domain durchführen möchte, kommst Instant dieser Fehler auf dem Server:
[2018/08/17 13:47:02.064320] [30827|30831] [LUA] LC.mutex: forcing unlock of mutex 'web.configure'
[2018/08/17 13:47:02.065718] [30827|30831] LC.web.vhostConfig(web10)) failed: /usr/lib/liveconfig/lua/apache.lua:1695: bad argument #4 to 'write' (string expected, got nil)
stack traceback:
[C]: in function 'write'
/usr/lib/liveconfig/lua/apache.lua:1695: in function 'writeVHostDocRoot'
/usr/lib/liveconfig/lua/apache.lua:2390: in function 'buildConfig'
/usr/lib/liveconfig/lua/apache.lua:2679: in function 'configureVHost'
/usr/lib/liveconfig/lua/web.lua:946: in function </usr/lib/liveconfig/lua/web.lua:919>
Es wird liveconfig 2.6.3-r5013 auf Debian Stretch verwendet
Er kann nichts löschen, erstellen, verschieben. Aber bestehende Elemente modifizieren / Berechtigungen ändern, wo er der owner ist:
sp118@sp-lc1:~/conf$ ls -ld
drwxr-x--- 6 www-data sp118 4096 Jun 21 14:35 .
sp118@sp-lc1:~/conf$ ls -l
insgesamt 16
dr-xr-xr-x 2 sp118 sp118 4096 Jun 21 14:35 php56
dr-xr-xr-x 2 sp118 sp118 4096 Jun 21 14:35 php7
dr-xr-xr-x 2 sp118 sp118 4096 Jun 21 14:35 php71
dr-xr-xr-x 2 sp118 sp118 4096 Jun 21 14:35 php72
sp118@sp-lc1:~/conf$ chmod 777 php*
sp118@sp-lc1:~/conf$ ls -l
insgesamt 16
drwxrwxrwx 2 sp118 sp118 4096 Jun 21 14:35 php56
drwxrwxrwx 2 sp118 sp118 4096 Jun 21 14:35 php7
drwxrwxrwx 2 sp118 sp118 4096 Jun 21 14:35 php71
drwxrwxrwx 2 sp118 sp118 4096 Jun 21 14:35 php72
sp118@sp-lc1:~/conf$ chmod 777 .
chmod: Beim Setzen der Zugriffsrechte für '.': Die Operation ist nicht erlaubt
sp118@sp-lc1:~/conf$Hi,
root:root für /var/www/<vertrag> ist korrekt. Die Berechtigungen für priv und tmp sind durch den Benutzer ja änderbar, da er Owner vom Ordner ist => sehe ich kein Problem drin. Beim conf Ordner sieht es anders aus:
root@sp-lc1:/var/www/sp114# lsattr conf
--------------e---- conf/php72
--------------e---- conf/php56
--------------e---- conf/php71
--------------e---- conf/php7
root@sp-lc1:/var/www/sp114# lsattr conf/*
----i---------e---- conf/php56/php.ini
----i---------e---- conf/php7/php.ini
----i---------e---- conf/php71/php.ini
----i---------e---- conf/php72/php.ini
Hier sind nur die Dateien, nicht jedoch die Ordner mit +i gesetzt. Dadurch kann der Benutzer auch die ganzen Ordnerberechtigungen setzen.
Guten Tag,
wir hatten jetzt schon öfters den Fall, dass einige "Spezialisten" seltsame Anleitungen befolgen, wo die nach dem FTP Upload alle Berechtigungen auf 777 setzen sollen. Ist an sich ja schon einmal quatsch und wird dann ja auch durch suexec geblockt.
Was jedoch unschöner ist, dass der Kunde bei LiveConfig Webhostings ebenso die Berechtigungen für /priv /tmp und /conf ändern kann. Gerade im /conf Ordner meinte dann mancher Kunde schon, herumfrickeln zu müssen..
suexec blockt dann die Aufrufe von PHP generell natürlich und man muss das händisch etwas "aufwandreicher" reparieren.
Könnt ihr bei den Installationen dort nicht die immutable Flags setzen zB?
Guten Tag,
seit der Verwendung von LiveConfig von uns steht bald das erste Serverupgrade an. Debian 7 (Wheezy) auf 8 (Jessie). Standardmäßig nutzen wir mit FCGI immer die Debian PHP Pakete, hier also 5.4.x noch. Via Multi PHP steht auch 5.6 und 7.0 dort zur Verfügung.
Nun zur Frage:
Wenn ich das Debian Upgrade, wird das von Debian bereitgestellte PHP ja von 5.4 auf 5.6 angehoben:
* 5.6 existiert ja schon als Multi PHP, muss das runter oder kann man dann zwischen 5.6 Debian und 5.6 aus /opt wählen?
* Nutzen alle, die 5.4 (Standard) eingestellt haben dann automatisch 5.6?
* * Nutzen die vor allem auch dann 5.6 (wenn vorher 5.4), wenn ich via Multi PHP in /opt beim Upgrade ein 5.4 mit installiere?
Reicht ein lcclient neustart dann aus, damit er evtl die Configs neu schreibt?
Leider habe ich zum Thema Server Upgrade nichts im Handbuch gefunden.
Hm mit dem Huawei Mate 10 Pro (Android 
funktioniert es auch.
Wir haben das eben mit Chrome unter Android 7 getestet und dabei kein Problem feststellen können.
Haben Sie die Anmeldung schon mal mit einem anderen Browser unter Android 8 getestet?
LiveConfig speichert während der Anmeldung lediglich ein Cookie (zur Authorisierung) - vielleicht macht das ja Probleme? Ansonsten wird nirgendwo "gezaubert" oder externer Content nachgeladen - daher wundert es mich, dass die Anmeldung nicht funktioniert...
Ich habe einmal kurz hier getestet:
Oneplus 3 Android 8 Chrome: kein Login möglich
Oneplus 3 Android 8 Firefox: funktioniert
Oneplus 3T Android 8 Chrome: kein Login möglich
Samsung Galaxy Note 4 Android 6.0.1 Chrome: funktioniert
Es macht auch keinen Unterschied, ob man im Private Mode surft oder die Seite vorher auch noch nie aufgerufen hatte / frisches Profil nimmt
Hallo,
den Fehler haben wir schon länger, zB bei mir auf einem OnePlus Handy mit Android 8 und dem aktuellen Chrome. Wenn ich mich im Liveconfig einloggen möchte, dann prüft er den Login und ich bleibe auf der Loginseite. Wenn ich mich dann wieder einlogge, werde ich zwar gefragt, ob ich mich noch einmal einloggen will (selbe IP), aber auch danach komme ich nicht in das Interface hinein.
Hallo,
ist es geplant für den Apache und Nginx in absehbarer Zeit auch HTTP v2 konfigurieren zu lassen?
