cl-naive-store

In 2016 I decided to have another go at writing my own database because I wanted a database that was blindingly fast for queries but with files that are machine and human-readable. Not to mention that I have a fondness/weakness for plists. Thus cl-naive-store was born.

Like any pet project, it took on a life of its own and has become a bit of a beast (by 2022) with the best of intentions. The reason is that you can customize just about anything (you could say it was designed to be customized) and it has a lot of additional packages that can be loaded to layer on more and more functionality. The “base API“, creating, deleting, querying etc stays the same no matter how many layers of functionality you load. So you can incrementally use more and more of the possible functionality without rewriting code. That means quick proto-type code can be fleshed out later if needed.

In its simplest form cl-naive-store is a collection of plists with or without keys. In its fully loaded form, it’s a lazy-loaded, in memory, persistent, hierarchical, declaratively described, document universe with indexing and sharding thrown in for good measure. You can choose what you want to use and what not its all up to you.

Query speed was always the number one priority, though with lazy loading and sharding the loading and persistence of data runs at a respectable clip. It was also never meant to be a database that would host terabytes of data in one collection. That being said, it can deal with millions of records without too much effort and I would wager that it could deal with tens of millions if sharding is used properly.

One peculiarity of cl-naive-store is that it does not use data definitions (like table definitions found in SQL), a package for such definitions is available (thus the “declaratively described”) but the inner workings of the cl-naive-store don’t need them to load, query or persist data. Collections of data only need a name and maybe keys to function. That means what a document looks like today compared to yesterday has no consequences as far as cl-naive-store is concerned. Such power could come at the cost of your sanity if you abuse it, so a framework for data definitions is supplied but not enforced.

I think cl-naive-store is pretty well documented and there are simple but comprehensive examples.

I have been blessed to have been assisted on this project by some really exceptional people, so it has been a really fulfilling experience in more than one way.

Try it out and let me know what you think.

Advertisement

Quick Self Signed SSL Certificate with SAN

There are thousands of articles and entries in stackexchange but none of them worked for me out of the box. So after hours of battling with this issue here is my short recipe.

Create the Root Key:

openssl genrsa -out rootCA.key 2048

Self-sign this root certificate:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3560 -out rootCA.pem

Create a certificate request for the domain you want:

You need the following in your san.cnf file to use in creating the certificate request. Just create the file where you are the certificates.

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
organizationName = Organization Name (eg, company)
commonName = Common Name (e.g. server FQDN or YOUR name)
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = app.somedomain.co.za

openssl req -out app.somedomain.co.za.csr -newkey rsa:2048 -nodes -keyout app.somedomain.co.za.key -config san.cnf

To verify that the .csr has the SAN in it

openssl req -noout -text -in app.somedomain.co.za.csr | grep DNS

Sign your final domain certificate with your root certificate and makes sure the SAN ends up in the resulting certificate:

openssl x509 -req -in app.somedomain.co.za.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out app.somedomain.co.za.crt -days 3560 -sha256 -extfile san.cnf -extensions req_ext

Verify the result:

openssl x509 -noout -text -in app.somedomain.co.za.crt | grep DNS:

Verify the result once you have uploaded the certificates to your web server:

echo | openssl s_client -connect app.somedomain.co.za:443 | openssl x509 -noout -text | grep DNS:

What is left is to import your root certificate into your browser, and that is another nightmare since it works differently for different versions of chrome and different operating systems. You will have to google and try until it works, but at least you will have a certificate that you know is not at issue.

Haunted by your IPv6’s address(es) yet?

I have been following some of the hype around the IPV6 day. I must admit that I am exited about it. The possibilities are endless. Just imagine a world where every device could have its own IP address. If the issuing of those IPV6 addresses is carefully controlled it would be like issuing a unique id to every device that could possibly connect to the internet (or each other).

Add a couple of verification servers, maybe in combination with a private key and you would not have to ever remember a password again. Your car, your house, the coffee machine at work even your wife could rely on the IPV6 addresses that you carry around with you in your phone, watch or pace maker to recognise you.

Throw in some gps/proximity technology and you could be notified of a friend that just walked around the corner. You would know when the boss was close by! (No more nasty little surprises). Your girlfriend would never ever have to worry about where you are and what you are up to any more. She would know where you are, whom you are with and what you are doing at the click of a button.

Such bliss, its just … priceless!!