temp adress for addon domains

[nappa]

What is the address for domains that are added on ? I know that the main user address is http://I.P/~username, but I would like to know what the other addresses are.

If there is not one, can you tell me how I can make some ? Thanks :)

[DirectAdmin Sales]

Right now you can only preview one domain (the main domain) before DNS propagation. :)

Mark

[nappa]

is it possible to manually add entires into apache to show the site at also : http://IP/~username/domain.com ? Even if it is a jury rigged solution for now, I would like to do this for one person.

NAPPA

[nappa]

I am an admin, so I can edit the apache conf. So maybe this shoudl be moved to the admin forum ?

[The Prohacker]

Originally posted by nappa
is it possible to manually add entires into apache to show the site at also : http://IP/~username/domain.com ? Even if it is a jury rigged solution for now, I would like to do this for one person.

NAPPA

For a temp solution at shell:

ln -s /home/username/domains/parkeddomain.com/public_html /home/username/public_html/domain.com

That should make it viewable as you wish...

[l0rdphi1]

Originally posted by The Prohacker
For a temp solution at shell:

ln -s /home/username/domains/parkeddomain.com/public_html /home/username/public_html/domain.com

That should make it viewable as you wish...
Yeah, I had to do that a while back too. It works.

Or actually, I used this:

ln -s /home/username/domains/parkeddomain.com/public_html /home/username/public_html

(DirectAdmin uses the symbolic public_html link in your home directory to route http://IP/~username/ requests.)

[DirectAdmin Support]

If you want to change ~username to ~username/domain.com

you can simply remove the public_html symbolic link, create a public_html directory in its place, then create symbolic links as domain.com pointing to where ever you want.

cd /home/username
rm public_html
mkdir public_html
cd public_html
ln -s ../domains/domain.com/public_html domain.com
ln -s ../domains/otherdomain.com/public_html otherdomain.com

John

[nappa]

Thanks everyone :) I've done the very first method on this thread. Is it possible to request this be made automatic ?

[switch]

Is there any update on the possiblity of making this automatic? Or having some method of previewing all domains in a user's account before propagation?

[jlasman]

you can simply remove the public_html symbolic link, create a public_html directory in its place, then create symbolic links as domain.com pointing to where ever you want.

cd /home/username
rm public_html
mkdir public_html
cd public_html
ln -s ../domains/domain.com/public_html domain.com
ln -s ../domains/otherdomain.com/public_html otherdomain.com
I like this, John. Care to make it automatic and default :)?

Jeff

[DirectAdmin Support]

I'm going to add it to the versions system for the next release after this one coming up, although I haven't considered any issues that may arise from it, but I'll see what I can do when I get to it.

John

[walo]

Maybe http://IP/~domain.com/ is easier. We don't need to remember the username, just the domain name.

[jlandes]

You could do this automatically whenever you setup and delete new domains by using the domain_create_post.sh and domain_delete_post.sh scripts. You'd have a couple of options if you'd decide to go this route.

[Soumyanon]

I got a much easier way... Especially if you need to do it for only one (or a few) people.

Simply add the domainname to the workstations hosts file that points to the server. As soon as the webserver is serving the new virtual domain you'll be able to access it.

If you've got a few more users, you might want to setup a temporary forwarding zone in your company's DNS server that forwards to your hosters DNS (which is probably the first DNS to know about the new zone). Once you can query your providers DNS (or root-servers) with NSLOOKUP you can delete the forward.

@switch: You can do that by adding the hosters DNS-server in the list of parents or forwarders of your current DNS server.

[cyberneticos]

Hi guys,

So now we have two an extra public_html directory to deal with ?

/home/user/public_html/
/home/user/domains/xxxxxxx/public_html/

and they could actually hold different information ?

In other words, we have tons of tutorials that say "Your site ALWAYS IN public_html"

not public_html/domain.com (which would seem backwards if you confused it with the domain.com/public_html folder)

I'm glad we got rid of the sombolic link, and glad we are looking at different ways to solve the "preview more than one site" issue, but are we killing a monster and creating another one ?

(perhaps I didn't quite grasp this whole deal correctly)

[floyd]

I used http://serverip/domainname

[jlasman]

Cyberneticos, the public_html shortcut, even as a link, would have problems with any ftp account where the user wasn't ftp'ing to his/her default domain.

As for us, we've always had our welcome emails, tutorials, etc., advise our clients to ftp to the public_directory at ~/domains/example.com/public_html (of course replacing example.com with the correct domain name).

That's always worked in the past and still works now.

Jeff

[cyberneticos]

Hi Jeff,

Right, right. That's what we were talking about on the thread I start months ago. That's why I'm glad about this new move, since we do the exact same thing (give the whole path)

But what I meant in the previous post was that if you are a user and start navigating the route, you will find a public_html earlier than the one described in the tutorials (even though they finally see domain shortcuts, which is cool)

So what happens if they confuse the first public_html as the actual web-root ?

(just being picky, but also making sure we haven't ignored this scenario)

:p

[jlasman]

If they do, then they end up uploading to the wrong directory. Of course it happens from time to time.

Without that public_html directory then there's no way to easily have a temporary address for domains before they resolve.

It's a usability tradeoff.

Jeff

[cyberneticos]

Perhaps we should make the public_html that's used for IP urls a different name ?

Like /home/user/shortcuts ??

[jlasman]

Do you want to do the research on how to make that change in apache for some lookups and not others? It's not as easy as you might think. It may be doable, and I, for one, look forward to the results of your research :).

Jeff

[cyberneticos]

Hehe,

I'm not an apache expert myself, but one of my admins, is pertty close to being a genious. Let me see if I can get him in here and give us a hand :)

Cheers :o

[Webcart]

Do you want to do the research on how to make that change in apache for some lookups and not others? It's not as easy as you might think. It may be doable, and I, for one, look forward to the results of your research :).
Could you give me an example of what apache changes you have in mind?
I might be able to help ;)

[jlasman]

See post #20 of this thread (it's on page 1).

Jeff

[Webcart]

See post #20 of this thread (it's on page 1).
Jeff
I saw that post and it didn't help much :) What are you trying to achieve from a user perspective?

[jlasman]

Perhaps the poster could give you better suggestions.

Request is for using /home/user/domains for domains using domain names for resolution, and home/user/shortcuts for domains using IP#s instead of domain names for resolution.

Jeff

[Webcart]

Request is for using /home/user/domains for domains using domain names for resolution, and home/user/shortcuts for domains using IP#s instead of domain names for resolution.

How about using domain instead of IP address?

1. Register a new domain (or subdomain) that will be used to access user accounts. Let's call it EXAMPLE.COM
2. Configure wildcard DNS record for example.com so that anything.example.com or even anything.anythingelse.example.com resolves to your server's main IP.
3. Create a custom apache template virtual_host.conf (or virtual_host2.conf) where this line ServerAlias www.|DOMAIN| |DOMAIN| |SERVER_ALIASES| is replaced with ServerAlias www.|DOMAIN| |DOMAIN| |SERVER_ALIASES| |DOMAIN|.example.com
Now, when you create a new hosting account with 2 domains, for example, for mydomain.com and myotherdomain.com they can be accessed as mydomain.com.example.com and myotherdomain.com.example.com.

[fmortara]

Hi!
Can you modified the text of default message that DA send to new user with link for access to domain until the domain is resolved?

example: IP-ADDRESS/~username/domain.ext

Actually the link is: IP-ADDRESS/~username but if I follow it, the result is "page not found"

bye!
fmortara

[floyd]

Hi!
Can you modified the text of default message that DA send to new user with link for access to domain until the domain is resolved?


Yes. Interesting that the link is called "Edit User Message" in the create new user dialog box.

[BigWil]

Ok guys you threw me for a loop on this one. Didn't see it coming and it hit me like a Mac truck.

John, rather than just old_public_html_link=1 or 0 how about if we made it a switch at setup as well? Maybe "Preview Multi-Domains" and have the old_public_html setting decide what the default is? Myself I don't like using ~username at all. Opens up security risks and causes problems with our PCI Compliance testing.

The main problem with the new structure is that it breaks various scripts that don't honor that .htaccess file and/or the way the syms are setup. Specifically our Miva Empresa stopped working and after hammering on Miva Engineering for an hour I finally found the issue.

But old_public_html_link=1 works for now. Just don't stop supporting it!

BigWil

[Webcart]

Myself I don't like using ~username at all. Opens up security risks and causes problems with our PCI Compliance testing.
We don't use ~username either, but how exactly do you think it introduces security risks? Just curious.

[floyd]

Somebody views their web site with ~username. They click a link going to another web page. Now their username is in the server logs of the other server.

Another: They click a link to another web page. The other web page tracks the referrer header. Now even somebody without root access to the other server has the username.

Another: Many referrers are in webalizer stats which have been made publicly viewable and are indexed by google. Now anybody who uses google can happen upon the username.

With the username one can then launch a dictionary attack on the server to try to guess the password.

[cyberneticos]

Webalizer also shows database usernames if I recall :eek:

[BigWil]

Bugtraq ID: http://www.securityfocus.com/bid/3335
Other Advisory URL: http://www.securiteam.com/unixfocus/5WP0C1F5FI.html
ISS X-Force ID: http://xforce.iss.net/xforce/xfdb/7129
Mail List Post: http://archives.neohapsis.com/archives/bugtraq/2001-09/0103.html
http://marc.theaimsgroup.com/?l=vuln-dev&m=96297636413302&w=2
http://marc.theaimsgroup.com/?l=vuln-dev&m=96297697414539&w=2
CVE ID: 2001-1013 (see also: NVD)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-1013
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2001-1013

[switch]

How about using domain instead of IP address?

1. Register a new domain (or subdomain) that will be used to access user accounts. Let's call it EXAMPLE.COM
2. Configure wildcard DNS record for example.com so that anything.example.com or even anything.anythingelse.example.com resolves to your server's main IP.
3. Create a custom apache template virtual_host.conf (or virtual_host2.conf) where this line ServerAlias www.|DOMAIN| |DOMAIN| |SERVER_ALIASES| is replaced with ServerAlias www.|DOMAIN| |DOMAIN| |SERVER_ALIASES| |DOMAIN|.example.com
Now, when you create a new hosting account with 2 domains, for example, for mydomain.com and myotherdomain.com they can be accessed as mydomain.com.example.com and myotherdomain.com.example.com.

This is a really great idea, and would mitigate all of the problems associated with using ~username.

I came from using H-Sphere (and haven't looked back), but I sorely missed how H-Sphere handles temporary access domains. They set up a code as the third level domain for each domain in the account. They looked like:

(where the web host domain is "hosterdomain.com"):
c2984.hosterdomain.com
c8934.hosterdomain.com

Etc.

The solution above is sexier though, in that it makes more sense to the end user... to access my domain before it propagates, simply do myotherdomain.com.example.com BRILLIANT!

[Webcart]

The solution above is sexier though, in that it makes more sense to the end user... to access my domain before it propagates, simply do myotherdomain.com.example.com BRILLIANT!
Thank you :)

BTW, you can use |USER|.example.com instead of |DOMAIN|.example.com for accounts with 1 domain.

[switch]

Webcart, in attempting to test your suggestion on my system, I find that it's not working.

I've looked and looked for where DA puts the custom virtual host files that get generated based on the template... do you know where these are saved? From there I can check to see if things are happening as they should.

[Webcart]

Webcart, in attempting to test your suggestion on my system, I find that it's not working.

I've looked and looked for where DA puts the custom virtual host files that get generated based on the template... do you know where these are saved? From there I can check to see if things are happening as they should.

First, make sure you create a correct custom template. For Apache 1.3.x it's "virtual_host.conf" while for Apache 2.x it's "virtual_host2.conf".

Once you create a custom template, your changes will be applied for newly created domains only. In order to rewrite configs for already existing domains, execute

echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d
service httpd stop
service httpd start

Main Apache configuration file is /etc/httpd/conf/httpd.conf. Follow its includes to find out domain specific VirtualHost configurations.

If your server has been installed without custombuild, you will find a bunch of these lines at the end of /etc/httpd/conf/httpd.conf:
Include /usr/local/directadmin/data/users/USERNAME/httpd.conf

For custombuild install, check /etc/httpd/conf/extra/directadmin-vhosts.conf file.

[switch]

Wow, now that's what I call a helpful answer.

Since I do have custombuild installed, checking /etc/httpd/conf/extra/directadmin-vhosts.conf found me the conf file I was looking for.

I have a new box with a fresh install set up just to test this, with a (real) domain: jobtasker.com

I added an account domain "testing.com", and I do indeed see the conf file generate correctly:

ServerAlias www.testing.com testing.com testing.com.jobtasker.com

But http://testing.com.jobtasker.com/ doesn't work (page cannot be displayed). I don't think it should matter that "testing.com" isn't a real domain, right? Since for the purposes of this test it's not being accessed directly (the perfect test since this is how it would be in real life).

It might be a propagation issue though, since digging testing.com.jobtasker.com yields positive results... I guess I'll wait a few hours and try again.

[smtalk]

I think you are missing DNS record for it.

[switch]

I think you are missing DNS record for it.

Do you mean that it's necessary to set up a DNS record in the domain jobtasker.com for this to work? Webcast can you verify this?

[Webcart]

I think you are missing DNS record for it.
You are right.

But http://testing.com.jobtasker.com/ doesn't work (page cannot be displayed). I don't think it should matter that "testing.com" isn't a real domain, right?

Right, testing.com doesn't have to be a real domain.
Just make sure you follow step 2 in my HOWTO above:

2. Configure wildcard DNS record for example.com so that anything.example.com or even anything.anythingelse.example.com resolves to your server's main IP.

Regarding
It might be a propagation issue though, since digging testing.com.jobtasker.com yields positive results... I guess I'll wait a few hours and try again.

No, it's not a propagation issue. I am digging an authoritative nameserver for jobtasker.com and it doesn't return an answer either:

[root@pe2850 ~]# dig @ns1.seblin.com testing.com.jobtasker.com

; <<>> DiG 9.2.4 <<>> @ns1.seblin.com testing.com.jobtasker.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62238
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;testing.com.jobtasker.com. IN A

;; AUTHORITY SECTION:
jobtasker.com. 14400 IN SOA ns1.seblin.com. root.jobtasker.com. 2008061100 14400 3600 1209600 86400

;; Query time: 77 msec
;; SERVER: 208.115.36.202#53(ns1.seblin.com)
;; WHEN: Wed Jun 11 16:59:07 2008
;; MSG SIZE rcvd: 95

[Webcart]

Do you mean that it's necessary to set up a DNS record in the domain jobtasker.com for this to work? Webcast can you verify this?

That's correct. Rather than creating a DNS record for each domain you host on this server, create a so-called wildcard record by putting * in the A record field.

[switch]

It always helps if one actually reads ALL the directions :/

Works like a charm.

Here's another curve ball for you:

Is there a way of making this work across multiple boxes? For marketing purposes it would be nice to always use the "main" domain and have it work across boxes.

On the other hand getting a domain for each box isn't the end of the world I suppose.

What do you think?

[Webcart]

Here's another curve ball for you:

Is there a way of making this work across multiple boxes? For marketing purposes it would be nice to always use the "main" domain and have it work across boxes.

On the other hand getting a domain for each box isn't the end of the world I suppose.

What do you think?
Doable, just use a subdomain for each of the boxes and set up a wildcard for 4th level domain:
Box1: srv1.jobtasker.com, DNS record: *.srv1
Box2: srv2.jobtasker.com, DNS record: *.srv2
etc
You can access domains as test1.com.srv1.jobtasker.com and test2.com.srv2.jobtasker.com. Don't forget to update the custom templates accordingly!

I would also set up A records for srv1, srv2 etc just for the sake of completness.

[switch]

That makes a client domain with a third level domain a total of, what, sixth level? Very cool.

third.clientdomain.com.server1.hostdomain.com/

Do you know off hand where to manually set up the A record for the box domain?

Thanks for all your help, I should compile all this into a help file and post it.

[Webcart]

That makes a client domain with a third level domain a total of, what, sixth level? Very cool.

third.clientdomain.com.server1.hostdomain.com/
Either that or USERNAME.server1.hostdomain.com


Do you know off hand where to manually set up the A record for the box domain?
I am not quite sure what you are asking, but generally speaking, you create A records for a domain at that domain's authoritative nameservers.

For jobtasker.com, the authoritative nameservers are ns1.seblin.com and ns2.seblin.com (same physical server which is running DA), so if you add jobtasker.com domain to that server you can use DNS management available at user level.

Alternatively, you can manage DNS records at admin level at http://www.seblin.com:2222/CMD_DNS_ADMIN

You create "regular" A records similarly to wildcard A records, that is, by typing the subdomain name where you used to put * for wildcards.

[switch]

This is a summary of this thread: http://www.directadmin.com/forum/showthread.php?t=198&page=2 All the information here was provided by Webcart and the patient help he gave.

The idea here is to give your users who haven't propagated their domains a way of accessing them that doesn't suffer the problems with using /~username

The big advantage with doing this is that you can test sites, script installations, etc. without having to account for artificial directory depth; pretty nifty.

- Create a custom template: http://help.directadmin.com/item.php?id=2
(For Apache 1.3.x it's "virtual_host.conf" while for Apache 2.x it's "virtual_host2.conf")
cd /usr/local/directadmin/data/templates
cp virtual_host*.conf custom
cd custom

- Edit the custom template, find:
ServerAlias www.|DOMAIN| |DOMAIN| |SERVER_ALIASES|
replace with:
ServerAlias www.|DOMAIN| |DOMAIN| |SERVER_ALIASES| |DOMAIN|.example.com
where "example.com" is your domain

Alternatively, you can do |USER|.example.com instead of |DOMAIN|.example.com
But this will only allow the user to access the main domain in their account. It makes for shorter addresses though.

- Changes will be applied for newly created domains only. To rewrite old configs, execute:
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d
service httpd stop
service httpd start

- Configure wildcard DNS record for example.com so that anything.example.com resolves to your server's main IP
http://www.[yourdomain].com:2222/CMD_DNS_ADMIN
* A 1.2.3.4

(If you have multiple boxes, and you want to use the same main domain, you can set it like so: )
First set up server1 A 1.2.3.4 and server2 A 2.4.6.8 (for convenience, not strictly necessary)
server1.example.com (create a wildcard like: *.server1 A 1.2.3.4 where you use server1's main IP)
server2.example.com (create a wildcard like: *.server2 A 2.4.6.8 where you use server2's main IP)

- If you need to verify that the conf files were written correctly, check out your conf files are located in:
Main Apache configuration file is /etc/httpd/conf/httpd.conf
Look for /usr/local/directadmin/data/users/USERNAME/httpd.conf at the end of the main file
If you have custombuild, check /etc/httpd/conf/extra/directadmin-vhosts.conf for paths to the user conf files

Now users can access their domains by going to http://userdomain.com.server1.hostdomain.com/ (or just userdomain.com.hostdomain.com if you didn't do the multi-server step above)

[Webcart]

(If you have multiple boxes, and you want to use the same main domain, you can set it like so:)
First set up server1 A 1.2.3.4 and server2 A 2.4.6.8 (TOCHECK: is this necessary, or would below suffice?)

You don't have to setup A records for server1, server2 etc. It's merely a matter of convenience. If you don't set up these A records, you won't be able to refer the servers as server1.example.com, server2.example.com etc which is sometime confusing.

[Webcart]

Nice HOW-TO, btw.

One thing I would add is a section about DNS issues troubleshooting, specifically:

1. Verifying authoritative nameservers for the main domain (example.com)
2. Reconfiguring authoritative nameservers where necessary
3. Verifying wildcards A records

Here are some interesting tools that can help you with that:
http://sonic.net/support/faq/advanced/troubleshooting.shtml#zonecheck

[switch]

Nice HOW-TO, btw.

One thing I would add is a section about DNS issues troubleshooting, specifically:

1. Verifying authoritative nameservers for the main domain (example.com)
2. Reconfiguring authoritative nameservers where necessary
3. Verifying wildcards A records

Here are some interesting tools that can help you with that:
http://sonic.net/support/faq/advanced/troubleshooting.shtml#zonecheck

Great link, thanks! The howto was just copying and pasting your stuff with more details in the parts where I ran into trouble.

The howto assumes the main domain is up and running... what other situation would call for needing to verify the authoritative nameserver? (That is, if everything was working in a default DA install, then would you still need to do this?)

Regarding 3, what I did to verify the wildcards was to go to http://whatever.domain.com/ (or whatever.server1/2.domain.com), is this adequate?

Thanks, and I'll compile the howto with your replies.

[Webcart]

Great link, thanks! The howto was just copying and pasting your stuff with more details in the parts where I ran into trouble.

The howto assumes the main domain is up and running... what other situation would call for needing to verify the authoritative nameserver? (That is, if everything was working in a default DA install, then would you still need to do this?)

You can set up a domain and make sure it resolves to your server. It doesn't necessarily mean that your server responds authoritatively for this domain.

Most registrars nowadays provide a control panel for DNS management, so you have an option of either using registrar's nameservers or your own.
Regarding 3, what I did to verify the wildcards was to go to http://whatever.domain.com/ (or whatever.server1/2.domain.com), is this adequate?
I normally verify it by quering nameservers.
Once you figure out the authoritative nameserver for a domain, you can query it with a dig command jut like I did above (see my post http://www.directadmin.com/forum/showpost.php?p=132938&postcount=42).

The format is
dig @AuthoritativeNameserver something.example.com