2019-07-01 06:07:58 +08:00
|
|
|
// Copyright 2015 Matthew Holt and The Caddy Authors
|
|
|
|
//
|
|
|
|
// 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
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// 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.
|
|
|
|
|
2019-06-15 01:58:28 +08:00
|
|
|
package caddy
|
2019-03-27 05:45:51 +08:00
|
|
|
|
|
|
|
import (
|
2019-11-05 03:05:20 +08:00
|
|
|
"bytes"
|
2019-05-17 06:05:38 +08:00
|
|
|
"context"
|
2022-07-07 03:50:07 +08:00
|
|
|
"encoding/hex"
|
2019-03-27 05:45:51 +08:00
|
|
|
"encoding/json"
|
2022-03-04 12:41:51 +08:00
|
|
|
"errors"
|
2019-03-27 05:45:51 +08:00
|
|
|
"fmt"
|
2019-11-05 03:05:20 +08:00
|
|
|
"io"
|
2024-01-02 13:48:55 +08:00
|
|
|
"io/fs"
|
2019-03-27 09:42:52 +08:00
|
|
|
"log"
|
2019-11-05 03:05:20 +08:00
|
|
|
"net/http"
|
2020-01-01 13:51:55 +08:00
|
|
|
"os"
|
2019-11-05 03:05:20 +08:00
|
|
|
"path"
|
2020-01-01 13:51:55 +08:00
|
|
|
"path/filepath"
|
2019-06-29 09:28:28 +08:00
|
|
|
"runtime/debug"
|
2019-11-05 03:05:20 +08:00
|
|
|
"strconv"
|
2019-03-27 05:45:51 +08:00
|
|
|
"strings"
|
2019-03-27 09:42:52 +08:00
|
|
|
"sync"
|
2022-09-20 11:54:47 +08:00
|
|
|
"sync/atomic"
|
2019-03-27 05:45:51 +08:00
|
|
|
"time"
|
2019-04-26 03:54:48 +08:00
|
|
|
|
2020-03-07 14:15:25 +08:00
|
|
|
"github.com/caddyserver/certmagic"
|
2021-03-31 04:15:20 +08:00
|
|
|
"github.com/google/uuid"
|
2020-01-01 07:56:19 +08:00
|
|
|
"go.uber.org/zap"
|
2023-08-14 23:41:15 +08:00
|
|
|
|
2024-01-14 04:12:43 +08:00
|
|
|
"github.com/caddyserver/caddy/v2/internal/filesystems"
|
2023-08-14 23:41:15 +08:00
|
|
|
"github.com/caddyserver/caddy/v2/notify"
|
2019-03-27 05:45:51 +08:00
|
|
|
)
|
|
|
|
|
2019-12-11 04:36:46 +08:00
|
|
|
// Config is the top (or beginning) of the Caddy configuration structure.
|
|
|
|
// Caddy config is expressed natively as a JSON document. If you prefer
|
|
|
|
// not to work with JSON directly, there are [many config adapters](/docs/config-adapters)
|
|
|
|
// available that can convert various inputs into Caddy JSON.
|
|
|
|
//
|
|
|
|
// Many parts of this config are extensible through the use of Caddy modules.
|
|
|
|
// Fields which have a json.RawMessage type and which appear as dots (•••) in
|
|
|
|
// the online docs can be fulfilled by modules in a certain module
|
|
|
|
// namespace. The docs show which modules can be used in a given place.
|
|
|
|
//
|
|
|
|
// Whenever a module is used, its name must be given either inline as part of
|
|
|
|
// the module, or as the key to the module's value. The docs will make it clear
|
|
|
|
// which to use.
|
|
|
|
//
|
|
|
|
// Generally, all config settings are optional, as it is Caddy convention to
|
|
|
|
// have good, documented default values. If a parameter is required, the docs
|
|
|
|
// should say so.
|
|
|
|
//
|
|
|
|
// Go programs which are directly building a Config struct value should take
|
|
|
|
// care to populate the JSON-encodable fields of the struct (i.e. the fields
|
|
|
|
// with `json` struct tags) if employing the module lifecycle (e.g. Provision
|
|
|
|
// method calls).
|
2019-06-29 09:28:28 +08:00
|
|
|
type Config struct {
|
2019-12-11 04:36:46 +08:00
|
|
|
Admin *AdminConfig `json:"admin,omitempty"`
|
|
|
|
Logging *Logging `json:"logging,omitempty"`
|
|
|
|
|
|
|
|
// StorageRaw is a storage module that defines how/where Caddy
|
2020-01-01 09:31:43 +08:00
|
|
|
// stores assets (such as TLS certificates). The default storage
|
|
|
|
// module is `caddy.storage.file_system` (the local file system),
|
|
|
|
// and the default path
|
|
|
|
// [depends on the OS and environment](/docs/conventions#data-directory).
|
2019-12-11 04:36:46 +08:00
|
|
|
StorageRaw json.RawMessage `json:"storage,omitempty" caddy:"namespace=caddy.storage inline_key=module"`
|
|
|
|
|
|
|
|
// AppsRaw are the apps that Caddy will load and run. The
|
|
|
|
// app module name is the key, and the app's config is the
|
|
|
|
// associated value.
|
|
|
|
AppsRaw ModuleMap `json:"apps,omitempty" caddy:"namespace="`
|
2019-06-29 09:28:28 +08:00
|
|
|
|
2019-10-29 04:39:37 +08:00
|
|
|
apps map[string]App
|
|
|
|
storage certmagic.Storage
|
2019-06-29 09:28:28 +08:00
|
|
|
|
|
|
|
cancelFunc context.CancelFunc
|
2024-01-14 04:12:43 +08:00
|
|
|
|
|
|
|
// filesystems is a dict of filesystems that will later be loaded from and added to.
|
|
|
|
filesystems FileSystems
|
2019-06-29 09:28:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// App is a thing that Caddy runs.
|
|
|
|
type App interface {
|
|
|
|
Start() error
|
|
|
|
Stop() error
|
|
|
|
}
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
// Run runs the given config, replacing any existing config.
|
|
|
|
func Run(cfg *Config) error {
|
|
|
|
cfgJSON, err := json.Marshal(cfg)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
return Load(cfgJSON, true)
|
|
|
|
}
|
|
|
|
|
|
|
|
// Load loads the given config JSON and runs it only
|
|
|
|
// if it is different from the current config or
|
|
|
|
// forceReload is true.
|
|
|
|
func Load(cfgJSON []byte, forceReload bool) error {
|
2022-09-02 23:23:51 +08:00
|
|
|
if err := notify.Reloading(); err != nil {
|
|
|
|
Log().Error("unable to notify service manager of reloading state", zap.Error(err))
|
2021-04-06 04:01:20 +08:00
|
|
|
}
|
|
|
|
|
2022-09-02 23:23:51 +08:00
|
|
|
// after reload, notify system of success or, if
|
|
|
|
// failure, update with status (error message)
|
|
|
|
var err error
|
2021-04-06 04:01:20 +08:00
|
|
|
defer func() {
|
2022-09-02 23:23:51 +08:00
|
|
|
if err != nil {
|
|
|
|
if notifyErr := notify.Error(err, 0); notifyErr != nil {
|
|
|
|
Log().Error("unable to notify to service manager of reload error",
|
2022-09-03 00:19:51 +08:00
|
|
|
zap.Error(notifyErr),
|
2022-09-02 23:23:51 +08:00
|
|
|
zap.String("reload_err", err.Error()))
|
|
|
|
}
|
|
|
|
return
|
|
|
|
}
|
|
|
|
if err := notify.Ready(); err != nil {
|
|
|
|
Log().Error("unable to notify to service manager of ready state", zap.Error(err))
|
2021-04-06 04:01:20 +08:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
|
2022-09-02 23:23:51 +08:00
|
|
|
err = changeConfig(http.MethodPost, "/"+rawConfigKey, cfgJSON, "", forceReload)
|
2022-03-04 12:41:51 +08:00
|
|
|
if errors.Is(err, errSameConfig) {
|
|
|
|
err = nil // not really an error
|
|
|
|
}
|
2022-09-02 23:23:51 +08:00
|
|
|
|
2022-03-04 12:41:51 +08:00
|
|
|
return err
|
2019-11-05 03:05:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// changeConfig changes the current config (rawCfg) according to the
|
|
|
|
// method, traversed via the given path, and uses the given input as
|
|
|
|
// the new value (if applicable; i.e. "DELETE" doesn't have an input).
|
|
|
|
// If the resulting config is the same as the previous, no reload will
|
2022-03-04 12:41:51 +08:00
|
|
|
// occur unless forceReload is true. If the config is unchanged and not
|
|
|
|
// forcefully reloaded, then errConfigUnchanged This function is safe for
|
2019-11-05 03:05:20 +08:00
|
|
|
// concurrent use.
|
2022-07-07 03:50:07 +08:00
|
|
|
// The ifMatchHeader can optionally be given a string of the format:
|
2022-08-05 01:16:59 +08:00
|
|
|
//
|
|
|
|
// "<path> <hash>"
|
|
|
|
//
|
2022-07-07 03:50:07 +08:00
|
|
|
// where <path> is the absolute path in the config and <hash> is the expected hash of
|
|
|
|
// the config at that path. If the hash in the ifMatchHeader doesn't match
|
|
|
|
// the hash of the config, then an APIError with status 412 will be returned.
|
|
|
|
func changeConfig(method, path string, input []byte, ifMatchHeader string, forceReload bool) error {
|
2019-11-05 03:05:20 +08:00
|
|
|
switch method {
|
|
|
|
case http.MethodGet,
|
|
|
|
http.MethodHead,
|
|
|
|
http.MethodOptions,
|
|
|
|
http.MethodConnect,
|
|
|
|
http.MethodTrace:
|
|
|
|
return fmt.Errorf("method not allowed")
|
|
|
|
}
|
|
|
|
|
2023-07-22 05:32:20 +08:00
|
|
|
rawCfgMu.Lock()
|
|
|
|
defer rawCfgMu.Unlock()
|
2019-05-17 06:05:38 +08:00
|
|
|
|
2022-07-07 03:50:07 +08:00
|
|
|
if ifMatchHeader != "" {
|
2022-07-13 02:23:55 +08:00
|
|
|
// expect the first and last character to be quotes
|
|
|
|
if len(ifMatchHeader) < 2 || ifMatchHeader[0] != '"' || ifMatchHeader[len(ifMatchHeader)-1] != '"' {
|
|
|
|
return APIError{
|
|
|
|
HTTPStatus: http.StatusBadRequest,
|
|
|
|
Err: fmt.Errorf("malformed If-Match header; expect quoted string"),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-07 03:50:07 +08:00
|
|
|
// read out the parts
|
2022-07-13 02:23:55 +08:00
|
|
|
parts := strings.Fields(ifMatchHeader[1 : len(ifMatchHeader)-1])
|
2022-07-07 03:50:07 +08:00
|
|
|
if len(parts) != 2 {
|
|
|
|
return APIError{
|
|
|
|
HTTPStatus: http.StatusBadRequest,
|
|
|
|
Err: fmt.Errorf("malformed If-Match header; expect format \"<path> <hash>\""),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// get the current hash of the config
|
|
|
|
// at the given path
|
|
|
|
hash := etagHasher()
|
|
|
|
err := unsyncedConfigAccess(http.MethodGet, parts[0], nil, hash)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if hex.EncodeToString(hash.Sum(nil)) != parts[1] {
|
|
|
|
return APIError{
|
|
|
|
HTTPStatus: http.StatusPreconditionFailed,
|
|
|
|
Err: fmt.Errorf("If-Match header did not match current config hash"),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
err := unsyncedConfigAccess(method, path, input, nil)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
// the mutation is complete, so encode the entire config as JSON
|
|
|
|
newCfg, err := json.Marshal(rawCfg[rawConfigKey])
|
|
|
|
if err != nil {
|
|
|
|
return APIError{
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
HTTPStatus: http.StatusBadRequest,
|
|
|
|
Err: fmt.Errorf("encoding new config: %v", err),
|
2019-11-05 03:05:20 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// if nothing changed, no need to do a whole reload unless the client forces it
|
|
|
|
if !forceReload && bytes.Equal(rawCfgJSON, newCfg) {
|
2022-03-02 04:00:14 +08:00
|
|
|
Log().Info("config is unchanged")
|
2022-03-04 12:41:51 +08:00
|
|
|
return errSameConfig
|
2019-11-05 03:05:20 +08:00
|
|
|
}
|
|
|
|
|
2019-11-28 02:49:49 +08:00
|
|
|
// find any IDs in this config and index them
|
|
|
|
idx := make(map[string]string)
|
|
|
|
err = indexConfigObjects(rawCfg[rawConfigKey], "/"+rawConfigKey, idx)
|
|
|
|
if err != nil {
|
|
|
|
return APIError{
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
HTTPStatus: http.StatusInternalServerError,
|
|
|
|
Err: fmt.Errorf("indexing config: %v", err),
|
2019-11-28 02:49:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
// load this new config; if it fails, we need to revert to
|
|
|
|
// our old representation of caddy's actual config
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
err = unsyncedDecodeAndRun(newCfg, true)
|
2019-11-05 03:05:20 +08:00
|
|
|
if err != nil {
|
|
|
|
if len(rawCfgJSON) > 0 {
|
|
|
|
// restore old config state to keep it consistent
|
|
|
|
// with what caddy is still running; we need to
|
|
|
|
// unmarshal it again because it's likely that
|
|
|
|
// pointers deep in our rawCfg map were modified
|
2022-08-03 04:39:09 +08:00
|
|
|
var oldCfg any
|
2019-11-05 03:05:20 +08:00
|
|
|
err2 := json.Unmarshal(rawCfgJSON, &oldCfg)
|
|
|
|
if err2 != nil {
|
|
|
|
err = fmt.Errorf("%v; additionally, restoring old config: %v", err, err2)
|
|
|
|
}
|
|
|
|
rawCfg[rawConfigKey] = oldCfg
|
|
|
|
}
|
|
|
|
|
|
|
|
return fmt.Errorf("loading new config: %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// success, so update our stored copy of the encoded
|
|
|
|
// config to keep it consistent with what caddy is now
|
|
|
|
// running (storing an encoded copy is not strictly
|
|
|
|
// necessary, but avoids an extra json.Marshal for
|
|
|
|
// each config change)
|
|
|
|
rawCfgJSON = newCfg
|
|
|
|
rawCfgIndex = idx
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// readConfig traverses the current config to path
|
|
|
|
// and writes its JSON encoding to out.
|
|
|
|
func readConfig(path string, out io.Writer) error {
|
2023-07-22 05:32:20 +08:00
|
|
|
rawCfgMu.RLock()
|
|
|
|
defer rawCfgMu.RUnlock()
|
2019-11-05 03:05:20 +08:00
|
|
|
return unsyncedConfigAccess(http.MethodGet, path, nil, out)
|
|
|
|
}
|
|
|
|
|
2020-02-27 13:22:40 +08:00
|
|
|
// indexConfigObjects recursively searches ptr for object fields named
|
2019-11-05 03:05:20 +08:00
|
|
|
// "@id" and maps that ID value to the full configPath in the index.
|
|
|
|
// This function is NOT safe for concurrent access; obtain a write lock
|
2022-08-02 03:36:22 +08:00
|
|
|
// on currentCtxMu.
|
2022-08-03 04:39:09 +08:00
|
|
|
func indexConfigObjects(ptr any, configPath string, index map[string]string) error {
|
2019-11-05 03:05:20 +08:00
|
|
|
switch val := ptr.(type) {
|
2022-08-03 04:39:09 +08:00
|
|
|
case map[string]any:
|
2019-11-05 03:05:20 +08:00
|
|
|
for k, v := range val {
|
|
|
|
if k == idKey {
|
|
|
|
switch idVal := v.(type) {
|
|
|
|
case string:
|
|
|
|
index[idVal] = configPath
|
|
|
|
case float64: // all JSON numbers decode as float64
|
|
|
|
index[fmt.Sprintf("%v", idVal)] = configPath
|
|
|
|
default:
|
|
|
|
return fmt.Errorf("%s: %s field must be a string or number", configPath, idKey)
|
|
|
|
}
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
// traverse this object property recursively
|
|
|
|
err := indexConfigObjects(val[k], path.Join(configPath, k), index)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
2022-08-03 04:39:09 +08:00
|
|
|
case []any:
|
2019-11-05 03:05:20 +08:00
|
|
|
// traverse each element of the array recursively
|
|
|
|
for i := range val {
|
|
|
|
err := indexConfigObjects(val[i], path.Join(configPath, strconv.Itoa(i)), index)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-01-01 07:56:19 +08:00
|
|
|
// unsyncedDecodeAndRun removes any meta fields (like @id tags)
|
|
|
|
// from cfgJSON, decodes the result into a *Config, and runs
|
|
|
|
// it as the new config, replacing any other current config.
|
|
|
|
// It does NOT update the raw config state, as this is a
|
|
|
|
// lower-level function; most callers will want to use Load
|
2023-07-22 05:32:20 +08:00
|
|
|
// instead. A write lock on rawCfgMu is required! If
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
// allowPersist is false, it will not be persisted to disk,
|
|
|
|
// even if it is configured to.
|
|
|
|
func unsyncedDecodeAndRun(cfgJSON []byte, allowPersist bool) error {
|
2020-01-01 07:56:19 +08:00
|
|
|
// remove any @id fields from the JSON, which would cause
|
|
|
|
// loading to break since the field wouldn't be recognized
|
|
|
|
strippedCfgJSON := RemoveMetaFields(cfgJSON)
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
var newCfg *Config
|
2023-02-23 02:39:40 +08:00
|
|
|
err := StrictUnmarshalJSON(strippedCfgJSON, &newCfg)
|
2019-11-05 03:05:20 +08:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
// prevent recursive config loads; that is a user error, and
|
|
|
|
// although frequent config loads should be safe, we cannot
|
|
|
|
// guarantee that in the presence of third party plugins, nor
|
|
|
|
// do we want this error to go unnoticed (we assume it was a
|
|
|
|
// pulled config if we're not allowed to persist it)
|
|
|
|
if !allowPersist &&
|
|
|
|
newCfg != nil &&
|
|
|
|
newCfg.Admin != nil &&
|
|
|
|
newCfg.Admin.Config != nil &&
|
2021-07-29 05:39:08 +08:00
|
|
|
newCfg.Admin.Config.LoadRaw != nil &&
|
2022-03-02 06:04:47 +08:00
|
|
|
newCfg.Admin.Config.LoadDelay <= 0 {
|
|
|
|
return fmt.Errorf("recursive config loading detected: pulled configs cannot pull other configs without positive load_delay")
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// run the new config and start all its apps
|
2022-08-02 03:36:22 +08:00
|
|
|
ctx, err := run(newCfg, true)
|
2019-09-30 23:16:01 +08:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2022-08-02 03:36:22 +08:00
|
|
|
// swap old context (including its config) with the new one
|
2023-07-22 05:32:20 +08:00
|
|
|
currentCtxMu.Lock()
|
2022-08-02 03:36:22 +08:00
|
|
|
oldCtx := currentCtx
|
|
|
|
currentCtx = ctx
|
2023-07-22 05:32:20 +08:00
|
|
|
currentCtxMu.Unlock()
|
2019-05-17 06:05:38 +08:00
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// Stop, Cleanup each old app
|
2022-08-02 03:36:22 +08:00
|
|
|
unsyncedStop(oldCtx)
|
2019-09-30 23:16:01 +08:00
|
|
|
|
2020-01-01 07:56:19 +08:00
|
|
|
// autosave a non-nil config, if not disabled
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
if allowPersist &&
|
|
|
|
newCfg != nil &&
|
2020-01-01 07:56:19 +08:00
|
|
|
(newCfg.Admin == nil ||
|
|
|
|
newCfg.Admin.Config == nil ||
|
|
|
|
newCfg.Admin.Config.Persist == nil ||
|
|
|
|
*newCfg.Admin.Config.Persist) {
|
2020-01-01 13:51:55 +08:00
|
|
|
dir := filepath.Dir(ConfigAutosavePath)
|
2023-08-08 03:40:31 +08:00
|
|
|
err := os.MkdirAll(dir, 0o700)
|
2020-01-01 13:51:55 +08:00
|
|
|
if err != nil {
|
|
|
|
Log().Error("unable to create folder for config autosave",
|
|
|
|
zap.String("dir", dir),
|
2020-01-01 07:56:19 +08:00
|
|
|
zap.Error(err))
|
2020-01-01 13:51:55 +08:00
|
|
|
} else {
|
2023-08-08 03:40:31 +08:00
|
|
|
err := os.WriteFile(ConfigAutosavePath, cfgJSON, 0o600)
|
2020-01-01 13:51:55 +08:00
|
|
|
if err == nil {
|
2021-02-25 02:55:56 +08:00
|
|
|
Log().Info("autosaved config (load with --resume flag)", zap.String("file", ConfigAutosavePath))
|
2020-01-01 13:51:55 +08:00
|
|
|
} else {
|
|
|
|
Log().Error("unable to autosave config",
|
|
|
|
zap.String("file", ConfigAutosavePath),
|
|
|
|
zap.Error(err))
|
|
|
|
}
|
2020-01-01 07:56:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// run runs newCfg and starts all its apps if
|
|
|
|
// start is true. If any errors happen, cleanup
|
|
|
|
// is performed if any modules were provisioned;
|
|
|
|
// apps that were started already will be stopped,
|
|
|
|
// so this function should not leak resources if
|
2019-10-29 04:39:37 +08:00
|
|
|
// an error is returned. However, if no error is
|
|
|
|
// returned and start == false, you should cancel
|
|
|
|
// the config if you are not going to start it,
|
|
|
|
// so that each provisioned module will be
|
|
|
|
// cleaned up.
|
2019-11-05 03:05:20 +08:00
|
|
|
//
|
|
|
|
// This is a low-level function; most callers
|
|
|
|
// will want to use Run instead, which also
|
|
|
|
// updates the config's raw state.
|
2022-08-02 03:36:22 +08:00
|
|
|
func run(newCfg *Config, start bool) (Context, error) {
|
2019-09-30 23:16:01 +08:00
|
|
|
// because we will need to roll back any state
|
|
|
|
// modifications if this function errors, we
|
|
|
|
// keep a single error value and scope all
|
|
|
|
// sub-operations to their own functions to
|
|
|
|
// ensure this error value does not get
|
|
|
|
// overridden or missed when it should have
|
|
|
|
// been set by a short assignment
|
|
|
|
var err error
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
if newCfg == nil {
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
newCfg = new(Config)
|
2019-11-05 03:05:20 +08:00
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// create a context within which to load
|
|
|
|
// modules - essentially our new config's
|
|
|
|
// execution environment; be sure that
|
|
|
|
// cleanup occurs when we return if there
|
|
|
|
// was an error; if no error, it will get
|
|
|
|
// cleaned up on next config cycle
|
|
|
|
ctx, cancel := NewContext(Context{Context: context.Background(), cfg: newCfg})
|
|
|
|
defer func() {
|
2019-05-17 06:05:38 +08:00
|
|
|
if err != nil {
|
2019-10-29 04:39:37 +08:00
|
|
|
// if there were any errors during startup,
|
|
|
|
// we should cancel the new context we created
|
|
|
|
// since the associated config won't be used;
|
|
|
|
// this will cause all modules that were newly
|
|
|
|
// provisioned to clean themselves up
|
|
|
|
cancel()
|
|
|
|
|
|
|
|
// also undo any other state changes we made
|
2022-08-02 03:36:22 +08:00
|
|
|
if currentCtx.cfg != nil {
|
|
|
|
certmagic.Default.Storage = currentCtx.cfg.storage
|
2019-10-29 04:39:37 +08:00
|
|
|
}
|
2019-03-27 09:42:52 +08:00
|
|
|
}
|
2019-09-30 23:16:01 +08:00
|
|
|
}()
|
|
|
|
newCfg.cancelFunc = cancel // clean up later
|
2019-04-26 03:54:48 +08:00
|
|
|
|
2019-10-29 04:39:37 +08:00
|
|
|
// set up logging before anything bad happens
|
2019-10-30 01:58:29 +08:00
|
|
|
if newCfg.Logging == nil {
|
|
|
|
newCfg.Logging = new(Logging)
|
|
|
|
}
|
|
|
|
err = newCfg.Logging.openLogs(ctx)
|
|
|
|
if err != nil {
|
2022-08-02 03:36:22 +08:00
|
|
|
return ctx, err
|
2019-10-29 04:39:37 +08:00
|
|
|
}
|
|
|
|
|
2021-02-24 03:57:10 +08:00
|
|
|
// start the admin endpoint (and stop any prior one)
|
|
|
|
if start {
|
|
|
|
err = replaceLocalAdminServer(newCfg)
|
|
|
|
if err != nil {
|
2022-08-02 03:36:22 +08:00
|
|
|
return ctx, fmt.Errorf("starting caddy administration endpoint: %v", err)
|
2021-02-24 03:57:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-01-14 04:12:43 +08:00
|
|
|
// create the new filesystem map
|
|
|
|
newCfg.filesystems = &filesystems.FilesystemMap{}
|
|
|
|
|
2021-02-24 03:57:10 +08:00
|
|
|
// prepare the new config for use
|
|
|
|
newCfg.apps = make(map[string]App)
|
|
|
|
|
2019-10-29 04:39:37 +08:00
|
|
|
// set up global storage and make it CertMagic's default storage, too
|
2019-09-30 23:16:01 +08:00
|
|
|
err = func() error {
|
|
|
|
if newCfg.StorageRaw != nil {
|
2019-12-11 04:36:46 +08:00
|
|
|
val, err := ctx.LoadModule(newCfg, "StorageRaw")
|
2019-09-30 23:16:01 +08:00
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("loading storage module: %v", err)
|
2019-05-17 06:05:38 +08:00
|
|
|
}
|
2019-09-30 23:16:01 +08:00
|
|
|
stor, err := val.(StorageConverter).CertMagicStorage()
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("creating storage value: %v", err)
|
|
|
|
}
|
|
|
|
newCfg.storage = stor
|
2019-04-08 14:00:14 +08:00
|
|
|
}
|
2019-12-11 04:36:46 +08:00
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
if newCfg.storage == nil {
|
2020-04-01 07:56:36 +08:00
|
|
|
newCfg.storage = DefaultStorage
|
2019-09-30 23:16:01 +08:00
|
|
|
}
|
|
|
|
certmagic.Default.Storage = newCfg.storage
|
2019-04-26 03:54:48 +08:00
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
return nil
|
|
|
|
}()
|
|
|
|
if err != nil {
|
2022-08-02 03:36:22 +08:00
|
|
|
return ctx, err
|
2019-09-30 23:16:01 +08:00
|
|
|
}
|
|
|
|
|
2020-03-07 14:15:25 +08:00
|
|
|
// Load and Provision each app and their submodules
|
2019-09-30 23:16:01 +08:00
|
|
|
err = func() error {
|
2020-03-07 14:15:25 +08:00
|
|
|
for appName := range newCfg.AppsRaw {
|
|
|
|
if _, err := ctx.App(appName); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2019-04-08 14:00:14 +08:00
|
|
|
}
|
2019-09-30 23:16:01 +08:00
|
|
|
return nil
|
|
|
|
}()
|
|
|
|
if err != nil {
|
2022-08-02 03:36:22 +08:00
|
|
|
return ctx, err
|
2019-04-26 03:54:48 +08:00
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
if !start {
|
2022-08-02 03:36:22 +08:00
|
|
|
return ctx, nil
|
2019-09-30 23:16:01 +08:00
|
|
|
}
|
2019-04-26 03:54:48 +08:00
|
|
|
|
2022-03-03 02:08:36 +08:00
|
|
|
// Provision any admin routers which may need to access
|
|
|
|
// some of the other apps at runtime
|
|
|
|
err = newCfg.Admin.provisionAdminRouters(ctx)
|
|
|
|
if err != nil {
|
2022-08-02 03:36:22 +08:00
|
|
|
return ctx, err
|
2022-03-03 02:08:36 +08:00
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// Start
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
err = func() error {
|
2022-05-25 03:52:50 +08:00
|
|
|
started := make([]string, 0, len(newCfg.apps))
|
2019-09-30 23:16:01 +08:00
|
|
|
for name, a := range newCfg.apps {
|
|
|
|
err := a.Start()
|
|
|
|
if err != nil {
|
|
|
|
// an app failed to start, so we need to stop
|
|
|
|
// all other apps that were already started
|
|
|
|
for _, otherAppName := range started {
|
|
|
|
err2 := newCfg.apps[otherAppName].Stop()
|
|
|
|
if err2 != nil {
|
|
|
|
err = fmt.Errorf("%v; additionally, aborting app %s: %v",
|
|
|
|
err, otherAppName, err2)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return fmt.Errorf("%s app module: start: %v", name, err)
|
|
|
|
}
|
|
|
|
started = append(started, name)
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}()
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
if err != nil {
|
2022-08-02 03:36:22 +08:00
|
|
|
return ctx, err
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// now that the user's config is running, finish setting up anything else,
|
|
|
|
// such as remote admin endpoint, config loader, etc.
|
2022-08-02 03:36:22 +08:00
|
|
|
return ctx, finishSettingUp(ctx, newCfg)
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// finishSettingUp should be run after all apps have successfully started.
|
|
|
|
func finishSettingUp(ctx Context, cfg *Config) error {
|
|
|
|
// establish this server's identity (only after apps are loaded
|
|
|
|
// so that cert management of this endpoint doesn't prevent user's
|
|
|
|
// servers from starting which likely also use HTTP/HTTPS ports;
|
|
|
|
// but before remote management which may depend on these creds)
|
|
|
|
err := manageIdentity(ctx, cfg)
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("provisioning remote admin endpoint: %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// replace any remote admin endpoint
|
|
|
|
err = replaceRemoteAdminServer(ctx, cfg)
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("provisioning remote admin endpoint: %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// if dynamic config is requested, set that up and run it
|
|
|
|
if cfg != nil && cfg.Admin != nil && cfg.Admin.Config != nil && cfg.Admin.Config.LoadRaw != nil {
|
|
|
|
val, err := ctx.LoadModule(cfg.Admin.Config, "LoadRaw")
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("loading config loader module: %s", err)
|
|
|
|
}
|
2022-03-02 02:32:33 +08:00
|
|
|
|
2022-03-02 04:00:14 +08:00
|
|
|
logger := Log().Named("config_loader").With(
|
|
|
|
zap.String("module", val.(Module).CaddyModule().ID.Name()),
|
2022-03-02 06:04:47 +08:00
|
|
|
zap.Int("load_delay", int(cfg.Admin.Config.LoadDelay)))
|
2022-03-02 02:32:33 +08:00
|
|
|
|
2022-03-04 12:41:51 +08:00
|
|
|
runLoadedConfig := func(config []byte) error {
|
2022-03-02 04:00:14 +08:00
|
|
|
logger.Info("applying dynamically-loaded config")
|
2022-07-07 03:50:07 +08:00
|
|
|
err := changeConfig(http.MethodPost, "/"+rawConfigKey, config, "", false)
|
2022-03-04 12:41:51 +08:00
|
|
|
if errors.Is(err, errSameConfig) {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if err != nil {
|
2022-03-02 04:00:14 +08:00
|
|
|
logger.Error("failed to run dynamically-loaded config", zap.Error(err))
|
2022-03-04 12:41:51 +08:00
|
|
|
return err
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
}
|
2022-03-04 12:41:51 +08:00
|
|
|
logger.Info("successfully applied dynamically-loaded config")
|
|
|
|
return nil
|
2021-07-29 05:39:08 +08:00
|
|
|
}
|
2022-03-02 04:00:14 +08:00
|
|
|
|
2022-03-02 06:04:47 +08:00
|
|
|
if cfg.Admin.Config.LoadDelay > 0 {
|
2021-07-29 05:39:08 +08:00
|
|
|
go func() {
|
2022-03-04 12:41:51 +08:00
|
|
|
// the loop is here to iterate ONLY if there is an error, a no-op config load,
|
|
|
|
// or an unchanged config; in which case we simply wait the delay and try again
|
2022-03-04 01:57:55 +08:00
|
|
|
for {
|
|
|
|
timer := time.NewTimer(time.Duration(cfg.Admin.Config.LoadDelay))
|
|
|
|
select {
|
|
|
|
case <-timer.C:
|
|
|
|
loadedConfig, err := val.(ConfigLoader).LoadConfig(ctx)
|
|
|
|
if err != nil {
|
2022-03-04 12:41:51 +08:00
|
|
|
logger.Error("failed loading dynamic config; will retry", zap.Error(err))
|
2022-03-04 01:57:55 +08:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
if loadedConfig == nil {
|
2022-03-04 12:41:51 +08:00
|
|
|
logger.Info("dynamically-loaded config was nil; will retry")
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
err = runLoadedConfig(loadedConfig)
|
|
|
|
if errors.Is(err, errSameConfig) {
|
|
|
|
logger.Info("dynamically-loaded config was unchanged; will retry")
|
2022-03-04 01:57:55 +08:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
case <-ctx.Done():
|
|
|
|
if !timer.Stop() {
|
|
|
|
<-timer.C
|
|
|
|
}
|
2022-03-04 12:41:51 +08:00
|
|
|
logger.Info("stopping dynamic config loading")
|
2021-07-29 05:39:08 +08:00
|
|
|
}
|
2022-03-04 01:57:55 +08:00
|
|
|
break
|
2021-07-29 05:39:08 +08:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
} else {
|
2022-03-02 06:04:47 +08:00
|
|
|
// if no LoadDelay is provided, will load config synchronously
|
2021-07-29 05:39:08 +08:00
|
|
|
loadedConfig, err := val.(ConfigLoader).LoadConfig(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("loading dynamic config from %T: %v", val, err)
|
|
|
|
}
|
|
|
|
// do this in a goroutine so current config can finish being loaded; otherwise deadlock
|
2022-03-05 11:26:37 +08:00
|
|
|
go func() { _ = runLoadedConfig(loadedConfig) }()
|
2021-07-29 05:39:08 +08:00
|
|
|
}
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2022-03-04 01:57:55 +08:00
|
|
|
// ConfigLoader is a type that can load a Caddy config. If
|
|
|
|
// the return value is non-nil, it must be valid Caddy JSON;
|
|
|
|
// if nil or with non-nil error, it is considered to be a
|
|
|
|
// no-op load and may be retried later.
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
type ConfigLoader interface {
|
|
|
|
LoadConfig(Context) ([]byte, error)
|
2019-07-13 00:07:11 +08:00
|
|
|
}
|
2019-04-03 05:31:02 +08:00
|
|
|
|
2019-07-13 00:07:11 +08:00
|
|
|
// Stop stops running the current configuration.
|
|
|
|
// It is the antithesis of Run(). This function
|
|
|
|
// will log any errors that occur during the
|
|
|
|
// stopping of individual apps and continue to
|
2019-11-05 03:05:20 +08:00
|
|
|
// stop the others. Stop should only be called
|
|
|
|
// if not replacing with a new config.
|
2019-07-13 00:07:11 +08:00
|
|
|
func Stop() error {
|
2023-07-22 05:32:20 +08:00
|
|
|
currentCtxMu.RLock()
|
|
|
|
ctx := currentCtx
|
|
|
|
currentCtxMu.RUnlock()
|
|
|
|
|
|
|
|
rawCfgMu.Lock()
|
|
|
|
unsyncedStop(ctx)
|
|
|
|
|
2022-08-02 03:36:22 +08:00
|
|
|
currentCtxMu.Lock()
|
|
|
|
currentCtx = Context{}
|
2023-07-22 05:32:20 +08:00
|
|
|
currentCtxMu.Unlock()
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
rawCfgJSON = nil
|
|
|
|
rawCfgIndex = nil
|
|
|
|
rawCfg[rawConfigKey] = nil
|
2023-07-22 05:32:20 +08:00
|
|
|
rawCfgMu.Unlock()
|
|
|
|
|
2019-03-27 05:45:51 +08:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2023-07-22 05:32:20 +08:00
|
|
|
// unsyncedStop stops ctx from running, but has
|
|
|
|
// no locking around ctx. It is a no-op if ctx has a
|
|
|
|
// nil cfg. If any app returns an error when stopping,
|
2019-11-05 03:05:20 +08:00
|
|
|
// it is logged and the function continues stopping
|
|
|
|
// the next app. This function assumes all apps in
|
2023-07-22 05:32:20 +08:00
|
|
|
// ctx were successfully started first.
|
|
|
|
//
|
|
|
|
// A lock on rawCfgMu is required, even though this
|
|
|
|
// function does not access rawCfg, that lock
|
|
|
|
// synchronizes the stop/start of apps.
|
2022-08-02 03:36:22 +08:00
|
|
|
func unsyncedStop(ctx Context) {
|
|
|
|
if ctx.cfg == nil {
|
2019-07-13 00:07:11 +08:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// stop each app
|
2022-08-02 03:36:22 +08:00
|
|
|
for name, a := range ctx.cfg.apps {
|
2019-07-13 00:07:11 +08:00
|
|
|
err := a.Stop()
|
|
|
|
if err != nil {
|
|
|
|
log.Printf("[ERROR] stop %s: %v", name, err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// clean up all modules
|
2022-08-02 03:36:22 +08:00
|
|
|
ctx.cfg.cancelFunc()
|
2019-09-30 23:16:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Validate loads, provisions, and validates
|
|
|
|
// cfg, but does not start running it.
|
|
|
|
func Validate(cfg *Config) error {
|
2022-08-02 03:36:22 +08:00
|
|
|
_, err := run(cfg, false)
|
2019-10-29 04:39:37 +08:00
|
|
|
if err == nil {
|
|
|
|
cfg.cancelFunc() // call Cleanup on all modules
|
|
|
|
}
|
|
|
|
return err
|
2019-07-13 00:07:11 +08:00
|
|
|
}
|
|
|
|
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
// exitProcess exits the process as gracefully as possible,
|
|
|
|
// but it always exits, even if there are errors doing so.
|
|
|
|
// It stops all apps, cleans up external locks, removes any
|
|
|
|
// PID file, and shuts down admin endpoint(s) in a goroutine.
|
|
|
|
// Errors are logged along the way, and an appropriate exit
|
|
|
|
// code is emitted.
|
2022-03-26 01:28:54 +08:00
|
|
|
func exitProcess(ctx context.Context, logger *zap.Logger) {
|
2022-09-20 11:54:47 +08:00
|
|
|
// let the rest of the program know we're quitting
|
|
|
|
atomic.StoreInt32(exiting, 1)
|
|
|
|
|
|
|
|
// give the OS or service/process manager our 2 weeks' notice: we quit
|
2022-09-02 23:23:51 +08:00
|
|
|
if err := notify.Stopping(); err != nil {
|
|
|
|
Log().Error("unable to notify service manager of stopping state", zap.Error(err))
|
|
|
|
}
|
|
|
|
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
if logger == nil {
|
|
|
|
logger = Log()
|
|
|
|
}
|
|
|
|
logger.Warn("exiting; byeee!! 👋")
|
|
|
|
|
|
|
|
exitCode := ExitCodeSuccess
|
2024-03-02 00:57:05 +08:00
|
|
|
lastContext := ActiveContext()
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
|
|
|
|
// stop all apps
|
|
|
|
if err := Stop(); err != nil {
|
|
|
|
logger.Error("failed to stop apps", zap.Error(err))
|
|
|
|
exitCode = ExitCodeFailedQuit
|
|
|
|
}
|
|
|
|
|
|
|
|
// clean up certmagic locks
|
2022-03-26 01:28:54 +08:00
|
|
|
certmagic.CleanUpOwnLocks(ctx, logger)
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
|
|
|
|
// remove pidfile
|
|
|
|
if pidfile != "" {
|
|
|
|
err := os.Remove(pidfile)
|
|
|
|
if err != nil {
|
|
|
|
logger.Error("cleaning up PID file:",
|
|
|
|
zap.String("pidfile", pidfile),
|
|
|
|
zap.Error(err))
|
|
|
|
exitCode = ExitCodeFailedQuit
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-03-02 00:57:05 +08:00
|
|
|
// execute any process-exit callbacks
|
|
|
|
for _, exitFunc := range lastContext.exitFuncs {
|
|
|
|
exitFunc(ctx)
|
|
|
|
}
|
|
|
|
exitFuncsMu.Lock()
|
|
|
|
for _, exitFunc := range exitFuncs {
|
|
|
|
exitFunc(ctx)
|
|
|
|
}
|
|
|
|
exitFuncsMu.Unlock()
|
|
|
|
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
// shut down admin endpoint(s) in goroutines so that
|
|
|
|
// if this function was called from an admin handler,
|
|
|
|
// it has a chance to return gracefully
|
|
|
|
// use goroutine so that we can finish responding to API request
|
|
|
|
go func() {
|
|
|
|
defer func() {
|
|
|
|
logger = logger.With(zap.Int("exit_code", exitCode))
|
|
|
|
if exitCode == ExitCodeSuccess {
|
|
|
|
logger.Info("shutdown complete")
|
|
|
|
} else {
|
|
|
|
logger.Error("unclean shutdown")
|
|
|
|
}
|
|
|
|
os.Exit(exitCode)
|
|
|
|
}()
|
|
|
|
|
|
|
|
if remoteAdminServer != nil {
|
|
|
|
err := stopAdminServer(remoteAdminServer)
|
|
|
|
if err != nil {
|
|
|
|
exitCode = ExitCodeFailedQuit
|
|
|
|
logger.Error("failed to stop remote admin server gracefully", zap.Error(err))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if localAdminServer != nil {
|
|
|
|
err := stopAdminServer(localAdminServer)
|
|
|
|
if err != nil {
|
|
|
|
exitCode = ExitCodeFailedQuit
|
|
|
|
logger.Error("failed to stop local admin server gracefully", zap.Error(err))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
2022-09-20 11:54:47 +08:00
|
|
|
var exiting = new(int32) // accessed atomically
|
|
|
|
|
|
|
|
// Exiting returns true if the process is exiting.
|
|
|
|
// EXPERIMENTAL API: subject to change or removal.
|
|
|
|
func Exiting() bool { return atomic.LoadInt32(exiting) == 1 }
|
|
|
|
|
2024-03-02 00:57:05 +08:00
|
|
|
// OnExit registers a callback to invoke during process exit.
|
|
|
|
// This registration is PROCESS-GLOBAL, meaning that each
|
|
|
|
// function should only be registered once forever, NOT once
|
|
|
|
// per config load (etc).
|
|
|
|
//
|
|
|
|
// EXPERIMENTAL API: subject to change or removal.
|
|
|
|
func OnExit(f func(context.Context)) {
|
|
|
|
exitFuncsMu.Lock()
|
|
|
|
exitFuncs = append(exitFuncs, f)
|
|
|
|
exitFuncsMu.Unlock()
|
|
|
|
}
|
|
|
|
|
|
|
|
var (
|
|
|
|
exitFuncs []func(context.Context)
|
|
|
|
exitFuncsMu sync.Mutex
|
|
|
|
)
|
|
|
|
|
2019-12-11 04:36:46 +08:00
|
|
|
// Duration can be an integer or a string. An integer is
|
|
|
|
// interpreted as nanoseconds. If a string, it is a Go
|
|
|
|
// time.Duration value such as `300ms`, `1.5h`, or `2h45m`;
|
2020-05-12 06:41:11 +08:00
|
|
|
// valid units are `ns`, `us`/`µs`, `ms`, `s`, `m`, `h`, and `d`.
|
2019-03-27 05:45:51 +08:00
|
|
|
type Duration time.Duration
|
|
|
|
|
|
|
|
// UnmarshalJSON satisfies json.Unmarshaler.
|
2019-04-01 10:41:29 +08:00
|
|
|
func (d *Duration) UnmarshalJSON(b []byte) error {
|
2019-11-05 03:54:46 +08:00
|
|
|
if len(b) == 0 {
|
|
|
|
return io.EOF
|
2019-04-01 10:41:29 +08:00
|
|
|
}
|
2019-11-05 03:54:46 +08:00
|
|
|
var dur time.Duration
|
|
|
|
var err error
|
|
|
|
if b[0] == byte('"') && b[len(b)-1] == byte('"') {
|
2020-05-12 06:41:11 +08:00
|
|
|
dur, err = ParseDuration(strings.Trim(string(b), `"`))
|
2019-11-05 03:54:46 +08:00
|
|
|
} else {
|
|
|
|
err = json.Unmarshal(b, &dur)
|
|
|
|
}
|
|
|
|
*d = Duration(dur)
|
|
|
|
return err
|
2019-03-27 05:45:51 +08:00
|
|
|
}
|
|
|
|
|
2020-05-12 06:41:11 +08:00
|
|
|
// ParseDuration parses a duration string, adding
|
|
|
|
// support for the "d" unit meaning number of days,
|
2022-09-16 04:25:29 +08:00
|
|
|
// where a day is assumed to be 24h. The maximum
|
|
|
|
// input string length is 1024.
|
2020-05-12 06:41:11 +08:00
|
|
|
func ParseDuration(s string) (time.Duration, error) {
|
2022-09-16 04:25:29 +08:00
|
|
|
if len(s) > 1024 {
|
|
|
|
return 0, fmt.Errorf("parsing duration: input string too long")
|
|
|
|
}
|
2020-05-12 06:41:11 +08:00
|
|
|
var inNumber bool
|
|
|
|
var numStart int
|
|
|
|
for i := 0; i < len(s); i++ {
|
|
|
|
ch := s[i]
|
|
|
|
if ch == 'd' {
|
|
|
|
daysStr := s[numStart:i]
|
|
|
|
days, err := strconv.ParseFloat(daysStr, 64)
|
|
|
|
if err != nil {
|
|
|
|
return 0, err
|
|
|
|
}
|
|
|
|
hours := days * 24.0
|
|
|
|
hoursStr := strconv.FormatFloat(hours, 'f', -1, 64)
|
|
|
|
s = s[:numStart] + hoursStr + "h" + s[i+1:]
|
|
|
|
i--
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if !inNumber {
|
|
|
|
numStart = i
|
|
|
|
}
|
|
|
|
inNumber = (ch >= '0' && ch <= '9') || ch == '.' || ch == '-' || ch == '+'
|
|
|
|
}
|
|
|
|
return time.ParseDuration(s)
|
|
|
|
}
|
|
|
|
|
2021-03-31 04:15:20 +08:00
|
|
|
// InstanceID returns the UUID for this instance, and generates one if it
|
|
|
|
// does not already exist. The UUID is stored in the local data directory,
|
|
|
|
// regardless of storage configuration, since each instance is intended to
|
|
|
|
// have its own unique ID.
|
|
|
|
func InstanceID() (uuid.UUID, error) {
|
2023-12-13 22:39:10 +08:00
|
|
|
appDataDir := AppDataDir()
|
|
|
|
uuidFilePath := filepath.Join(appDataDir, "instance.uuid")
|
2021-09-30 01:17:48 +08:00
|
|
|
uuidFileBytes, err := os.ReadFile(uuidFilePath)
|
2024-01-02 13:48:55 +08:00
|
|
|
if errors.Is(err, fs.ErrNotExist) {
|
2021-03-31 04:15:20 +08:00
|
|
|
uuid, err := uuid.NewRandom()
|
|
|
|
if err != nil {
|
|
|
|
return uuid, err
|
|
|
|
}
|
2023-12-13 22:39:10 +08:00
|
|
|
err = os.MkdirAll(appDataDir, 0o600)
|
|
|
|
if err != nil {
|
|
|
|
return uuid, err
|
|
|
|
}
|
2023-08-08 03:40:31 +08:00
|
|
|
err = os.WriteFile(uuidFilePath, []byte(uuid.String()), 0o600)
|
2021-03-31 04:15:20 +08:00
|
|
|
return uuid, err
|
|
|
|
} else if err != nil {
|
|
|
|
return [16]byte{}, err
|
|
|
|
}
|
|
|
|
return uuid.ParseBytes(uuidFileBytes)
|
|
|
|
}
|
|
|
|
|
2022-10-06 00:59:57 +08:00
|
|
|
// CustomVersion is an optional string that overrides Caddy's
|
|
|
|
// reported version. It can be helpful when downstream packagers
|
|
|
|
// need to manually set Caddy's version. If no other version
|
|
|
|
// information is available, the short form version (see
|
|
|
|
// Version()) will be set to CustomVersion, and the full version
|
|
|
|
// will include CustomVersion at the beginning.
|
|
|
|
//
|
|
|
|
// Set this variable during `go build` with `-ldflags`:
|
|
|
|
//
|
|
|
|
// -ldflags '-X github.com/caddyserver/caddy/v2.CustomVersion=v2.6.2'
|
|
|
|
//
|
|
|
|
// for example.
|
|
|
|
var CustomVersion string
|
|
|
|
|
2022-08-05 01:16:59 +08:00
|
|
|
// Version returns the Caddy version in a simple/short form, and
|
|
|
|
// a full version string. The short form will not have spaces and
|
|
|
|
// is intended for User-Agent strings and similar, but may be
|
|
|
|
// omitting valuable information. Note that Caddy must be compiled
|
|
|
|
// in a special way to properly embed complete version information.
|
|
|
|
// First this function tries to get the version from the embedded
|
|
|
|
// build info provided by go.mod dependencies; then it tries to
|
|
|
|
// get info from embedded VCS information, which requires having
|
|
|
|
// built Caddy from a git repository. If no version is available,
|
2022-10-06 00:59:57 +08:00
|
|
|
// this function returns "(devel)" because Go uses that, but for
|
|
|
|
// the simple form we change it to "unknown". If still no version
|
|
|
|
// is available (e.g. no VCS repo), then it will use CustomVersion;
|
|
|
|
// CustomVersion is always prepended to the full version string.
|
2022-08-05 01:16:59 +08:00
|
|
|
//
|
|
|
|
// See relevant Go issues: https://github.com/golang/go/issues/29228
|
|
|
|
// and https://github.com/golang/go/issues/50603.
|
|
|
|
//
|
|
|
|
// This function is experimental and subject to change or removal.
|
|
|
|
func Version() (simple, full string) {
|
|
|
|
// the currently-recommended way to build Caddy involves
|
|
|
|
// building it as a dependency so we can extract version
|
|
|
|
// information from go.mod tooling; once the upstream
|
|
|
|
// Go issues are fixed, we should just be able to use
|
|
|
|
// bi.Main... hopefully.
|
|
|
|
var module *debug.Module
|
2019-06-29 09:28:28 +08:00
|
|
|
bi, ok := debug.ReadBuildInfo()
|
2022-12-20 05:23:45 +08:00
|
|
|
if !ok {
|
|
|
|
if CustomVersion != "" {
|
|
|
|
full = CustomVersion
|
|
|
|
simple = CustomVersion
|
|
|
|
return
|
|
|
|
}
|
|
|
|
full = "unknown"
|
|
|
|
simple = "unknown"
|
|
|
|
return
|
|
|
|
}
|
|
|
|
// find the Caddy module in the dependency list
|
|
|
|
for _, dep := range bi.Deps {
|
|
|
|
if dep.Path == ImportPath {
|
|
|
|
module = dep
|
|
|
|
break
|
2019-06-29 09:28:28 +08:00
|
|
|
}
|
|
|
|
}
|
2022-08-05 01:16:59 +08:00
|
|
|
if module != nil {
|
|
|
|
simple, full = module.Version, module.Version
|
|
|
|
if module.Sum != "" {
|
|
|
|
full += " " + module.Sum
|
|
|
|
}
|
|
|
|
if module.Replace != nil {
|
|
|
|
full += " => " + module.Replace.Path
|
|
|
|
if module.Replace.Version != "" {
|
|
|
|
simple = module.Replace.Version + "_custom"
|
|
|
|
full += "@" + module.Replace.Version
|
|
|
|
}
|
|
|
|
if module.Replace.Sum != "" {
|
|
|
|
full += " " + module.Replace.Sum
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if full == "" {
|
|
|
|
var vcsRevision string
|
|
|
|
var vcsTime time.Time
|
|
|
|
var vcsModified bool
|
|
|
|
for _, setting := range bi.Settings {
|
|
|
|
switch setting.Key {
|
|
|
|
case "vcs.revision":
|
|
|
|
vcsRevision = setting.Value
|
|
|
|
case "vcs.time":
|
|
|
|
vcsTime, _ = time.Parse(time.RFC3339, setting.Value)
|
|
|
|
case "vcs.modified":
|
|
|
|
vcsModified, _ = strconv.ParseBool(setting.Value)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if vcsRevision != "" {
|
|
|
|
var modified string
|
|
|
|
if vcsModified {
|
|
|
|
modified = "+modified"
|
|
|
|
}
|
|
|
|
full = fmt.Sprintf("%s%s (%s)", vcsRevision, modified, vcsTime.Format(time.RFC822))
|
|
|
|
simple = vcsRevision
|
|
|
|
|
|
|
|
// use short checksum for simple, if hex-only
|
|
|
|
if _, err := hex.DecodeString(simple); err == nil {
|
|
|
|
simple = simple[:8]
|
|
|
|
}
|
|
|
|
|
|
|
|
// append date to simple since it can be convenient
|
|
|
|
// to know the commit date as part of the version
|
|
|
|
if !vcsTime.IsZero() {
|
|
|
|
simple += "-" + vcsTime.Format("20060102")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-10-06 00:59:57 +08:00
|
|
|
if full == "" {
|
|
|
|
if CustomVersion != "" {
|
|
|
|
full = CustomVersion
|
|
|
|
} else {
|
|
|
|
full = "unknown"
|
|
|
|
}
|
|
|
|
} else if CustomVersion != "" {
|
|
|
|
full = CustomVersion + " " + full
|
|
|
|
}
|
|
|
|
|
2022-08-05 01:16:59 +08:00
|
|
|
if simple == "" || simple == "(devel)" {
|
2022-10-06 00:59:57 +08:00
|
|
|
if CustomVersion != "" {
|
|
|
|
simple = CustomVersion
|
|
|
|
} else {
|
|
|
|
simple = "unknown"
|
|
|
|
}
|
2022-08-05 01:16:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return
|
2019-06-29 09:28:28 +08:00
|
|
|
}
|
|
|
|
|
2022-08-05 01:16:59 +08:00
|
|
|
// ActiveContext returns the currently-active context.
|
|
|
|
// This function is experimental and might be changed
|
|
|
|
// or removed in the future.
|
2022-08-02 03:36:22 +08:00
|
|
|
func ActiveContext() Context {
|
2023-07-22 05:32:20 +08:00
|
|
|
currentCtxMu.RLock()
|
|
|
|
defer currentCtxMu.RUnlock()
|
2022-08-02 03:36:22 +08:00
|
|
|
return currentCtx
|
|
|
|
}
|
|
|
|
|
2019-04-12 10:42:55 +08:00
|
|
|
// CtxKey is a value type for use with context.WithValue.
|
|
|
|
type CtxKey string
|
2019-04-08 14:00:14 +08:00
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
// This group of variables pertains to the current configuration.
|
2019-04-08 14:00:14 +08:00
|
|
|
var (
|
2022-08-02 03:36:22 +08:00
|
|
|
// currentCtx is the root context for the currently-running
|
|
|
|
// configuration, which can be accessed through this value.
|
|
|
|
// If the Config contained in this value is not nil, then
|
|
|
|
// a config is currently active/running.
|
2023-07-22 05:32:20 +08:00
|
|
|
currentCtx Context
|
|
|
|
currentCtxMu sync.RWMutex
|
2019-11-05 03:05:20 +08:00
|
|
|
|
|
|
|
// rawCfg is the current, generic-decoded configuration;
|
|
|
|
// we initialize it as a map with one field ("config")
|
|
|
|
// to maintain parity with the API endpoint and to avoid
|
|
|
|
// the special case of having to access/mutate the variable
|
|
|
|
// directly without traversing into it.
|
2022-08-03 04:39:09 +08:00
|
|
|
rawCfg = map[string]any{
|
2019-11-05 03:05:20 +08:00
|
|
|
rawConfigKey: nil,
|
|
|
|
}
|
|
|
|
|
|
|
|
// rawCfgJSON is the JSON-encoded form of rawCfg. Keeping
|
|
|
|
// this around avoids an extra Marshal call during changes.
|
|
|
|
rawCfgJSON []byte
|
|
|
|
|
|
|
|
// rawCfgIndex is the map of user-assigned ID to expanded
|
|
|
|
// path, for converting /id/ paths to /config/ paths.
|
|
|
|
rawCfgIndex map[string]string
|
2023-07-22 05:32:20 +08:00
|
|
|
|
|
|
|
// rawCfgMu protects all the rawCfg fields and also
|
|
|
|
// essentially synchronizes config changes/reloads.
|
|
|
|
rawCfgMu sync.RWMutex
|
2019-04-08 14:00:14 +08:00
|
|
|
)
|
2019-12-30 04:16:34 +08:00
|
|
|
|
2022-03-04 12:41:51 +08:00
|
|
|
// errSameConfig is returned if the new config is the same
|
|
|
|
// as the old one. This isn't usually an actual, actionable
|
|
|
|
// error; it's mostly a sentinel value.
|
|
|
|
var errSameConfig = errors.New("config is unchanged")
|
|
|
|
|
2019-12-30 04:16:34 +08:00
|
|
|
// ImportPath is the package import path for Caddy core.
|
2022-08-05 01:16:59 +08:00
|
|
|
// This identifier may be removed in the future.
|
2019-12-30 04:16:34 +08:00
|
|
|
const ImportPath = "github.com/caddyserver/caddy/v2"
|