Tlaloc

Chapter 1.2 : Basic objects

The local node environment provides a set of `PHP` classes available to any node script executing under a `PHP` environment.

The reasoning behind the use of `PHP` as the scripting engine is thus;

• PHP is well documented
• PHP is a language of choice for many
• What SysAdmin dislikes a C-like language where they can feel comfortable ?
• PHP's execution overhead and performance is actually better than Ruby, Python or Java (I did the math)
• PHP's script are easier to debug in a console window
• Its easy enough to provide hooks into other languages at execution time
• The Unix command prompt is very accessible to `PHP` scripts
• The scripting environment offers something much bigger than I could program as a parser mechanism. ;)

Idempotency

This is a big word, centered around a philosophy with which the reader must come to grasps with, in order to perfectly understand the way things really work with Tlaloc.

Basically, idempotency means that every action can be repeated any number of times and the results will remain unique, stable or simply not fuck up the machine. So for example; starting a MySQL server 3 times in a row would result in it getting started only once, and its flow of operations not be bothered by an additional 2 shutdown/restarts procedures.

Another example is creating the user foo three times in a row; the result would be that the passwd file would contain only 1 foo entry, while the other 2 would simply ignore the request and return true to the operating script.

What this means is that executing object methods would return a result that in an idempotent world would mean success if nothing was done. ;)

Using the user creation example from above, it means the calling script would get a success on each iterative User->Create('foo'), even if the user already exists.

So, with that said, on with the available objects.

Objects are summarized in this page, the actual implementation details and usage are part of Chapter 2.

File class object

Used for manipulating files (like Unix /etc/* config files). It allows the creation of files, adjusting properties such as the owner, group or permissions and synchronizing files from repositories to the local node. It's also meant to manipulate the content of unix config files, with 2 special functions to manipulate the content of variables, and other functions to add or remove lines within config files, using Grep pattern matching.

Package class object

Allows the installation of software packages, according to the node's unix flavour and package preferences. Its basically an encapsulation of the Yum and RPM of Linux and Pkg_* utilities on OpenBSD, to make it simpler to script.

Service class object

Used to manipulate the local node's installed services. Mostly rc.d systems, as used on Linux and OpenBSD since version 4.1. It also encapsulates the rc system to make it easier to play with from the scripting interfaces.

In general this class is apart from Package because their uses are not necessarily inclusive of one another. It also makes it possible to start, stop and reload services from your scripts. :)

User class object

Another encapsulating class around the usual Unix user management interfaces. Meant to allow for the creation, removal and verification of unix user accounts.

QueryDB class object

Currently tuned to MySQL/MariaDB (all versions), this object is a simple DB wrapper which can easily be ported to other databases. We use it along with the implementation of the current Message Queue system to relay messages through a central database system.

MessageQueue class object

One of our latest additions, this class allows for the processing, parsing, securing and sending of complex chained actions. Messages are queued on a priority basis, and can be distributed to a multitude of nodes, as required within the programming parameters.

Our Wolfpack integration allows Nodes to issue messages for other Nodes, even to create and rip clustered Nodes.

ServerStats class object

Well, this one ain't new, but it's been lately revamped. Totally not inspired by the competitors, but rather, inspired by the OpenBSD *ctl kernel modules which made integration such an obvious step.

The class allows to properly size the hardware of a Node (porting required to other OSes, currently it supports OpenBSD) and report the findings to an Asset database schema.

The Asset database schema is also included in the software distribution, along with a whole management web interface built in PHP. (Probably for a limited time, as we all gotta make some money somewhere.)

Crypto class

I dare say we are the forerunners of crypto implementations in Message Queueing systems, and accross file storage systems. Our methodologies have evolved under constant hacker pressure on the Internet, and with our efforts to protect hosting infrastructure, our encryption methodologies have also greatly improved. This latest revision is greatly influenced by the works of the Monero digital currency Research Group, the crypto-currency community in general, and a good friend of mine, Matt S-F. who's been a great eye-opener to proper crypto in my younger years.

Cloud Agent

Not really a class object, but rather a sort of Cron job stub which can be used to extend or inspire the cluster programmers out there.

It's current job (out of the box) is to run a regular check on the Message Queue for any pending jobs, and dispatch the job to the appropriate script handler.

Part of the Agent registration process is the reconnaissance of the hardware (through the ServerStats object), any bootstrapping variables that might indicate a preference for its role, it's hostname and registering its capabilities (which can be overridden/tuned through the web administration interface of course)