[FR] Host www subdomain externally

[interfasys]

[FR] Lets us install the www subdomain in another account

Currently DA has some restrictions in place which prevent us from installing a client's www subdomain outside of the user's account.
This restricts the use of local SaaS unless we manage these customers' DNS externally.

Example:
Account service offers a content management platform hosted at service.tld
Account user1 is hosting domain.tld
Both are on the same server and that's the problem.

We want to host www.domain.tld in the service account.

There are 2 things which get in the way currently:

1. When we want to add the www.domain.tld subdomain to a different account, DA sees www in the input and automatically assumes we want to add domain.tld and its www subdomain instead of simply adding www to the domain we're adding, like it's doing for any other subdomain. If doing this on the same server where the main domain is installed, this triggers an alert stating that the domain is already installed.
2. HTTP templates all add www to the domain in ServerName and ServerAlias, even if www is not in the DNS which means that even if we manage to install the www subdomain under another account, the browser will never find it.

Possible solutions:

• Make the check optional, perhaps on the "Add domain" page. Other checks are already in place which prevent domain stealing anyway
• Have some variable in the vhost template which let us turn off www or check if www is even in the dns

 

[nobaloney]

Just like we can host emails, any subdomain except www and DNS externally, we should be able to host the www subdomain externally.

You can host DNS externally; we do, using our local DNS server only as a hidden master.

You can also host www externally, we do that as well four our 1275domains.com, which is hosted on a LogicBoxes control panel at their datacenter in Texas. We change the DNS manually, and create a redirect so apache users going to the it without the WWW get redirected to WWW.

There are 2 things which get in the way currently:

You may care about the extra stuff that DirectAdmin sets up, but we don't. We simply ignore it, since if WWW isn't pointed to the server and the subdomain or domain withoout the WWW gets redirected, we don't see that it makes a difference.

Am I missing some concern of yours which needs to be addressed?

Jeff

 

[interfasys]

You can host DNS externally; we do, using our local DNS server only as a hidden master.

I've added brackets to clarify that I meant that DNS can be hosted externally. The only exception being the www subdomain.

You can also host www externally, we do that as well four our 1275domains.com, which is hosted on a LogicBoxes control panel at their datacenter in Texas. We change the DNS manually, and create a redirect so apache users going to the it without the WWW get redirected to WWW.

Of course, but my OP states that by "externally", I mean outside of the user's account, not necessarily outside of the server. That's when we try to add the www subdomain on the same server that we run into the issue.

You may care about the extra stuff that DirectAdmin sets up, but we don't. We simply ignore it, since if WWW isn't pointed to the server and the subdomain or domain withoout the WWW gets redirected, we don't see that it makes a difference.

I'm going to need to rewrite the OP to make it clearer that I want to keep www on the same server, just in a different account.

 

[interfasys]

OK, rewrite is done. Let me know if it's clearer

 

[nobaloney]

Definitely, though part of the problem is I've been out of touch for several days (my desktop system crashed and had to be reubilt from scratch including lots of custom stuff and things normally not built on linux desktops). So perhaps the first time I didn't read your thread as carefully as I might have.

Interesting feature request. Simple things like the DNS could be managed by changes to the template including if/then to a setting which could be added simply to DirectAdmin or a plugin.

What else needs to be changed?

Anyone care to write a spec as to what might be involved?

Jeff

 

[interfasys]

If DA-Team doesn't want to include a new variable in the template, I'm sure we could patch things up using hooks. It's just not as clean imho.
Regarding the "Add domain" page, I'm not sure how we can work around the limitation (it's not built in javascript). Even if designing our own page, DA might not accept the variables we post and strip the www from the domain.
There is a silly workaround which works though, but again, it's not very clean.
We can add www1.domain.tld to the service account and then add www.domain.tld as an alias.

 

[nobaloney]

Problem is that so far no-one else has expressed an interest. This thread is just a dialogue between the two of us; I'm not sure directAdmin staff would want to build a new feature based on just two interested parties.

Anyone else interested?

Jeff

 

[interfasys]

I guess most people use DA for traditional hosting or store standard accounts and services on different servers or are using custom solutions to manage their SaaS. I was looking for a quick, cheap way of doing things.

I tested the API and DA refuses to add the www.domain.ltd subdomain to its system , so unless they introduce a switch to turn that check off, it seems we're stuck with either using aliases or manually configuring DNS, Apache and SSL entries.

 

[Arieh]

I understand the issue, but it's indeed quite specific.

Personally I was wondering, why is it needed to separate them? I suppose you want to separate the http/CMS from the other DA functions (email?). In a SaaS platform I wouldn't think it would be necessary.

 

[interfasys]

I understand the issue, but it's indeed quite specific.

Personally I was wondering, why is it needed to separate them? I suppose you want to separate the http/CMS from the other DA functions (email?). In a SaaS platform I wouldn't think it would be necessary.

Specific indeed, but the reason the check is in place is purely so that customers don't screw it up, so it should be possible to lift that limitation for people who know what they're doing. An extra variable in CMD_API_DOMAIN perhaps.

And yes, the reason to separate them is so that they can't have access to the CP account where the service is installed and a DNS record change for www doesn't work since each domain needs its own SSL cert.