Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.apps Subject: Re: UNIX(*)/ Linux history & system design Date: Thu, 08 May 2014 15:43:29 +0100 Lines: 62 Message-ID: <8761lgib5a.fsf@sable.mobileactivedefense.com> References: <87k3adxomn.fsf@sable.mobileactivedefense.com> <87wqear01o.fsf@sable.mobileactivedefense.com> <874n1dwvo0.fsf@sable.mobileactivedefense.com> <87zjj5vf1k.fsf@sable.mobileactivedefense.com> <87k3a0q867.fsf@sable.mobileactivedefense.com> <87zjivatio.fsf@sable.mobileactivedefense.com> <87a9atpq7y.fsf@sable.mobileactivedefense.com> <87ha51nvzw.fsf@sable.mobileactivedefense.com> <87fvkkifth.fsf@sable.mobileactivedefense.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net RPqA5Zn2Xh5EMO5WnfeVNgZ+dXdx3rrhK0pdTqW4FEcR8fado= Cancel-Lock: sha1:uzcVuJ+lJrAaAA8WQLERZX59cNs= sha1:7GEepyzVg6H4gLOHSo9vzYty1oo= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.os.linux.development.apps:728 Rainer Weikusat writes: [using the shell for application development] > An interpreter is not a hammer and 'adjusting watches' not something > programs usually do, IOW, this doesn't really communicated anything > except that you're strongly convinced that something I consider to be > 'fit for purpose' (for some purposes) because of in depth practical > experiences with Example based on something I've been working on for the past few days: An existing product includes an internal CA ('certificate authority') used for generating client and server certificates for IPsec authentication. Server certificates are renewed automatically before they expire. The 'servers' usually run inside 'Linux containers' (light-weight, OS-based virtualization) and 'the CA' either runs on the machine hosting these Linux containers or on 'some other computer on the internet', eg, (actual example) a 'container host' in the USA needs to use a CA located in the UK. In addition to 'automatic generation of certificates', this needs to support signing unsigned certificates with 'the CA certificate and private key' for HTTPS-interception (in order to do content-filtering). The same other constraints apply. The (incomplete) solution is composed of 1280 lines of C code and shell scripts with a total size of 232 lines. It is structured like this: There are two 'top-level commands', one for each functions which is supposed to be performed. Both are essentially single-line shell scripts which invoke another command passing 'their own name' as first argument, followed by any other arguments passed to them. This 'other command' is also a shell-script(*). It reads a config file via the shell 'source'-command because this is a simple way to get 'named parameters' from a file. In case parameters named SERVER and USER are defined in the config file (when the CA is hosted on another machine), this umbrella script appends .marshal to its first argument and uses this name to invoke a tool supposed to create a message using a simple, binary protocol which encapsulates the necessary information for performing the intended operation 'on the remote CA machine'. The two marshalling programs are written in C because this makes it easy to create 'binary messages' and write 'their message' to stdout. This output is piped into a ssh-process which connects to $SERVER as $USER and executes a 'CA server program' there. This 'Ca server program' is also written in C. It reads the message available on its standard input, performs sanity checks on it and then invokes 'the original top-level command' in the necessary way which 'gets us back to (*)'. If the two parameters I mentioned don't exist in the config file (the CA is local), an 'execution command name' is composed by appending .local to the first argument and the execution command is then invoked in the same way as the marshalling command was invoked for the other case. The execution command performs the requested task (which involves executing more shell scripts executing other programs and shell scripts) and writes the result to its standard output. If the CA was remote, the ssh-process will transport this output back to the originally invoking machine and write it to its standard output. In order to use this from inside a Linux container, the CA server also runs on the container host and it can be accessed by connecting to an AF_UNIX socket shared by the host and all running containers (this socket is actually serviced by a program which does nothing but that and executes 'some server program' in case 'something connected' for handling that). The same kind of messages (created by the same code) are sent to the same 'CA server program' via unix-domain socket for this case and the reply 'comes out of this socket'.