Reseller müssen keinerlei Server verwalten können.
Du erstellst ein Reseller-Angebot (Kunden: >0).
Erstellst damit bei deinem Kunden einen neuen "Wiederverkäufer-Vertrag" ("res1234").
Wenn der Kunde sich nun anmeldet, hat er "Kunden" sowie "mein Hosting". Und kann nun Endkunden-Verträge erstellen, wobei er die Ressourcen eines Reseller-Vertrages auswählen muss.
Es geht somit nicht, dass ein Reseller seine Kunden auf die Server web1 und web2 verteilt, wenn er nur einen Reseller-Vertrag hat.
Unter Confixx hieß das Postfach z.B. web123p1, darauf konnten beliebig viele E-Mailadressen gemappt werden.
So konnte ich abc@meine-domain.tld als Absender im AndroidMail eintragen und Login war web123p1.
Nochmals: was hindert dich jetzt an folgendem:
- Mailadresse f.mustermann@example.com
- "Postfach anlegen", Passwort vergeben
- Alias "fmustermann"
In Android-Mail kannst jetzt genau so vorgehen wie du. Absender "fmustermann@example.com", Login mit "f.mustermann@example.com".
Oder noch besser: Mailadresse "info@example.com" erstellen und als Weiterleitung an f.mustermann und a.mustermann definieren.
Auch "info@example.com" kann nun in jedem Mailclient als Absender gewählt werden.
Du kannst aber auch "einkauf@example.com" als Absender setzen - obwohl die Mailadresse gar nicht existiert.
Postfix interessiert der Absender nämlich genau gar nicht, sobald man sich erfolgreich via SMTP-Auth angemeldet hat.
ZitatSo war es z.B. auch möglich Mails auch ohne E-Mailadresse direkt an das Postfach web123p1@server-name zu senden. Das war sehr hilfreich, wenn man bei einem Serverumzug auf dem alten Server so die Postfächer abschalten konnte und die Mail so an die neuen Konten senden konnte bis alle Systeme den neuen MX gelernt hatten.
Oder man legt auf dem alten Server über die Transport-Maps einen Eintrag für die Domain an, der dann auf den neuen Server geht. Dafür muss nicht mal die Mailadresse geändert werden.
ZitatFür Roundcube gibt es sogar ein Confixx-Plugin, dass zusätzlich zu dem Postfachlogin auch einen Login über die Mailadressen ermöglicht.
Das RoundCube-Plugin macht nichts anderes, als beim Login in die Confixx-Datenbank zu schauen und zum angegebenen Benutzernamen über die E-Mail-Tabellen ein Postfach zu finden. Der Postfachname wird dann statt dem vom Benutzer angegebenen Login an den IMAP-Server geschickt.
Das passiert völlig unabhängig von Dovecot.
Aber $vertrag/$nummer kann ich nicht als Login verwenden.
Korrekt. Hat Confixx aber auch nicht unterstützt. Es sei denn, man hat mit MySQL selbst rumgefriemelt.
ZitatWas ist daran so speziell?
In geschäftlichen Umgebungen gibt es Benutzerpostfächer und Funktionsadressen (Aliases). Und manchmal will/muss man mit diesen auch versenden können. Das war unter Confixx kein Problem, weil Postfach-Login != E-Mailadresse
Exchange erlaubt "SendAs". Das ist dann eine Client(!)-Funktionalität, so dass der Absender(!) von E-Mails vom SMTP-Benutzernamen abweichen darf.
Da die Absender-Mailadresse aktuell gar nicht validiert wird, sehe ich keine Abweichung: Kunden können sich in Thunderbird und Apple Mail einen einzigen Postausgangsserver mit z.B. user@example.com definieren, gleichzeitig aber mehrere Mailkonten (info@example.com) definieren, die diesen SMTP-Server für ausgehende Mails benutzen.
Zusätzlich erlaubt Thunderbird noch, "Identitäten" anzulegen.
Die Anforderung "Kunde darf verschiedene IMAP/SMTP-Zugangsdaten verwenden, um auf das gleiche Postfach zuzugreifen", ist definitiv nicht Standard.
was war das doch zu Confixx-zeiten schön, wenn Postfachname und Mailadressen nichts miteiander zutun haben...
Das ist intern immer noch so. Deshalb liegen die Mails ja auch in Ordnern $vertrag/$nummer.
ZitatIch dachte LC wäre hier flexibler...
Die Anforderung ist allerdings auch ... speziall.
wäre das über die Datenbank machbar?
Da Dovecot mit den gespeicherten Passwörtern nichts anfangen kann, außerdem die Quota-Informationen komplett inkompatibel gespeichert sind: nein.
Lösung
Das File "http2.conf" muss scheinbar in /etc/apache2/conf.d/ liegen, damit es geladen wird.
Nö, muss es nicht.
Unter Debian Stretch ist "conf-enabled" (bzw. conf-available und danach die Config aktivieren) der richtige Ordner.
Bitte bei solchen Angaben immer das Betriebssystem bzw. die Distribution mit angeben,
Danke. Steht jedoch nicht da, sobald die Domain auf eine Anwendung geleitet wird also per App installiert wurde
HTTPS-Zugriff beim Vertrag aktiviert?
Den Anwendungen ist HTTP bzw. HTTPS egal. Die Konfiguration passiert komplett bei "Domains" und ist identisch zu Webspace bzw. Redirect.
Bitte an den Provider wenden. ionCube ist unabhängig von LiveConfig und Provider-Angelegenheit.
Dann liegt's vermutlich nicht an der PHPMailer-Version.
Läuft der LCPolicyd?
Einfach bei "Domains" den HTTPS-Zugriff steuern.
Warum sollten "alte" Zertifikate gelöscht werden?
Der Renew erfolgt ja mit dem bestehenden Private Key - nur das Zertifikat selbst wird getauscht.
Es gibt also bei einem Renew o.ä. keinen zusätzlichen Eintrag bei den "SSL-Zertifikaten".
Ich wollte eigentlich wissen, ob man das default-SSL-Zertifikat, welches bei der Installation von LC angelegt wird löschen bzw. durch ein vollwertiges SSL-Zertifikat tauschen kann.
eines kaufen oder via Let's Encrypt beantragen?!?
ZitatWie gesagt ich habe das jetzt mit der Canonical-Methode gemacht und über eine Subdomain geroutet.
Also eine Subdomain in LiveConfig angelegt, ein passendes SSL-Zertifikat über Let's Encrypt geholt und dieses Zertifikat ggf. noch anderweitig installiert? Das hat aber null nada mit dem "cacert.pem" zu tun.
Das Default-Zertifikat existiert auch weiterhin. Browser, die SNI können, sehen das nur nicht mehr.
Ansonsten bei der IP-Konfiguration HTTPS von "gemeinsam" auf "exklusiv" stellen. Dann wird nur noch dieses Zertifikat konfiguriert - aber heißt dann auch, dass es sonst kein Zertifikat mehr geben kann 
Also wenn man es eh schon einbaut kann man vielleicht noch ne Spalte Serverweit/Global mit einbauen odeR?
Header/Body-Checks gehören zu Postfix und müssen auch anders validiert/geprüft werden.
Globale SpamAssassin-Einstellungen sind ein anderes Kapitel.
Eine Möglichkeit, einen individuellen Inhaltsfilter zu haben, der E-Mails nach bestimmten Kriterien ablehnen kann, wäre bestimmt hilfreich. Also die Postfix Header- und Body-Checks in ein Interface gepackt.
Das ist aber dann "individuell pro Server" und nicht "pro Postfach", also vollkommen disjunkte Ansätze.
Kommt leider oft genug vor, dass Kunden mit "ich will Mails von xxx@example.com nicht mehr haben!" ankommen.
Der Bayes-Filter trägt nur zum Teil zum Scoring bei.
Es macht mehr Sinn, vernünftige Regeln zu nutzen - und generell nicht nur auf SpamAsasssin zu setzen.
Im Confixx ist aktuell offenbar DNS aktiv:
https://github.com/LiveConfig/…master/cfximport.php#L654
Andernfalls würde das DNS-Template gar nicht erst übergeben werden.
Entweder im LiveCOnfig auch DNS aktivieren (und ein passendes DNS-Template übergeben), oder in der Confixx-DB "DNS" abschalten ("update domains set dns=0"). Ob letzteres gefahrlos geht, bitte selbst verifizieren.
Erst mal ein zum kleinsten gemeinsamen Nenner:
FTP ist tot. Ich hab sogar alle FTP-Server deinstalliert sodass in LC keine FTP-Einstellungen mehr zu machen sind. Ich will kein ProFTP, vsftpd, oder den anderen da...
Mir ist neu, dass dann überhaupt die Benutzerverwaltung über LiveConfig ohne installierten FTP geht.
ZitatIn der Passwd stehen z.B. pro Hauptbenutzer:
MEINUSER:x:1001:1001::/var/www/MEINUSER:/bin/bash
web1:x:1005:1005::/var/www/web1:/bin/bash
- Das sieht schon mal ok aus oder?
ja.
Bitte zukünftig "code"-Tags im Forum verwenden, dann liest es sich leichter.
ZitatWenn ich per WinSCP über SFTP versuche den Server zu erreichen, (ich bin mit sicher das Benutzername und Passwort ok sind! - also ehrlich...)
Wenn ich das mache löse ich folgende Logs in der auth.log aus:
Aug 1 13:35:36 HOST sshd[10044]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=INTERNET user=MEINUSER
Aug 1 13:35:38 HOST sshd[10044]: Failed password for MEINUSER from IP port 38558 ssh2
da fehlen unter Umständen zuvor noch Zeilen. Bitte größeren Log-Auszüg posten.
Es kann aber eben durch den fehlenden ProFTPd sein, dass LiveConfig das Passwort gar nicht konfiguriert.
Wenn die FTP-Verbindung grundsätzlich funktioniert, aber die Übertragung dann Probleme macht, dann hat das nichts mit Benutzerdaten/Login/etc. zu tun, sondern in der Regel irgendetwas mit SSL.
Oder ein Bug in ProFTPd, der in Jessie nicht gelöst wurde:
Wieder ein Schritt weiter, allerdings akzeptiert die Bash das Passwort nicht. das gilt auch für den admin und für root!
admin gibt es normal nicht.
Root darf sich üblicherweise nur mit Key anmelden - das hat hier aber nichts verloren, da unabhängig von LiveConfig.
ZitatWie läuft denn die Benutzerverwaltung bei Liveconfig? Ich denke SSH schaut nicht in die passwd...
doch, genau dorthin und nur dorthin.
Zitathab da leider zu wenig Ahnung.
dann wird's Zeit für einen Admin
Logs und /etc/passwd prüfen, ob überhaupt die Bash hinterlegt ist.
