Created
June 8, 2016 23:14
-
-
Save kilburn/2974f81d3d0189ebdb4ed45f2b93d4ee to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# i-MSCP Listener::Named::NotifySecondary listener file | |
# Copyright (C) 2016 Marc Pujol <[email protected]> | |
# | |
# This library is free software; you can redistribute it and/or | |
# modify it under the terms of the GNU Lesser General Public | |
# License as published by the Free Software Foundation; either | |
# version 2.1 of the License, or (at your option) any later version. | |
# | |
# This library is distributed in the hope that it will be useful, | |
# but WITHOUT ANY WARRANTY; without even the implied warranty of | |
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | |
# Lesser General Public License for more details. | |
# | |
# You should have received a copy of the GNU Lesser General Public | |
# License along with this library; if not, write to the Free Software | |
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA | |
# | |
## Notifies a secondary server using using the bdns protocol | |
# | |
package Listener::Named::NotifySecondary; | |
use vars('$serial'); | |
use strict; | |
use warnings; | |
use iMSCP::EventManager; | |
use Data::Dumper; | |
use LWP::UserAgent; | |
use HTTP::Request; | |
# | |
## Configuration settings: change this! | |
# | |
my $port = 54515; # Port where bdns is listening | |
my $verify = 1; # Whether to validate the server's certificate or not | |
my $username = 'client1'; # Bdns username | |
my $password = 'password1'; # Bdns password | |
# List of secondary servers to manage | |
my @secondaries = ( | |
'your.secondary.server' | |
); | |
# | |
## Actual listener, do not modify above this line unless you know what you are doing | |
# | |
$Listener::Named::NotifySecondary::serial = 1; | |
sub out { | |
my ( $file, $aoh_ref ) = @_; | |
open my $fh, '>', $file | |
or die "Can't write '$file': $!"; | |
local $Data::Dumper::Terse = 1; # no '$VAR1 = ' | |
local $Data::Dumper::Useqq = 1; # double quoted strings | |
print $fh Dumper $aoh_ref; | |
close $fh or die "Can't close '$file': $!"; | |
} | |
sub notify { | |
my ($action, $zone) = @_; | |
for my $secondary(@secondaries) { | |
my $ua = LWP::UserAgent->new(ssl_opts => { verify_hostname => $verify }); | |
my $req = HTTP::Request->new(GET => "https://$secondary:$port/$action/$zone"); | |
$req->authorization_basic($username, $password); | |
my $res = $ua->request($req); | |
if (!$res->is_success) { | |
print $res->content; | |
} | |
} | |
} | |
iMSCP::EventManager->getInstance()->register('afterNamedAddDmn', sub { | |
#out('/tmp/dump.'.$$.'.afterNamedAddDmn', \@_); | |
my $data = shift; | |
if ($data->{"CTM_ALS_ENTRY_ADD"} || $data->{"CTM_ALS_ENTRY_DEL"}) { | |
return 0; | |
} | |
notify('add', $data->{"DOMAIN_NAME"}); | |
0; | |
}); | |
iMSCP::EventManager->getInstance()->register('afterNamedDelDmn', sub { | |
#out('/tmp/dump.'.$$.'.beforeNamedDelDmn', \@_); | |
my $data = shift; | |
notify('remove', $data->{"DOMAIN_NAME"}); | |
0; | |
}); | |
1; | |
__END__ |
Notice that the master is always automatically assumed to be the IP from which the requests are originating. Hence, you need to make sure that you use the proper interface when sending requests to bdns.
Well, if you follow my recommendations, such sentence would become obsolete. For Instance, in i-MSCP, IP are assigned per resellers/customers. Thus, I'm wondering how you could change the request originating IP through the i-MSCP listener. It is easy to retrieve customer IP but for the rest (setting originating IP on LWP) ... Also: Think that some are behind NAT and so on...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@kilburn
Question:
How the daemon is aware of the master DNS IP? As I see here, you make a simple notification (add|remove with a domain name). Thus, I presume that the daemon must be preconfigured somewhere to known DNS server info. Or do you simply pull them through AXFR ?
It would be great to have the daemon able to receive more details about master DNS server and actc accordingly:
For instance: Listener send a JSON payload such as:
My thinking here is that your daemon should know nothing about master DNS server. It should act according received data only.