The following schema apply to SQLite, MySQL and PostgreSQL.
The supplied file /doc/config.sql for client configuration contains this scheme:
CREATE TABLE hosts ( hostname varchar(255) NOT NULL, mac varchar(1024) DEFAULT NULL, class varchar(255) DEFAULT NULL, address varchar(255) DEFAULT NULL, prefix varchar(255) DEFAULT NULL, id varchar(255) DEFAULT NULL, duid varchar(255) DEFAULT NULL, PRIMARY KEY (hostname) );
If client configuration should be read from a database it should be created with above scheme. A client can have these attributes:
- hostname (required)
- mac – more than one have to be separated by spaces
- address – more than one have to be separated by spaces
- prefix – only if needed, will work without too
- id (0-FFFF) – will be used for one octet of IPv6 address
- duid – more than one have to be separated by spaces
Depending on planned identification and address generation some fields have to be filled respectively.
If you already store your clients in a database create a view for translation or glue your database and the one used for dhcpy6d with some scripting.
A database created with the needed schemas is used to store leases and the MAC-LLIP-mapping. This data is completely generated by dhcpy6d.
This database could be used for clustering (not yet implemented) and as replacement for DHCPv6 relaying. Due to being MAC-aware only on local network segments relaying is not possible. Using several dhcpy6d servers which share information in one central database might be a workaround therefore.
Since version 1.0 the needed database schemas is created automatically. The ones in /dhcpy6d/storage/schemas.py are used therefore.