Added the possibility for assigning users to an account, providing access to all domains associated with that account automatically.
This makes management easier, especially in installations with lots of domains and lots of managing entities.
The old style per-domain permissions are still there and working as usual. The two methods work perfectly side-by-side and are analogous to "user" (per-domain) and "group" (account) permissions as we know them from Active Directory and such places.
(cherry picked from commit 34fbc634d2848a7f76dc89a03dd8c0604068cc17)
This adds initial support for accounts a concept meant to signify a customer, a department or any other entity that somehow owns or manages one or more domains.
The purpose is to be able to assign an account to any number of domains, making it easy to track who owns or manages a domain, significantly improving manageability in setups with a large number of domains.
An account consists of a mandatory, unique `name` and optional `description`, `contact` name and `mail` address. The account `name` is stripped of spaces and symbols, and lower cased before getting stored in the database and in PowerDNS, to help ensure some type of predictability and uniqueness in the database.
The term *account* is actually taken from the PowerDNS database, where the `domains.account` column is used to store the account relationship, in in the form of the account `name`.
The link to a domain in PowerDNS-Admin is done through the `domain.account_id` FOREIGN KEY, that is linked to the `account.id` PRIMARY KEY.
(cherry picked from commits 4e95f33dfb0676d1c401a033c28bca3be7d6ec26, da0d596bd019a339549e2c59630a8fdee65d0e22, 7f06e6aaf4fd8011c784f24b7bbbba5f52aef319, 1c624dad8749024033d1d15dd6242ca52b39f135)
The options for SOA-EDIT-API included was actually the options used for SOA-EDIT, which is a very different beast.
Those options have been swapped out for the options allowed in SOA-EDIT-API and SOA-EDIT-DNSUPDATE.
With refactoring the get_reverse_domain_name
function, we change the reverse domain checking to
a reverse order. In this way we check the lowest class
(more specific) reverse zone first. When an existing domain found we use it to create the reverse PTR records. If no one existing can be find, The most specific address will be used.
In this way the reverse it is possible to create
auto-ptr records in higher ip classes (eg. class A in IPv4).
Only works with existing higher class domain.
If is isn't find higher class domain, create a lowest class domain, and add there the reverse PTRs.
Also works with IPv6!
iteratively checking of existing domains with higher IP
classes. When this function find an existing higher class
domain return with that reverse address. eg. 192.in-addr.arpa
If it is not find any existing higher class domain it returns with the lowest class domain reverse domain name. eg, 39.168.192.in-addr.arpa
With this modification it can be possible, to detect
custom IP classes for domains. It just need to
modify the multipler in regexp {4} or {1}.
In the future it will works automaticly, but not now
Because this bug domain deleting isn't possible when
a domain specific attribute is set (eg. dyndns).
This modification delete domain settings before domain
deleting.
First of all we cut all of dot char at the end of the rstring and than we put one there.
this way we make sure that our string contains just
one dot at its end.
When a record successefully added to a domain, it will
try to create a reverse lookup domain for that record.
In this point we aren't create the records yet...
This function will create automatically the reverse lookup
domain for the applied record of a Domain.
And also grant the privileges from the original Domain.
If we try to check if a domain exists, and we fetch with
get_id_by_name() function it will return with None if
the domain not exists, and return the id when yes.
Depending on the database backend the string might not be UTF-8 encoded.
This makes sure that the hashing function works regardless of that.
Signed-off-by: Felix Kaechele <felix@kaechele.ca>
This commit adds a new table to store per-domain settings, so a database
migrate/upgrade will be required. The first use-case is to allow dyndns
updates to create a record if one doesn't yet exist but only if the
per-domain setting is set.
This change populates the 'role' and 'setting' tables to their initial
states via the create_db.py script which removes a step from the initial
setup. We now also search for roles instead of expecting them to be at
certain IDs.
