Hi there! I used the Multiserver Tutorial for my Amazon Environment (Ubuntu 11.1). Now got some DNS trouble. In my opinion the bind services can not do any entries in named.conf-files with ispconfig. Check out jobqueue: Code: 2011-11-13 21:08 ns1.codag.net Update dns_rr 2011-11-13 21:08 ns1.codag.net Update dns_soa 2011-11-13 21:06 ns1.codag.net Update dns_rr 2011-11-13 21:06 ns1.codag.net Update dns_soa I added 2 dns zones "codag.net" and another one. Entries in db tables are ok! But in /etc/bind are just following files: Code: bind.keys db.255 db.root named.conf.local slave/ db.0 db.empty named.conf named.conf.options zones.rfc1918 db.127 db.local named.conf.default-zones rndc.key And as you can see in named.conf.options Code: Graph this data and manage this system at https://landscape.canonical.com/ options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. // forwarders { // 0.0.0.0; // }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; }; That can't be right!? Seems like there couldn't be made any zone-files?! Does anybody had allready the same problem? Thank you for help! Marc
here the printscreent from my records ns1.codag.net -> *.*.173.157 ping codag.net -> *.*.173.157 ping web.codag.net -> *.*.173.157
Please check if your ISPConfig server is authoritative for your domain. You can find that out by running Code: dig ns yourdomain.com
As you can see, entries are set: Code: mb0:~ Marc$ dig ns codag.net ; <<>> DiG 9.7.3-P3 <<>> ns codag.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;codag.net. IN NS ;; ANSWER SECTION: codag.net. 86367 IN NS ns2.codag.net. codag.net. 86367 IN NS ns1.codag.net. ;; ADDITIONAL SECTION: ns1.codag.net. 86367 IN A 107.22.173.157 ns2.codag.net. 86367 IN A 107.22.173.157 ;; Query time: 15 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Mon Nov 14 20:41:01 2011 ;; MSG SIZE rcvd: 95 At the moment i use just 1 dns server. -> 107.22.173.157 This problem should be ok now. But the main problem is still "alive". Jobqueue is still full and dns couldn't be done in /etc/bind...
Thanks for help so far! but does anybody have further ideas?.. Are there any specific system rights to be customize? setted up servers couple of times!
Most likely a problem with mysql permissions. Have you set the IP addresses and FQDN hostnames as described in the multiserver tutorial in the /etc/hosts files of all servers that belong to the cluster? Setting them in dns is not sufficient as mysql authentication will fail then.
hi till yes i've set fqdn and ip's like it's described in tutorial. But of corse I should try connection from dns to db. Can you tell me how i can see the way the dns connects to the db-server? i there a specific ispconfig config-file?
You can find the login details for the master database in the file /usr/local/ispconfig/server/lib/config.inc.php (dont mix up with local login details which are in the same file) on the slave server. Use this login details to connect from the slave to the master with the mysql command. example: mysql -h masterhostname -u ispmasteruser -p ispmasterdbname
unfortunately i dont have ssh access from my office. but as you can in phpmyadmin dns_rr entries are set: can we say thats a certificate that dns->db works? or can we just say master(web)->db works? it doesnt make sense when we think to the update dns_rr jobqueue entry :S
Is this the databse of the slave or the master? If thats the local mysql DN on the slave, then this means that the mysql connection works. if its the master db, then this does not indicate anything for the slave.
Ah, i'm sorry for missing info! I'm not sure if i understand what you mean with master/slave...does it mean ispconfig 1xmaster + 3x slave? like my configuration: .162.214 -> www.codag.net -> master .173.115 -> mail... -> slave .173.157 -> ns1+2...->slave .173.xxx ->db...->slave considering to *.*.162.214/phpmyadmin which is the web-server who's the master (if i understand you correctly), then this is must be master database because phpmyadmin is shows server as localhost.
Till, thank you so much! This was the issue! In "/usr/local/ispconfig/server/lib/config.inc.php" User ispcsrv4 was entered with a hash password!! which dindn't work with mysql -h masterhostname -u ispmasteruser -p ispmasterdbname. So I tried user "root" and password i've set in installation and it worked! changing the password of ispcsrv4 in phpmyadmin neither worked - most possible beause of global rights are set to "usage". how can i fix that?, the other way is using root on every server.
Please undo that, you just opened a huge security hole in your cluster. With your changes, a hacker that get access to a single node can now take over all servers of your cluster. Never store the root password of the master server on any of the slave servers. The password in that file was the cleartext password, it was not a hash. Please restore the original password as it was in that file. The problem you describe happens when the hostnames in /etc/hosts are not set correctly on all nodes. Please set the hostnames exactly as decsribed in the multiserver guide in /etc/hosts, e.g. 192.168.0.111 web.yourserver.tld and not 192.168.0.111 web.yourserver.tld web on all nodes incl. the master server. It is not enough that the hostnames are registered in DNS, the hosts entrys are still required. Afterwards run a ispconfig update on every slave and choose to reconfigure permissions in the master database when the updater asks you.
hooly! i allways made 2 spaces beween ip and hostname!! will never do that again! thank you so much for helping!
That should not make a difference. You can have one or more spaces or tabs between IP and hostname. The difference is that the second example defines two hostnames for the IP (web.yourserver.tld and web) which can confuse mysql, so the right way for this setup is to define only the fqdn like this: 192.168.0.111 web.yourserver.tld