ldez/dp-salad-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

init

Browse source
This commit is contained in:
ld3zian 2025-01-04 22:46:09 -07:00
commit f79ed7c8e4
111 changed files with 14931 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1335
configuration/auth-config.md Normal file
View file

File diff suppressed because it is too large Load diff

34
configuration/authy-duo-config.md Normal file
View file

@ -0,0 +1,34 @@
---
title: DP-Salad Configuration
---
# Authy/Duo Configuration
This is like one of those "Choose Your Own Adventure" books! Pick one, not the other, it may be hard to swap later on. You may be able to give your user a choice too! 2FA is handled by either Authelia using an 8 digit code that generates through Authy :logos-authy: or it can be passed off to Duo :simple-icons-cisco: to handle, and then "reinjected" back into the authentication process later on. I'll outline steps for both, and you can choose the method(s) you want your users to be able to 2FA.
---
Authy is probably the easiest, and the cheapest way to configure 2FA, especially if you are going to
have more than 5 users.
The default for the SALA/D Stack for 2FA for the more technical people is SHA1, 8 Digits
All this means for the user is what applications are supported, list is below:
- [Bitwarden](https://bitwarden.com) :simple-icons-bitwarden: / [Vaultwarden](https://github.com/dani-garcia/vaultwarden) :simple-icons-vaultwarden: (Password Managers, Vaultwarden can be selfhosted!, 2FA is setup in addition to account)
- Authy :logos-authy: (Recommended application, named as the best for the stack)
- Aegis (Supported, never used. YMMV)
These three options are supported for 2FA for Authelia :simple-icons-authelia:. It is recommended to actually set this up,
as it prevents complete lockouts.
---
Duo :simple-icons-cisco: is another way to configure 2FA. If you enable Duo 2FA, you'll need to consult the
documentation for Duo setup via Authelia, I've linked some setup links here.
https://www.authelia.com/configuration/second-factor/duo/
https://www.authelia.com/overview/authentication/push-notification/
You'll need to modify the configuration of Authelia to finish the setup of 2FA via Duo.

143
configuration/lldap-config.md Normal file
View file

@ -0,0 +1,143 @@
---
title: LLDAP Configuration
---
# LLDAP Configuration :material-symbols-lock:
LLDAP :material-symbols-lock: is the *Light Lightweight Directory Access Protocol*, and for our purposes, it will store all the information that we have on our users, like usernames, emails, and hashed passwords. These are the typical values, and only a few more exist in this light implementation of LDAP. I include a sample config file if you don't want to set values in the Docker Compose file.
As with the Authelia :simple-icons-authelia: Configuration, please change things in square brackets to your relevant values. This file uses **REPLACE_WITH** to tell you where to replace other such values like secrets/tokens.
```yaml
## Default configuration for Docker.
## All the values can be overridden through environment variables, prefixed
## with "LLDAP_". For instance, "ldap_port" can be overridden with the
## "LLDAP_LDAP_PORT" variable.
## Tune the logging to be more verbose by setting this to be true.
## You can set it with the LLDAP_VERBOSE environment variable.
# verbose=false
## The host address that the LDAP server will be bound to.
## To enable IPv6 support, simply switch "ldap_host" to "::":
## To only allow connections from localhost (if you want to restrict to local self-hosted services),
## change it to "127.0.0.1" ("::1" in case of IPv6)".
ldap_host = "0.0.0.0"
## The port on which to have the LDAP server.
ldap_port = 3890
## The host address that the HTTP server will be bound to.
## To enable IPv6 support, simply switch "http_host" to "::".
## To only allow connections from localhost (if you want to restrict to local self-hosted services),
## change it to "127.0.0.1" ("::1" in case of IPv6)".
http_host = "0.0.0.0"
## The port on which to have the HTTP server, for user login and
## administration.
http_port = 17170
## The public URL of the server, for password reset links.
#http_url = "http://localhost"
## Random secret for JWT signature.
## This secret should be random, and should be shared with application
## servers that need to consume the JWTs.
## Changing this secret will invalidate all user sessions and require
## them to re-login.
## You should probably set it through the LLDAP_JWT_SECRET environment
## variable from a secret ".env" file.
## This can also be set from a file's contents by specifying the file path
## in the LLDAP_JWT_SECRET_FILE environment variable
## You can generate it with (on linux):
## LC_ALL=C tr -dc 'A-Za-z0-9!#%&'\''()*+,-./:;<=>?@[\]^_{|}~' </dev/urandom | head -c 32; echo ''
jwt_secret = "REPLACE_WITH_RANDOM"
## Base DN for LDAP.
## This is usually your domain name, and is used as a
## namespace for your users. The choice is arbitrary, but will be needed
## to configure the LDAP integration with other services.
## The sample value is for "example.com", but you can extend it with as
## many "dc" as you want, and you don't actually need to own the domain
## name.
ldap_base_dn = "dc=[DOMAIN],dc=[TLD]"
## Admin username.
## For the LDAP interface, a value of "admin" here will create the LDAP
## user "cn=admin,ou=people,dc=example,dc=com" (with the base DN above).
## For the administration interface, this is the username.
ldap_user_dn = "admin"
## Admin email.
## Email for the admin account. It is only used when initially creating
## the admin user, and can safely be omitted.
ldap_user_email = "admin@[DOMAIN.TLD]"
## Admin password.
## Password for the admin account, both for the LDAP bind and for the
## administration interface. It is only used when initially creating
## the admin user.
## It should be minimum 8 characters long.
## You can set it with the LLDAP_LDAP_USER_PASS environment variable.
## This can also be set from a file's contents by specifying the file path
## in the LLDAP_LDAP_USER_PASS_FILE environment variable
## Note: you can create another admin user for user administration, this
## is just the default one.
ldap_user_pass = "REPLACE_WITH_PASSWORD"
## Database URL.
## This encodes the type of database (SQlite, MySQL, or PostgreSQL)
## , the path, the user, password, and sometimes the mode (when
## relevant).
## Note: SQlite should come with "?mode=rwc" to create the DB
## if not present.
## Example URLs:
## - "postgres://postgres-user:password@postgres-server/my-database"
## - "mysql://mysql-user:password@mysql-server/my-database"
##
## This can be overridden with the LLDAP_DATABASE_URL env variable.
database_url = "sqlite:///data/users.db?mode=rwc"
## Private key file.
## Contains the secret private key used to store the passwords safely.
## Note that even with a database dump and the private key, an attacker
## would still have to perform an (expensive) brute force attack to find
## each password.
## Randomly generated on first run if it doesn't exist.
## Alternatively, you can use key_seed to override this instead of relying on
## a file.
## Env variable: LLDAP_KEY_FILE
key_file = "/data/private_key"
## Seed to generate the server private key, see key_file above.
## This can be any random string, the recommendation is that it's at least 12
## characters long.
## Env variable: LLDAP_KEY_SEED
#key_seed = "RanD0m STR1ng"
## Ignored attributes.
## Some services will request attributes that are not present in LLDAP. When it
## is the case, LLDAP will warn about the attribute being unknown. If you want
## to ignore the attribute and the service works without, you can add it to this
## list to silence the warning.
#ignored_user_attributes = [ "sAMAccountName" ]
#ignored_group_attributes = [ "mail", "userPrincipalName" ]
## Options to configure SMTP parameters, to send password reset emails.
## To set these options from environment variables, use the following format
## (example with "password"): LLDAP_SMTP_OPTIONS__PASSWORD
[smtp_options]
## Whether to enabled password reset via email, from LLDAP.
#enable_password_reset=true
## The SMTP server.
#server="smtp.gmail.com"
## The SMTP port.
#port=587
## How the connection is encrypted, either "NONE" (no encryption), "TLS" or "STARTTLS".
#smtp_encryption = "TLS"
## The SMTP user, usually your email address.
#user="sender@gmail.com"
## The SMTP password.
#password="password"
## The header field, optional: how the sender appears in the email. The first
## is a free-form name, followed by an email between <>.
#from="LLDAP Admin <sender@gmail.com>"
## Same for reply-to, optional.
#reply_to="Do not reply <noreply@localhost>"
## Options to configure LDAPS.
## To set these options from environment variables, use the following format
## (example with "port"): LLDAP_LDAPS_OPTIONS__PORT
[ldaps_options]
## Whether to enable LDAPS.
#enabled=true
## Port on which to listen.
#port=6360
## Certificate file.
#cert_file="/data/cert.pem"
## Certificate key file.
#key_file="/data/key.pem"
```

20
configuration/swag-config.md Normal file
View file

@ -0,0 +1,20 @@
---
title: Swag Config
---
# SWAG Configuration :simple-icons-linuxserver:
Configuring the Secure Web Application Gateway has a lot of options and potential. It is primarily used to have one gateway for all your services hosted through two ports. Assuming you've used the Docker Compose file, you should be able to view and edit all the configuration files through `/home/[USER]/appdata/swag`. This location now has multiple places you can go.
1. `/home/[USER]/appdata/swag/nginx` - This holds all of the webserver configuration files, this is where you will go when adding a new application/service.
- `/home/[USER]/appdata/swag/nginx/proxy-confs` - This is where all the reverse proxy magic happens, and will likely be the most used folder.
- `/home/[USER]/appdata/swag/nginx/site-confs` - If you want to host a static site using SWAG, this is the conf file that you will modify to make it function.
::: tip
Highly recommend learning how NGINX :logos-nginx: conf files work.
:::
- The files in this nginx directory are all usually not touched, but used for the rest of configuration to connect Authelia :simple-icons-authelia: to SWAG :simple-icons-linuxserver: for logins.
2. `/home/[USER]/appdata/swag/etc/letsencrypt` - This holds all the relevant data for your SSL certificates using Let's Encrypt :simple-icons-letsencrypt:. The current certificates are in the "*live*" folder, under the domain name folder.
3. `/home/[USER]/appdata/swag/dns-conf` - This holds the API keys or access information in order for SWAG to setup Let's Encrypt :simple-icons-letsencrypt: certificates or other DNS :material-symbols-dns-outline: information. There are many providers available, however, Cloudflare will most likely be used. In order for a SSL Certificate to be issued, you will have to set this up.
4. `/home/[USER]/appdata/swag/www` - This folder holds all of the static site stuff, if you decide to make a static site, you can host it through SWAG's configurations. This does take some patience, as getting the stuff exactly right is a bit tricky.
See [How do I add a new application to my stack?](/faq.md#how-do-i-add-a-new-application-to-my-stack) for more information as to how to use the SWAG proxy-confs folder to add a new application to your hosting repertoire.