Work in progress, so what's next?
Recent developments, deployment models and plans for the future
Time flies quickly, so I should give details of current development efforts. In 2023, I spent most of my time refactoring and improving the main codebase, but I kept forgetting about the installer.
This component now seems to need a major redesign, including improvements to its security model, validation and general logic. I'm not sure I'll be able to implement everything I have in mind, but it's what I'm most focused on at the moment. It might be that you will see minimal UI changes there but I already changed multiple things under hood.
The release date will depend on how much time I have, but I'm aiming to have it done by the end of this year. This may be the last release in the 3.x branch, as I'm currently evaluating whether to stay with the existing technology or move to a new one.
And remember, once Poweradmin is installed, always remove the installation folder as a safety precaution.
Deployment models
Also, after reviewing various issues and comments, I understood that there are different deployment models in use and some are still missing that I would like to describe. It's interesting that the way people use or want to use Poweradmin is so different and sometimes unexpected. Here I have tried to collect existing and desired models.
1. Monolithic Deployment (single machine)
All components (Poweradmin, PowerDNS and DB) run on a single machine.
Database Configuration:
Option A: Single database schema for both Poweradmin and PowerDNS.
Option B: Separate database schemas for Poweradmin and PowerDNS within the same database.
This is probably the simplest model from a deployment and maintenance perspective, the most isolated, and I usually use it for testing from time to time.
2. Distributed (split-service) Deployment
Poweradmin and PowerDNS run on separate machines; DB is on one of these machines or a third machine. Identical database configuration options available: single schema or separate schemas.
I use this deployment option locally for development and by using Docker containers. Such a model increases the complexity of installing and maintaining, but makes some parts easy to replace.
The 1st and 2nd models are generally similar and you can multiply these instances to have more isolation and control. This allows the database to remain internally visible.
3. Managing Multiple DNS Servers
In this model, Poweradmin manages multiple PowerDNS servers centrally. This sounds like an interesting option, but there's currently no support for it, just some ideas on how it could be added, but it requires changing the configuration file to be more object oriented to make life a bit easier. I think I've heard this feature request before, and there may be a related ticket or discussion.
4. Multi-Tenant Architecture
This model would use a single database with multiple schemas for different tenants. I may be wrong, but PowerDNS doesn't support this. It requires careful design for data isolation by the application and by the database (e.g. PostgreSQL has row-level security).
Models 3 and 4 can result in an externally accessible database.
Overall Risks Across Deployment Models
No matter how we set things up, we'll always have some risks to deal with. Security, data, and keeping the system running are constant concerns. As we move to fancier setups, it gets trickier to keep everything in check. But that's just part of making Poweradmin work for everyone's needs.
Future
Every day I struggle with some legacy stuff that needs to be refactored and rethought, but at the same time I don't want to break anything. From time to time I think about different options, like moving to Laravel, which would help implement features much faster, but the transition might not be so easy, so version 4 might be quite unstable. A framework like Laravel could really simplify things - built-in tools for auth, database management, and even API creation could save us a ton of time and headaches.
Another thing I have started is to integrate some of the Symfony libraries. There are days when I dream of using something completely different, like the Go language or even Rust, because I'd like to learn and try new things. I'd like to have less dependencies on the installation, just one binary that does the same functionality and can be rewritten from scratch, which would be better designed and without the legacy part that I always struggle with.
I am not sure which direction to take yet and would be interested to hear your opinions or expectations. Anyway, thank you all for your ideas, feedback and kind words.