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?
temp adress for addon domains
- Thread starter nappa
- Start date
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?
You are right.
Right, testing.com doesn't have to be a real domain.
Just make sure you follow step 2 in my HOWTO above:
Regarding
No, it's not a propagation issue. I am digging an authoritative nameserver for jobtasker.com and it doesn't return an answer either:
Code:
[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: 95That'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.
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?
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?
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.
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.
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.
Either that or USERNAME.server1.hostdomain.com
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.
Solution Summary - Thanks to Webcart!!
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)
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)
Last edited:
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.(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?)
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
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.
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.
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
Sorry to reopen this topic.
I have setup all subdomain instructions (wildcard, htttpd confs.. ) and i can now create the USER.domain.tld that matches IP/~USER.
The problem is that, after an user account creation i can instantly access it by IP/~USER but not by USER.domain.tld.
To access by USER.domain.tld i must restart apache first. After that restart, USER.domain.tld is available.
Restarting apache is really required? Am i doing something worng? Is there any other workaround for this? Restarting apache for each account creation is really not good at all.
Thanks for you time
Francisco A
I have setup all subdomain instructions (wildcard, htttpd confs.. ) and i can now create the USER.domain.tld that matches IP/~USER.
The problem is that, after an user account creation i can instantly access it by IP/~USER but not by USER.domain.tld.
To access by USER.domain.tld i must restart apache first. After that restart, USER.domain.tld is available.
Restarting apache is really required? Am i doing something worng? Is there any other workaround for this? Restarting apache for each account creation is really not good at all.
Thanks for you time
Francisco A
nobaloney
NoBaloney Internet Svcs - In Memoriam †
Only a few minutes? None of our systems restart apache every few minutes.
Jeff
Jeff