Beiträge von WebService4U

  • 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

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

    Ich merke gerade, der Sachverhalt stellt sich doch noch anders dar:


    LC schreibt in die proftpd.conf:


    TLSRSACertificateFile /etc/ssl/certs/proftpd.crt
    TLSRSACertificateKeyFile /etc/ssl/private/proftpd.key


    Ich habe das nun auskommentiert und mal das Zertifikat aus der (funktionierenden) VHOST-Konfiguration des Apache eingesetzt und damit funktioniert es korrekt:
    #TLSRSACertificateFile /etc/ssl/certs/proftpd.crt
    #TLSRSACertificateKeyFile /etc/ssl/private/proftpd.key


    TLSRSACertificateFile /etc/ssl/certs/e728dffBLABLA7c.crt
    TLSRSACertificateKeyFile /etc/ssl/private/e728dffBLABLA7c.key
    TLSCACertificateFile /etc/ssl/certs/e728dffBLABLA7c-ca.crt


    Meine vorherige Aussage:
    TLSRSACertificateFile /etc/ssl/certs/proftpd.crt
    TLSRSACertificateKeyFile /etc/ssl/private/proftpd.key
    TLSCACertificateFile /etc/ssl/certs/BLABLABLAc-ca.crt
    würde funktionieren, ist NICHT richtig.


    Ideen?

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

    Hallo Anton,


    das Zertifikat ist komplett inklusive CA in LC hinterlegt und wird auch problemlos beim Apache2 und Dovecot verarbeitet (ja, ich weiß, die Auth-Mechnismen bei FTPS/HTTPS usw. sind verschieden und somit nicht vergleichbar).


    In proftpd.crt steht tatsächlich die gesamte chain. Ich erhalte beim Verbinden (hier WinSCP) aber trotzdem siehe:
    https://www.dropbox.com/s/lrqx…11-12%2015.47.09.png?dl=0


    Setze ich in der proftpd.conf TLSCACertificateFile /etc/pfad_zum_ca-cert, dann wird das Zertifikat bei der Verbindung nicht angefragt.


    Gruß
    Reiko

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

    Guten Tag,


    bei der Zuweisung eines eigenen SSL-Zertifikats für Proftpd, der durch LiveConfig verwaltet wird fehlt in der proftpd.conf der Verweis auf die Zwischen- bzw. Root-Zertifikate: TLSCACertificateFile /etc/pfad_zum_ca-cert


    Die Folge ist, dass gültige signierte Zertifikate von FTP-Clients bei FTPS als ungültig moniert werden.


    Internette Grüße
    Reiko

  • LiveConfig meldet sich von MySQL ab

    Hallo Herr Keppler,


    es gab seit 25 Tagen keinen Neustart und auch zwischen den Vorfällen keine LC-Update.


    Kann ich LC vielleicht bis zur Ursachenfindung per Cron zwingen, die Verbindung aufzubauen, zur Zeit prüfe ich jeden Tag manuell, ob die Verbindung da ist.


    Internette Grüße
    Reiko