A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/tank0226/SaltGUI below:

tank0226/SaltGUI: A web interface for managing SaltStack based infrastructure.

A new open source web interface for managing a SaltStack server. Built using vanilla ES6 and implemented as a wrapper around the rest_cherrypy server.

The version tagged release is the latest released version. The version master should be fine, but it may contain changes that are not yet in these release-notes.

Quick start using PAM as authentication method 
external_auth:
  pam:
    saltuser:
      - .*
      - '@runner'
      - '@wheel'
      - '@jobs'

rest_cherrypy:
  port: 3333
  host: 0.0.0.0
  disable_ssl: true
  app: /srv/saltgui/index.html
  static: /srv/saltgui/static
  static_path: /static

Note: With this configuration, the saltuser user has access to all salt modules available, maybe this is not what you want

Please read the Permissions page for more information.

SaltGUI supports the following authentication methods supported by salt:

Since pam by itself is already very powerfull, that one is mentionned as standard. By default, it provides access to the Linux password file, When other authentication methods need to be used their names can be added to file saltgui/static/salt-auth.txt. There is one name per line in that file. Choose the authentication methods that are activated in the salt-master configuration wisely, as the integrity of the salt-master and all salt-minions depends on it.

See the EAUTH documentation and the Salt auth source code for more information.

SaltGUI supports entry of commands using the "command-box". Click on >_ in the top right corner to open it.

Enter salt-run commands with the prefix runners.. e.g. runners.jobs.last_run. The target field can remain empty in that case as it is not used.

Enter salt-call commands with the prefix wheel.. e.g. wheel.key.finger. The target field will be added as named parameter target. But note that that parameter may not actually be used depending on the command.

Enter regular commands without special prefix. e.g. test.ping. The command is sent to the minions specified in the target field.

Commands can be run normally, in which case the command runs to completion and shows the results. Alternatively, it can be started asynchronously, in which case only a bit of progress information is shown. When variable state_events is set to true, then the progress is shown per state when applicable. Batch commands are not supported at this time.

SaltGUI shows the data that is returned by the Salt API. Some variation can be achieved by modifying salt master configuration file /etc/salt/master. e.g. (the default)

saltgui_output_formats: doc,saltguihighstate,json

doc allows reformatting of documentation output into more readable format. Also implies that only the result from one minion is used. saltguihighstate allows reformatting of highstate data in a sorted and more readable format. json, yaml and nested specify how all other output should be formatted. Only the first available of these formats is used.

The time formats used by Salt are very detailed and by default have 6 decimal digits to specify as accurate as nano-seconds. For most uses that is not needed. The fraction can be truncated to less digits by modifying salt master configuration file /etc/salt/master. e.g.

saltgui_datetime_fraction_digits: 3

The value must be a number from 0 to 6. Note that the effect is achieved by string truncation only. This is equivalent to always rounding downwards.

SaltGUI supports command templates for easier command entry into the command-box. The menu item for that becomes visible there when you define one or more templates in salt master configuration file /etc/salt/master. The field targettype supports the values glob, list, compound and nodegroup. Entries will be sorted in the GUI based on their key. You can leave out any detail field. e.g.:

saltgui_templates:
    template1:
        description: First template
        target: "*"
        command: test.fib num=10
    template2:
        description: Second template
        targettype: glob
        target: dev*
        command: test.version

SaltGUI shows a maximum of 7 jobs in on the right-hand-side of the screen. SaltGUI shows a maximum of 50 jobs on the dedicated jobs page. Commands that are used internally in SaltGUI are hidden.

Additional commands to hide can be configured in salt master configuration file /etc/salt/master. e.g.:

saltgui_hide_jobs:
    - test.ping

Commands that are normally hidden can be made visible using configuration in salt master configuration file /etc/salt/master. e.g.:

saltgui_show_jobs:
    - grains.items

Selected grains can be previewed on the Grains page. The names of these grains can be configured in salt master configuration file /etc/salt/master. e.g.:

saltgui_preview_grains:
    - "osrelease_info"

The names can be specified as simple names like the example above. Alternatively, the grains.get notation can be used to get more detailed information. The separator is always :. e.g. locale_info:timezone. Alternatively, the jsonpath notation can be used to allow even more freedom. Jsonpath is used when the text starts with a $. e.g. $.ip4_interfaces.eth0[0].

Pillars potentially contain security senstitive information. Therefore their values are initially hidden. Values become visible by clicking on them. This behavior can be changed by adjusting the values of the configuration in salt master configuration file /etc/salt/master. The values for the pillar whose name match one of these regular expressions are initially shown. e.g.:

saltgui_public_pillars:
    - pub_.*

A message-of-the-day (motd) can be added to the login screen. It can be used for any information, e.g.:

The text is stored in file saltgui/static/salt-motd.txt or saltgui/static/salt-motd.html. The first must be pre-formatted text only. The second one can contain full HTML text. Both are shown when they are present. Note that the message should not contain sensitive data, as its content is shown before logging in.

Alternatively, or additionally, the text can be retrieved from the master file entries saltgui_motd_txt and saltgui_motd_html. These entries can contain sensitive information because its content can only be retrieved after login. But it is still recommended to not let the text contain any sensitive data.

When apis are disabled using the native external_auth mechanism, SaltGUI may show menu-items that have become unuseable. In that case, it may be useful to reduce the menu-bar to less items. Variable saltgui_pages is read from salt master configuration file /etc/salt/master. It contains the list of accessible pages per user. The first page in the list also becomes the landing page. Users that are not listed still have the full menu. e.g.:

saltgui_pages:
  user1:
    - keys
    - grains

Note that this is NOT a security mechanism to reduce what a user can do. All pages are still accessible using their original deep-link. And also any command can still be issued using the command-box. For real security measures, use parameter external_auth.

SaltGUI does not have artificial restrictions. But displaying all data may be slow when there is a lot of data. Most notorious is the display of a highstate with hundreds of minions, each with douzens of states. SaltGUI can be forced to use a slightly simpler output by setting a parameter in salt master configuration file /etc/salt/master. e.g.:

saltgui_tooltip_mode: simple

This parameter forces SaltGUI to use a very simple tooltip representation. This is then the built-in version from the brower. Typical effect is that it is shown slightly delayed and that is looks a bit primitive. The only other allowed value is "none", with the effect that no tooltips are shown at all.

In situations like cloud hosting, hosts may be deleted or shutdown frequently. But Salt remembers the key status from both. SaltGUI can compare the list of keys against a reference list. The reference list is maintained as a text file, one minion per line. First column is the minion name. Second column is false when the minion is known to be absent due to machine shutdown. It should be true otherwise. When the second column is missing, this validation is not performed. Lines starting with # are comment lines. The filename is saltgui/static/minions.txt. Differences with this file are highlighted on the Keys page. Minions that are unexpectedly down are highlighted on the Minions page. When the file is absent or empty, no such validation is done. It is suggested that the file is generated from a central source, e.g. the Azure, AWS or similar cloud portals; or from a company asset management list.

In some specific environments you might not be able to serve SaltGUI directly from salt-api. In that case you might want to configure a web server (for example NGINX) to serve SaltGui and use it as proxy to salt-api so that requests are answered from the same origin from the browser point of view.

Sample NGINX configuration might look like this:

server {
  listen       80;
  server_name  _;
  root         /data/www;
  index        index.html;

  # handle internal api (proxy)
  location /api/ {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-NginX-Proxy true;
      proxy_pass http://saltmaster-local:3333/;
      proxy_ssl_session_reuse off;
      proxy_set_header Host $http_host;
      proxy_redirect off;
  }

  # handle saltgui web page
  location / {
    try_files $uri /index.html;
  }

}

The value of the API_URL in the config.js file must point to path where salt-api is exposed. The value of the NAV_URL in the config.js file must point to path where the SaltGUI application is exposed.

const config = {
  API_URL: '/api',
  NAV_URL: '/app'
};

Note that the main page of SaltGUI is then located at /app/. When you want /app to work as well, you should instruct an intermediate proxy server to translate /app into /app/.

Currently you can't use totally independent salt-api without proxy as support for CORS preflight request is not properly support.

Development environment with Docker

To make life a bit easier for testing SaltGUI or setting up a local development environment you can use the provided docker-compose setup in this repository to run a saltmaster with three minions, including SaltGUI:

cd docker
docker-compose up

Then browse to http://localhost:3333/, you can login with salt:salt.

We provide some functional tests and unit tests. They use the docker setup to run the functional tests. You will also need yarn and node.js to run them. When you have docker, yarn and node.js installed, you can run the tests from the root of the repository like this:

To show the browser window + a debugger while running the functional tests you can run:

NIGHTMARE_DEBUG=1 ./runtests.sh

We use the following testing libraries:

You'll need at least:

Open a PR! Try to use no dependencies where possible, as vanilla JS is the aim. Any libraries will need to be heavily considered first. Please see the section above as PRs won't be reviewed if they don't pass the tests.

This excellent frontend is originally written by Oliver Dunk.

SaltGUI includes these libraries (with possible modifications):

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4