An ex-employee was caught making manual changes to db_ispconfig and now there's an MX record lost in the DB. We keep getting the error "This or a similar MX Record does already exist in this zone." I've put a band-aid on the problem by adding the MX manually after the "MAKE MANUAL ENTRIES BELOW THIS LINE!" in the bind zone file, but we would really like to fix the issue. I'm sure also that we're bound to find more errors like this. I've made a mysqldump before and after adding another MX entry, and made a diff of the two, to find the places where the database is changed in an attempt to locate the rogue records. dns_dep, dns_mx, and dns_nodes seem to be the relevant tables. From what I've seen future additions in ispconfig won't be affected by these, there's an auto-increment feature that (I believe) makes new entries clean. Also re-installation isn't really an option for us, far too many domains are here already, and I don't mind slowly fixing issues for many months. Can some one point me to more explicit documentation on the table relationships, to assist me in this? Or anything that might simplify the process? Thank you all in advance.
There is no further documenatation available. Basically the dns_dep table is the cross table that links dns_mx with the dns_soa table. Here are the relations to find your phantom record: dns_soa.doc_id = dns_dep.parent_doc_id dns_soa.doctype_id = dns_dep.parent_doctype_id dns_dep.child_doc_id = dns_mx.doc_id dns_dep.child_doctype_id = dns_mx.doctype_id
Great Thanks for the table relation mappings. I've used this post to eliminate 3 inconsistencies already, and feel much better about the process. Only about 4500 more entries to check, lol. I'm writing SQL queries to simplify the process so it's only a matter of time. Again, Thank you very much.
