From f5978f82d395129bf24e222eaca43aa726ac10cf Mon Sep 17 00:00:00 2001 From: Gabriel Adrian Samfira Date: Sat, 8 Jul 2023 14:13:54 +0000 Subject: [PATCH] Remove some options and add docs * Remove the unused CondifGir option * Add docs for the default section * Move some docs from other files Signed-off-by: Gabriel Adrian Samfira --- README.md | 45 ++++--- cloudconfig/templates.go | 8 ++ config/config.go | 15 --- config/config_test.go | 39 ------ doc/config_api_server.md | 0 ...oks_and_callbacks.md => config_default.md} | 127 ++++++++++++++---- doc/config_jwt_auth.md | 0 doc/config_metrics.md | 0 doc/database.md | 2 +- doc/logging.md | 30 ----- doc/providers.md | 26 +++- doc/the_boring_details.md | 4 + doc/webhooks.md | 27 ++++ testdata/config.toml | 17 --- util/appdefaults/appdefaults.go | 4 - 15 files changed, 185 insertions(+), 159 deletions(-) create mode 100644 doc/config_api_server.md rename doc/{webhooks_and_callbacks.md => config_default.md} (56%) create mode 100644 doc/config_jwt_auth.md create mode 100644 doc/config_metrics.md delete mode 100644 doc/logging.md create mode 100644 doc/the_boring_details.md create mode 100644 doc/webhooks.md diff --git a/README.md b/README.md index 03930a78..397bf16a 100644 --- a/README.md +++ b/README.md @@ -23,16 +23,18 @@ Whether you're running into issues or just want to drop by and say "hi", feel fr You need to have Go installed, then run: ```bash - git clone https://github.com/cloudbase/garm - cd garm - go install ./... + go install github.com/cloudbase/garm/cmd/garm@latest + go install github.com/cloudbase/garm/cmd/garm-cli@latest ``` -You should now have both ```garm``` and ```garm-cli``` in your ```$GOPATH/bin``` folder. +This will install the garm binaries in ```$GOPATH/bin``` folder. Move them somewhere in your ```$PATH``` to make them available system-wide. If you have docker/podman installed, you can also build statically linked binaries by running: ```bash + git clone https://github.com/cloudbase/garm + cd garm + git checkout release/v0.1 make build-static ``` @@ -75,12 +77,6 @@ Copy the config template: sudo cp ./testdata/config.toml /etc/garm/ ``` -Copy the external provider (optional): - - ```bash - sudo cp -a ./contrib/providers.d /etc/garm/ - ``` - Copy the systemd service file: ```bash @@ -106,15 +102,26 @@ Customize the config in ```/etc/garm/config.toml```, and start the service: sudo systemctl start garm ``` +## Installing external providers + +External providers are binaries that GARM calls into to create runners in a particular IaaS. There are currently two external providers available: + +* [OpenStack](https://github.com/cloudbase/garm-provider-openstack) +* [Azure](https://github.com/cloudbase/garm-provider-azure) + +Follow the instructions in the README of each provider to install them. + ## Configuration -The ```garm``` configuration is a simple ```toml```. A sample of the config file can be found in [the testdata folder](/testdata/config.toml). +The ```garm``` configuration is a simple ```toml```. The sample config file in [the testdata folder](/testdata/config.toml) is fairly well commented and should be enough to get you started. The configuration file is split into several sections, each of which is documented in its own page. The sections are: -There are 3 major sections of the config that require your attention: - -* [Github credentials section](/doc/github_credentials.md) -* [Providers section](/doc/providers.md) -* [The database section](/doc/database.md) +* [The default section](/doc/config_default.md) +* [Metrics](/doc/config_metrics.md) +* [JWT authentication](/doc/config_jwt_auth.md) +* [API server](/doc/config_api_server.md) +* [Github credentials](/doc/github_credentials.md) +* [Providers](/doc/providers.md) +* [Database](/doc/database.md) Once you've configured your database, providers and github credentials, you'll need to configure your [webhooks and the callback_url](/doc/webhooks_and_callbacks.md). @@ -124,12 +131,6 @@ If you would like to use ```garm``` with a different IaaS than the ones already If you like to optimize the startup time of new instance, take a look at the [performance considerations](/doc/performance_considerations.md) page. -## Security considerations - -Garm does not apply any ACLs of any kind to the instances it creates. That task remains in the responsibility of the user. [Here is a guide for creating ACLs in LXD](https://linuxcontainers.org/lxd/docs/master/howto/network_acls/). You can of course use ```iptables``` or ```nftables``` to create any rules you wish. I recommend you create a separate isolated lxd bridge for runners, and secure it using ACLs/iptables/nftables. - -You must make sure that the code that runs as part of the workflows is trusted, and if that cannot be done, you must make sure that any malicious code that will be pulled in by the actions and run as part of a workload, is as contained as possible. There is a nice article about [securing your workflow runs here](https://blog.gitguardian.com/github-actions-security-cheat-sheet/). - ## Write your own provider The providers are interfaces between ```garm``` and a particular IaaS in which we spin up GitHub Runners. These providers can be either **native** or **external**. The **native** providers are written in ```Go```, and must implement [the interface defined here](https://github.com/cloudbase/garm/blob/main/runner/common/provider.go#L22-L39). **External** providers can be written in any language, as they are in the form of an external executable that ```garm``` calls into. diff --git a/cloudconfig/templates.go b/cloudconfig/templates.go index e02c9c77..1d5b71c3 100644 --- a/cloudconfig/templates.go +++ b/cloudconfig/templates.go @@ -40,6 +40,10 @@ GITHUB_TOKEN=$(curl --retry 5 --retry-delay 5 --retry-connrefused --fail -s -X G function call() { PAYLOAD="$1" + [[ $CALLBACK_URL =~ ^(.*)/status$ ]] + if [ -z "$BASH_REMATCH" ];then + CALLBACK_URL="${CALLBACK_URL}/status" + fi curl --retry 5 --retry-delay 5 --retry-connrefused --fail -s -X POST -d "${PAYLOAD}" -H 'Accept: application/json' -H "Authorization: Bearer ${BEARER_TOKEN}" "${CALLBACK_URL}" || echo "failed to call home: exit code ($?)" } @@ -350,6 +354,10 @@ $GHRunnerGroup = "{{.GitHubRunnerGroup}}" function Install-Runner() { $CallbackURL="{{.CallbackURL}}" + if (!$CallbackURL.EndsWith("/status")) { + $CallbackURL = "$CallbackURL/status" + } + if ($Token.Length -eq 0) { Throw "missing callback authentication token" } diff --git a/config/config.go b/config/config.go index a0eca1e3..a65c4668 100644 --- a/config/config.go +++ b/config/config.go @@ -47,9 +47,6 @@ func NewConfig(cfgFile string) (*Config, error) { if _, err := toml.DecodeFile(cfgFile, &config); err != nil { return nil, errors.Wrap(err, "decoding toml") } - if config.Default.ConfigDir == "" { - config.Default.ConfigDir = appdefaults.DefaultConfigDir - } if err := config.Validate(); err != nil { return nil, errors.Wrap(err, "validating config") } @@ -108,10 +105,6 @@ func (c *Config) Validate() error { } type Default struct { - // ConfigDir is the folder where the runner may save any aditional files - // or configurations it may need. Things like auto-generated SSH keys that - // may be used to access the runner instances. - ConfigDir string `toml:"config_dir,omitempty" json:"config-dir,omitempty"` // CallbackURL is the URL where the instances can send back status reports. CallbackURL string `toml:"callback_url" json:"callback-url"` // MetadataURL is the URL where instances can fetch information they may need @@ -139,14 +132,6 @@ func (d *Default) Validate() error { return errors.Wrap(err, "validating metadata_url") } - if d.ConfigDir == "" { - return fmt.Errorf("config_dir cannot be empty") - } - - if _, err := os.Stat(d.ConfigDir); err != nil { - return errors.Wrap(err, "accessing config dir") - } - return nil } diff --git a/config/config_test.go b/config/config_test.go index 210b0fce..f6558cd8 100644 --- a/config/config_test.go +++ b/config/config_test.go @@ -32,7 +32,6 @@ var ( func getDefaultSectionConfig(configDir string) Default { return Default{ - ConfigDir: configDir, CallbackURL: "https://garm.example.com/", MetadataURL: "https://garm.example.com/api/v1/metadata", LogFile: filepath.Join(configDir, "garm.log"), @@ -152,7 +151,6 @@ func TestDefaultSectionConfig(t *testing.T) { cfg: Default{ CallbackURL: "", MetadataURL: cfg.MetadataURL, - ConfigDir: cfg.ConfigDir, }, errString: "missing callback_url", }, @@ -161,25 +159,14 @@ func TestDefaultSectionConfig(t *testing.T) { cfg: Default{ CallbackURL: cfg.CallbackURL, MetadataURL: "", - ConfigDir: cfg.ConfigDir, }, errString: "missing metadata-url", }, - { - name: "ConfigDir cannot be empty", - cfg: Default{ - CallbackURL: cfg.CallbackURL, - MetadataURL: cfg.MetadataURL, - ConfigDir: "", - }, - errString: "config_dir cannot be empty", - }, { name: "config_dir must exist and be accessible", cfg: Default{ CallbackURL: cfg.CallbackURL, MetadataURL: cfg.MetadataURL, - ConfigDir: "/i/do/not/exist", }, errString: "accessing config dir: stat /i/do/not/exist:.*", }, @@ -560,7 +547,6 @@ func TestNewConfig(t *testing.T) { require.Nil(t, err) require.NotNil(t, cfg) require.Equal(t, "https://garm.example.com/", cfg.Default.CallbackURL) - require.Equal(t, "./testdata", cfg.Default.ConfigDir) require.Equal(t, "0.0.0.0", cfg.APIServer.Bind) require.Equal(t, 9998, cfg.APIServer.Port) require.Equal(t, false, cfg.APIServer.UseTLS) @@ -574,31 +560,6 @@ func TestNewConfig(t *testing.T) { require.Equal(t, timeToLive("48h"), cfg.JWTAuth.TimeToLive) } -func TestNewConfigEmptyConfigDir(t *testing.T) { - dirPath, err := os.MkdirTemp("", "garm-config-test") - if err != nil { - t.Fatalf("failed to create temporary directory: %s", err) - } - defer os.RemoveAll(dirPath) - appdefaults.DefaultConfigDir = dirPath - - cfg, err := NewConfig("testdata/test-empty-config-dir.toml") - require.Nil(t, err) - require.NotNil(t, cfg) - require.Equal(t, cfg.Default.ConfigDir, dirPath) - require.Equal(t, "https://garm.example.com/", cfg.Default.CallbackURL) - require.Equal(t, "0.0.0.0", cfg.APIServer.Bind) - require.Equal(t, 9998, cfg.APIServer.Port) - require.Equal(t, false, cfg.APIServer.UseTLS) - require.Equal(t, DBBackendType("mysql"), cfg.Database.DbBackend) - require.Equal(t, "test", cfg.Database.MySQL.Username) - require.Equal(t, "test", cfg.Database.MySQL.Password) - require.Equal(t, "127.0.0.1", cfg.Database.MySQL.Hostname) - require.Equal(t, "garm", cfg.Database.MySQL.DatabaseName) - require.Equal(t, "bocyasicgatEtenOubwonIbsudNutDom", cfg.JWTAuth.Secret) - require.Equal(t, timeToLive("48h"), cfg.JWTAuth.TimeToLive) -} - func TestNewConfigInvalidTomlPath(t *testing.T) { cfg, err := NewConfig("this is not a file path") require.Nil(t, cfg) diff --git a/doc/config_api_server.md b/doc/config_api_server.md new file mode 100644 index 00000000..e69de29b diff --git a/doc/webhooks_and_callbacks.md b/doc/config_default.md similarity index 56% rename from doc/webhooks_and_callbacks.md rename to doc/config_default.md index 0ff7555d..0d75e397 100644 --- a/doc/webhooks_and_callbacks.md +++ b/doc/config_default.md @@ -1,30 +1,35 @@ -# Webhooks +# The default config section -Garm is designed to auto-scale github runners. To achieve this, ```garm``` relies on [GitHub Webhooks](https://docs.github.com/en/developers/webhooks-and-events/webhooks/about-webhooks). Webhooks allow ```garm``` to react to workflow events from your repository, organization or enterprise. +The `default` config section holds configuration options that don't need a category of their own, but are essential to the operation of the service. In this section we will detail each of the options available in the `default` section. -In your repository or organization, navigate to ```Settings --> Webhooks```. In the ```Payload URL``` field, enter the URL to the ```garm``` webhook endpoint. The ```garm``` API endpoint for webhooks is: +```toml +[default] +# This URL is used by instances to send back status messages as they install +# the github actions runner. Status messages can be seen by querying the +# runner status in garm. +# Note: If you're using a reverse proxy in front of your garm installation, +# this URL needs to point to the address of the reverse proxy. Using TLS is +# highly encouraged. +callback_url = "https://garm.example.com/api/v1/callbacks" - ```txt - POST /webhooks - ``` +# This URL is used by instances to retrieve information they need to set themselves +# up. Access to this URL is granted using the same JWT token used to send back +# status updates. Once the instance transitions to "installed" or "failed" state, +# access to both the status and metadata endpoints is disabled. +# Note: If you're using a reverse proxy in front of your garm installation, +# this URL needs to point to the address of the reverse proxy. Using TLS is +# highly encouraged. +metadata_url = "https://garm.example.com/api/v1/metadata" -If ```garm``` is running on a server under the domain ```garm.example.com```, then that field should be set to ```https://garm.example.com/webhooks```. +# Uncomment this line if you'd like to log to a file instead of standard output. +# log_file = "/tmp/runner-manager.log" -In the webhook configuration page under ```Content type``` you will need to select ```application/json```, set the proper webhook URL and, really important, **make sure you configure a webhook secret**. Garm will authenticate the payloads to make sure they are coming from GitHub. +# Enable streaming logs via web sockets. Use garm-cli debug-log. +enable_log_streamer = false -The webhook secret must be secure. Use something like this to generate one: - - ```bash - gabriel@rossak:~$ function generate_secret () { - tr -dc 'a-zA-Z0-9!@#$%^&*()_+?><~\`;' < /dev/urandom | head -c 64; - echo '' - } - - gabriel@rossak:~$ generate_secret - 9Q*nsr*S54g0imK64(!2$Ns6C!~VsH(p)cFj+AMLug%LM!R%FOQ - ``` - -Next, you can choose which events GitHub should send to ```garm``` via webhooks. Click on ```Let me select individual events``` and select ```Workflow jobs``` (should be at the bottom). You can send everything if you want, but any events ```garm``` doesn't care about will simply be ignored. +# Enable the golang debug server. See the documentation in the "doc" folder for more information. +debug_server = false +``` ## The callback_url option @@ -37,13 +42,13 @@ Your runners will call back home with status updates as they install. Once they Example of a runner sending status updates: ```bash - garm-cli runner show garm-f5227755-129d-4e2d-b306-377a8f3a5dfe + garm-cli runner show garm-DvxiVAlfHeE7 +-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------+ | FIELD | VALUE | +-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------+ | ID | 1afb407b-e9f7-4d75-a410-fc4a8c2dbe6c | - | Provider ID | garm-f5227755-129d-4e2d-b306-377a8f3a5dfe | - | Name | garm-f5227755-129d-4e2d-b306-377a8f3a5dfe | + | Provider ID | garm-DvxiVAlfHeE7 | + | Name | garm-DvxiVAlfHeE7 | | OS Type | linux | | OS Architecture | amd64 | | OS Name | ubuntu | @@ -86,3 +91,77 @@ This URL needs to be accessible only by the instances ```garm``` sets up. This U ```toml metadata_url = "https://garm.example.com/api/v1/metadata" ``` + +## The debug_server option + +GARM can optionally enable the golang profiling server. You can then use the usual `go tool pprof` command to start profiling. This is useful if you suspect garm may be bottlenecking in any way. To enable the profiling server, add the following section to the garm config: + +```toml +[default] + +debug_server = true +``` + +Then restarg garm. You can then use the following command to start profiling: + +```bash +go tool pprof http://127.0.0.1:9997/debug/pprof/profile?seconds=120 +``` + +Important note on profiling when behind a reverse proxy. The above command will hang for a fairly long time. Most reverse proxies will timeout after about 60 seconds. To avoid this, you should only profile on localhost by connecting directly to garm. + +It's also advisable to exclude the debug server URLs from your reverse proxy and only make them available locally. + +Now that the debug server is enabled, here is a blog post on how to profile golang applications: https://blog.golang.org/profiling-go-programs + + +## The log_file option + +By default, GARM logs everything to standard output. + +You can optionally log to file by adding the following to your config file: + +```toml +[default] +# Use this if you'd like to log to a file instead of standard output. +log_file = "/tmp/runner-manager.log" +``` + +### Rotating log files + +GARM automatically rotates the log if it reaches 500 MB in size or 28 days, whichever comes first. + +However, if you want to manually rotate the log file, you can send a `SIGHUP` signal to the GARM process. + +You can add the following to your systemd unit file to enable `reload`: + +```ini +[Service] +ExecReload=/bin/kill -HUP $MAINPID +``` + +Then you can simply: + +```bash +systemctl reload garm +``` + +## The enable_log_streamer option + +This option allows you to stream garm logs directly to your terminal. Set this option to true, then you can use the following command to stream logs: + +```bash +garm-cli debug-log +``` + +An important note on enabling this option when behind a reverse proxy. The log streamer uses websockets to stream logs to you. You will need to configure your reverse proxy to allow websocket connections. If you're using nginx, you will need to add the following to your nginx `server` config: + +```nginx +location /api/v1/ws { + proxy_pass http://garm_backend; + proxy_http_version 1.1; + proxy_set_header Upgrade $http_upgrade; + proxy_set_header Connection "Upgrade"; + proxy_set_header Host $host; +} +``` \ No newline at end of file diff --git a/doc/config_jwt_auth.md b/doc/config_jwt_auth.md new file mode 100644 index 00000000..e69de29b diff --git a/doc/config_metrics.md b/doc/config_metrics.md new file mode 100644 index 00000000..e69de29b diff --git a/doc/database.md b/doc/database.md index 09c9be43..c3e1edc6 100644 --- a/doc/database.md +++ b/doc/database.md @@ -1,6 +1,6 @@ # Database configuration -GARM currently supports SQLite3. The current implementation of GARM is single server, so it does not make much sense to enable anything else at the moment. +GARM currently supports SQLite3. Support for other stores will be added in the future. ```toml [database] diff --git a/doc/logging.md b/doc/logging.md deleted file mode 100644 index 339b1e58..00000000 --- a/doc/logging.md +++ /dev/null @@ -1,30 +0,0 @@ -# Logging - -By default, GARM logs everything to standard output. - -You can optionally log to file by adding the following to your config file: - -```toml -[default] -# Use this if you'd like to log to a file instead of standard output. -log_file = "/tmp/runner-manager.log" -``` - -## Rotating log files - -GARM automatically rotates the log if it reaches 500 MB in size or 28 days, whichever comes first. - -However, if you want to manually rotate the log file, you can send a `SIGHUP` signal to the GARM process. - -You can add the following to your systemd unit file to enable `reload`: - -```ini -[Service] -ExecReload=/bin/kill -HUP $MAINPID -``` - -Then you can simply: - -```bash -systemctl reload garm -``` \ No newline at end of file diff --git a/doc/providers.md b/doc/providers.md index 7a724ecc..2dcb4f90 100644 --- a/doc/providers.md +++ b/doc/providers.md @@ -1,13 +1,17 @@ # Provider configuration -Garm was designed to be extensible. The database layer as well as the providers are defined as interfaces. Currently there are two providers: +GARM was designed to be extensible. Providers can be written either as built-in plugins or as external executables. The built-in plugins are written in Go, and they are compiled into the ```garm``` binary. External providers are executables that implement the needed interface to create/delete/list compute systems that are used by ```garm``` to create runners. -* [LXD](https://linuxcontainers.org/lxd/introduction/) -* External +GARM currently ships with one built-in provider for [LXD](https://linuxcontainers.org/lxd/introduction/) and the external provider interface which allows you to write your own provider in any language you want. -LXD is the simplest cloud-like system you can easily set up on any GNU/Linux machine, which enables you to create both containers and Virtual Machines. The ```external``` provider is a special type of provider, which delegates functionality to external executables. -## The LXD provider +- [LXD provider](#lxd-provider) + - [LXD remotes](#lxd-remotes) + - [LXD Security considerations](#lxd-security-considerations) +- [External provider](#external-provider) + - [Available external providers](#available-external-providers) + +## LXD provider Garm leverages the virtual machines feature of LXD to create the runners. Here is a sample config section for an LXD provider: @@ -102,11 +106,19 @@ You can also create your own image remote, where you can host your own custom im Image remotes in the ```garm``` config, is a map of strings to remote settings. The name of the remote is the last bit of string in the section header. For example, the following section ```[provider.lxd.image_remotes.ubuntu_daily]```, defines the image remote named **ubuntu_daily**. Use this name to reference images inside that remote. -## The External provider +You can also use locally uploaded images. Check out the [performance considerations](./performance_considerations.md) page for details on how to customize local images and use them with garm. + +### LXD Security considerations + +Garm does not apply any ACLs of any kind to the instances it creates. That task remains in the responsibility of the user. [Here is a guide for creating ACLs in LXD](https://linuxcontainers.org/lxd/docs/master/howto/network_acls/). You can of course use ```iptables``` or ```nftables``` to create any rules you wish. I recommend you create a separate isolated lxd bridge for runners, and secure it using ACLs/iptables/nftables. + +You must make sure that the code that runs as part of the workflows is trusted, and if that cannot be done, you must make sure that any malicious code that will be pulled in by the actions and run as part of a workload, is as contained as possible. There is a nice article about [securing your workflow runs here](https://blog.gitguardian.com/github-actions-security-cheat-sheet/). + +## External provider The external provider is a special kind of provider. It delegates the functionality needed to create the runners to external executables. These executables can be either binaries or scripts. As long as they adhere to the needed interface, they can be used to create runners in any target IaaS. This is identical to what ```containerd``` does with ```CNIs```. -There are currently two external providers available in the [contrib folder of this repository](../contrib/providers.d/). The providers are written in ```bash``` and it are just samples. Production ready providers would need more error checking and idempotency, but they serve as an example of what can be done. As it stands, they are functional. +There are currently two sample external providers available in the [contrib folder of this repository](../contrib/providers.d/). The providers are written in ```bash``` and are meant as examples of how a provider could be written in ```bash```. Production ready providers would need more error checking and idempotency, but they serve as an example of what can be done. As it stands, they are functional. The configuration for an external provider is quite simple: diff --git a/doc/the_boring_details.md b/doc/the_boring_details.md new file mode 100644 index 00000000..12d1bc39 --- /dev/null +++ b/doc/the_boring_details.md @@ -0,0 +1,4 @@ +# GARM implementation details and design decissions + +This document attempts to offer an in-depth look at the implementation details and design decisions that went into the creation of GARM. It is not meant to be a user guide, but rather a technical document for those interested in the inner workings of the application. + diff --git a/doc/webhooks.md b/doc/webhooks.md new file mode 100644 index 00000000..03dd8956 --- /dev/null +++ b/doc/webhooks.md @@ -0,0 +1,27 @@ +# Webhooks + +Garm is designed to auto-scale github runners. To achieve this, ```garm``` relies on [GitHub Webhooks](https://docs.github.com/en/developers/webhooks-and-events/webhooks/about-webhooks). Webhooks allow ```garm``` to react to workflow events from your repository, organization or enterprise. + +In your repository or organization, navigate to ```Settings --> Webhooks```. In the ```Payload URL``` field, enter the URL to the ```garm``` webhook endpoint. The ```garm``` API endpoint for webhooks is: + + ```txt + POST /webhooks + ``` + +If ```garm``` is running on a server under the domain ```garm.example.com```, then that field should be set to ```https://garm.example.com/webhooks```. + +In the webhook configuration page under ```Content type``` you will need to select ```application/json```, set the proper webhook URL and, really important, **make sure you configure a webhook secret**. Garm will authenticate the payloads to make sure they are coming from GitHub. + +The webhook secret must be secure. Use something like this to generate one: + + ```bash + gabriel@rossak:~$ function generate_secret () { + tr -dc 'a-zA-Z0-9!@#$%^&*()_+?><~\`;' < /dev/urandom | head -c 64; + echo '' + } + + gabriel@rossak:~$ generate_secret + 9Q*nsr*S54g0imK64(!2$Ns6C!~VsH(p)cFj+AMLug%LM!R%FOQ + ``` + +Next, you can choose which events GitHub should send to ```garm``` via webhooks. Click on ```Let me select individual events``` and select ```Workflow jobs``` (should be at the bottom). You can send everything if you want, but any events ```garm``` doesn't care about will simply be ignored. diff --git a/testdata/config.toml b/testdata/config.toml index 0952ef34..5df14a2d 100644 --- a/testdata/config.toml +++ b/testdata/config.toml @@ -17,10 +17,6 @@ callback_url = "https://garm.example.com/api/v1/callbacks/status" # highly encouraged. metadata_url = "https://garm.example.com/api/v1/metadata" -# This folder is defined here for future use. Right now, we create a SSH -# public/private key-pair. -config_dir = "/etc/garm" - # Uncomment this line if you'd like to log to a file instead of standard output. # log_file = "/tmp/runner-manager.log" @@ -81,29 +77,16 @@ time_to_live = "8760h" debug = false # Database backend to use. Currently supported backends are: # * sqlite3 - # * mysql backend = "sqlite3" # the passphrase option is a temporary measure by which we encrypt the webhook # secret that gets saved to the database, using AES256. In the future, secrets # will be saved to something like Barbican or Vault, eliminating the need for # this. This setting needs to be 32 characters in size. passphrase = "shreotsinWadquidAitNefayctowUrph" - [database.mysql] - # If MySQL is used, these are the credentials and connection information used - # to connect to the server instance. - # database username - username = "" - # Database password - password = "" - # hostname to connect to - hostname = "" - # database name - database = "" [database.sqlite3] # Path on disk to the sqlite3 database file. db_file = "/etc/garm/garm.db" - # Currently, providers are defined statically in the config. This is due to the fact # that we have not yet added support for storing secrets in something like Barbican # or Vault. This will change in the future. However, for now, it's important to remember diff --git a/util/appdefaults/appdefaults.go b/util/appdefaults/appdefaults.go index 70b779bc..41fa3645 100644 --- a/util/appdefaults/appdefaults.go +++ b/util/appdefaults/appdefaults.go @@ -35,10 +35,6 @@ const ( ) var ( - // DefaultConfigDir is the default path on disk to the config dir. The config - // file will probably be in the same folder, but it is not mandatory. - DefaultConfigDir = "/etc/garm" - // DefaultUserGroups are the groups the default user will be part of. DefaultUserGroups = []string{ "sudo", "adm", "cdrom", "dialout",