Beiträge von kk

Gibt's schon ("undocumented feature" ;-))
Wenn eine Datei namens ~/conf/nginx.conf existiert, dann wird diese per include mit aufgenommen. WICHTIG ist aber: diese wird in jeden server-Abschnitt (quasi jeden VirtualHost) übernommen - ggf muss man die Einstellungen darin also mit entsprechenden Bedingungen ausstatten.

Dieses Feature ist deshalb undokumentiert, weil die Möglichkeit für eigene Rewrite-Regeln mittelfristig über die GUI gelöst werden soll. Wir möchten das dann so lösen, dass die Regeln in einer "allgemeinen" Syntax erfasst werden und LiveConfig diese dann jeweils für NGINX bzw. für Apache rausschreibt.

Zitat von bfal

Wenn ich einen Passwortschutz für einen Ordner einrichte wird dieser in der Apache Konfiguration eingetragen aber die .htpasswd Datei nicht angelegt.

Welche Distribution verwenden Sie?

Zitat

Weiter klappt bei mir die Funktion "Log Anzeigen" nicht. Es dreht sich nur dieser "Lade-Kreis" aber es wird nichts angezeigt.

Es werden nur neue Einträge im Log angezeigt. Theoretisch müssten Sie also z.B. auf's access.log umschalten können, dann die Website in einem anderen Browser-Tab mal öffnen -> die Zugriffe sollten dann im Log-Viewer auftauchen.

Noch mal: wir reden hier was Joomla betrifft von gerade mal 14 Tagen, das Typo3-Update ist noch keine Woche verfügbar.
Sofortige Updates sind häufig auch problematisch (siehe z.B. Joomla 2.5.10 oder ownCloud 5.0.1/5.0.2).

Bislang weiß ich nur von der Dovecot-Konfiguration und php.ini-Dateien (beim Upgrade auf PHP 5.4 müssen einige Einträge aus den php.inis entfernt werden - darum kann sich ja aber nun die neueste LiveConfig-Version kümmern)

Die Info-Seite soll am Freitag online gehen (in der Wissensdatenbank)

Viele Grüße & einen schönen Feiertag

Debian 7 wird bereits seit... äh... keine Ahnung... ich glaube seit Mitte 2012 unterstützt (müsste ich nun erst mal genauer nachschauen). Eine Neuinstallation auf Wheezy stellt also kein Problem dar, lediglich beim Upgrade von Debian 6 müsste man 2-3 Dinge beachten (wir erstellen derzeit eine Info-Seite dafür). Da z.B. Dovecot von 1.x auf 2.x aktualisiert wird, müssen die Konfigurationsdateien entsprechend neu erzeugt werden.

Viele Grüße

-Klaus Keppler

Nehmen Sie's mir nicht übel, aber auf solche unverschämten Beiträge werde ich künftig schlicht nicht mehr antworten. Mir ist nicht ganz klar was Sie damit bezwecken wollen, aber offenbar wissen Sie ja ohnehin alles besser.
Und Tschüß...

Zitat von Sebbel2

[2013/05/05 20:47:55.797155] [8697|8701] LC.web.vhostConfig() failed: /usr/lib/liveconfig/lua/apache.lua:1401: attempt to index global 'pfh' (a nil value)

Danke, das war der richtige Hinweis
Es gab hier im Rahmen der neuen php.ini-Verwaltung einen Fehler, wenn man mod_php verwendet (ich hoffe, Sie teilen Ihren Server mit keinem anderen Benutzer?)

Update mit Bugfix wurde eben bereitgestellt (v1.6.2-r2325) - bitte spielen Sie das ein, entfernen dann die v6-IP aus der default-Gruppe und fügen diese dann schließlich wieder hinzu. Danach sollte alles (wieder) klappen.

Joomla 2.5.10 kam am 24.04.2013 heraus, an dem Tag haben wir kurz vorher 7 andere Apps aktualisiert. v2.5.11 kam am 26.04. heraus, nachdem 2.5.10 einige Fehler enthielt.

Ich kann Sie also beruhigen - wir haben das auf dem Radar und pflegen neue Versionen auch möglichst zeitnah ein - das kann dennoch mal 2-3 Wochen dauern bis der Installer aktualisiert ist und wir das getestet haben.

Für XTC gibt es kein Update mehr, die haben sich ja inzwischen in "Modified Shop" umbenannt. Der neue Installer ist bereits fertig, ein Kollege muss den nur noch durchtesten. Werden wir voraussichtlich auch am Freitag mit freigeben.

Mogwais: vielen Dank für den Troll-Beitrag.

In der vHost-Konfiguration (/etc/apache2/sites-available/###.conf) steht bei jedem vHost gleich zu Beginn der Name der verwendeten IP-Gruppe sowie die Liste der konfigurierten IP-Adressen, etwa so:

# IP group: 'default'
<VirtualHost 62.146.188.37:80 [2a01:138:a005::2:4]:80>
    ServerName xn--hxajbheg2az3al.xn--jxalpdlp
    ServerAlias www.xn--hxajbheg2az3al.xn--jxalpdlp
    ServerAlias xn--mgbh0fb.xn--kgbechtv
    ServerAlias www.xn--p1b6ci4b4b3a.xn--11b5bs3a9aj6g
    ServerAlias www.mustermann.test
    ServerAlias www.xn--mgbh0fb.xn--kgbechtv
    ServerAlias xn--p1b6ci4b4b3a.xn--11b5bs3a9aj6g
[...]

Ohne weitere Infos (s.o.) kann ich wirklich nicht weiter helfen.

Die Preview wurde eben noch mal aktualisiert (v1.6.2-r2324).

Darin gab es nun noch eine Menge Fehlerbeseitigungen und Verbesserungen aus dem Feedback der letzten Tage, unter anderem:
- Unterstützung von Wildcard-Subdomains
- Erkennung der PHP-Version (wird nun also bei der Erstellung der php.ini-Dateien berücksichtigt)
- offizielle Unterstützung von OpenSUSE 12.2 und Ubuntu 13.04

Wir erstellen derzeit noch Tests für die letzten Features dieser Version (Vertrag verschieben, Erweiterungen SOAP-API); wenn alles klappt wird diese dann noch am Freitag (10.05.) freigegeben.

Viele Grüße & einen schönen Feiertag!

-Klaus Keppler

Mit diesr Fehlermeldung alleine können auch wir leider nichts anfangen.
- LiveConfig-Version?
- Distribution?

Mit dem Befehl "apache2ctl -S -t" sollten Sie eine Liste aller IPs und den jeweils konfigurierten Domains bekommen.
Bitte senden Sie uns diese Liste sowie die Konfigurationsdatei des entsprechenden vHosts (/etc/apache2/sites-available/###.conf) an support@liveconfig.com, dann schauen wir das gerne mal im Detail an.

Viele Grüße

-Klaus Keppler

Good point, we just changed this (r2319, available this afternoon as preview).
From now on, when the user configures his AWStats settings (Webspace -> Web statistics settings) the language from the logged-in user is saved to be also used for generating the stats.

So your existing users only need to save their web statistics settings again (even without changing anything). On the next AWStats run, the results should be localized (DE/EN/NL).

Best regards

-Klaus

Ja, sollte klappen (ist bereits in Arbeit - es gibt aber noch einige Abhängigkeiten zu prüfen, u.a. dass man z.B. keine E-Mail-Adressen auf Wildcard-Subdomains einrichten kann (blabla@*.example.org))

Viele Grüße

-Klaus Keppler

Zitat von r00xster

Ich kann in der Benutzerverwaltung bei keinem Benutzer die PHP.ini-Verwaltung aktivieren. Sie ist lediglich über den von LiveConfig bei der Installation erstellten admin-Nutzer einsehbar, wobei auch bei diesem Nutzer kein Häkchen in der Berechtigungsliste sichtbar ist.

Das ist äußerst merkwürdig - wir haben das eben auf verschiedensten Installationen überprüft, der "admin"-Benutzer hat immer diese Berechtigung. Haben Sie LiveConfig "frisch" installiert oder ein Upgrade durchgeführt? Haben Sie irgendwelche Änderungen in der Datenbank vorgenommen, oder eventuell den "admin"-Benutzer mal gelöscht und neu angelegt?

Zitat von solidius

kann mit dem Chrome und dem IE den Passwortschutz nicht mehr löschen.

Wurde eben korrigiert, Update kommt heute Abend.

Zitat

Und bei mir geht die Fehlerprotokoll Funktion leider noch immer nicht einwandfrei. Beim schließen des Logfenster und beim Wechseln des Logs bekomme ich die Fehlermeldung "Error: abort" was auch jeweils mit dem Chrome und dem IE 9 getestet wurde.

Sollte mit dem Update dann auch beseitigt sein (IE/Chrome werfen unter bestimmten Umständen offenbar eine Exception, wenn eine Ajax-Abfrage abgebrochen wird - die Fehlerbehandlung in LiveConfig gibt diese dann am Bildschirm aus...)

Viele Grüße

-Klaus Keppler

Zitat von solidius

ist es nicht möglich für ein Passwortschutz einen 2. Benutzer zu berechtigen ? Oder habe ich diese Funktion einfach übersehen ?

Einfach auf den neu angelegten Passwortschutz-Eintrag klicken => Popup öffnet sich => dort weiteren Benutzer hinzufügen (entweder neuen Benutzer anlegen oder - falls vorhanden - einen bestehenden anderen Benutzer auswählen)

Die Preview wurde eben noch mal aktualisiert:
- Löschen von php.ini-Einstellungen klappt nun auch mit Chrome & Opera
- htpasswd-Verwaltung erscheint nun (ist im Menü unter "Webspace")
- Fehler bei Berechtigungen für externen MySQL-Zugriff beseitigt

Voraussichtlich morgen Abend kommt noch ein Update:
- Erkennung der php-Version und entsprechende Berücksichtigung bei der Erzeugung der php.ini-Dateien
- Verbesserungen und Erweiterungen der SOAP-API

Viele Grüße

-Klaus Keppler

Es handelt sich hier um kein Problem, dieses Verhalten ist beabsichtigt.
Auf die von LiveConfig konfigurierte Art wird ein 404-Fehler "erzwungen", wenn ein Besucher eine ungültige/unbekannte Domain aufruft. Mit dem o.g. Rewrite-Workaround auf die "/not-available.shtml" erhält der Besucher zwar die selbe Anzeige, aber mit einem HTTP-Status 200 statt 404.
Unserer Ansicht nach ist ein 404 der "richtigere" Statuscode, da ja letztendlich der angeforderte Inhalt nicht gefunden werden konnte. Das kann vor allem dann wichtig sein, wenn man z.B. die IP-Adressen einer Domain bereits auf einen LiveConfig-Server umgestellt hat, die Domain in LiveConfig aber noch nicht eingerichtet wurde. Wenn Suchmaschinen in diesem Fall die "Nicht verfügbar"-Website mit einem 200er Statuscode bekommen, wird diese Seite ganz normal in den Suchindex aufgenommen.

Fazit: der 404 erzeugt zwar eine Warnmeldung im error.log, ist aber völlig harmlos und (unserer Ansicht nach) sinnvoll. Sollte es dringende Gründe gegen dieses Verhalten geben, würde ich mich über eine entsprechende Diskussion freuen.

Viele Grüße

-Klaus Keppler

Zitat von loswebos.de

Korrekt: Chrome

Danke für die Rückmeldung - Problem wurde lokalisiert und beseitigt (Opera&Chrome kamen mit einem Funktionsnamen ("del()") nicht zurecht).

Zitat von tniebergall

Ich habe einen Vetrag in dem der externe Zugriff auf Datenbanken nicht erlaubt ist. Unter dem Kunden hat man allerdings trotzdem die Möglichkeit den Zugriff zu erlauben.

Danke für den Hinweis, hier gab es auch noch einen Fehler in der Bildschirmmaske. Ist bereits beseitigt und somit auch beim nächsten Update dabei.