Beiträge von WebService4U

  • Fehler im Migrationsscript Confixx? - Bleibt bei Cronjobs stehen

    Guten Morgen,


    ich migriere von Confixx 3.3.9 auf die aktuelle LC-Version. Diese ist fertig eingerichtet und mit
    touch /usr/lib/liveconfig/lua/custom.lua
    echo "web.HTDOCS_PATH = 'html'" >> /usr/lib/liveconfig/lua/custom.lua
    aufgesetzt.


    Das Migrationsscript auf dem alten Server rufe ich daher wie folgt auf:
    /usr/bin/php5 cfximport.php -a --htdocs='html' --kdnr --fixmailquota --verbose


    Trifft das Script nun auf einen Cronjob im Confixx bleibt es ohne Fehlermeldung (in einer Endloschleife?) hängen.


    Workaround:
    Zeilen 656 bis 660 im Importscript auskommentiert:
    # Verzeichnisnamen von $command anpassen: /var/www/web#/html/ -> /var/www/web#/htdocs/
    #while (preg_match('/\/var\/www\/([^\/]+)\/html(\/.*)?$/', $command)) {
    # $command = preg_replace('/\/var\/www\/([^\/]+)\/html(\/.*)?$/', '/var/www/$1/' . $OPTS['htdocs'] . '$2', $command);
    #}


    Internette Grüße
    Reiko

  • Update lcdbdump

    Dafür ein dickes Like. Ich habe gerade am Wochenende 3 Server installiert und auf MySQL umgestellt und mich jedes Mal gefragt, was da so lange dauert beim Import.

  • Begrüßungsemail beim Anlegen eines Kunden

    Guten Tag,


    ich kann mich erinnern, dass es hier mal eine Aussage gab, dass beim Anlegen eines Kunden eine Begrüßungsemail mit den Credentials verschickt werden kann. Aktuell scheint das aber immer noch nicht der Fall zu sein. Ist das noch aktuell oder einfach untergegangen?


    Internette Grüße
    Reiko

  • LiveConfig v1.8.2 freigegeben

    Guten Morgen Herr Keppler,


    wir sind hier auf Debian Squeeze unterwegs.


    Output beim Updaten von LC:


    Preparing to replace liveconfig 1.8.1-r3397 (using .../liveconfig_1.8.2-r3447_amd64.deb) ...
    [ ok ] Stopping LiveConfig Server: liveconfig.
    Creating SQLite Database Backup
    Input File: /var/lib/liveconfig/liveconfig.db
    Output File: /var/lib/liveconfig/liveconfig.db.bak-1.8.1-r3397
    Done.
    Unpacking replacement liveconfig ...
    Preparing to replace unzip 6.0-8+deb7u1 (using .../unzip_6.0-8+deb7u2_amd64.deb) ...
    Unpacking replacement unzip ...
    Processing triggers for man-db ...
    Processing triggers for mime-support ...
    Setting up libkrb5support0:amd64 (1.10.1+dfsg-5+deb7u3) ...
    Setting up libk5crypto3:amd64 (1.10.1+dfsg-5+deb7u3) ...
    Setting up libkrb5-3:amd64 (1.10.1+dfsg-5+deb7u3) ...
    Setting up libgssapi-krb5-2:amd64 (1.10.1+dfsg-5+deb7u3) ...
    Setting up libdbus-1-3:amd64 (1.6.8-1+deb7u6) ...
    Setting up libxml2:amd64 (2.8.0+dfsg1-7+wheezy3) ...
    Setting up ntp (1:4.2.6.p5+dfsg-2+deb7u3) ...
    [ ok ] Starting NTP server: ntpd.
    Setting up dbus (1.6.8-1+deb7u6) ...
    Installing new version of config file /etc/dbus-1/system.conf ...
    [ ok ] system message bus already started; not starting..
    Setting up liveconfig (1.8.2-r3447) ...
    [....] Starting LiveConfig Server: liveconfig - /usr/sbin/liveconfig: Can't open any socket for address (null), port 8443
    failed!
    Setting up unzip (6.0-8+deb7u2) ...


    Ja, LiveConfig wird gestoppt. /var/run/liveconfig.pid? ist 0Byte und leer.


    xx@webclient2 ~ # ps auwfx | grep liveconfig
    root 2362 0.0 0.0 4484 792 ? Ss Jan12 31:37 /usr/lib/liveconfig/lclogparse -c /etc/liveconfig/lclogparse.conf
    root 29903 0.0 0.0 9236 888 pts/0 S+ 10:04 0:00 | \_ grep liveconfig
    root 20806 0.0 0.0 54216 1848 ? Ss Jan28 0:03 /usr/sbin/liveconfig
    113 20807 0.2 0.1 261956 36904 ? Sl Jan28 49:28 \_ liveconfig [server]
    root 20808 0.0 0.0 272044 13140 ? Sl Jan28 2:36 \_ liveconfig [client]
    root 13296 0.0 0.0 4220 576 ? S 09:28 0:00 \_ /usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats


    xx@webclient2 ~ # netstat -putln | grep 8443
    tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 20806/liveconfig
    tcp6 0 0 :::8443 :::* LISTEN 20806/liveconfig


    xx@webclient2 ~ # kill 20806
    xx@webclient2 ~ # netstat -putln | grep 8443
    xx@webclient2 ~ # service liveconfig restart
    [ ok ] Stopping LiveConfig Server: liveconfig.
    [ ok ] Starting LiveConfig Server: liveconfig.


    Ich hoffe das hilft weiter.

  • PHP-Einstellungen durch Kunden greifen nicht

    Die Fehlerursache:
    Ich habe folgende Struktur: res0 im admin-Account, res0 hat web0 bis webx (also Confixx-Struktur). Der Server wurde aus Confixx migriert. Beim res0 war eine andere PHP-"Bereitstellungsart" eingestellt, als beim Kunden.


    Das sollte nach meinem Verständnis nicht möglich sein, als Beispiel:


    Admin:
    Angebot: R als Resellerpaket mit PHP = modphp
    Kunde res0 mit Vertrag auf R mit PHP = modphp


    Res0:
    Kunde web0 mit Vertrag PHP = suphp


    Warum ist für den Kunden suphp auswählbar, wenn doch der Vertrag von res0 mit dem Admin modphp sagt? (modphp und suphp sind jetzt hier willkürlich genannt).


    Bei der Fehlersuche bin ich noch über ein Problem mit SSI (nicht SSL!) gestolpert, was aber dann ein generelles Anzeigeproblem ist: Die Anzeige von Eigenschaften bei den Verträgen ist durch die interaktive dynamische Optionsbeschriftung nicht nur suboptimal, sie ist designtechnisch schlichtweg falsch und inkonsistent in der Umsetzung:


    Beispiel:
    X=Häkchen gesetzt
    o=Häkchen nicht gesetzt
    Annahme: im Angebot ist gesetzt: SSI o


    Rufe ich beim Kunden "Vertrag bearbeiten auf" finde ich


    SSI o abweichend o nein
    Nein ist NICHT angekreuzt und das ist unlogisch, denn ohne Kreuz bedeutet ein nicht ausgewähles "Nein" ist ein "Ja". Ich muss also gedanklich auswerten: Aha, diese Option ist nicht abweichend und obwohl das nein nicht angekreuzt ist steht die Option SSI auf "nein". Wäre das "nein" angekreuzt, dann würde ein "ja" da stehen. Das macht dann auch Sinn: ein angekreuztes "ja" ist nunmal ein "ja", da kann man sich drehen und wenden wie man will. Aber ein nicht angekreuztes "nein" ist eben kein "nein"....


    Richtig wäre also die Anzeige:
    SSI o abweichend x nein
    denn SSI ist ja im Angebot nicht angekreuzt.


    Das könnte man viel ergonomischer lösen: das Optionskästchen bei "abweichend" weglassen und auch die Beschriftung "ja" "nein" weglassen. Das würde im Beispiel zur Anzeige führen:
    SSI abweichend(abgeblendet) o
    Setzt man nun ein x entsteht:
    SSI abweichend(aufgeblendet) x
    Oder: einfach Dropdownfelder mit "Ja" und "Nein" einsetzen.


    Das ist m.E. vie besser zu überblicken und hilft bei der Fehlersuche enorm.


    Just my 2 cents wie wir Franzosen sagen....

  • PHP-Einstellungen durch Kunden greifen nicht

    Guten Morgen Herr Keppler,


    das Änderungsdatum der php.ini im Kundenverzeichnis (/var/www/webXXX/conf/php5/php.ini) ist plausibel, liegt sehr zeitnah bei der Änderung.


    Das LC-Log (getestet am web299):


    [2014/12/04 22:24:16.843183] [4824|4854] [LUA] LC.exec(/usr/sbin/a2ensite web299.conf): program output: Site web299.conf already enabled
    [2014/12/04 22:24:27.514461] [4824|4851] [LUA] LC.exec(/etc/init.d/apache2 reload): program output: Reloading web server config: apache2.
    [2014/12/04 22:24:27.514654] [4824|4851] [LUA] LC.exec(/etc/init.d/apache2 reload): error output: [Thu Dec 04 22:24:27 2014] [warn] The Alias directive in /etc/apache2/sites-enabled/local.conf at line 6 will probably never match because it overlaps an earlier Alias.


    Der Server läuft unter wheezy mit PHP 5.4 als einziger PHP-Version.


    Möchten Sie Zugriff auf den Server über Ihren öffentlichen Schlüssel?


    Internette Grüße
    Reiko

  • PHP-Einstellungen durch Kunden greifen nicht

    Guten Abend,


    Kunde ändert unter Hosting>Webspace>PHP-Einstellungen den Werte display_errors auf "Ja", Standard war "Nein".


    LC schreibt in die php.ini display_errors = Off, egal ob "Ja" oder "Nein" ausgewählt wird.


    Ebenso bei display_startup_errors.


    Auch die Werte von upload_max_filesize und post_max_size werden nicht korrekt geschrieben.


    Fehler nur bei mir??


    Internette Grüße
    Reiko

  • Mailzustellung an Domain, die dem Hostname entspricht schlägt fehl

    Danke Herr Keppler.


    @anton
    Auf dem Confixx-Server habe ich tatsächlich doch servername.xy bei myhostname, mydestination UND in confixx_localDomains stehen und es funktioniert trotzdem. Es gibt allerdings im Log ein "warning: do not list domain servername.xy in BOTH mydestination and virtual_alias_domains".


    Egal, Problem gelösgt, nur darauf kommt es an. Danke für die Hilfe. :)


    Internette Grüße
    Reiko

  • Mailzustellung an Domain, die dem Hostname entspricht schlägt fehl

    Hallo Anton,


    danke für das Feedback.


    Zitat von antondollmaier

    Bekanntes Problem und unabhängig von LC.


    Nicht plausibel: z.B. unter Confixx funktionierte das exakt so und ohne Fehler.


    Den Lösungsvorschalg habe ich nachvollzogen, mit negativem Ergebins.


    /etc/hostname:
    subdomain


    /etc/hosts:
    127.0.0.1 localhost.localdomain localhost
    123.456.789.123 subdomain.servername.xy subdomain
    #
    # IPv6
    ::1 ip6-localhost ip6-loopback
    fe00::0 ip6-localnet
    ff00::0 ip6-mcastprefix
    ff02::1 ip6-allnodes
    ff02::2 ip6-allrouters
    ff02::3 ip6-allhosts
    abcd:123:123:1234::2 subdomain.servername.xy subdomain


    /etc/init.d/hostname.sh wurde ausgeführt
    service postfix restart auch.



    Andere Ideen?


    Internette Grüße
    Reiko

  • Mailzustellung an Domain, die dem Hostname entspricht schlägt fehl

    Guten Morgen,


    eine Mailzustellung an ein Postfach auf dem Domainnamen, der auch unter /etc/hostname eingetragen ist schlägt fehl.


    /etc/hostname enthält servername.xy
    /etc/mailname enthält mail.servername.xy


    Auf dem Vertrag web0 wird nun auch servernamexy als Domain eingerichtet, dazu eine Emailadresse test@servername.xy.


    Sende ich eine Email an test@servername.xy erhalte ich folgende Rückantwort:


    ----
    This is the mail system at host servername.xy.


    I'm sorry to have to inform ...


    The mail system


    <test@servername.xy>: unknown user:
    "test"



    Reporting-MTA: dns; servername.xy
    X-Postfix-Queue-ID: CCBblabla
    X-Postfix-Sender: rfc822; ich@meineadresse.de
    Arrival-Date: Thu, 13 Nov 2014 09:52:42 +0100 (CET)


    Original-Recipient: rfc822;test@servername.xy
    Action: failed
    Status: 5.1.1
    Diagnostic-Code: X-Postfix; unknown user: "test"
    -----



    Lege ich jedoch zur Domain servername.xy im web0 eine Subdomain test.servername.xy an und erstelle darauf die Emailadresse test@test.servername.xy wird die Email einwandfrei zugestellt.


    Das beschriebene Problem betrifft ausschließlich den Fall, dass es sich bei servername.xy um die Domain handelt, die auch unter /etc/hostname eingetragen ist. Alle Anderen Domains laufen diesbezüglich einwandfrei. Das Verhalten konnte ich auf mehreren LC-Servern reproduzieren.


    Grundlagen:
    Debian Wheezy mit LC letzte Version


    Bin für jeden Tipp dankbar.


    Internette Grüße
    Reiko

  • SSL-Zertifikat als ungültig/self signed bei FTPS mit Proftpd

    Guten Abend Herr Keppler,


    danke, dass Sie sich das Sache so zügig angenommen haben. Jetzt funktioniert es einwandfrei. Natürlich mußte nach dem LC Neustart noch einmal die Proftpd-Konfiguration in LC aktualisiert werden.


    Aber wie das so ist im Leben, ich habe da gleich noch ein Problem, dazu mache ich aber nätürlich einen neuen Thread auf :)


    Ansonsten weiter so: je länger ich LiveConfig benutze, desto besser finde ich es ;)


    Internette Grüße
    Reiko