Alice's Adventures In The Wonderland Wide Web
I keep finding new and amazing things that the creatures have been making over the past fifteen years or so, ... This is a follow-up to my post The World Wide Web is Broken.
Today's finds were sparked by my discovery that, on installing the ISC-Kea package on my Ubuntu desktop machine, I was apparently running a DHCP service, somewhere, for something, ... why?
kea-dhcp4-server.service - Kea IPv4 DHCP daemon
Loaded: loaded (/usr/lib/systemd/system/kea-dhcp4-server.service; enabled; preset: enabled)
Active: active (running) since Sat 2025-03-22 07:30:49 GMT; 4h 2min ago
Docs: man:kea-dhcp4(8)
Main PID: 2568 (kea-dhcp4)
Tasks: 13 (limit: 18957)
Memory: 9.6M (peak: 13.5M)
CPU: 1.265s
CGroup: /system.slice/kea-dhcp4-server.service
└─2568 /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
Not only that, it's also a Dynamic DNS service:
kea-dhcp-ddns-server.service - Kea DDNS Service
Loaded: loaded (/usr/lib/systemd/system/kea-dhcp-ddns-server.service; enabled; preset: enabled)
Active: active (running) since Sat 2025-03-22 07:30:49 GMT; 4h 5min ago
Docs: man:kea-dhcp-ddns(8)
Main PID: 2567 (kea-dhcp-ddns)
Tasks: 5 (limit: 18957)
Memory: 6.4M (peak: 6.4M)
CPU: 25ms
CGroup: /system.slice/kea-dhcp-ddns-server.service
└─2567 /usr/sbin/kea-dhcp-ddns -c /etc/kea/kea-dhcp-ddns.conf
That's fifteen megabytes of running code which does nothing!
Well, I loaded the software package, to read the manual page, so of course I want the service to start up and run automatically, before I've even configured it, ... But that's not what this post is about. In doing this I discovered the RESTful Interface for Kea DHCP Server. So I looked up what RESTful really means, ... and it turns out it was this guy Roy Fielding's PhD thesis (UC Irvine, 2000). Fielding was one of the developers of the Apache Web Server. The idea is that the intermediate states in a complex interaction with a server are all stored as data represented in the individual clients. This makes such services scalable because the server only has to process atomic messages and it returns a new state representation which is then held in the client and from which the client can transition to the next state by choosing which message to send back to the server. It's what Robin Milner designed pi-calculus (1991) to describe. But Fielding's thesis is about Software Architecture: "A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture. ... A software architecture is defined by a configuration of architectural elements--components, connectors, and data--constrained in their relationships in order to achieve a desired set of architectural properties."
So I started wondering how I might communicate with that kea-control-agent service ... but it isn't running, because to get it you need to install it and run it, ... and the package doesn't do that for you. Nevertheless, I can imagine it running, then I might wonder how I could use the interface to control the configuration. So I searched a bit on Google and I found this example of REST API Perl Scripts. It's part of the documentation for a service called Secret Server, which isn't a secret server, it's a server for sharing secrets. I think the idea is that as an enterprise, there are certain secrets like the usernames and passwords for database server access that need to be made available to scripts running on various different machines within an enterprise, and the secret server is a kind of enterprise-level keyring that makes these secrets available to authorised processes that need to use them. So for example, you may have a web server providing some application user interface and storing the data in an SQL backend, so the web server, when it starts, needs to know the username and password to the database server in order to be able to perform whatever actions it is supposed to perform on the database. This is all "software architecture" as Roy Fielding conceives it. Anyway, these perl scripts use a perl module called REST::Client and implement a perl module called TSS, which I think is some set of "architectural constraints" for secure web services. See https://tss-web.secodis.com. This is so that the client can securely pass the username and password to the secret server, to get the username and passwords it needs for the other services. Part of the TSS requirements are that the request be constructed according to an XML Schema defined by some company called MadCap Software. This schema itself is invisible:
# Crafts a HTTP header for providing authentication to <MadCap:variable name="global-vars.SecretServer" xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" />.
sub getHeaders {
my $self = shift;
my $headers = {
Accept => 'application/json',
Authorization => 'Bearer ' . $self->tokenResponse->access_token
};
return $headers;
}
A large part of the client code consists in lines like this:
my $secretModel = SecretModel->new(
id => $responseJson->{'id'},
name => $responseJson->{'name'},
secretTemplateId => $responseJson->{'secretTemplateId'},
folderId => $responseJson->{'folderId'},
active => $responseJson->{'active'},
items => $responseJson->{'items'},
... 30+ similar fields elided ...
responseCodes => $responseJson->{'responseCodes'}
);
return $secretModel;
}
and
package SecretModel;
use warnings;
use strict;
sub new {
my $class = shift;
my %options = @_;
my $self = {
id => undef,
name => undef,
secretTemplateId => undef,
folderId => undef,
active => undef,
items => undef,
... 30+ similar fields elided ...
responseCodes => undef,
%options
};
bless $self, $class;
return $self;
}
sub id {
my $self = shift;
return $self->{id};
}
sub name {
my $self = shift;
return $self->{name};
}
sub secretTemplateId {
my $self = shift;
return $self->{secretTemplateId};
}
sub folderId {
my $self = shift;
return $self->{folderId};
}
sub active {
my $self = shift;
return $self->{active};
}
sub items {
my $self = shift;
return $self->{items};
}
... 30+ similar fields elided ...
sub responseCodes {
my $self = shift;
return $self->{responseCodes};
}
So these are untyped, unstructured fields, the only thing that distinguishes them is their names. Is there a schema for this? I don't think so!
And now if you just think about what all this was about, it was about configuring a DHCP server on a local network. What's that? It's a think that allows machines connecting to a local area network to request their IP addresses from the enterprise.
Oh the ARCHITECTURE! It just takes your breath away! See this post from three years ago, looking over the US/Mexico border fence Programming Channel Processes and this post yesterday: Cabrera Lab Podcast #55:
Subscribe to Cabrera Lab.
Comments
Post a Comment