|Erwin Müller 30059a6786 Merge branch 'release/v0.10'||1 year ago|
|sscontrol-app-main||2 years ago|
|sscontrol-app-main-pax-test||2 years ago|
|sscontrol-app-parent||3 years ago|
|sscontrol-osgi-collectd-script-centos||2 years ago|
|sscontrol-osgi-collectd-script-collectd-5-7||2 years ago|
|sscontrol-osgi-collectd-script-debian||2 years ago|
|sscontrol-osgi-collectd-service||2 years ago|
|sscontrol-osgi-command-copy||2 years ago|
|sscontrol-osgi-command-facts||2 years ago|
|sscontrol-osgi-command-fetch||2 years ago|
|sscontrol-osgi-command-replace||2 years ago|
|sscontrol-osgi-command-shell||2 years ago|
|sscontrol-osgi-command-shell-linux-openssh||2 years ago|
|sscontrol-osgi-command-shell-openssh||1 year ago|
|sscontrol-osgi-command-template||2 years ago|
|sscontrol-osgi-debug||2 years ago|
|sscontrol-osgi-docker-script-debian||1 year ago|
|sscontrol-osgi-docker-script-systemd||1 year ago|
|sscontrol-osgi-docker-service||1 year ago|
|sscontrol-osgi-etcd-script-debian||1 year ago|
|sscontrol-osgi-etcd-script-upstream||2 years ago|
|sscontrol-osgi-etcd-service||2 years ago|
|sscontrol-osgi-fail2ban-script-0-9||2 years ago|
|sscontrol-osgi-fail2ban-script-debian||2 years ago|
|sscontrol-osgi-fail2ban-service||2 years ago|
|sscontrol-osgi-flannel-docker-script-debian||2 years ago|
|sscontrol-osgi-flannel-docker-script-upstream||2 years ago|
|sscontrol-osgi-flannel-docker-service||2 years ago|
|sscontrol-osgi-groovy-parser||2 years ago|
|sscontrol-osgi-groovy-script||1 year ago|
|sscontrol-osgi-groovy-types||2 years ago|
|sscontrol-osgi-hostname-script-debian||2 years ago|
|sscontrol-osgi-hostname-script-systemd||2 years ago|
|sscontrol-osgi-hostname-service||2 years ago|
|sscontrol-osgi-hosts-script-linux||2 years ago|
|sscontrol-osgi-hosts-service||2 years ago|
|sscontrol-osgi-inline||3 years ago|
|sscontrol-osgi-inline-linux||3 years ago|
|sscontrol-osgi-k8s-backup-client||1 year ago|
|sscontrol-osgi-k8s-backup-script-linux||1 year ago|
|sscontrol-osgi-k8s-backup-service||1 year ago|
|sscontrol-osgi-k8s-base-script-upstream-debian||1 year ago|
|sscontrol-osgi-k8s-base-script-upstream-linux||1 year ago|
|sscontrol-osgi-k8s-base-service||1 year ago|
|sscontrol-osgi-k8s-cluster-script-linux||1 year ago|
|sscontrol-osgi-k8s-cluster-service||1 year ago|
|sscontrol-osgi-k8s-from-repository-script-linux||1 year ago|
|sscontrol-osgi-k8s-from-repository-service||1 year ago|
|sscontrol-osgi-k8s-glusterfs-heketi-script-debian||1 year ago|
|sscontrol-osgi-k8s-glusterfs-heketi-service||1 year ago|
|sscontrol-osgi-k8s-kubectl-linux||1 year ago|
|sscontrol-osgi-k8s-master-script-debian||1 year ago|
|sscontrol-osgi-k8s-master-service||1 year ago|
|sscontrol-osgi-k8s-node-script-debian||1 year ago|
|sscontrol-osgi-k8s-node-service||1 year ago|
|sscontrol-osgi-k8s-restore-script-linux||1 year ago|
|sscontrol-osgi-k8s-restore-service||1 year ago|
|sscontrol-osgi-parent||2 years ago|
|sscontrol-osgi-registry-docker-script-linux||2 years ago|
|sscontrol-osgi-registry-docker-service||2 years ago|
|sscontrol-osgi-repo-git-script-debian||2 years ago|
|sscontrol-osgi-repo-git-service||2 years ago|
|sscontrol-osgi-rkt-script-deb||2 years ago|
|sscontrol-osgi-rkt-script-debian||2 years ago|
|sscontrol-osgi-rkt-service||2 years ago|
|sscontrol-osgi-scr-parent||1 year ago|
|sscontrol-osgi-script-runner||2 years ago|
|sscontrol-osgi-script-runner-test||2 years ago|
|sscontrol-osgi-services-properties||2 years ago|
|sscontrol-osgi-services-repository||1 year ago|
|sscontrol-osgi-shell-linux||2 years ago|
|sscontrol-osgi-shell-service||1 year ago|
|sscontrol-osgi-shell-test||1 year ago|
|sscontrol-osgi-ssh-script-linux||2 years ago|
|sscontrol-osgi-ssh-service||2 years ago|
|sscontrol-osgi-sshd-script-debian||1 year ago|
|sscontrol-osgi-sshd-script-openssh||1 year ago|
|sscontrol-osgi-sshd-service||1 year ago|
|sscontrol-osgi-types-app||2 years ago|
|sscontrol-osgi-types-cluster||1 year ago|
|sscontrol-osgi-types-host||2 years ago|
|sscontrol-osgi-types-misc||2 years ago|
|sscontrol-osgi-types-parser||2 years ago|
|sscontrol-osgi-types-registry||2 years ago|
|sscontrol-osgi-types-repo||2 years ago|
|sscontrol-osgi-types-run||2 years ago|
|sscontrol-osgi-types-ssh||2 years ago|
|sscontrol-osgi-utils-centos||2 years ago|
|sscontrol-osgi-utils-debian||1 year ago|
|sscontrol-osgi-utils-st-base64renderer||2 years ago|
|sscontrol-osgi-utils-st-durationrenderer||2 years ago|
|sscontrol-osgi-utils-st-miscrenderers||2 years ago|
|sscontrol-osgi-utils-system-mappings||2 years ago|
|sscontrol-osgi-utils-systemd||2 years ago|
|sscontrol-osgi-utils-tls||2 years ago|
|sscontrol-osgi-utils-ufw-linux||1 year ago|
|sscontrol-osgi-zimbra-script-centos||2 years ago|
|sscontrol-osgi-zimbra-service||2 years ago|
|test||3 years ago|
|.gitignore||3 years ago|
|LICENSE-2.0.txt||3 years ago|
|README.md||3 years ago|
|header.txt||3 years ago|
|pom.xml||3 years ago|
The idea to create a new server configuration tool was born out of a simple concideration, the configuration of each new server is always the same for the same stack, and the stack is always similar, i.e. web server, database server, email server, DNS server. So, I asked myself, what if I could just tell the computer to install and configure me the stack on the server, without for me to actually have any knowledge how to configure it. The user should be able to tell the computer to just install and setup, for example, a web-server without to have the actual knowledge how to do it. All the knowledge how to install and configure the server should be contained in the application that is installing and configures the server.
RoboBee will contain expert knowledge to install and configure the server with the needed services and applications. The expert knowledge will contain best practices in regards to security and it will updated regularly to fix bugs and to react to new security issues. To ensure a constant flow of updated expert knowledge, the OSGi technology will be used for RoboBee. OSGi container allows for seamlessly updates of the modules that contain the expert knowledge from a central repository.
There are multiple OSGi container implementations (Apache Felix, Equinox OSGi, Knopflerfish, etc.) and RoboBee will be able to run on those, but also it will provide its own container, Karaf. Based on the Karaf container, RoboBee can be installed on a GNU/Linux server just as any other application and run as a service in the background. The communication between RoboBee and the user is done via a SSH connection and the OSGi console.
The user is expected to write simple scripts in a domain specific language (DSL) based on Groovy that communicate the wishes of the user to RoboBee. A syntax must be followed that groups the server services into categories, like web server, DNS server, mail server, etc. and also have application categories like Wordpress, Drupal, Postfix, MySQL, etc. The user is assumed to have only very basic knowledge of those services and applications, for example, the user should know that the MySQL database server have an administration user, provides databases and have users that have permissions to create tables in those databases. But this kind of knowledge is not expert knowledge and is expected from the user to have. Expert knowledge in this case would be how to install the MySQL server, configure the server, create databases and users on the server and grant the users permissions to those databases.
The RoboBee (aka Simple Server Control) is about to fully configure a server by defined profiles and script files using a domain specific language (DSL). The goal of the project is to follow high level user specifications to install and configure specific services on the server. RoboBee will follow the “Ask, don’t tell”, the “Convention over configuration” and the “Principle of least knowledge” philosophies and principles.
“Ask, don’t tell”,
the user is expected to ask the different RoboBee services to install and configure the server. The services will install and configure the server according to the wishes of the user and will not expect from the user to know how to do it.
“Convention over configuration”,
the user is expected to follow the convention set from RoboBee to reduce the amount of needed configuration. Basically, to follow configuration file name conventions, and to follow protected configuration of the server.
“Principle of least knowledge”,
the user is not expected to have any expert knowledge of how to install or configure the server, all expoert knowledge is contained in RoboBee.
installs server services on the server. Server services are usually DNS server to resolve DNS names (Bind, MaraDns), Httpd server to serve websites (Apache, Tomcat), proxy server for caching (Nginx, Squid), firewall to block harmful packages, MTA (Postfix, Exim, qmail), MDA (Dovecot, Courier), etc.
configures server services on the server according to the whishes to the user. The manually edited configuration will be preserved as far as possible.
installs server applications that are run on the server. Applications are usually run on already installed and configured server services like Apache or Tomcat. Those are, for example, Wordpress, Drupal, Squirrelmail, Roundcube, Redmine, JIRA, etc.
configures the applications on the server according to the whishes to the user. The manually edited configuration will be preserved as far as possible.
the system dependent configuration is stored in profiles and can be selected without the need to modify the script files. Different systems have different commands to configure the server (SysVInit, upstart, systemd, etc.) and have different paths of the commands and configuration files.
the underlying technology of the project.
the underlying technology of the project. RoboBee is seperate the different services in bundles that can be started and updated at run-time.
the framework to parse the domain specific language of the script files.
the framework to create service configuration files.
is a configuration management for systems automation and uses Json data structures in manifests files, but also uses a declarative domain specific language (DSL) based on Ruby. It is developed by Puppet Labs
“[is a] configuration management tool written in Ruby and Erlang. It uses a pure-Ruby, domain-specific language (DSL) for writing system configuration “recipes”. Chef is used to streamline the task of configuring and maintaining a company’s servers, and can integrate with cloud-based platforms such as Internap, Amazon EC2, Google Cloud Platform, OpenStack, SoftLayer, Microsoft Azure and Rackspace to automatically provision and configure new machines. Chef contains solutions for both small and large scale systems, with features and pricing for the respective ranges.”
“is an open source configuration management system, written by Mark Burgess. Its primary function is to provide automated configuration and maintenance of large-scale computer systems, including the unified management of servers, desktops, consumer and industrial devices, embedded networked devices, mobile smartphones, and tablet computers.”
“SaltStack platform or Salt is a Python-based open source configuration management software and remote execution engine. Supporting the “Infrastructure as Code” approach to deployment and cloud management.”
“a free-software platform for configuring and managing computers, combines multi-node software deployment, ad hoc task execution, and configuration management. It manages nodes (which must have Python 2.4 or later installed on them) over SSH or over PowerShell. Modules work over JSON and standard output and can be written in any programming language. The system uses YAML to express reusable descriptions of systems.”
Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.