I’ve been in the industry a while. I learned Unix and Linux administration in the mid to late 90s. I remember the old monolithic configurations, and I’ve seen the overly complex modular configurations for things we have now.

I’m going to show 2 examples below.

This is what a Kismet looks like

Fail2Ban on Debian.

As can be seen from the above copy and pastes, Kismet has 2 monolithic files. One for the server, and one for Kismet Drones. The administrator modifies the one that he needs to use. Looking at Fail 2 ban, why do we need so many different files?

I like the thought of having modules to work with, it makes it easier to make changes (I remember the days of the Mono file and compiling it for Sendmail) over the Monolithic file, but I think we have gone too far in to the modular forest. There are too many trees, and it makes finding what needs to be changed hard to do. Even when you find the right file, it’s a pain in the ass to trouble shoot problems.

Most recently I was working with Automater on Kali 2.0. It took several minutes to hunt down the proper location for the script, so I could add my VirusTotal API key. But it doesn’t seem to be working when I call the script. The other problem I had was with using text files with multiple URLs in it.

But back to the main point, there are more files in that directory (the automater python script directory) than are probably really needed.  Although I’m sure that some people could make the argument that it should be 1 xml file per lookup site, meaning more config files to deal with.

The point I’m trying to make, is we’ve gone too modular in our configuration files, and it takes a yellow legal pad and lots of notes to figure out what the calls between the configuration files are doing. We’ve traded a single large tree in the field for a redwood forest in some cases and it’s not making maintaining the programs and scripts any easier from a System Admin’s standpoint.