Beiträge von kk

Einfach die Checkbox bei "Webspace aktivieren" wegklicken, dann werden keine A-Records für den Webspace angelegt.
Wir werden beim nächsten Update noch ein Beispiel dafür einbauen.

Zitat von Mogwais

Na wenn sie in der DB landen kannst du sie ja da abgraben und sie an Powerdns Server verteilen, zumindest werde ich das so erstmal machen

Um mal keine falschen Hoffnungen zu wecken: so wie LiveConfig die DNS-Daten intern verwaltet, werden Sie diese nicht ohne weiteres auslesen und daraus Zonen-Daten für PowerDNS erzeugen können. Das hat damit zu tun, dass wir alle Daten streng normalisiert verwalten - die notwenigen JOIN-Operationen sind für Außenstehende äußerst komplex. (alleine für die Generierung eines A-Records bei Webspace kommen 4-5 Tabellen zum Einsatz)

Zitat

Zb: Ich habe einen Teamspeak Server, der soll über teamspeak.domain.de erreichbar sein.
Somit muss ich genau dort einen A Record hinterlegen. Muss ich nun extra eine "SubDomain" anlegen damit ich das einstellen kann ?

Exakt. Bei "teamspeak.domain.de" handelt es sich ja schließlich auch um eine Subdomain (um was auch sonst?)

Für sekundäre DNS braucht man dann eine LC-Lizenz, wenn sich LiveConfig darum kümmern soll/muss das die sekundären Zonen dort auch automatisch angelegt werden.
Bei BIND wäre das also nicht verkehrt - es wird aber auch eine SOAP-Funktion geben, mit der man die Liste der Secondary-Zonen abrufen kann. Der eigentliche Zonentransfer erfolgt via AXFR.

Zitat von Mogwais

wird ja eh in der Datenbank gespeichert oder schreibt ihr das direkt als Zonefiles weg?

Weder noch. Natürlich landen die Basisdaten in der LiveConfig-internen Datenbank - prinzipiell wird aber mit dem Anlegen einer Domain (quasi einmalig) ein Zonefile erzeugt, und alle weiteren Änderungen über dynamische Updates (nsupdate) direkt an den Nameserver gesendet.
Bei jeder DNS-Anfrage eine MySQL-Abfrage zu machen halte ich für ziemlich ineffizient. In den letzten Jahren hat sich PowerDNS bzgl der Performance aber scheinbar etwas weiterentwickelt.

Zitat von arnoldB

Bugfixing:
Ich würde z.B. gerne eine andere Standard PHP-Version statt die lange nicht mehr von PHP unterstützte Version 5.3 definieren. Soll wohl nicht passieren.

http://www.liveconfig.com/de/forum/threads/1560-PHP-Schwerwiegende-Bugs-innerhalb-von-Configs-in-speziellen-Fällen?p=8655&viewfull=1#post8655

Das ist kein Bug, sondern ein Feature Request. Und der ist nicht gaaanz so trivial, wie das auf den ersten Blick erscheinen mag.
Nehmen wir mal an, Sie setzen über die custom.lua/addPHP() nun PHP 5.4 als "Standard". Dann müssen bei allen Webspaces, welche bei der PHP-Version "Standard" ausgewählt haben, die php.ini-Dateien neu erzeugt werden (da PHP 5.4 ja z.B. nichts mehr mit safe_mode anfangen kann), zudem müssen die FastCGI-Starter (und später die FPM-Configs) auf das neue PHP-Binary aktualisiert und zuletzt alle entsprechenden Prozesse neu gestartet werden.

Etwas anderes wäre es, wenn man die Dropdown-Box zur PHP-Auswahl bei neuen Subdomain dann einfach auf z.B. PHP 5.4 voreinstellt.

Also: keine Angst, wir machen uns Gedanken dazu.

Nein, bislang wird nur BIND unterstützt. PowerDNS können wir dann aber gerne als nächstes mit aufnehmen.

Die Demo (https://demo18.liveconfig.com:8443 Login: admin/demo18) wurde eben wieder aktualisiert. Unter "Webhosting" -> "Domains" -> Subdomain bearbeiten sieht man nun auch die DNS-Verwaltung.
Außerdem gibt es in Angeboten/Verträgen nun die Eigenschaft "Darf DNS-Einstellungen bearbeiten".

Nächste Woche wird es die v1.8 dann als Preview-Version zum Download geben.

Viele Grüße

-Klaus Keppler

Hallo,

was da geschehen ist war kein Logrotate, sondern ein Server-Neustart (ein Kill-Signal 15 vom init-Prozess deutet zumindest stark darauf hin Außerdem gibt es eine Zeitlücke von über 1,5 Minuten zwischen den Service-Stopps und -Starts.

Das hat die Fehlerquelle dann auch eingegrenzt: unter Ubuntu 12 konnte LiveConfig das init-Script für lcsam nicht korrekt installieren. Mit folgendem Befehl kann das nachgeholt werden:

update-rc.d lcsam defaults

Mit dem nächsten Update (v1.8) holt LiveConfig das ggf. selbst nach.

Viele Grüße

-Klaus Keppler

Nein, wurde nicht vergessen sondern mit r3132 in den Entwicklerzweig (v1.8.0) aufgenommen. In dem kürzlich freigegebenen 1.7.5-Update wurde das nicht "backported". Ist also im kommenden "richtigen" Update mit dabei. Die Preview erscheint kommende Woche.

Viele Grüße

-Klaus Keppler

Noch mal: Inhalte, die nur per HTTP erreichbar sind, sollten am besten immer nur auf einer IP betrieben werden die nicht mit SSL genutzt wird. Das war schon immer so und wird auch immer so bleiben.

Unabhängig davon: bearbeiten Sie bitte im LiveConfig einfach irgend eine IP-Gruppe (z.B. irgendwas am Namen einer IP-Gruppe ändern - das reicht schon). Danach erzeugt LiveConfig automatisch auch die Default-vHosts neu und sollte diesen ein eigenes Standard-SNI-Zertifikat zuweisen.

Viele Grüße

-Klaus Keppler

Ab sofort steht mit Version 1.7.5-r3221 ein kleines LiveConfig-Update bereit. Es werden darin nur zwei Detailfehler behoben (ProFTPd-SSL-Konfiguration und Problem mit LCCP bei zu großen Nachrichten). Zudem steht nun auch ein Application-Installer für Magento (inkl. der FireGento-Erweiterung "Mage Setup") zur Verfügung.

Die Arbeiten an der "nächsten großen Version" (v1.8) gehen gut voran, Anfang kommender Woche soll es die erste Preview-Version geben.

Viele Grüße

-Klaus Keppler

Die Version v1.7.5-r3221 wurde nun unverändert als "Stable" freigegeben. Der "showstopper" war ein Problem im Application Installer, das aber letztendlich im betroffenen Installationsscript lag. Mit v1.7.5-r3221 steht nun nämlich auch Magento (inkl. der FireGento-Erweiterung "Mage Setup") im AppInstaller bereit.

Die Demo zur v1.8 (siehe anderer Thread) wurde in den letzten Tagen unabhängig davon auch immer wieder mal aktualisiert. Voraussichtlich (!) nächste Woche steht diese dann als erste Preview bereit.

Zitat von aziegler

Wird dem Nutzer anhand des UserAgent dann direkt eine entsprechende Meldung angezeigt und der Login verweigert oder kommt es zu einer Vielzahl von Problemen?

Nein, wir treffen keine Entscheidungen anhand des UserAgents. Zum einen ist dieser Header nicht unbedingt zuverlässig, zum anderen haben wir keinen Einfluss darauf was ein Browser kann oder nicht kann. Wer tatsächlich noch mit dem IE6 oder 7 unterwegs ist, hat ohnehin ganz andere Probleme. Und auf Windows XP ist ja IE8 schon lange verfügbar.

Wir haben eben einen kleinen vServer mit unserer aktuellen Entwicklungsversion von v1.8 aufgesetzt:

https://demo18.liveconfig.com:8443
Login: "admin"
Passwort: "demo18"

WICHTIG: sehr viele Anzeige- und Eingabemasken sind noch nicht überarbeitet bzw. wurde deren CSS noch nicht angepasst. Es gibt in der GUI also noch viele Bereiche, die komisch/defekt aussehen bzw. nicht funktionieren. Also bitte nicht wundern, und bitte vorerst noch keine Fehlerberichte melden.

Die komplette HTML-Erzeugung wird ja überarbeitet, was bis zu 40% weniger HTML-Code erzeugt und die Seiten i.d.R. fast doppelt so schnell laden lässt. Zudem wird die komplette Ausgabe nur per CSS gesteuert, welches dann auch durch eigene Designs ersetzt werden kann. Alle Eingabemasken nutzen die neuen HTML5-Features zur Formularprüfung - fehlende Eingaben werden so schneller und besser am Bildschirm markiert.
Wer möchte, kann auch gerne einen Blick auf die neue Passwort-Eingabe werfen (z.B. Einstellungen -> Passwort ändern). Der Schwellwert (ab wann LC ein Passwort akzeptiert) ist frei konfigurierbar.

Die GUI-Umstellung kommt derzeit ganz gut voran - sobald dieser Punkt abgeschlossen ist, werde ich hier noch mal Bescheid geben - dann können wir die Preview auch zum Download bereitstellen.

Viele Grüße

-Klaus Keppler

PS: ach ja, mit IE6/7 ist LiveConfig nun leider nicht mehr verwendbar. Minimum ist nun IE8 (mit dem testen wir das zumindest als "Minimal-Standard" durch).

Hallo,

wir haben eben noch mal ein Update der 1.7.5er-Serie (r3221) als Preview bereitgestellt. Darin werden zwei Fehler beseitigt und zwei Detailsverbesserungen vorgenommen, welche ein paar Kunden betreffen.
Wir führen morgen früh noch ein paar Tests durch, danach wird die Version dann als "stable" freigegeben.

Zum Entwicklungsstand der v1.8 gibt es noch separate Informationen (deren Changelog ist auch deutlich länger

Hallo,

biete spielen Sie die aktuelle Preview-Version ein (v1.7.5-r3221) - damit sollte das Problem behoben sein.
Offenbar haben Sie mindestens einen "sehr großen" vHost konfiguriert (soll heißen: wo die reinen Daten aus vHost-Konfiguration und ggf. SSL-Zertifikaten insgesamt >1MB groß sind). Eine eher zu Testzwecken implementierte Prüfung hat diese Nachricht dann nicht durchgelassen. Ab sofort können die einzelnen Konfigurationen nahezu unbegrenzt groß werden.

Viele Grüße

-Klaus Keppler

Wer gestern Abend das neueste PHP5-Paket von Debian Wheezy (5.4.35-0+deb7u1) eingespielt hat, erhält seitdem alle 30 Minuten eine Cron-Fehlermeldung:

Zitat

Cron <root@www> [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)

sed: invalid option -- 'z'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

Dabei handelt es sich um einen Fehler im Debian-Paket (siehe Debian-Bug #770105).

Ein vorläufiger Workaround ist, in der Datei /usr/lib/php5/sessionclean die erste Befehlszeile (beginnt mit "[ -x /usr/bin/lsof ] ...]") auszukommentieren.

Ein Update ist wohl schon in Arbeit, dabei werden aber die Patches einer anderen Sicherheitslücken angeblich wieder entfernt...

Viele Grüße

-Klaus Keppler

Die PHP-Pakete für Debian Linux (siehe KB#22) wurden eben auf die aktuellen Versionen 5.4.35, 5.5.19 und 5.6.3 aktualisiert.

Viele Grüße

-Klaus Keppler

Hallo,

aufgrund eines Umzugs auf neuere Hardware waren die LiveConfig-Websites eben für knapp 30 Minuten nicht erreichbar. Das war so natürlich nicht geplant: da alles virtualisiert läuft, sollte eigentlich nur ein Container umziehen. Der Teufel steckte dann im Detail: auf dem neuen System lief ein geringfügig anderer Kernel, mit diesem lief "fam" (file alternation monitor) nicht mehr, damit kam der Webserver nicht mehr korrekt hoch

Wir werden Serverarbeiten künftig hier ankündigen, auch wenn diese als "trivial" eingestuft sind.

Ironie des Schicksals: genau diese Arbeiten dienten übrigens der Vorbereitung für zusätzliche Redundanz (via Round-Robin-DNS)...

Zitat von solidius

Code

Nov 12 23:28:15 system01 lcsam[17737]: 5.83.128.154: lcsam_helo('node-fra')
Nov 12 23:28:15 system01 lcsam[17737]: 5.83.128.154: lcsam_envfrom('monitoring@isp-serverfarm.de')
Nov 12 23:28:15 system01 lcsam[17737]: 5.83.128.154: lcsam_abort()
Nov 12 23:28:15 system01 lcsam[17737]: : lcsam_close()
Nov 12 23:31:35 system01 postfix/smtpd[4579]: warning: connect to Milter service unix:/var/run/lcsam.sock: No such file or directory

Prüfen Sie bitte mal im mail.log bzw. syslog, was zwischen 23:28:15 und 23:31:35 eventuell so alles passiert ist.

Zitat

Der Dienst war nach dem letzten Auswahl und Neustart am 12.11. um 22:22, nach nur etwas mehr als 24 Stunden wieder ausgestiegen.

Das Blöde an der Sache ist, dass der Milter-Prozess komplett durch das Milter-Framework gesteuert wird - man registriert quasi nur die eigenen Handler-Funktionen. Wenn sich das bei Ihnen aber so schnell reproduzieren lässt, bauen wir mal weitere Debug-Informationen ein, die vielleicht einen Hinweis darauf liefern könnten wo genau Milter da aussteigt.