Async management of servers, containers, workstations...basically anything that runs an operating system.

Overview

steward

What is it ?

Command And Control anything asynchronously.

Send shell commands to control your servers by passing a message that will have guaranteed delivery if/when the subsribing node is available. Or for example send logs or metrics from an end node back to a central log subscriber.

The idea is to build and use a pure message passing architecture for the commands back and forth from nodes, where delivery is guaranteed, and where all of the processes in the system are running concurrently so if something breaks or some process is slow it will not affect the handling and delivery of the other messages in the system.

By default the system guarantees that the order of the messages are handled by the subscriber in the order they where sent. There have also been implemented a special type NOSEQ which will allow messages to be handled within that process in a not sequential manner. This is handy for jobs that will run for a long time, and where other messages are not dependent on it's result.

A node can be a server running any host operating system, a container living in the cloud somewhere, a rapsberry pi, or something else that needs to be controlled that have an operating system installed . The message passing backend used is https://nats.io

Why ?

With existing solutions there is often either a push or a pull kind of setup.

In a push setup the commands to be executed is pushed to the receiver, but if a command fails because for example a broken network link it is up to you as an administrator to detect those failures and retry them at a later time until it is executed successfully.

In a pull setup an agent is installed at the Edge unit, and the configuration or commands to execute locally are pulled from a central repository. With this kind of setup you can be pretty certain that sometime in the future the node will reach it's desired state, but you don't know when. And if you want to know the current state you will need to have some second service which gives you that information.

In it's simplest form the idea about using an event driven system as the core for management of Edge units is that the sender/publisher are fully decoupled from the receiver/subscriber. We can get an acknowledge if a message is received or not, and with this functionality we will at all times know the current state of the receiving end. We can also add information in the ACK message if the command sent to the receiver was successful or not by appending the actual output of the command.

Disclaimer

All code in this repository are to be concidered not-production-ready. The code are the attempt to concretize the idea of a purely async management system where the controlling unit is decoupled from the receiving unit, and that that we know the state of all the receiving units at all times.

Terminology

  • Node: Something with an operating system that have network available. This can be a server, a cloud instance, a container, or other.
  • Process: One message handler running in it's own thread with 1 subject for sending and 1 for reply.
  • Message:
    • Command: Something to be executed on the message received. An example can be a shell command.
    • Event: Something that have happened. An example can be transfer of syslog data from a host.

Features

  • By default the system guarantees that the order of the messages are handled by the subscriber in the order they where sent. So if a network link is down when the message is being sent, it will automatically be rescheduled at the specified interval with the given number of retries.

  • There have been implemented a special type NOSEQ which will allow messages to be handled within that process in a not sequential manner. This is handy for jobs that will run for a long time, and where other messages are not dependent on it's result.

  • Error messages will be sent back to the central error handler upon failure on a node.

  • The handling of all messages is done by spawning up a process for the handling the message in it's own thread. This allows us to individually down to the message level keep the state for each message both in regards to ACK's, error handling, send retries, and rerun of a method for a message if the first run was not successful.

  • Processes for handling messages on a host can be restarted upon failure, or asked to just terminate and send a message back to the operator that something have gone seriously wrong. This is right now just partially implemented to test that the concept works.

  • Processes on the publishing node for handling incomming messages for new nodes will automatically be spawned when needed if it does not already exist.

  • Publishing processes will potentially be able to send to all nodes. It is the subscribing nodes who will limit from where and what they will receive from.

  • Messages not fully processed or not started yet will be automatically handled in chronological order if the service is restarted since the current state of all the messages being processed are stored on the local node in a key value store until they are finished.

  • All messages processed by a publisher will be written to a log file as they are processed, with all the information needed to recreate the same message if needed, or it can be used for auditing.

  • All handling down to the process and message level are handled concurrently. So if there are problems handling one message sent to a node on a subject it will not affect the messages being sent to other nodes, or other messages sent on other subjects to the same host.

  • Default timeouts to wait for ACK messages and max attempts to retry sending a message specified upon startup. This can be overridden on the message level.

  • Report errors happening on some node in to central error handler.

  • Message types of both ACK and NACK, so we can decide if we want or don't want an Acknowledge if a message was delivered succesfully. Example: We probably want an ACK when sending some CLICommand to be executed, but we don't care for an acknowledge (NACK) when we send an "hello I'm here" event.

  • Prometheus exporters for Metrics

  • More will come. In active development.

Howto

Build and Run

clone the repository, then cd ./steward/cmd and do go build -o steward, and run the application with ./steward --help

Options for running

    -brokerAddress string
      the address of the message broker (default "0")
  -centralErrorLogger
      set to true if this is the node that should receive the error log's from other nodes
  -defaultMessageRetries int
      default amount of retries that will be done before a message is thrown away, and out of the system
  -defaultMessageTimeout int
      default message timeout in seconds. This can be overridden on the message level (default 10)
  -node string
      some unique string to identify this Edge unit (default "0")
  -profilingPort string
      The number of the profiling port
  -promHostAndPort string
      host and port for prometheus listener, e.g. localhost:2112 (default ":2112")

How to Run

The broker for messaging is Nats-server from https://nats.io. Download, run it, and use the --brokerAddress flag on Steward to point to it.

On some central server which will act as your command and control server.

./steward --node="central"

One the nodes out there

./steward --node="ship1" & ./steward --node="ship1" and so on.

Use the --help flag to get all possibilities.

Message fields explanation

// The node to send the message to
toNode
// The Unique ID of the message
data
// method, what is this message doing, etc. CLI, syslog, etc.
method
// Normal Reply wait timeout
timeout
// Normal Resend retries
retries
// The timeout of the new message created via a request event.
requestTimeout
// The retries of the new message created via a request event.
requestRetries
// Timeout for long a process should be allowed to operate
methodTimeout

How to send a Message

Right now the API for sending a message from one node to another node is by pasting a structured JSON object into a file called inmsg.txt living alongside the binary. This file will be watched continously, and when updated the content will be picked up, umarshaled, and if OK it will be sent a message to the node specified in the toNode field.

The method is what defines what the event will do. The preconfigured methods are:

// Execute a CLI command in for example bash or cmd.
// This is a command type, so the output of the command executed
// will directly showed in the ACK message received.
CLICommand Method = "CLICommand"
// Execute a CLI command in for example bash or cmd.
// This is an event type, where a message will be sent to a
// node with the command to execute and an ACK will be replied
// if it was delivered succesfully. The output of the command
// ran will be delivered back to the node where it was initiated
// as a new message.
CLICommandRequest Method = "CLICommandRequest"
// Execute a CLI command in for example bash or cmd.
// This is an event type, where a message will be sent to a
// node with the command to execute and an ACK will be replied
// if it was delivered succesfully. The output of the command
// ran will be delivered back to the node where it was initiated
// as a new message.
// The NOSEQ method will process messages as they are recived,
// and the reply back will be sent as soon as the process is
// done. No order are preserved.
CLICommandRequestNOSEQ Method = "CLICommandRequestNOSEQ"
// Will generate a reply for a CLICommandRequest.
// This type is normally not used by the user when creating
// a message. It is used in creating the reply message with
// request messages. It is also used when defining a process to
// start up for receiving the CLICommand request messages.
CLICommandReply Method = "CLICommandReply"
// Send text logging to some host.
// A file with the full subject+hostName will be created on
// the receiving end.
TextLogging Method = "TextLogging"
// Send Hello I'm here message.
SayHello Method = "SayHello"
// Error log methods to centralError node.
ErrorLog Method = "ErrorLog"
// Echo request will ask the subscriber for a
// reply generated as a new message, and sent back to where
// the initial request was made.
ECHORequest Method = "ECHORequest"
// Will generate a reply for a ECHORequest
ECHOReply Method = "ECHOReply"

NB: Both the keys and the values used are case sensitive.

Sending a command from one Node to Another Node

Example JSON for appending a message of type command into the inmsg.txt file

[
    {
        
        "toNode": "ship1",
        "data": ["bash","-c","ls -l ../"],
        "commandOrEvent":"CommandACK",
        "method":"CLICommand"
            
    }
]

To send specify more messages at once do

[
    {
        
        "toNode": "ship1",
        "data": ["bash","-c","ls -l ../"],
        "commandOrEvent":"CommandACK",
        "method":"CLICommand"
            
    },
    {
        
        "toNode": "ship2",
        "data": ["bash","-c","ls -l ../"],
        "commandOrEvent":"CommandACK",
        "method":"CLICommand"
            
    }
]

To send a message with custom timeout and amount of retries

[
    {
        
        "toNode": "ship1",
        "data": ["bash","-c","netstat -an|grep -i listen"],
        "commandOrEvent":"CommandACK",
        "method":"CLICommand",
        "timeout":3,
        "retries":3
    }
]

You can save the content to myfile.JSON and append it to inmsg.txt

cat myfile.json >> inmsg.txt

The content of inmsg.txt will be erased as messages a processed.

Sending a message of type Event

[
    {
        "toNode": "central",
        "data": ["some message sent from a ship for testing\n"],
        "commandOrEvent":"EventACK",
        "method":"TextLogging"
    }
]

You can save the content to myfile.JSON and append it to inmsg.txt

cat myfile.json >> inmsg.txt

The content of inmsg.txt will be erased as messages a processed.

Concepts/Ideas

Naming

Subject

..

Nodename: Are the hostname of the device. This do not have to be resolvable via DNS, it is just a unique name for the host to receive the message.

Command/Event: Are type of message sent. CommandACK/EventACK/CommandNACK/EventNACK. Description of the differences are mentioned earlier.
Info: The command/event which is called a MessageType are present in both the Subject structure and the Message structure. The reason for this is that it is used both in the naming of a subject, and in the message for knowing what kind of message it is and how to handle it.

Method: Are the functionality the message provide. Example could be CLICommand or Syslogforwarding

Complete subject example

For syslog of type event to a host named "ship1"

ship1.EventACK.Syslogforwarding

and for a shell command of type command to a host named "ship2"

ship2.CommandACK.CLICommand

TODO

  • FIX so it can handle multiple slices of input for inmsg.txt

  • Make a scraper that first send an EventACK, and the content of the scraping is returned by a node as a new EventACK back the where the initial event originated.

  • Implement a log scraper method in tail -f style ?

  • Implement a web scraper method ?

  • Encryption between Node instances and brokers.

  • Authentication between node instances and brokers.

  • Implement context to be able to stop processes, and message handlers.

Overview

All parts of the system like processes, method handlers, messages, error handling are running concurrently.

If one process hangs on a long running message method it will not affect the rest of the system.

Publisher

  • A message in valid format is appended to the in pipe.
  • The message is picked up by the system and put on a FIFO ringbuffer.
  • The method type of the message is checked, a subject is created based on the content of the message, and a process to handle that message type for that specific receiving node is started if it does not exist.
  • The message is then serialized to binary format, and sent to the subscriber on the receiving node.
  • If the message is expected to be ACK'ed by the subcriber then the publisher will wait for an ACK if the message was delivered. If an ACK was not received within the defined timeout the message will be resent. The amount of retries are defined within the message.

Subscriber

  • The subscriber will need to have a listener started on the wanted subject to be able to receive messages.
  • When a message have been deserialized, it will lookup the correct handler for the method type specified within the message, and execute that handler.
  • If the output of the method called is supposed to be returned to the publiser it will do so, or else it will be finish, and pick up the next message in the queue.

overview

Issues
  • Goals of this project/Consider studying Salt's architecture

    Goals of this project/Consider studying Salt's architecture

    We discussed this in Slack briefly, but this project is similar to the early days of Salt, which started out as very limited remote execution. Over time, it accumulated tons of code and features.

    I think the core Salt architecture and DSL are solid. But the implementation is a mess. It's a metric ton of Python. There are more open issues on Salt than the Kubernetes project. Even a casual user of Salt is guaranteed to find bugs.

    Still, I am experienced with it. And, right now, I need the feature set and extensibility of Salt.

    For the month of April, Pluralsight (which is worth paying for anyway, imo) is free. This course will give you a good overview that the docs (which are also a mess) cannot. https://app.pluralsight.com/paths/skills/implementing-it-automation-with-salt-open

    If you intend to reach into the higher-level config management space, it is worth it to linger on the design, and learn from the mistakes of the past.

    enhancement 
    opened by dontlaugh 1
  • Separate README from a more detailed MANUAL

    Separate README from a more detailed MANUAL

    README should be relatively short and point to other locations for more detailed guides on usage and contributions.

    Build instructions and a quick start ought to go in the README next.

    References #3

    opened by dontlaugh 2
  • README comments, suggestions

    README comments, suggestions

    Good to see this project coming along and becoming more sophisticated. You asked me to take a look at your README, and I did so yesterday. Here are my comments.

    Simple Edits

    In the "Options for Running" section, you show the fields of a struct, but this would look nicer as an actual TOML document.

    Even better: a minimal, runnable subset of your config.

    Also, I would remove the SVG from the README. It's quite low-level, and will probably quickly become out of date as the software evolves.

    Bigger Changes

    Your README has good content, but it is actually the beginnings of a website. Break up the content in your README into 2 places:

    1. The README should contain a very short intro, and then info for other developers who want to build your software. This should include a quick start guide (more on that below).
    2. Move the philosphy, architecture, and detailed stuff to /docs, which should become...

    /docs Static Site

    Start with moving part of your README content into /docs. But in my opinion you have more than enough content for a small, static website. Also, the complexity of the project demands it.

    Take a look at the spcss single-file stylesheet, and start with one big HTML page. You could write a script for markdown -> HTML.

    You have worked on this for a year, and you're clearly serious, so I think it's time. You can publish with GitHub pages for free :)

    Some ideas for headings in your site, most you already have writen:

    • Design Philosophy - what is this an alternative to
    • Architecture - deployable components
    • RPC design - the layout of NATS subjects and their meaning
    • RPC messaging schemas - ops, payloads, low-level and detailed

    Quickstart guide

    Back in the README, focus on getting someone up and running with the simplest example possible. If it doesn't cause problems for your software, consider running NATS in a no-authentication mode to make it even easier.

    The nkey stuff is fairly complicated so put that in /docs

    README is 1) basic summary, 2) how to build, 3) quickstart, 4) License, maybe some other stuff.

    One technical note

    Just a note: only use /tmp as a last resort for your sockets. Prefer XDG_RUNTIME_DIR, /run, or similar. Use a directory where permissions can be controlled.

    enhancement 
    opened by dontlaugh 1
  • Link repo to Sonarcloud analysis

    Link repo to Sonarcloud analysis

    Sonarcloud provides a lot of badges to link the repo to the analysis and highlight specific parts of the analysis.

    In other repos we highlighted the maintainability rating, the code coverage and the quality gate pass.

    Let me know what you think about this :)

    Edit: looks like this: Screenshot 2021-03-15 at 11 20 46

    opened by rafaelschlatter 2
Releases(v0.3.0)
  • v0.3.0(Jun 24, 2022)

    NB: This version is not backward compatible with earlier releases if CBOR serialization are used

    Changes/Features in this release

    ACL and Signature checking:

    • ed25519 key distribution. Each Steward instance now generates an unique ed25519 keypair which is used for signature creation and checking of the message payload. The public keys distribution are managed with the central server. Public keys are reported within the Hello messages.
    • An ed25519 Signature are now generated for payload of the messages which can be checked on the receiving node. If the signature verifies ok the message will be processed, else it will be discarded. Signature checking can be enabled without ACL checking.
    • Access Lists (ACL) for fine tuning of access based on the MethodArgs are now implemented. This can be turned on/off on each individual node, and the Access Lists are both managed and distributed from the central server if the isCentralAuth config options is set to true. ACL should be enabled together with signature checking on a receiving node.

    File copying:

    • File copying with the new Request type REQCopySrc have been implemented. When copying a source file it will be split up into user specified chunks sizes, where each chunk is sent as a separate message to the destination node. When all file chunks are transferred to the destination they will be resembled into the original file, and written to the path specified.

    Messages:

    • Added a retryWait field for finer control of message retries and ACK times.
    • Added a schedule field to messages so all request types can now be given a schedule for how often and how long to run for each individual message.
    • The directory directory field now honours the path given if prefixed with ./ or /. If no prefix it will as earlier by default be created/written to the /data folder.
    • REQToConsole can now also write to STDERR by setting the first value of the methodArgs to stderr.

    Performance:

    • Performance: The persisting to disk for the message queue for a node can now be disabled by setting the RingBufferPersistStore = false. This will give a huge performance improvement, but will also remove the ability to continue where it left off if Steward is restarted.

    Other:

    • Fix: Nats subscribers are now closed correctly if the process is closed.
    • Fix: Publishers are now closed if they have been inactive for a given period of time to save memory. They will automatically respawn if a new message to publish is received.
    • Fix: Proper stop and removal of subscriber processes.
    • Logging: Added logging to central when a message is read on the socket.
    • Logging: When failed marshaling the original message are now included in the error message.
    • Config: Renamed flag/config StartSubREQErrorLog to IsCentralErrorLogger. Default value are false.
    • Config: TOML file now included comments for each of the fields.
    Source code(tar.gz)
    Source code(zip)
  • v0.2.6(Mar 17, 2022)

  • v0.2.5(Mar 9, 2022)

    • Added timeout when no responders available.
    • Added concurrent handling of publishing messages within a process.
    • ZSTD compression now uses one go routine.
    • Added context for cancelation when publishing messages.
    • Fixed proper closing of NATS subscribe sync for all branches when publishing messages.
    Source code(tar.gz)
    Source code(zip)
    steward(17.00 MB)
  • v0.2.4(Mar 4, 2022)

  • v0.2.3(Feb 23, 2022)

  • v0.2.2(Feb 22, 2022)

  • v0.2.1(Feb 18, 2022)

    • Updated docker compose scripts and Dockerfile to reflect all flags and Go version 1.17.7.
    • Updated NATS packages.
    • Added subject and fromNode to the NATS Header and to serialization errors.
    • All logging to STDERR for processes are now turned off by default. All logs are still sent to Central Error Logger. Logging to STDERR for processes can be turned on with the new -enableDebug flag.
    Source code(tar.gz)
    Source code(zip)
    steward(16.51 MB)
  • v0.2.0(Feb 11, 2022)

    NB: v0.2.x will not be backward compatible with v0.1.0, and the reason being that the event type commandACK and commandNACK was removed. Now there is only eventACK and evenNACK. Also the data field used in the messages was changed from []string to []byte.

    New features and main changes added to v0.2.0:

    • Added flag for ringbuffer size.
    • Added compression on the messages being sent. The current supported compression methods are ZSTD and GZIP.
    • Added support for CBOR serialization of messages sent. Default will still be GOB, but CBOR can be enabled with startup flag.
    • Added flag to enable block profiling.
    • Earlier versions would append the hello messages to file on central server. Now only the last hello will be present in the file.
    • Added request type REQNone, which does nothing.
    • Added TUI (Terminal User Interface) which can be used both for creating and sending messages. The TUI is enabled with startup flag. With the introduction of TUI the old Stew client have been removed.
    • The error kernel was implemented early as a concept but did not being used. From this release the error kernel now handles all the error logging.
    • The message field methodTimeout now accepts the value -1 which will set the timeout to 200 years, and it's intended use is for REQCliCommand's which you want to run and don't stop.
    • The concept of a startup folder have been added. If we want some message(s) to always be handled by a Steward instance at startup, we can be put it into the startup folder and Steward will read and execute all the messages found in that folder. This can be used for starting a metrics scraper on a node, or that we for example want to run a bash command/script at each startup.
    • Removed the command message type, so now all messages being sent are either eventACK/evenNACK. This is a braking change compared to previous versions since the REQCliCommand earlier was of the now deprecated command type. Now it is all *event's.
    • Fixed client timeout error in REQHttpGet Handler.
    • The data field of the messages have now changed from []string to []byte.
    • Restructured some of the logic for sending messages to make code clearer.
    • Added flag -purgeBufferDB to delete the state buffer DB at startup.
    • Added a new Request type REQHttpGetScheduled that can be used for scheduled metrics scraping, or other.

    Started to implementing checking of signatures based on ed25519. This is a work in progress, and are not yet working, and should not be used yet. Flags to control if we should use signature checking or not and Central authentication server have been added, and for now the default state is false, meaning not enabled.

    More details can be found in the README.md.

    Source code(tar.gz)
    Source code(zip)
    steward(16.52 MB)
  • v0.1.15(Dec 17, 2021)

  • v0.1.14(Dec 9, 2021)

    New features and changes:

    • Implemented functionality for relaying messages via another node. The primary goal for implementing this functionality is to use use steward on for example client pc' to send messages via Central node to the final destination node.
    • Implemented a request type to transfer files between Steward instances. This also works when relaying the messages via nodes.
    • Created orchestration scripts for creating docker-compose files for both Nats-server and steward. These can be found in the scripts folder.
    • Created a mini-steward that can be used to setup and configure steward instances on nodes where steward is not yet configured via ssh.
    • Rewrote the handling the running processes map structure to simplify it.
    • Removed the REQOpCmd request type, and replaced them with more specific request types that only does one thing.
    • Other minor changes. Details can be found in the commit log.

    More details about the new functionality added can be found in the README.md file.

    Source code(tar.gz)
    Source code(zip)
    steward(14.20 MB)
  • v0.1.13(Nov 3, 2021)

    New features/changes:

    • added script for making docker-compose files
    • rewrote REQCliCommandCont pipe reading
    • added MethodArgs to max retries error message
    • created wrapper script for nats-server config
    • added mini-steward script
    • Created methods to get/update/delete values for procsMap to avoid mutex lock's spread around in the code.
    Source code(tar.gz)
    Source code(zip)
    steward(13.99 MB)
  • v0.1.12(Sep 23, 2021)

    v0.1.12:

    • Bug fix of bounds checks on the methodArgs fields used within messages.

    v0.1.11:

    • Added more correct info to error messages.
    • REQCliCommand can now be used as a reply method. Read more about the details in the readme.
    • Reply messages of type REQCliCommand allow the data from the initial Request to be embedded into the reply message for further some other action.
    • AllowedReceivers have been removed from the config since this is handled on the NATS message broker.
    • Several error messages have been added to where things can go wrong.
    • methodArgs have been added to the message field to hold the input data of the Request. Prior to v0.1.11 the data field was used for this purpose, but now the data field is only for holding the result of the request.
    • Removed the option for setting unlimited retries on a message when the value was set to 0.
    • Fixed memory leak not unsubscribing reply messages.
    • The REQN methods have been removed, and the standard Request types have the same functionality.
    • Timeout's and retries's for reply messages have been added.
    • Some more internal changes have also been done, details can be found in the commit history.
    Source code(tar.gz)
    Source code(zip)
    steward(13.99 MB)
  • v0.1.11(Sep 23, 2021)

    • Added more correct info to error messages.
    • REQCliCommand can now be used as a reply method. Read more about the details in the readme.
    • Reply messages of type REQCliCommand allow the data from the initial Request to be embedded into the reply message for further some other action.
    • AllowedReceivers have been removed from the config since this is handled on the NATS message broker.
    • Several error messages have been added to where things can go wrong.
    • methodArgs have been added to the message field to hold the input data of the Request. Prior to v0.1.11 the data field was used for this purpose, but now the data field is only for holding the result of the request.
    • Removed the option for setting unlimited retries on a message when the value was set to 0.
    • Fixed memory leak not unsubscribing reply messages.
    • The REQN methods have been removed, and the standard Request types have the same functionality.
    • Timeout's and retries's for reply messages have been added.
    • Some more internal changes have also been done, details can be found in the commit history.
    Source code(tar.gz)
    Source code(zip)
    steward(13.98 MB)
  • v0.1.10(Sep 9, 2021)

    Configuration file:

    • Default values are now working if a new Configuration field is added to the Configuration struct.
    • If new fields or flags are added in the Configuration struct during an update, the according field in the config file will also be updated to reflect the new field. Old no longer used fields will automatically be cleaned up.

    The flagSlice structure used with flags and config file to permit where to allow receiving messages from have now been replaced with a bool value flag to tell if we want to start a service. The authorization on the subject level is already present in the nats-server message broker, so we don't need it within the steward config.

    Hello message retries have been set to 1

    Error messages now have their own flag/config fields to specify ACK timeout and retries for for sending.

    Source code(tar.gz)
    Source code(zip)
    steward(13.46 MB)
  • v0.1.9(Sep 2, 2021)

  • v0.1.8(Aug 27, 2021)

  • v0.1.7(Aug 27, 2021)

  • v0.1.6(Aug 26, 2021)

    • Added more metrics.
    • Added the toNodes fields to messages, so several nodes to send to can be specified within one message.
    • Added a fileName field in messages that replaces the the fileExtension field for the naming of files to write the reply message data to.
    • Error message log files are now named by node names.
    • An option to expose the data folder via http have been added.
    • An option to start a tcp listener for receving user messages in addition to the sock file have been added.
    • configFolder flag value have now been removed. This can now only be set via the env variable env CONFIGFOLDER=./etc/ go run ..
    Source code(tar.gz)
    Source code(zip)
    steward(13.46 MB)
  • v0.1.5(Aug 18, 2021)

    • Control of all spawned processes, with controlled shutdown implemented.
    • Started implementing various metrics.
    • Implemented main tests for all request types in Steward, and errorKernel.
    • Implemented timeout's for methods.
    • Support for Nkeys when authenticating toward nats-server.
    • And more.....
    Source code(tar.gz)
    Source code(zip)
    steward(13.34 MB)
  • v0.1.4(Jun 9, 2021)

  • v0.1.3(May 28, 2021)

  • v0.1.2(May 25, 2021)

    • Added unlimited retry with 5 second intervals if no nats server available at startup
    • Set nats maxreconnects to unlimited.
    • Fixed bug where error message failed when kv store where missing
    • Added flag for reading nkey seed key from file
    • Added docker file and flag for nkey seed file
    • Changed config directories handling
    Source code(tar.gz)
    Source code(zip)
    steward(13.61 MB)
  • v0.1.1(May 12, 2021)

  • v0.1.0(Apr 16, 2021)

Owner
RaaLabs
The digital accelerator for the maritime industry
RaaLabs
Selfhosted collaborative browser - room management for n.eko

neko-rooms Simple room management system for n.eko. Self hosted rabb.it alternative. How to start You need to have installed Docker and docker-compose

Miroslav Šedivý 191 Aug 8, 2022
Distributed reliable key-value store for the most critical data of a distributed system

etcd Note: The master branch may be in an unstable or even broken state during development. Please use releases instead of the master branch in order

etcd-io 40.8k Aug 11, 2022
A feature flag solution, with only a YAML file in the backend (S3, GitHub, HTTP, local file ...), no server to install, just add a file in a central system and refer to it. 🎛️

??️ go-feature-flag A feature flag solution, with YAML file in the backend (S3, GitHub, HTTP, local file ...). No server to install, just add a file i

Thomas Poignant 492 Aug 13, 2022
Simple webhook delivery system powered by Golang and PostgreSQL

postmand Simple webhook delivery system powered by Golang and PostgreSQL. Features Simple rest api with only three endpoints (webhooks/deliveries/deli

Allisson Azevedo 18 Aug 12, 2022
CasaOS - A simple, easy-to-use, elegant open-source home server system.

CasaOS - A simple, easy-to-use, elegant open-source home server system. CasaOS is an open-source home server system based on the Docker ecosystem and

IceWhale 4.5k Aug 14, 2022
Virtual-Operating-System - Virtual Operating System Using Golang And Fyne Implemented Gallery app

Virtual Operating System Virtual Operating System Using Golang And Fyne Implemen

Arjit Kumar 0 Jan 1, 2022
Jsos - A operating system that runs system-level javascript, based on the Linux kernel

JsOS ?? An linux-based operating system that runs Javascript code at the system-

Theo Paris 1 Mar 8, 2022
Kubedock is a minimal implementation of the docker api that will orchestrate containers on a Kubernetes cluster, rather than running containers locally.

Kubedock Kubedock is an minimal implementation of the docker api that will orchestrate containers on a kubernetes cluster, rather than running contain

Vincent van Dam 72 Aug 3, 2022
Open Source runtime scanner for Linux containers (LXD), It performs security audit checks based on CIS Linux containers Benchmark specification

lxd-probe Scan your Linux container runtime !! Lxd-Probe is an open source audit scanner who perform audit check on a linux container manager and outp

Chen Keinan 14 May 16, 2022
PolarDB Cluster Manager is the cluster management component of PolarDB for PostgreSQL, responsible for topology management, high availability, configuration management, and plugin extensions.

What is PolarDB Cluster Manager PolarDB Cluster Manager is the cluster management component of PolarDB for PostgreSQL, responsible for topology manage

null 8 Dec 15, 2021
Zms - The Bhojpur ZMS is a software-as-a-service product applied in different risk management areas. It is a containment Zone Management System based on Bhojpur.NET Platform.

Bhojpur ZMS - Zone Management System The Bhojpur ZMS is a software-as-a-service product used as a Zone Management System based on Bhojpur.NET Platform

Bhojpur Consulting 0 Jan 2, 2022
Cross-platform Go library to place an icon in the host operating system's taskbar.

trayhost Package trayhost is a cross-platform Go library to place an icon in the host operating system's taskbar. Platform Support macOS - Fully imple

null 231 Aug 15, 2022
🔹 Golang module to move the terminal cursor in any direction on every operating system.

AtomicGo | cursor Get The Module | Documentation | Contributing | Code of Conduct Description Package cursor contains cross-platform methods to move t

AtomicGo 45 Jul 25, 2022
This is a Virtual Operating System made by using GOLANG and FYNE.

Virtual-Operating-System This is a Virtual Operating System made by using GOLANG and FYNE. Hello! All In this project I have made a virtual Operating

SURBHI SINHA 1 Nov 1, 2021
Built Virtual Operating System and integrated application like calculator, gallery app , weather app, and text editor.

Virtual Operating System Built Virtual Operating System and integrated application like calculator, gallery app , weather app, and text editor. Langua

null 0 Nov 2, 2021
Virtual Operating System Using Golang

Virtual Operating System Virtual Operating System Using Golang And Fyne Installation 1.Install Go 2.Install Gcc 3.Install Fyne Using This Command:- g

Ranjit Kumar Sahoo 2 Jun 5, 2022
An operating system written in Go

Let's Go OS This is a little experiment I did for myself where I tried to make an OS in the Go programming language. Go-al The goal is not to create a

Sansero 18 Jul 15, 2022
List, find and inspect operating system processes in Go

ps Package ps provides functionality to find, list and inspect operating system processes, without using cgo or external binaries. Supported operating

Tobias Klauser 14 Aug 5, 2022
Provides simple, semantic manipulation of the operating system's signal processing.

Provides simple, semantic manipulation of the operating system's signal processing.

Jayson Wang 0 Dec 15, 2021
A lightweight operating system that allows Discord channels to essentially function as terminal interfaces

KuriOS KuriOS is an lightweight operating system that allows Discord channels to essentially function as terminal interfaces. As such, all permissions

Eduard Anton 1 Dec 31, 2021
Built in user interface, LAN file transfer, such as mobile phone, computer, tablet, different operating system

Modao Built in user interface, LAN file transfer, such as mobile phone, computer, tablet, different operating systems, etc., as well as text transfer

null 0 May 7, 2022
🥑 Language focused docker images, minus the operating system.

"Distroless" Docker Images "Distroless" images contain only your application and its runtime dependencies. They do not contain package managers, shell

null 13.5k Aug 15, 2022
OperatingSys-GO - A Virtual Operating System made by using GOLANG and FYNE

Operating-System This is a Virtual Operating System made by using GOLANG and FYN

null 0 Jan 2, 2022
Vulture - A Unix Operating System Built Using Golang

vulture A Unix Operating System Built Using Golang Requirements: macOS: make sur

null 14 Jul 30, 2022
Operating system cpu scheduler algorithms

features first-come-first-serve algorithm. shortest-job-first algorithm. round-r

mahmoud reza kheyrati fard 2 Feb 11, 2022
Unik is a Go module for running Go programs as unikernels, without an underlying operating system

Unik is a Go module for running Go programs as unikernels, without an underlying operating system. The included demo is a functional Gio GUI prog

null 0 Feb 9, 2022
Take control of your data, connect with anything, and expose it anywhere through protocols such as HTTP, GraphQL, and gRPC.

Semaphore Chat: Discord Documentation: Github pages Go package documentation: GoDev Take control of your data, connect with anything, and expose it an

Jexia.com 74 May 22, 2022
DockerSlim (docker-slim): Don't change anything in your Docker container image and minify it by up to 30x (and for compiled languages even more) making it secure too! (free and open source)

Minify and Secure Docker containers (free and open source!) Don't change anything in your Docker container image and minify it by up to 30x making it

docker-slim 14.7k Aug 8, 2022
How to systematically secure anything: a repository about security engineering

How to Secure Anything Security engineering is the discipline of building secure systems. Its lessons are not just applicable to computer security. In

Veeral Patel 9.3k Aug 8, 2022