Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.os.linux.development.apps > #728

Re: UNIX(*)/ Linux history & system design

Show all headers | View raw

Rainer Weikusat <rweikusat@mobileactivedefense.com> 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'.

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-16 18:17 -0400
  Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-17 04:19 -0600
    Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-18 22:30 -0400
      Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-19 07:42 +0000
        Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-19 10:04 +0100
      Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-19 02:15 -0600
      Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-19 23:05 +0100
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-20 02:47 -0600
          Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-20 07:56 -0500
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 03:51 -0600
              Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-21 11:50 +0000
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 06:14 -0600
            Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-21 18:44 -0400
          Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-21 13:24 +0100
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:10 -0600
              Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-22 14:39 +0100
  Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-17 16:41 +0200
  Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 22:01 +0100
    Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:37 -0600
      Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 14:02 +0100
        Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 15:43 +0100
        Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:56 -0600
          Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 17:57 +0100

csiph-web