Beiträge von ñull

  • iOS mail problematisch

    Viele Benützer hatten Probleme mit der Email Konfiguration. Die meiste sind gelöst, nur einen Ipod benützer hatte noch wenig Erfolg. IMAP Konfiguration klappt schon gar nicht. POP3 geht aber verschicken (SMTP) geht nicht, obwohl beim Account einrichten alles OK anzeigt. Leider hab ich keinen Ipod oder Iphone um selber weiter zu erforschen. Hatte jemand auch Probleme damit? Hat es vielleicht mit der Serverkonfiguration zu tun?

  • Kunden Domänen und Subdomänen anlegen

    Anscheinend kann nur den Wiederverkäufer neue Domänen einwandfrei anlegen. Wenn der Kunde es macht kann er nur Subdomänen anlegen oder nur Hauptdomänen ohne Subdominänen. Ich probierte eingeloggt als Kunde neu.com y http://www.neu.com anzulegen. Nur neu.com geht oder http://www.neu.com, aber neu.com UND http://www.neu.com geht nicht. Wenn man probiert ein Subdomain www unter neu.com an zu legen, dann ändert neu.com in http://www.neu.com


    Ist das einen Fehler oder ein Feature?

  • Postfix / Greylist http://serverfault.com/questions/471581/postfix-warning-connect-to

    My attempt to correct this and the other issue with {SCRYPT} hash in a custom.lua, utterly failed. The simple override in the documentation is not sufficiently illustrative to teach me how to override a large function like this, without knowing all the in and outs of LUA. So for now I'll just put an chattr +i for the hacked lua file and wait until I see the fix in the changelog.


    If somebody else finds the right way to solve it in custom.lua, please feel free to post it here.

  • Dovecot authentication with existing MD5 hash fails.

    I felt now free to change this in /usr/lib/liveconfig/lua/dovecot.lua:

  • Dovecot authentication with existing MD5 hash fails.

    An update. All good for the Dovecot (pop3) side of things. Now the Postfix side. There it still fails and the log tells me:



    Code
    postfix/smtpd[12000]: warning: server[ip]: SASL CRAM-MD5 authentication failed:


    Apparently it still is considering it a CRAM-MD5 hash. How do you make Postfix respect the same {CRYPT} label?

  • Dovecot authentication with existing MD5 hash fails.

    I found the solution. With pre-existing $1$ type of hashes, the presently used label {MD5-CRYPT}, that is put there by LC's SOAP API, is not correct. The right label to use here is {CRYPT}. I just tried changing the MD5-CRYPT to CRYPT and then it would authenticate correctly. Please correct this bug!

  • Postfix / Greylist http://serverfault.com/questions/471581/postfix-warning-connect-to

    Apparently since Ubuntu 12.04LTS postgrey service now exclusively listens to ipv6 and this needs to be corrected in the postfix settings. See this post. This manifested as failing local mail delivery logged as:


    After changing the following line in /etc/postfix/main.cf, local mail delivery was recovered:


    Zitat

    greylist = check_policy_service inet:::1:10023


    After that I changed /usr/lib/liveconfig/lua/postfix.lua :

    Zitat


    if LC.distribution.family == "Debian" then
    fh:write("greylist = check_policy_service inet:::1:10023\n")


    In LUA I don't see distinction is made between Debian and Ubuntu. Since I don't use Debian, I cannot tell if the same setting would work there. Is so, please correct the LUA script like indicated in your next release.

  • Dovecot authentication with existing MD5 hash fails.

    It seems that existing mailbox MD5 ends up nicely in /etc/dovecot/passwd. Problem is that authentication fails. It just seems that dovecot refuses to authenticate with that scheme, so I tried to add plain-md5 to the configuration, but it does not recognise it either:


    dovecot: auth: Fatal: Unknown authentication mechanism 'plain-md5'


    Could this be a distribution issue? May be the Ubuntu version does not support it any more?

  • app install under an alias

    I think of the case where you want to use ssl certificates for privacy and for economical reasons you want to use only one certificate for all installed apps, you don't want to spend big money on a wildcard certificate and you don't want visitor confronted with SSL security warning screens, then the only reasonable option left is to access the apps through a path alias instead of (sub)domains.

  • postfix warning: TLS library problem

    Code
    Jan 10 23:10:38 myhostname postfix/smtpd[13079]: connect from myisp.domain.com[myipaddress]
Jan 10 23:10:39 myhostname postfix/smtpd[13079]: warning: TLS library problem: 13079:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1256:SSL alert number 42:
Jan 10 23:10:39 myhostname postfix/smtpd[13079]: lost connection after STARTTLS from myisp.domain.com[myipaddress]
Jan 10 23:10:39 myhostname postfix/smtpd[13079]: disconnect from myisp.domain.com[myipaddress]


    which basically makes secure smtp impossible.


    Then I read in http://linuxlasse.net/linux/howtos/Postfix_with_TLS:



    Where can I find the certificates to try this?

  • Feature request: Extended security

    Would like to limit access to SOAP. Would it be possible that it listens to a different port than the web frontend. When they share the SSL port, I cannot restrict access by firewall, which makes the SOAP password the only security.


    With my previous control panel I could configure it to limit access to clients that have a client certificate installed. Would you please consider adding this feature to LiveConfig? The simplest is to check presence of a client certificate signed by CA (official or selfsigned in the bundle). Extended feature could be to include authenticating through certain certificate fields, for instance the email or serial number field, which makes it possible to identify the client before log-in.

  • Extended WEB Server configuration

    Among the configuration I am thinking of are:


    • WEB Dav configuration
    • Client certificate authentication for SSL sites


    In stead of adding these features one by one, another way would be when system administrators in some form or another could manipulate the text of the configuration directly. Or better still, allowing the system admin to add these functions through LUA. You have already in PHP the possiblity to add custom configuration. Would be nice when something similar were possible in Apache (or other web servers too).