For Sogo I simply made a copy of the virtual host configuration file /etc/httpd/conf.d/zzz_SOGo.conf and changed the host names in it. It works, but that’s a bit ugly.
I think you’re wrong Andy, but I admit I shared your doubts until I tested
The client (with secondary domain name) sends the outgoing emails to NS, which in turns sends outgoing emails to the recipient’s SMTP server by advertising itself with the main domain name, which corresponds the rDNS entry configured for the IP adresse of the server. So no problem.
Right ! I forgot that. But until now I wasn’t able to even connect to NC through the secondary domain I think I’ll try using the same ugly receipt I used for Sogo : copying and customising the virtual host config file.
I think I could do it by creating a custom template but I’m not sure it will have any added value in this case.
The lack of Multiple virtual host support for SOGo is my responsibility. @stephdl actualy did build it in (see “discussion” here ).
Reasoning I had (and have) : although NS can server multiple mail-domain aliases, In it’s gene’s it is a single domain solution.
IMHO, Providing multiple virtualhosts by default would lead to the expectancy of so-called multi-tenant functionality which is not present.
However It should be possible to create a reserve-proxy to add an (virtual) host to access SOGo.
Have forgotten how to do so but key is to add the /SOGo part in this proxy;
I think it is solved here:
Maybe but I also think they are saying that SAMBA4 on NS is only configured for 1 domain and that having user1@example1.com and user1@example22.com can be done at the email level all the other integrated services (OpenVNP/SAMBA AD/File Share/…) are not compatible with the multi-tenancy email deployment.
And note user1@what-ever-domian will always be the same user1, that is in essence the restriction we are dealing with. I do agree the old fashioned way of configuring a local-domain(.lan) for the account provider and (multiple) outside oriented domains (for mail) still does appeal to me.
Back to topic;
As the underling services do not provide it, the SOGo configuration should not imply they do…
Wow. It wasn’t my goal to revive an old polemic - I was unaware of it TBH.
That said, I do not agree with you
Many organisations or individuals soon or later feel the need to get a new domain name for a project, an event, a family name, a brand or parent company name, and so on. That is something that happens every day.
That is totally different than a pure multi-tenant system, which goes far further in terms of features, granularity, privacy, security. That’s out of the scope of NS, I agree with this.
I always thought and said that since NS offers the possibility to define multiple domains, it should offer the basic features listed above and at least offer the possibly to make network services reachable through those domains.
It looks technically not so difficult to me (but I may be wrong), since I more or less reached that goal by using (a bit ugly) customisations, which should be avoided of course.
I really think that it would be a great addition for NS8.
In your setup there are two ProxyPasses to port 20000 on the localhost instead of one with an extra proxypass to this single one.
However I would advise to call it zzz_something.conf to preserve the default virtual host. Apache reads the configuration files alphabetically and the first becomes the default virtual host.
There is a very distinct difference in maildomain and Samba domain.
There is no such thing that NethServer offers the possibility of multi Samba domain. It even doesn’t offer multi DC.
Yes you can have multi mail domains but they will always be tied to an account in the single Samba domain. (I have no experience with LDAP accountprovider, but I think there is also just a single realm possible.)
But I am sure you already knew this …
Not even a Windows Server can handle multiple Windows Domains or ADs.
A windows server can only be in one Domain/AD.
It would need a “forest” of multiple servers to do that…
MS Exchange also couples users to the domain (AD), even if they use different mail domains.
The AD “realm” remains the same, as even Exchange can only be a member of one AD.