Beiträge von apos

    Hi,


    wollte mal meine Post updaten, denn mittlerweile habe ich eine ganz einache KISS***-Lösung gefunden und mich wieder an diese Frage erinnert:


    *** keep it simple and stupid


    Für die Greenhorns: der

    Code
    SSH server auf dem Host sollte natürlich nur über Zertifikate erreichbar sein

    (sshd_config: PasswordAuthentication no, UsePAM no). Das entspricht dann in etwa einer VPN Verbindung.


    Auf einer lokalen Konsole den SSH Tunnel etablieren:


    Code
    ssh -L 9000:IP_OF_SERVER:8443  loginname@IP_OF_SERVER


    wobei

    • 8443 der Port des Zentyal Web Interface auf dem Server ist
    • 9000 der lokale Port im Browser ist, unter dem man nun das Web Interface aufrufen kann

    ... und zwar so:

    Code
    https://localhost:9000


    Tja, das Leben kann so einfach sein ;)


    P.S.: Es is ist nicht möglich ohne Eingriffe ins KVM Host System ins innere der Maschine zu kommen. Zum Hintergrund und wie man das realisieren kann, hier ein paar Artikel. I

    Ich selbst mache das auf einem eigenen KVM-Root Server mit IPtables (siehe hier: KVM - Knowledge Base) - und das ist echt Arbeit ;) Mein zugehöriger Zentyal Thread auf Englisch ist hier: [url=https://forum.zentyal.org/index.php/topic,20028.msg98671.html#msg98671]Can't reach zentyal webadmin via vpn network on virtual nic from vpn client pc[/url]

    Die iptable-rules kann man unter Zentyal sehr einfach in einen Hook packen:


    Code
    vim / etc/zentyal/hooks/firewall.postservice



    Code
    service zentyal firewall restart;




    Leider kein Durchkommen ;(


    Irgendwo mach ich wohl einen Denkfehler ...

    Hallo zusammen,


    ich habe auf meinem Neptun ein Zentyal installiert. Es ist also eine sehr spezielle Frage.


    So weit so gut. Zur Absicherung läuft ein VPN Server. Der ließ sich auch wunderbar einrichten und funktioniert.
    Da der Server nur eine Netzwerkkarte hat, habe ich kurzer Hand eine virtuelle erstellt.


    Ja, das ist ein Crosspost, aber ich denke, Zentyal könnte für einige Leute interessant sein (Zentyal - Knowledge Base )


    Das Szenario ist hier dargestellt
    * Can't reach zentyal webadmin via vpn network on virtual nic from vpn client pc


    Nun wollte ich gerne das Administrationsinterface (ein spezieller Port) nur noch via VPN zugänglich machen, komme aber vom VPN-Client PC einfach nicht auf das virtuelle Interface.


    Hier sind die NAT / iptables Gurus gefragt, denke ich.
    Irgendwelche Ideen? Im o.g. Thread ist die iptable-save gepostet.


    Grüße
    Axel

    Hallo zusammen,


    Nach dem vollständigen


    - Löschen der Domain
    - Löschen des Benutzers
    - Löschen aller Ordner in /var/kunden/mails
    - Neu anlegen des Benutzers
    - Neu Zuweisen der Domain
    - Neu Anlegen des Email Account und Weiterleitung


    hat sich das Problem einfach in Luft aufgelöst. Ich bin echt sprachlos, woran es lag.


    Vielleicht lags auch an diversen


    Code
    /etc/init.d/postfix restart
    /etc/init.d/dovecot restart
    newaliases

    :confused:


    Ach ja, in der /etc/postfix/main.cf habe ich die Zeile


    Code
    mydestination = $myhostname $mydomain localhost localhost.$mydomain


    wieder in den Ursprungszustand gesetzt (war aber vorher auch schon so).


    Nun denn, es geht jedenfalls.
    Grüsse Axel

    Hallo zusammen,



    • Debian Squeeze / 6.0 (Problem gabs aber auch schon unter 5.0)
    • SysCP 1.4.2.2
    • postfix für Dovecot enabled (geht aber ohne Dovecot genausowenig)


    komme hier mit meinem Postfix einfach nicht weiter.


    Die email-Funktionalität (Mailversand / Empfang9 über TLS geht soweit wunderbar.


    Nur wenn ich Weiterleitungen einrichten möchte, bekomme ich folgende Mailer Fehler.


    1. Fall:


    Wenn ich die Mail von einem Konto auf dem Server an die umgeleitete Adresse versende, kommtd ie Mail kommt zurück mit:


    2. Fall:


    Wenn ich die Mail von ausserhalb an die umgeleitete Adresse versende, wird die Mail verworfen:


    Die /var/log/mail.log zeigt folgende Informationen:


    Code
    Mar  9 14:31:49 myvserver postfix/smtpd[9291]: connect from mailout-de.gmx.net[213.165.64.23]
    Mar  9 14:31:49 myvserver postfix/smtpd[9291]: NOQUEUE: reject: RCPT from mailout-de.gmx.net[213.165.64.23]: 554 5.7.1 <[B]info@vserverdomain.de[/B]>: Relay access denied; from=<[B]absender@mail.com[/B]> to=<[B]info@vserverdomain.de[/B]> proto=SMTP helo=<mailout-de.gmx.net>
    Mar  9 14:31:49myvserver postfix/smtpd[9291]: disconnect from mailout-de.gmx.net[213.165.64.23]

    Seltsam:


    • Die Email der erstellten Weiterleitung (weiterleitung@otherdomain.de) erscheint hier nicht als Final-Recipient
    • Es gibt einen reject, wenn von ausserhalb versendet wird


    Im Mysql Code ist die destination-Adresse jedoch vermerkt:

    Code
    mysql> select email, email_full, destination from mail_virtual where email LIKE '%vserverdomain%';
    +-----------------------+-----------------------+------------------------------------------------------+
    | email                 | email_full            | destination                                          |
    +-----------------------+-----------------------+------------------------------------------------------+
    | info@vserverdomain.de | info@vserverdomain.de | info@vserverdomain.de weiterleitung@otherdomain.de |
    +-----------------------+-----------------------+------------------------------------------------------+

    Any clue? Bin (noch) nicht so der Postfix-Guru und steh irgendwie auf dem Schlauch. Das Problem scheint jedoch bekannt zu sein und scheint irgendetwas mit den Einstellungen im Postfix main.cf zu tun zu haben.


    Seltsam: Vor einer Woche habe ich es zum ersten Mal eingerichtet und es ging (für einen Tag). Nach einem Serverreboot ging es nicht mehr :o


    Danke schon mal
    Grüsse Axel



    Achso, die üblichen Verdächtigen fehlen noch

    Code
    /etc/postfix# cat sasl/smtpd.conf
    pwcheck_method: auxprop
    auxprop_plugin: sql
    mech_list: plain login cram-md5 digest-md5
    sql_engine: mysql
    sql_hostnames: localhost
    sql_user: syscp
    sql_passwd: mysycppass
    sql_database: syscp
    sql_select: select password from mail_users where username='%u@%r'
    Code
    [B]/etc/postfix# cat mysql-virtual_alias_maps.cf[/B]
    user = syscp
    password = mysycppass
    dbname = syscp
    table = mail_virtual
    select_field = destination
    where_field = email
    additional_conditions = and destination <> '' and destination <> ' '
    hosts = localhost
    Code
    [B]/etc/postfix# cat mysql-virtual_mailbox_domains.cf[/B]
    user = syscp
    password = mysycppass
    dbname = syscp
    table = panel_domains
    select_field = domain
    where_field = domain
    additional_conditions = and isemaildomain = '1'
    hosts = localhost
    Code
    [B]/etc/postfix# cat mysql-virtual_mailbox_maps.cf[/B]
    user = syscp
    password = mysyscppass
    dbname = syscp
    table = mail_users
    select_field = maildir
    where_field = email
    hosts = localhost
    Zitat

    Weiss jemand von euch, ob man den smtp Port auch aktiviert lassen kann, damit Postfix auf beiden Ports hört?

    Konnte die Antwort selbst finden und testen:


    JA es ist möglich. Durch einfaches aktivieren beider Zeilen lauscht Postfix dann auf Port 25 und 587.


    Siehe http://rackerhacker.com/2007/0…sion-port-587-in-postfix/


    Code
    smtp      inet  n       -       -       -       -       smtpd
    submission inet n       -       -       -       -       smtpd
       -o smtpd_enforce_tls=yes
       -o smtpd_sasl_auth_enable=yes
       -o smtpd_client_restrictions=permit_sasl_authenticated,reject

    Hallo zusammen,


    heute morgen rief mich ein Freund aus Schweden an, der dort vergeblich versuchte, seine Emails zu versenden. Ich war ein wenig überrascht, schien nach Einrichtung eines Testclients auf meinem Rechner doch alles hier in deutschen Landen prima zu funktionieren.


    Nun ich möchte euch die Lösung nicht vorenthalten. Wohl auf Grund von Spam wird in manchen Ländern der Port 25 für das Versenden von Mails gesperrt.


    http://wolf-u.li/1655/submissi…87-in-postfix-aktivieren/ erklärt, wie man die Postfixeinstellungen entsprechend ändert um dann auf Port 587 ausweichen zu können.


    Die folgenden Zeilen in der /etc/postfix/master.cf (Debian) zum submission (!) Port sollten genau so auskommentiert, die zum smtp port kommentiert werden und dann der emailserver neu gestartet werden.


    Code
    #smtp      inet  n       -       -       -       -       smtpd
    submission inet n       -       -       -       -       smtpd
       -o smtpd_enforce_tls=yes
       -o smtpd_sasl_auth_enable=yes
       -o smtpd_client_restrictions=permit_sasl_authenticated,reject
    Code
    /etc/init.d/postfix restart

    Nachteil: Email Versand läuft nur noch unter TLS und mit Port 587.


    Getestet unter Debian Lenny / SysCP 1.4 / Vserver 15xx.


    Weiss jemand von euch, ob man den smtp Port auch aktiviert lassen kann, damit Postfix auf beiden Ports hört?


    Grüße Axel

    Zitat von [netcup] Alex;2613


    Es kommt eben drauf an was du mit dem Server machst bzw. darauf betreibst ;)


    So seh' ich das eigentlich auch. Danke für die Antwort.


    Fazit: Die Umstellung der Consolen locale ist also eher unproblematisch für "nicht Shell Programme", eher schon für z.B. Perl, die Nutzung von CGI beim Apache o.ä., und natürlich beim compilieren (fallsman sowas auf dem vs überhaupt macht , ts. ts. :rolleyes:).


    Schönen Sonntag noch.
    Greets

    Hi zusammen,


    erst einmal hallo als neuer Kunde von netcup und "Neuer" im Forum :D


    Habe vor einigen Tagen den Umzug von s4... nach hier endlich geschafft (vs768 / Debian). Arbeite zu Hause unter Ubuntu 8.10 und nach diversen Tests der Neuinstallationsfunktionen von OpenVCP :) fiel mir immer wieder die inkorrekte Darstellung der Umlaute unter dem Debian Image in meinem Ubuntu Terminal auf.


    Grund:[INDENT] meinUbuntu# locale
    LANG=de_DE@UTF-8
    [...]


    meinVserver# locale
    LANG=de_DE@euro
    [...]
    [/INDENT]Lösung auf dem Debian System (Vserver):[INDENT] meinVserver# dpkg-reconfigure locales
    [...]
    [/INDENT][INDENT]Darin die UTF-8 Locale im zweiten Schritt als Standard auswählen.
    Logout / Login:


    meinVserver# locale
    LANG=de_DE.UTF-8
    [...]
    [/INDENT]So, nun zur Frage:


    Glaubt jemand, das gibt Probleme in der Zukunft?
    Sollte man nicht generell besser mit der englischen UTF-8 den Server fahren?


    Greets