Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We don't really support the current DNS functionality, it is half-baked as is, and doesn't provide a UI. Let's spin it off into it's own contrib project, and invite interested contributors to take a stab at it.
Comments
Comment #1
helmo CreditAttribution: helmo at Initfour websolutions commentedComment #2
Neograph734I think I can find some time to work in this. I've moved the dns portions of provision and hosting into a new sandbox https://www.drupal.org/sandbox/neograph734/2760307.
This is currently a slightly modified copy of the existing dns implementation; the provision module is renamed to be hosting_dns instead of dns. And the drush command
provision-zone
has been renamed tohosting-dns-zone
. I guess that is a good basis to start with.But I need some guidance for the next questions.
Should I move all open dns issues to that sandbox?
Should I give you guys mantainer access? (And who exactly?)
Do you prefer to create the sandbox yourself?
Are there any standards (other than Drupal coding standards) I have to keep in mind?
Comment #3
helmo CreditAttribution: helmo at Initfour websolutions commentedThanks, I haven't had timer to look at the code ... but I'll try to find some time for it.
> Should I move all open dns issues to that sandbox?
Let's first upgrade it to a normal module, after that ... Yes. And lets leave this issue as a pointer to the new queue.
> Should I give you guys mantainer access? (And who exactly?)
Yes please, start with the current members listed on http://docs.aegirproject.org/en/3.x/community/core-team/
> Do you prefer to create the sandbox yourself?
No, lets just upgrade the one you have. Or do you miss the option to upgrade?
> Are there any standards (other than Drupal coding standards) I have to keep in mind?
The most relevant link would be http://docs.aegirproject.org/en/3.x/community/code-of-conduct/
Comment #4
Neograph734I have full git access and can promote it into a full module (I just thought it wouldn't offer much benefit while still under development). But I'll promote it to a full project and add the current core members in a few minutes. Then migrate the open DNS issues.
As for the code of conduct, thanks for sharing I am used to working in diverse teams so that should not be any problem :)
Comment #5
Neograph734All done.
I could not find a username matching Jon Pugh, so he is not added as a maintainer.
I guess all there is left to do before this can be closed is:
- Remove the DNS folder from hosting and provision (but you might want to scan through the code before you do so).
- Remove the DNS category from the provision issue queue.
Comment #6
helmo CreditAttribution: helmo at Initfour websolutions commentedI've now also added Jon Pugh as maintainer.
I've also made a start at removing the dns code from hosting and provision the a feature branch:
Adding it on GitLab is a bit of an experiment .. We'll see how it goes.
Comment #7
Neograph734@helmo Thanks for adding Jon. I assumed usernames didn't contain spaces...
In the meantime I have made some progress in the module's 7.x-3.x branch.
- Every site now has a DNS-tab, where one can edit and add new DNS records (these are all nodes). I believe this solves #922264: simpler zonefile editor for regular users and/or #922250: DNS: generic zonefile editor.
- The zone can be deployed from the site's view page (I will add a button to the DNS overview page later) and with
drush @site.com provision-dns-deploy
. I deliberately chose not deploy the zone on every change to prevent the SOA from overflowing.This is built on the preconception that every site is its own zone, and there are no other zones. This might be a bit dangerous, but I guess it should be enough for now. We could later add a zone content-type and position them between the site and the DNS record. However before I continue I'd prefer to receive some feedback on the work so far.
It took me quite some fiddling to read the DNS records from the hostmaster site, while drush is running in another site and I am not 100% sure I have done it right. That part is in drush/hosting_dns.drush.inc. The rest of the drush and provision code has remained untouched.
The short term roadmap contains:
- A default zone configuration (for new sites)
- A way to parse any existing
aegir_root/config/dns.d/ZONE.zone.inc
files. (However since DNS was broken anyway I don't know how necessary this is.)- A way to get rid of the
aegir_root/config/dns.d/ZONE.zone.inc
files and write the/var/aegir/config/server_master/bind/zone.d/SITE.zone
file directly based on the DNS nodes.Could you perhaps have a look at the code so far and tell me what you think?
Comment #8
helmo CreditAttribution: helmo at Initfour websolutions commentedYes, good enough for a minimal viable product.
But separating it makes al lot of sense to me. A site can have multiple domainnames as vhost alias, and within one domain there can be multiple sites... test.example.com and www.example.com. I use both these situations.
The minimal option might be to log an error if aegir_root/config/dns.d exists, mentioning the need to move/migrate the files.
Other remarks:
* My test site is not saving any zone data to either config/server_master/bind/zone.d or config/dns.d/ ... It logs 'has no zone config file' twice.
* I assume it needs sudo to reload bind, we can add something like this to the README to start with.
* The code also mentions '/etc/init.d/bind' which on Debian should be '/etc/init.d/bind9', but maybe we can replace that too with rndc reload?
Comment #9
Neograph734Thanks for having a look. I'll try to implement it in the upcoming week.
Comment #11
helmo CreditAttribution: helmo at Initfour websolutions commentedI've merged the feature/2466989-spin-off-dns branches to remove the old code from hosting and provision.
This should give us enough time before the next release to double check that nothing breaks.
In the hostmaster makefile I've added the 1.x branch of hosting_dns for now... which is the almost the same code... but should enable wider testing of 3.x
@Neograph734, Any updates you can share on the 3.x status?
@Neograph734, thanks again for working on this.
Comment #12
Neograph734A few days ago I thought it all worked, but the generated zonefile had some duplicate lines and missed some others. That is the last major issue. Once that is solved I'll publish a dev version and then there some minor UI tweaks left.
Hopefully I have something by next week.