DNS Management -- Remote HTTP API/Command Line API

Hi there folks,

Firstly, pardon the newbie if this has been covered; I’ve parsed through the docs and tried to find what I’m looking for in the forums, but I thought somebody might know the answer more quickly than I can dig it up.

I’m looking at integrating VirtualMin with my billing system (developed in-house) so that my clients can alter their account settings from within my system, which may or may not be located on the server their websites are being hosted on.

The main questions I have are related to DNS management (A records, MX records, CNAMEs, etc.) and SSL certificate installation. I understand the latter just arrived in the latest release, but I can’t find any clear way in the docs to manage the BIND hosts files through the remote API or CLI. Maybe there’s another common way to manage BIND remotely that I’m not familiar with, but I definately need to be able to manage such records from my system if this will work in the long run.

I’m only working with the GPL version of VirtualMin for now, and I know some functionality is only available with the paid product. I just want to make sure that it will allow me to do what I need before I invest in it. I’m trying to get away from Plesk, but I want to be able to reproduce all of the functions my customers have gotten accustomed to if I can.

Thanks for any help or links to what I’m looking for.

Hmm, well, I had initially thought that modify-dns.pl might do the trick:


But, it appears that more-so deals with SPF records.

What I might suggest is filing a feature request in the Bugs and Issues tracker (link below). Jamie will see that, and either point us in the right direction if we’re just overlooking it, or offer how feasible it is to add such a feature.

Yeah, I noticed that.

Does Webmin have any sort of API to connect remotely? I got the impression there was some sort of XML interface, but it centered around Perl, and I’m more of a PHP/Python guy, so I got in over my head pretty quickly. Even if it’s not a feature that can be implemented easily in production, I might be able to hack out a module of my own if I can decipher the basics of the API, but I didn’t want to start reinventing the wheel if it was already out there or if it would be on its way soon.

I posted a feature request, and looks like Jaime’s going to put it in the next release. How’s that for service for ya?

Thanks for the help!

Indeed, Jamie is pretty cool that way :slight_smile:

Thanks for the feature request though, that’s how this stuff gets better.

Have a good one!

I got the impression there was some sort of XML interface, but it centered around Perl

There is and XML-RPC interface that gets access to all of Webmin (including Virtualmin). It is extremely low on documentation, and you pretty much have to read up on the Perl functions (which are slowly but surely being converted to POD so the API docs can be put up on the web rather than in the ghetto of only being visible in the module library).

So, it is accessible via PHP or Python (or anything else that can speak XML). It’s not nearly as easy to use as the command line and remote HTTP API that ships with Virtualmin. It’s much lower level, as the Webmin module libraries are usually quite low level–it access things at the same level as module code doe, so you can import the bind8-lib.pl via XML-RPC, but you can’t usefully do anything with the higher level functions within the module. That’s probably not a very clear description if you’ve never done any Webmin programming…Webmin has its own module system (invented before Perl got objects and such). A module is a combination of a modulename-lib.pl file, which contains a handful of parsers and writers and such for the configuration files of the service, and a bunch of cgi files that server the UI and call the low-level functions to “do stuff”.

More programmer-friendly interfaces are something we’ve been working on for a while. Jamie just merged the Virtualmin Pro command line and remote tools down to GPL yesterday, so those will be converged going forward–should lead to more usage and more documentation.