((Ich habe die Beiträge eben in ein eigenes Thema verschoben.))
Ich vermute, dass Sie keine IP-Adressen für externe Nameserver hinterlegt oder gar keine externen Nameserver konfiguriert haben.
Siehe Handbuch: http://www.liveconfig.com/de/handbuch/tutorial.dns.html
Hier sind alle aktiven Einstellungen der vsftpd.conf:
# grep '^[^#]\+$' vsftpd.conf
listen=YES
ftpd_banner=FTP Server
local_enable=YES
write_enable=YES
local_umask=022
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
pam_service_name=vsftpd-lc
anonymous_enable=NO
guest_enable=YES
virtual_use_local_privs=YES
user_config_dir=/etc/vsftpd/users
max_clients=100
max_per_ip=5Die benutzerspezifische Konfiguration (hier: für "web1") sieht so aus:
# cat /etc/vsftpd/users/web1
# Created by LiveConfig - DO NOT MODIFY
local_root=/var/www/web1
guest_username=web1Ich habe eben versucht das von Ihnen beschriebene Verhalten zu reproduzieren (CentOS 6.4) - hier funktioniert alles. Die hochgeladene Datei (egal ob mit dem Haupt-FTP-Account oder einem zusätzlichem FTP-Benutzer) gehört dem richtigen Benutzer & Gruppe. (hier: web1:web1)
Kann es sein, dass Sie im übergeordneten Verzeichnis (htdocs), welches der Gruppe "apache" gehört, das Sticky-Bit für die Gruppe gesetzt haben?
# ls -l /var/www/web1/
[...]
drwxr-x--- 3 web1 apache 4096 Nov 29 16:11 htdocsHallo,
es wurde eben ein kleines Update freigegeben (v1.7.0-r2692), welches einen Fehler beim Speichern der php.ini-Einstellungen in Kundenverträgen beseitigt.
Viele Grüße
-Klaus Keppler
du hast beim Backup .zip gewählt.
Du musst zip auf deinen Server installieren via apt-get install zip
Jepp, wir werden das "zip"-Paket daher auch ins nächste Update vom Meta-Paket (liveconfig-meta) mit aufnehmen.
[2013/11/28 22:55:10.224718] [32166|32169] Requesting installer file 'wai-roundcube-0.9.5-1.php.gz'...
[2013/11/28 22:55:10.232709] [32166|32169] => Error: Server status returned '404'
Danke für den Hinweis, hier gab es offenbar einen Fehler beim Synchronisieren des App-Repositories auf unserer Seite. Der Roundcube-Installer steht nun jedenfalls (wieder) bereit.
Wenn sich ein LiveConfig-Client mit einem LiveConfig-Server (Business) verbindet, dann hat das mit "unseren Servern" (repo.liveconfig.com usw.) nicht das geringste zu tun, da sich der LC-Client direkt mit dem LC-Server verbindet.
So wie es aussieht gab/gibt es auf dem betroffenen Server insgesamt Probleme mit dem DNS-Resolving. Ob die Google-Nameserver die beste Wahl sind, möchte ich mal bezweifeln (viele RZ bieten anständige, lokale Resolver kostenlos mit an).
Das gesamte LiveConfig-Team freut sich, die Verfügbarkeit von LiveConfig v1.7.0 bekannt geben zu dürfen. Die neue Version steht ab sofort auf der Download-Seite sowie in den Repositories bereit.
Die wichtigsten Neuerungen in Version 1.7.0 sind:
Die vollständige Liste aller Änderungen finden Sie im Änderungsverlauf.
Das Update ist wie gewohnt unkompliziert. Bitte beachten Sie jedoch, dass während des Updates falsch berechnete RRD-Daten gelöscht werden. Das kann einige Sekunden dauern und führt dazu, dass in den Übersichten zum Traffic/Zugriffszahlen von Webspaces alle Werte älter als ca. 24 Stunden gelöscht werden.
Das nächste Update (v1.7.1) wird wieder in einem deutlich kürzeren Abstand verfügbar sein (noch vor Weihnachten :))
Höchstwahrscheinlich liegt das am Trash-Folder.
Am einfachsten wäre es wohl, wenn Sie auf Version 1.7.0 aktualisieren - da werden beim LiveConfig-Start nun praktisch alle hängen gebliebenen Jobs (u.a. auch das Löschen von Postfächern) automatisch abgearbeitet. Die neue v1.7 steht aktuell noch im Preview-Bereich, wird aber morgen für den Produktivbetrieb freigegeben.
Viele Grüße
-Klaus Keppler
Hallo,
eben wurde die Preview auf Version 1.7.0-r2685 aktualisiert. Mit diesem Update wurde die DNS-Verwaltung auch auf OpenSUSE und CentOS (inkl. SELinux) erfolgreich durchgetestet, sowie einige Konfigurationsprobleme auf Gentoo beseitigt.
Wir rollen diese Version nun schrittweise auf unseren eigenen Servern produktiv aus; sofern keine Probleme auftreten wird diese dann morgen (27.11.) produktiv freigegeben.
Parallel dazu wird an den nächsten Features gearbeitet (u.a. bessere Mail-Konfiguration, E-Mail-Rundschreiben, mehrere PHP-Versionen), die dann auch in deutlich kürzeren Abständen freigeben werden.
Viele Grüße
-Klaus Keppler
Hallo, kurz eine Frage wurde das Ticket #86 PHP Version Wechsel mit integrieret? Wir können es in der Preview leider nicht sehen.
Wenn das Ticket noch offen ist, dann ist es noch offen. Der PHP-Switch wird für 1.7.0 leider nicht mehr ganz fertig. Bis dahin kann man nach wie vor nur manuell über .htaccess zwischen verschiedenen PHP-Versionen wählen, indem man serverseitig verschiedene PHP-Handler in Apache konfiguriert.
Ihnen ist schon klar, dass bei FastCGI die PHP-Prozesse selbstverständlich weiter laufen?
Siehe mod_php, suPHP und FastCGI
Hallo,
die Preview wurde nun noch mal aktualisiert (v1.7.0-r2675). Die Builds sind nun wieder für alle Plattformen verfügbar - allerdings wurde die DNS-Verwaltung für .rpm-Systeme noch nicht angepasst! (hierfür gibt es morgen noch ein Update, da wir noch nicht alle Änderungen in den Test-Zweig zusammenführen konnten).
Auf Debian-Systemen sollte nun aber soweit alles "fertig" sein - insbesondere also auch die DNS-Verwaltung. Alle Standardfälle konnten wir fehlerfrei durchtesten (Anlegen einer Zone auf eigenen DNS-Servern; Anlegen, Bearbeiten und Löschen von Subdomains; Löschen von Domains). Alle DNS-Änderungen werden mittels dynamischer Updates sofort auf dem Master-Server ausgeführt, es gibt also keine Wartezeiten (außer 10-60 Sekunden nach dem Anlegen einer neuen Zone).
Zudem ist nun auch die php.ini-Verwaltung für Endkunden mit enthalten (Hosting -> Webspace).
Bitte beachten Sie beim Update, dass historische RRD-Daten (Älter als ca. 7 Tage) während des Updates zurückgesetzt werden, da es einen Berechnungsfehler beim Aufaggregieren der Daten gab (diese wurden mehrfach gezählt, was zu auffällig hohen Werten führte).
Heute und morgen werden lediglich noch die DNS-Sachen auf CentOS, OpenSUSE und Gentoo getestet und angepasst, danach steht dem Release nichts mehr im Wege.
Viele Grüße
-Klaus Keppler
Dass RC4 in Echtzeit decodiert werden kann ist derzeit reine Spekulation (wobei dies durchaus im Bereich des Möglich liegt). Wer so etwas machen möchte, benötigt aber einen erheblichen Aufwand - mehr als beispielsweise bei einem BEAST-Angriff.
Daher noch mal: wenn Sie alle (theoretisch) knackbaren Algorithmen deaktivieren (DES, 3DES, AES, RC4), dann bleibt für die meisten Besucher gar kein Verschlüsselungsalgoithmus mehr übrig.
Wenn Sie die Chiffres dennoch manuell einschränken möchten, modifizieren Sie einfach die entsprechenden Vorgaben in /usr/lib/liveconfig/lua/apache.lua.
Die von uns voreingestellten Werte bieten den besten Kompromiss aus Sicherheit und Kompatibilität. Gerade bei Online-Shops geht es mehr darum, nicht versehentlich 5 von 1000 Kunden aufgrund inkompatibler Chiffres zu verlieren als theoretisch von der NSA abgeschnüffelt zu werden.
Sehr geehrter Herr Linde,
welcher Algorithmus letztendlich zwischen Browser und Server verwendet wird, hängt davon ab, auf welchen "kleinsten gemeinsamen Nenner" sich Server und Client einigen können. Standardmäßig versuchen beide Seiten selbstverständlich die bestmögliche Verschlüsselung zu verwenden (und da zählt RC4 sicher nicht dazu). Nur bei Endgeräten, die sonst nichts Anderes (z.B. AES) unterstützen, findet ein Fallback auf RC4 statt.
Wenn Sie alle Blockchiffren (DES, AES etc.) gemäß PCI ausschließen und gleichzeitig RC4 verbieten, bleiben bei SSLv3/TLS1.0 übrigens keine anderen Verschlüsselungsalgorithmen mehr übrig. 
Erst ab TLS 1.2 stehen mit Elliptic Curves ausreichend starke Alternativen zur Verfügung; diese sind z.B. erst mit OpenSSL 1.0 (also ab Debian 7.0) verwendbar.
Kurzum: lassen Sie sich durch die Medien nicht scheu machen. Es handelt sich hier definitiv nicht um ein "kritisches Problem", da ja nicht nur RC4 erlaubt ist.
Mit freundlichen Grüßen
-Klaus Keppler
Confixx lässt dann zumindest nicht mehr zu das neue Dateien (Webspeicher) hochgeladen bzw. erstellt werden können
Dann können die Datenbanken ja aber trotzdem noch wachsen, oder? Was ist dann der Unterschied zu LiveConfig, außer, dass der Webspace "früher" voll ist?
Wie gesagt: es ist nicht ganz trivial, ein Datenbank-Quota zu realisieren, weil das rein technisch eben nicht über ein Filesystem-Quota erledigt werden kann. LiveConfig zeigt die Datenbankgrößen an, kann diese aber nicht begrenzen.
Wir haben bereits eine Lösung hierfür (vereinfacht gesagt wird beim Erreichen einer festzulegenden Datenbank-Größe das Recht für INSERT vorübergehend entfernt). Noch ist das aber nicht umgesetzt.
ZitatDie Version 1.7.0 ist für openSUSE leider nicht verfügbar...
Ja, darauf haben wir hingewiesen, weil wir größere Änderungen an unserer Build- und Testumgebung durchgeführt haben. Voraussichtlich ab heute Abend werden auch die restlichen Builds wieder bereitgestellt.
Viele Grüße
-Klaus Keppler
Nun, wir können auch gerne die Werte aufaddieren - die entscheidende Frage ist doch aber: was macht Confixx, wenn die Datenbank "zu groß" wird?
Zur Datenbank-Größe: es gab einen Anzeigefehler, der mit dem nächsten Update (v1.7.0) beseitigt ist (siehe https://www.liveconfig.com/dev/issues/96)
Was für eine Antwort erwarten Sie bei Ihrer Fragestellung?
Die Datenbankgröße kann schon rein technisch nicht zum Webspace dazugezählt werden, da Webspace-Quota per Filesystemquota realisiert wird. Die Datenbanken werden aber nicht auf einzelne Dateien pro Benutzer abgebildet (InnoDB) bzw. können nicht einfach dem User übereignet und per Quota limitiert werden (MyISAM) da es sonst gewaltige Inkonsitenzen beim Erreichen des Quotas gibt.
Wir werden aber ein Datenbankquota in einer der nächsten Versionen realisieren - dieses muss aber (genauso wie das Mailquota) separat definiert werden.
root@testserver:~# gpg -a --export 7AFC07EA649BE239 | sudo apt-key add -
-bash: sudo: command not found
gpg: [stdout]: write error: Broken pipe
gpg: iobuf_flush failed on close: file write error
Ähem, die Fehlermeldung ist doch recht eindeutig: "sudo" ist nicht vorhanden (was übrigens auch nicht benötigt wird, wenn Sie bereits als root angemeldet sind):
gpg -a --export 7AFC07EA649BE239 | apt-key add -