108.bz » CLI

Cloning DHCP reservations between Windows servers

Giuliano — Tue, 12 Apr 2011 16:01:30 +0000

Quick post to show you how DHCP reservations can be replicated between Windows servers. Why whould you want to do that? Because often, to achieve DHCP service high availability, DHCP scopes are equally divided between servers. When a client PC is connected to the network, it sends out a broadcast to discover which DHCP servers are active on that particular ethernet segment. Depending on their number, the PC will receive one or more answer, each offering an IP address. If a client is to be assigned a fixed IP, all of those offers should bear the same IP address. Hence, DHCP reservations need to be configured the same for every DHCP server in the given scope. As far as I know, this needs to be done by hand. To speed up the process, I use netsh (see Netsh commands for DHCP).

The command below will dump all of the reservations to a file named “reservations.txt”. findstr filters netsh output keeping just the info we need.

C:\Documents and Settings\Administrator> netsh dhcp server \\dhcpsrv1 scope 10.4.0.0 dump | findstr Add.reservedip > reservations.txt

Each line in “reservations.txt” should look like this:

Dhcp Server 10.4.1.1 Scope 10.4.0.0 Add reservedip 10.4.5.3 58b04576339a "pcname.domain.lan" "Reservation Comment" "BOTH"

10.4.1.1 is the IP address for dhcpsrv1, the “source” DHCP server.

Open “reservations.txt” in a text editor, check that everything is fine and substitute the source DHCP server IP with the target’s one (i.e.: 10.4.1.1 becomes 10.4.1.2), save the file and run:

C:\Documents and Settings\Administrator> netsh < reservations.txt
netsh>
Changed the current scope context to 10.4.0.0 scope.

Command completed successfully.
netsh>
Command completed successfully.
netsh>
[..]

That’s it; not a fancy trick, but it may be useful nonetheless. Just beware that, when there are thousands of clients, netsh could take a while to complete its job (especially the “dump” step)…

JavaScript for Sysadmins, again

Giuliano — Wed, 30 Mar 2011 21:09:50 +0000

Following up on the previous post, let me show you other ways to trick web application into doing what they’ve not been designed to do: saving the Sysadmin some typing and avoding errors. I’ll use JavaScript, jQuery, Greasemonkey and Perl to automate Firefox and implement a sort of dynamic form filling. Let’s start with a screencast:

The config I had to do (on a SonicWALL firewall), involves about 70 subnets, each similar to the other. Only the subnet’s addressing scheme changes, making creation of VLANs/objects/rules a repetitive and error-prone task.

What’s happening in the screencast? VLAN sub-interfaces are being automatically created without me having to type anything at all. How could that be? A simple Greasemonkey script calls a “web service” (AJAX style) fetching the needed data and filling the form for me (I just click the “OK” or “Cancel” buttons). Why this whole Greasemonkey/web service mess? Because here, as in the previous post, JavaScript code is basically being injected into a “page”. Pages (or tabs, or windows) are ran by the browser into a sandbox: they can’t exchange data between each other. Thus page A (the webapp) can’t access code/data in page B (our code). Moreover, injected JavaScript gets lost when the page is closed (think ugly GUIs where dialog windows pop up just to be destroyed shortly after). We need a way (Greasemonkey) to re-inject the code each time our page is shown and some external, long lived, entity to update/keep status (the web service).

Thanks to the HTTP::Server::Simple Perl module, building the web service is trivial. The only logic behind it is keeping track of the current VLAN’s index, iterating through each value on subsequent web service calls:

#!/usr/bin/perl
use strict;
package LameServer;
use base qw(HTTP::Server::Simple::CGI);

my @VLANS = qw(10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98);

my $COUNTER = 0;

sub handle_request {
my ($self, $cgi) = @_;

print "HTTP/1.0 200 OK\r\n";
print "Content-type:text/plain\r\n\r\n";
print STDERR "$VLANS[$COUNTER] index $COUNTER\n";
print $VLANS[$COUNTER];
$COUNTER++;
$COUNTER = 0 if $COUNTER >= @VLANS;
}

1;

package main;

my $server = LameServer->new(3333);
$server->run();

And here’s the Greasemonkey script. It runs automatically when the “add VLAN” page pops up, does the sort-of-AJAX call, uses jQuery to properly fill the form.

// ==UserScript==
// @name CurrentVLAN
// @namespace dontcare
// @require http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js
// @include https://192.168.168.168/*
// ==/UserScript==

if (window.location.toString().match(/192.168.168.168.*editInterface/)) {
GM_xmlhttpRequest({
method: "GET",
url: "http://localhost:3333/",
onload: function(response) {
window.GM_CurrentVLAN = parseInt(response.responseText);
GM_log(window.GM_CurrentVLAN);
}
});
function GM_wait() {
if(typeof unsafeWindow.jQuery == 'undefined') {
window.setTimeout(GM_wait,100);
}
else {
$ = unsafeWindow.jQuery;
}
}
GM_wait();

window.setTimeout(function() {
$('select[name=interface_Zone]').val('CZ');
unsafeWindow.setIfaceContent(); // "Zone" onchange function.
$('input[name=iface_vlan_tag]').val(window.GM_CurrentVLAN+100);
$('select[name=iface_vlan_parent]').val('X0');
$('input[name=lan_iface_lan_ip]').val("10.0."+window.GM_CurrentVLAN+".1");
$('input[name=lan_iface_ping_mgmt]').attr('checked', true);
}, 1000);
}

I built similar scripts to create static ARP entries and routes. Another one took care of firewall symbolic objects (names) but, as that part of the config is itself carried out by AJAX (in a non reloading window), I didn’t need Greasemonkey, just Firebug.
No kidding, the above tricks saved me half a day of tedium…

FireQuery fun

Giuliano — Sat, 19 Mar 2011 22:09:44 +0000

Or how to toggle a thousand checkboxes clicking none.
Have you ever wondered that jQuery may be relevant to your everyday sysadmin job? It is: web-based GUIs proliferate and the Command Line is sooo nineties (this one’s not mine)…
Working on a SonicWALL/Aventail SSL VPN box, I was asked to simplify how permissions were mapped to Users. What a User could or couldn’t do, was defined at the User level. Ok, let’s just:

Create an A/D group for each role/profile.
Configure permissions (rules, resources access, …) on various Communities (Aventail parlance for roles/profiles).
Put the right Users into the right A/D group.
Cleanup: generally, each Community should just have A/D groups assigned to it. Get rid of unnecessary Community memberships.

First three tasks were easy (thanks also to the DS* commands). The fourth, uhm:

Removing members from a Community means unchecking each User. In my case, more than one thousand clicks and a beginning of carpal tunnel syndrome. At page three I started to think about a less saddening way.

FireQuery is a Firefox extensions that let’s you “inject” jQuery into any webpage. Here’s what I did:

Went to the page depicted above (the one that let’s you assign members to a Community).
Launched Firebug.
Inspected the DOM and noticed that each of the checkboxes value begins with “AV”.
Used the debugger to see what’s going on when checking/unchecking members. Nothing really strange: just a bit of JavaScript to highlight a row depending on its checkbox’s status.
Hit the jQuerify button. FireQuery is needed because Aventail’s web-based GUI doesn’t use jQuery.
Went to Console, typed the JavaScript one-liner below and hit Run

$('input[value^="AV"]').attr('checked', false)

which translates to: use jQuery to select all of the checkboxes whose value starts with “AV”. Uncheck the selected checkboxes.

See? No useless clicking: a GUI has been CLI-fied.

Using the CLI to manage Windows DNS servers

Giuliano — Mon, 24 May 2010 14:16:46 +0000

(This, for once, is going to be quick.)
Did you know about the Dnscmd.exe command? Read about it here and here. It’s the command-line/DOS prompt way to configure Microsoft’s DNS servers… If you need to create many zones/records at once, it saves you lots of clicks.
Here’s how to add six DNS zones (same domain name, different TLD). With the /DSPrimary option, the zone will be stored into Active Directory (rather than a file).

dnscmd /ZoneAdd domainname.bz /DSPrimary
dnscmd /ZoneAdd domainname.biz /DSPrimary
dnscmd /ZoneAdd domainname.com /DSPrimary
dnscmd /ZoneAdd domainname.eu /DSPrimary
dnscmd /ZoneAdd domainname.net /DSPrimary
dnscmd /ZoneAdd domainname.org /DSPrimary

And here’s how to add the same “A” record (named “www”) to each of the zones created above.

dnscmd dns-dc-hostname /RecordAdd domainname.bz www A 10.0.0.123
dnscmd dns-dc-hostname /RecordAdd domainname.biz www A 10.0.0.123
dnscmd dns-dc-hostname /RecordAdd domainname.com www A 10.0.0.123
dnscmd dns-dc-hostname /RecordAdd domainname.eu www A 10.0.0.123
dnscmd dns-dc-hostname /RecordAdd domainname.net www A 10.0.0.123
dnscmd dns-dc-hostname /RecordAdd domainname.org www A 10.0.0.123

As you may have guessed this is the typical scenario where you’ve got to re-create some external zones, on the internal DNS servers. That’s needed in order for the internal hosts to reach some server with the “public” DNS name, but the private IP.
For the sake of completeness, let me also mention that you could achieve the same effect by leaving DNS as it is, and configuring “loopback NAT”/”double NAT” on the router/firewall. E.g.: an internal Host wants to reach an internal Server, given it’s public hostname, mapped to a public IP address. It asks the (possibly internal) DNS to translate the name. DNS doesn’t know the zone, it forwards the query to an external DNS Server, obtaining a public IP address that it hands back to the Client. Since its address is non-local, while trying to talk with the Server, the Client sends packets to its default gateway (possibly the router/firewall). The firewall matches the server’s public IP addresses, substituting it with the right private one. It also changes the source IP, swapping the Client’s with the firewall’s LAN address. This way Client and Server are actually communicating through the firewall, even if they’re both internal hosts. And the Server can’t tell Client A from Client B since every connection to it comes from the firewall’s IP address. That’s the main reason why I prefer duplicating the public DNS zones on internal DNS servers, with private IP addresses: you avoid routing internal traffic through the firewall, and avoid NAT where there shouldn’t be any.