Giter Site home page Giter Site logo

felddy / foundryvtt-docker Goto Github PK

View Code? Open in Web Editor NEW
528.0 14.0 111.0 2.73 MB

An easy-to-deploy Dockerized Foundry Virtual Tabletop server.

Home Page: https://hub.docker.com/r/felddy/foundryvtt

License: MIT License

Dockerfile 3.60% Shell 48.81% Python 17.60% JavaScript 28.56% TypeScript 1.43%
docker foundryvtt foundry vtt hacktoberfest docker-image virtual-tabletop icosahedron opendnd

foundryvtt-docker's Introduction

foundryvtt-docker

Build CodeQL OpenSSF Scorecard CII Best Practices FoundryVTT Release Version: v11.315

Docker Pulls Docker Image Size (latest by date) Platforms

You can get a Foundry Virtual Tabletop instance up and running in minutes using this container. This Docker container is designed to be secure, reliable, compact, and simple to use. It only requires that you provide the credentials or URL needed to download a Foundry Virtual Tabletop distribution.

Prerequisites

Running

Running with Docker and credentials

You can use the following command to start up a Foundry Virtual Tabletop server. Your foundryvtt.com credentials are required so the container can install and license your server.

docker run \
  --env FOUNDRY_USERNAME='<your_username>' \
  --env FOUNDRY_PASSWORD='<your_password>' \
  --publish 30000:30000/tcp \
  --volume <your_data_dir>:/data \
  felddy/foundryvtt:release

Note

If you are using bash, or a similar shell, consider pre-pending the Docker command with a space to prevent your credentials from being committed to the shell history list. See: HISTCONTROL

Running with Docker and a temporary URL

Alternatively, you may acquire a temporary download URL from your user profile page on the Foundry website.

  1. Navigate to the Purchased Software Licenses page.
  2. Change the Operating System menu item to Linux/NodeJS.
  3. Click the ๐Ÿ”— Timed URL button to obtain the temporary URL.
  4. Use the following command to start up a Foundry Virtual Tabletop server:
docker run \
  --env FOUNDRY_RELEASE_URL='<temporary_url>' \
  --publish 30000:30000/tcp \
  --volume <your_data_dir>:/data \
  felddy/foundryvtt:release

Configuration management

Configuration options are specified using environment variables. It is highly recommended that you use docker compose or similar container orchestration to manage your server's configuration. A docker-compose.yml file, like the example below, is a reliable way to start and maintain a container while capturing its configurations.

Each time the container starts it generates the configuration files needed by Foundry Virtual Tabletop using the values of the environment variables. That means changes made in the server's configuration GUI will not persist between container restarts. If you would like to disable the regeneration of these configuration files, set CONTAINER_PRESERVE_CONFIG to true.

  1. Create a docker-compose.yml file similar to the one below. Provide your credentials as values to the environment variables:

    ---
    version: "3.8"
    
    services:
      foundry:
        image: felddy/foundryvtt:release
        hostname: my_foundry_host
        volumes:
          - type: bind
            source: <your_data_dir>
            target: /data
        environment:
          - FOUNDRY_PASSWORD=<your_password>
          - FOUNDRY_USERNAME=<your_username>
          - FOUNDRY_ADMIN_KEY=atropos
        ports:
          - target: 30000
            published: 30000
            protocol: tcp
  2. Start the container and detach:

    docker compose up --detach
  3. Access the web application at: http://localhost:30000.

If all goes well you should be prompted with the license agreement, and then "admin access key" set with the FOUNDRY_ADMIN_KEY variable.

Using secrets

This container also supports passing sensitive values via Docker secrets. Passing sensitive values like your credentials can be more secure using secrets than using environment variables. Your secrets json file can have any name. This example uses secrets.json. Regardless of the name you choose it must be targeted to config.json within the container as in the example below. See the secrets section below for a table of all supported secret keys.

  1. To use secrets, create a secrets.json file containing the values you want set:

    {
      "foundry_admin_key": "atropos",
      "foundry_password": "your_password",
      "foundry_username": "your_username"
    }
  2. Then add the secret to your docker-compose.yml file:

    ---
    version: "3.8"
    
    secrets:
      config_json:
        file: secrets.json
    
    services:
      foundry:
        image: felddy/foundryvtt:release
        hostname: my_foundry_host
        volumes:
          - type: bind
            source: <your_data_dir>
            target: /data
        environment:
        ports:
          - target: 30000
            published: 30000
            protocol: tcp
        secrets:
          - source: config_json
            target: config.json

Updating your container

The Foundry "Update Software" tab is disabled by default in this container. To upgrade to a new version of Foundry pull an updated image version.

Updating with Docker Compose

  1. Pull the new image from Docker Hub:

    docker compose pull
  2. Recreate the running container:

    docker compose up --detach

Updating with Docker

  1. Stop the running container:

    docker stop <container_id>
  2. Pull the new image:

    docker pull felddy/foundryvtt:release
  3. Follow the previous instructions for running the container above.

Image tags

The images of this container are tagged with semantic versions that align with the version and build of Foundry Virtual Tabletop that they support. It is recommended that most users use the :release tag.

Image:tag Description
felddy/foundryvtt:release The most recent image from the stable channel. These images are considered stable, and well-tested. Most users will use this tag. The latest tag always points to the same version as release.
felddy/foundryvtt:11.315.1 An exact image version.
felddy/foundryvtt:11.315 The most recent image matching the major and minor version numbers.
felddy/foundryvtt:11 The most recent image matching the major version number.
felddy/foundryvtt:latest See the release tag. Why does latest == release?

See the tags tab on Docker Hub for a list of all the supported tags.

Volumes

Mount point Purpose
/data Configuration, data, and log storage.

Ports

The following ports are exposed by this container:

Port Purpose
30000 Foundry Virtual Tabletop server web interface

Environment variables

Required variable combinations

One of the three combinations of environment variables listed below must be set in order for the container to locate and install a Foundry Virtual Tabletop distribution. Although all variables may be specified together, they are evaluated in the following order of precedence:

  1. FOUNDRY_RELEASE_URL, or
  2. FOUNDRY_USERNAME and FOUNDRY_PASSWORD, or
  3. CONTAINER_CACHE

Credentials variables

Name Purpose
FOUNDRY_PASSWORD Account password for foundryvtt.com. Required for downloading an application distribution.
FOUNDRY_USERNAME Account username or email address for foundryvtt.com. Required for downloading an application distribution.

Note: FOUNDRY_USERNAME and FOUNDRY_PASSWORD may be set using secrets instead of environment variables.

Pre-signed URL variable

Name Purpose
FOUNDRY_RELEASE_URL S3 pre-signed URL generate from the user's profile. Required for downloading an application distribution.

Optional variables

Name Purpose Default
CONTAINER_CACHE Set a path to cache downloads of the Foundry distribution archive and speed up subsequent container startups. The path should be in /data or another persistent mount point in the container. Set to "" to disable. Note: When the cache is disabled the container may sleep instead of exiting, in certain circumstances, to prevent a download loop. A distribution can be pre-downloaded and placed into a cache directory. The distribution's name must be of the form: foundryvtt-11.315.zip /data/container_cache
CONTAINER_CACHE_SIZE Set the maximum number of distribution versions to keep in the cache. The minimum is 1. When the limit is exceeded, the oldest versions (lowest version numbers) are removed first. Unset to disable cache size management and keep all versions.
CONTAINER_PATCHES Set a path to a directory of shell scripts to be sourced after Foundry is installed but before it is started. The path should be in /data or another persistent mount point in the container. e.g.; /data/container_patches Patch files are sourced in lexicographic order. CONTAINER_PATCHES are processed after CONTAINER_PATCH_URLS.
CONTAINER_PATCH_URLS Set to a space-delimited list of URLs to be sourced after Foundry is installed but before it is started. Patch URLs are sourced in the order specified. CONTAINER_PATCH_URLS are processed before CONTAINER_PATCHES. โš ๏ธ Only use patch URLs from trusted sources!
CONTAINER_PRESERVE_CONFIG Normally new options.json and admin.txt files are generated by the container at each startup. Setting this to true prevents the container from modifying these files when they exist. If they do not exist, they will be created as normal. false
CONTAINER_PRESERVE_OWNER Normally the ownership of the /data directory and its contents are changed to match that of the server at startup. Setting this to a regular expression will exclude any matching paths and preserve their ownership. Note: This is a match on the whole path, not a search. This is useful if you want mount a volume as read-only inside /data (e.g.; a volume that contains assets mounted at /data/Data/assets).
CONTAINER_URL_FETCH_RETRY Number of times to retry fetching the S3 pre-signed URL using exponential back off. This behavior is useful in continuous integration environments where multiple parallel workflows can exceed the rate-limit of the URL generation service. 0
CONTAINER_VERBOSE Set to true to enable verbose logging for the container utility scripts. false
FOUNDRY_ADMIN_KEY Admin password to be applied at startup. If omitted the admin password will be cleared. May be set using secrets.
FOUNDRY_AWS_CONFIG An absolute or relative path that points to the awsConfig.json or true for AWS environment variable credentials evaluation usage. null
FOUNDRY_COMPRESS_WEBSOCKET Set to true to enable compression of data sent from the server to the client via websocket. This is recommended for network performance. true
FOUNDRY_CSS_THEME Choose the CSS theme for the setup page. Choose from foundry, fantasy, or scifi. foundry
FOUNDRY_DEMO_CONFIG Demo mode allows you to configure a world which will be automatically launched and reset at a frequency of your choosing. When the world is reset, it is deactivated. The source data for the world is restored to its original state using a provided .zip file, and the next reset is automatically scheduled. See: Configuring demo mode.
FOUNDRY_GID gid the daemon will be run under. foundry
FOUNDRY_HOSTNAME A custom hostname to use in place of the host machine's public IP address when displaying the address of the game session. This allows for reverse proxies or DNS servers to modify the public address. null
FOUNDRY_HOT_RELOAD Set to true to allow packages to hot-reload certain assets, such as CSS, HTML, and localization files without a full refresh. This setting is only recommended for developers. false
FOUNDRY_IP_DISCOVERY Allow the Foundry server to discover and report the accessibility of the host machine's public IP address and port. Setting this to false may reduce server startup time in instances where this discovery would timeout. true
FOUNDRY_LANGUAGE The default application language and module which provides the core translation files. en.core
FOUNDRY_LOCAL_HOSTNAME Override the local network address used for invitation links, mirroring the functionality of the FOUNDRY_HOSTNAME option which configures the external address. null
FOUNDRY_LICENSE_KEY The license key to install. e.g.; AAAA-BBBB-CCCC-DDDD-EEEE-FFFF If left unset, a license key will be fetched when using account authentication. If multiple license keys are associated with an account, one will be chosen at random. Specific licenses can be selected by passing in an integer index. The first license key being 1. May be set using secrets.
FOUNDRY_MINIFY_STATIC_FILES Set to true to reduce network traffic by serving minified static JavaScript and CSS files. Enabling this setting is recommended for most users, but module developers may wish to disable it. false
FOUNDRY_PASSWORD_SALT Custom salt string to be applied to the admin password instead of the default salt string. May be set using secrets. null
FOUNDRY_PROTOCOL If left unset Foundry VTT will bind to IPv4 and IPv6 interfaces. To limit to IPv4 only, set to 4. To limit to IPv6 only set to 6. null
FOUNDRY_PROXY_PORT Inform the Foundry server that the software is running behind a reverse proxy on some other port. This allows the invitation links created to the game to include the correct external port. null
FOUNDRY_PROXY_SSL Indicates whether the software is running behind a reverse proxy that uses SSL. This allows invitation links and A/V functionality to work as if the Foundry server had SSL configured directly. false
FOUNDRY_ROUTE_PREFIX A string path which is appended to the base hostname to serve Foundry VTT content from a specific namespace. For example setting this to demo will result in data being served from http://x.x.x.x:30000/demo/. null
FOUNDRY_SSL_CERT An absolute or relative path that points towards a SSL certificate file which is used jointly with the sslKey option to enable SSL and https connections. If both options are provided, the server will start using HTTPS automatically. null
FOUNDRY_SSL_KEY An absolute or relative path that points towards a SSL key file which is used jointly with the sslCert option to enable SSL and https connections. If both options are provided, the server will start using HTTPS automatically. null
FOUNDRY_TELEMETRY Set to true to enable FoundryVTT telemetry, false to disable. This options allows the collection of anonymous usage data to help improve FoundryVTT. null
FOUNDRY_UID uid the daemon will be run under. foundry
FOUNDRY_UPNP Allow Universal Plug and Play to automatically request port forwarding for the Foundry server port to your local network address. false
FOUNDRY_UPNP_LEASE_DURATION Sets the Universal Plug and Play lease duration, allowing for the possibility of permanent leases for routers which do not support temporary leases. To define an indefinite lease duration set the value to 0. null
FOUNDRY_VERSION Version of Foundry Virtual Tabletop to install. 11.315
FOUNDRY_WORLD The world to startup at system start. null
TIMEZONE Container TZ database name UTC

Node.js variables

Any Node.js variables (NODE_*) supplied to the container will be passed to the underlying Node.js server running FoundryVTT. Listed below are some variables that are particularly useful.

Name Purpose
NODE_DEBUG ,-separated list of core modules that should print debug information.
NODE_EXTRA_CA_CERTS When set, the well known "root" CAs (like VeriSign) will be extended with the extra certificates. The file should consist of one or more trusted certificates in PEM format. A message will be emitted (once) with process.emitWarning() if the file is missing or malformed, but any errors are otherwise ignored.
NODE_OPTIONS A space-separated list of command-line options that are interpreted before command-line options, so command-line options will override or compound after anything supplied. Node.js will exit with an error if an option that is not allowed in the environment is used, such as -p or a script file.
NODE_TLS_REJECT_UNAUTHORIZED If the value equals 0, certificate validation is disabled for TLS connections. This makes TLS, and HTTPS by extension, insecure. โš ๏ธ The use of this environment variable is strongly discouraged.

Secrets

Filename Key Purpose
config.json foundry_admin_key Overrides FOUNDRY_ADMIN_KEY environment variable.
config.json foundry_license_key Overrides FOUNDRY_LICENSE_KEY environment variable.
config.json foundry_password Overrides FOUNDRY_PASSWORD environment variable.
config.json foundry_password_salt Overrides FOUNDRY_PASSWORD_SALT environment variable.
config.json foundry_username Overrides FOUNDRY_USERNAME environment variable.

Building from source

Build the image locally using this git repository as the build context:

docker build \
  --build-arg VERSION=11.315.1 \
  --tag felddy/foundryvtt:11.315.1 \
  https://github.com/felddy/foundryvtt-docker.git#develop

Cross-platform builds

To create images that are compatible with other platforms you can use the buildx feature of Docker:

  1. Copy the project to your machine using the Clone button above or the command line:

    git clone https://github.com/felddy/foundryvtt-docker.git
    cd foundryvtt-docker
  2. Build the image using buildx:

    docker buildx build \
      --platform linux/amd64 \
      --build-arg VERSION=11.315.1 \
      --output type=docker \
      --tag felddy/foundryvtt:11.315.1 .

Pre-installed distribution builds

It is possible to install a Foundry Virtual Tabletop distribution into the Docker image at build-time. This results in a significantly larger Docker image, but removes the need to install a distribution at container startup, resulting in a faster startup. It also moves the user authentication to build-time instead of start-time. Note: Credentials are only used to fetch a distribution, and are not stored in the resulting image.

Build the image with credentials:

docker build \
  --build-arg FOUNDRY_USERNAME='<your_username>' \
  --build-arg FOUNDRY_PASSWORD='<your_password>' \
  --build-arg VERSION=11.315.1 \
  --tag felddy/foundryvtt:11.315.1 \
  https://github.com/felddy/foundryvtt-docker.git#develop

Or build the image using a temporary URL:

docker build \
  --build-arg FOUNDRY_RELEASE_URL='<temporary_url>' \
  --build-arg VERSION=11.315.1 \
  --tag felddy/foundryvtt:11.315.1 \
  https://github.com/felddy/foundryvtt-docker.git#develop

Contributing

We welcome contributions! Please see CONTRIBUTING.md for details.

License

This project is released as open source under the MIT license.

All contributions to this project will be released under the same MIT license. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.

foundryvtt-docker's People

Contributors

dav3r avatar dawidizydor avatar dependabot[bot] avatar felddy avatar felerius avatar futurekill avatar hillaryj avatar hugoprudente avatar jsf9k avatar krb1997 avatar mcdonnnj avatar tcflanag avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

foundryvtt-docker's Issues

"unzip: short read" error during container startup

๐Ÿ› Bug Report

Hi. We have your Foundry VTT felddy docker image installed on a Synology 16+ server. We have 0.7.5 installed. We began to update to the latest 0.7.7, but the docker installation stops after just a few seconds.

To Reproduce

Steps to reproduce the behavior:

See above.

Expected behavior

The docker installation should not stop.

Any helpful log output

Clicking the link doesn't work. Copy it into a new browser tab to get an image of the log output:
https://drive.google.com/drive/folders/1MrptUVy6ChITxyPwMqXGitjtqWZ8Lbzs?usp=sharing

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:latest

Paste the results here:

            "Labels": {
                "com.foundryvtt.version": "0.7.7",
                "org.opencontainers.image.authors": "[email protected]",
                "org.opencontainers.image.created": "2020-11-13T16:03:01Z",
                "org.opencontainers.image.description": "An easy-to-deploy Dockerized Foundry Virtual Tabletop server.",
                "org.opencontainers.image.licenses": "MIT",
                "org.opencontainers.image.revision": "acf4d926c2645b9f810a2dff5169580d2354b78b",
                "org.opencontainers.image.source": "https://github.com/felddy/foundryvtt-docker.git",
                "org.opencontainers.image.title": "foundryvtt-docker",
                "org.opencontainers.image.url": "https://github.com/felddy/foundryvtt-docker",
                "org.opencontainers.image.vendor": "Geekpad",
                "org.opencontainers.image.version": "0.7.7"
            },

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

Support setting of serviceConfig option

๐Ÿš€ Feature Proposal

Determine what serviceConfig option does, and support its configuration.
This is visible in 0.8.1. It might have been in 0.8.0.
Undocumented at time of issue creation.

Invalid license after upgrading image

๐Ÿ’ฌ Questions and Help

I was using release v0.7.5 happily using Foundry VTT username and password. It fetched license as expected. But I decided to upgrade to the new v0.7.7 using docker-compose pull as stated in README.md file. I use the same data volume. When I try to use my deployment again, logs say (my license is valid):

[error] License verification failed. Please confirm your Foundry Virtual Tabletop software license

I verified that the data/Config/license.json contains valid information, fetched again after last run.

What I am doing wrong? Do I need to create data volume again? I would like to maintain my worlds, plugins and configuration.

Websocket config?

๐Ÿ’ฌ Questions and Help

I can load foundry and use it just fine internally at http://localhost:30000/ , but when I try to connect to my internet facing hostname with letsencrypt cert all configured, using the Apache2 SSL Proxy config from this page, the setup page loads, but I can't login and keep getting this error in the browser console:

Firefox canโ€™t establish a connection to the server at wss://foundry.mydomain.com/socket.io/?session=<sessionid>&transport=websocket.

(note the extra 's' in wss above)

My VirtualHost has this line (from the page above):

ProxyPass "/socket.io/" "ws*//<my foundry internal ip>:30000/socket.io/"

Is it possible that there's a configuration in your container that is asking for a connection to wss:// instead of ws://? I'm at a loss and don't know how to proceed.

Apache Log, fwiw, says:
[proxy:error] [pid 29863] (111)Connection refused: AH00957: HTTP: attempt to connect to <my foundry internal ip>:30000 (<internal ip again>) failed

Docker image fails to start with the latest version.

๐Ÿ› Bug Report

All of a sudden, a previously functional 0.7.9 image stopped working, and gets stuck starting in an endless chown loop. The image starts up, gets to "Setting data directory permissions", and then a whole bunch of chown errors arise.

To Reproduce

I am unsure what caused the problem as it was working yesterday and stopped working when I got home today.

Some additional info:
I am running this image inside docker on a Synology NAS, and I set up a user jail so I could allow the GM access to the git repo that hosts our game.

Expected behavior

I expected the image to load as usual. A work-around was provided on Foundry Discord, setting the image to 0.7.8 and the FOUNDRY_VERSION configuration variable to 0.7.9 which worked for me.

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:latest

Paste the results here:

com.foundryvtt.version = "0.7.9"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-12-19T18:22:45Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "d7bbea8063e5cbf8cc93ef114aca843be45d299d"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.7.9"

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

Entrypoint | 2020-12-27 22:01:45 | [debug] Timezone set to: UTC
Entrypoint | 2020-12-27 22:01:45 | [info] Starting felddy/foundryvtt container v0.7.9
Entrypoint | 2020-12-27 22:01:45 | [debug] CONTAINER_VERBOSE set.  Debug logging enabled.
Entrypoint | 2020-12-27 22:01:45 | [info] Reading configured secrets from: /run/secrets/config.json
Entrypoint | 2020-12-27 22:01:46 | [info] Foundry Virtual Tabletop 0.7.9 is installed.
Entrypoint | 2020-12-27 22:01:46 | [info] Not modifying existing installation license key.
Entrypoint | 2020-12-27 22:01:46 | [info] Setting data directory permissions.
chown: /data/lib_all/i686: No such file or directory
chown: /data/lib_all/libsynotrigger.so: No such file or directory
chown: /data/lib_all/perl5: No such file or directory
chown: /data/lib_all/sharing/plugin/SYNO.SDS.App.SharingUpload.Application.so: No such file or directory
chown: /data/lib_all/sharing/plugin/SYNO.SDS.App.FileStation3.Instance.so: No such file or directory
chown: /data/lib_all/ld-linux.so.2: No such file or directory
chown: /data/lib_all/terminfo: No such file or directory
chown: /data/Data/var/packages/git/etc: No such file or directory
chown: /data/Data/var/packages/git/target: No such file or directory
chown: /data/Data/etc/ssl/certs/Swisscom_Root_CA_1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/c9f83a1c.0: No such file or directory
chown: /data/Data/etc/ssl/certs/WellsSecure_Public_Root_Certificate_Authority.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/DST_ACES_CA_X6.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/157753a5.0: No such file or directory
chown: /data/Data/etc/ssl/certs/NetLock_Express_=Class_C=_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/UTN_USERFirst_Hardware_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/3efd4dc0.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Equifax_Secure_eBusiness_CA_1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/7d5a75e4.0: No such file or directory
chown: /data/Data/etc/ssl/certs/NetLock_Qualified_=Class_QA=_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/StartCom_Certification_Authority_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/S-TRUST_Authentication_and_Encryption_Root_CA_2005_PN.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/9f0f5fd6.0: No such file or directory
chown: /data/Data/etc/ssl/certs/cb357862.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Certinomis_-_Autoritรฉ_Racine.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/cbeee9e2.0: No such file or directory
chown: /data/Data/etc/ssl/certs/StartCom_Certification_Authority_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Visa_eCommerce_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/0810ba98.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/56657bde.0: No such file or directory
chown: /data/Data/etc/ssl/certs/876f1e28.0: No such file or directory
chown: /data/Data/etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_2007.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/TC_TrustCenter_Class_3_CA_II.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/b6c5745d.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Comodo_Secure_Services_root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/3ee7e181.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Comodo_Trusted_Services_root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/1874d4aa.0: No such file or directory
chown: /data/Data/etc/ssl/certs/f38a011e.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Swisscom_Root_CA_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Swisscom_Root_EV_CA_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/9007ae68.0: No such file or directory
chown: /data/Data/etc/ssl/certs/9d520b32.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Equifax_Secure_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Certification_Authority_of_WoSign_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/WoSign_China.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/5620c4aa.0: No such file or directory
chown: /data/Data/etc/ssl/certs/c99398f3.0: No such file or directory
chown: /data/Data/etc/ssl/certs/China_Internet_Network_Information_Center_EV_Certificates_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/c5e082db.0: No such file or directory
chown: /data/Data/etc/ssl/certs/790a7190.0: No such file or directory
chown: /data/Data/etc/ssl/certs/bb2d49a0.0: No such file or directory
chown: /data/Data/etc/ssl/certs/ef2f636c.0: No such file or directory
chown: /data/Data/etc/ssl/certs/IGC_A.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Staat_der_Nederlanden_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/cfa1c2ee.0: No such file or directory
chown: /data/Data/etc/ssl/certs/CA_WoSign_ECC_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/861e0100.0: No such file or directory
chown: /data/Data/etc/ssl/certs/AddTrust_External_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/c679bc3f.0: No such file or directory
chown: /data/Data/etc/ssl/certs/UTN_USERFirst_Email_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/034868d6.0: No such file or directory
chown: /data/Data/etc/ssl/certs/ACEDICOM_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/e536d871.0: No such file or directory
chown: /data/Data/etc/ssl/certs/024dc131.0: No such file or directory
chown: /data/Data/etc/ssl/certs/8b59b1ad.0: No such file or directory
chown: /data/Data/etc/ssl/certs/TรœBฤฐTAK_UEKAE_Kรถk_Sertifika_Hizmet_SaฤŸlayฤฑcฤฑsฤฑ_-_Sรผrรผm_3.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/a760e1bd.0: No such file or directory
chown: /data/Data/etc/ssl/certs/65b876bd.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Security_Communication_EV_RootCA1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/PSCProcert.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/c5d3212a.0: No such file or directory
chown: /data/Data/etc/ssl/certs/57bbd831.0: No such file or directory
chown: /data/Data/etc/ssl/certs/ae8153b9.1: No such file or directory
chown: /data/Data/etc/ssl/certs/f060240e.0: No such file or directory
chown: /data/Data/etc/ssl/certs/0d1b923b.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Root_CA_Generalitat_Valenciana.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/CA_Disig_Root_R1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/7992b8bb.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/415660c1.1: No such file or directory
chown: /data/Data/etc/ssl/certs/2ab3b959.0: No such file or directory
chown: /data/Data/etc/ssl/certs/RSA_Security_2048_v3.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Buypass_Class_2_CA_1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/bd1910d4.0: No such file or directory
chown: /data/Data/etc/ssl/certs/1ec4d31a.0: No such file or directory
chown: /data/Data/etc/ssl/certs/381ce4dd.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/CNNIC_ROOT.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Sonera_Class_1_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/NetLock_Business_=Class_B=_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/EBG_Elektronik_Sertifika_Hizmet_SaฤŸlayฤฑcฤฑsฤฑ.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/8096d0a9.0: No such file or directory
chown: /data/Data/etc/ssl/certs/24ad0b63.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Juur-SK.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/26eaad2f.0: No such file or directory
chown: /data/Data/etc/ssl/certs/NetLock_Notary_=Class_A=_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/CA_Disig.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/TรœRKTRUST_Elektronik_Sertifika_Hizmet_SaฤŸlayฤฑcฤฑsฤฑ_H6.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/StartCom_Certification_Authority.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/AC_Raรญz_Certicรกmara_S.A..pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Microsec_e-Szigno_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/578d5c04.0: No such file or directory
chown: /data/Data/etc/ssl/certs/WoSign.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/79ad8b43.0: No such file or directory
chown: /data/Data/etc/ssl/certs/b13cc6df.0: No such file or directory
chown: /data/Data/etc/ssl/certs/b8e83700.0: No such file or directory
chown: /data/Data/etc/ssl/certs/667c66d4.0: No such file or directory
chown: /data/Data/etc/ssl/certs/TรœRKTRUST_Elektronik_Sertifika_Hizmet_SaฤŸlayฤฑcฤฑsฤฑ_H5.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/3b2716e5.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Certplus_Class_2_Primary_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_1_Public_Primary_Certification_Authority.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/415660c1.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Certinomis_-_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/fcac10e3.0: No such file or directory
chown: /data/Data/etc/ssl/certs/b7e7231a.0: No such file or directory
chown: /data/Data/etc/ssl/certs/6f2c1157.0: No such file or directory
chown: /data/Data/etc/ssl/certs/592c0a9a.0: No such file or directory
chown: /data/Data/etc/ssl/certs/b42ff584.0: No such file or directory
chown: /data/Data/etc/ssl/certs/812e17de.0: No such file or directory
chown: /data/Data/etc/ssl/certs/19c1fa33.0: No such file or directory
chown: /data/Data/etc/ssl/certs/d9d12c58.0: No such file or directory
chown: /data/Data/etc/ssl/certs/AddTrust_Qualified_Certificates_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/67d559d1.0: No such file or directory
chown: /data/Data/etc/ssl/certs/ApplicationCA_-_Japanese_Government.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/ComSign_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/AddTrust_Public_Services_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/ae8153b9.0: No such file or directory
chown: /data/Data/etc/ssl/certs/5d63b0ae.0: No such file or directory
chown: /data/Data/etc/ssl/certs/S-TRUST_Universal_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/GeoTrust_Global_CA_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/d957f522.0: No such file or directory

Support email addresses in FOUNDRY_USERNAME environment variable

๐Ÿš€ Feature Proposal

Support using an email address as the FOUNDRY_USERNAME.

Motivation

Reported by: @Corvimae

It is possible to log in to foundryvtt.com using your email address. But when the download_release.js helper util goes to fetch the license key, it will error out as it is trying to build a path with the username.

We could document that FOUNDRY_USERNAME is not supposed to be an email address but user's don't read the docs, and it will be simpler in the long run to allow this to happen.

Example

[email protected]
FOUNDRY_PASSWORD=yourmom

Pitch

Make the user's lives easier. Things are hard enough nowadays.

Add "release" tag

๐Ÿš€ Feature Proposal

Add support for a :release tag that will point to the latest version from the Foundry "release" channel.

The release tag will be added to any GitHub published release that does not have the "pre-release" checkbox checked. Beta and alpha channel versions will continue to be published with the :latest tag.

Motivation

Not all users live on the bleeding edge. In fact, most users probably want the stable builds offered from the "release" channel. This will allow them to only receive these images.

Example

docker run \
  --env FOUNDRY_USERNAME='<your_username>' \
  --env FOUNDRY_PASSWORD='<your_password>' \
  --publish 30000:30000/tcp \
  --volume /data:<your_data_dir> \
  felddy/foundryvtt:release

Pitch

It was requested by Tatonker on the Foundry discord. The users are always right... (usually)

Make CURL respect 302 Redirect when download FoundryVTT ZIP file

๐Ÿš€ Feature Proposal

Currently, in entrypoint.sh when download FoundryVTT ZIP file, CURL doesn't follow 302 Redirect, causing failed download if that URL responses 302.

log "Downloading Foundry Virtual Tabletop release."
# Download release if newer than cached version.
# Filter out warnings about bad date formats if the file is missing.
curl --fail --time-cond "${release_filename}" \
--output "${downloading_filename}" "${s3_url}" 2>&1 | \
tr "\r" "\n" | \
sed --unbuffered '/^Warning: .* date/d'

I'd say it's better to add -L/--location option to respect 302 Redirect.

Motivation

Following 302 Redirect will make the download process more "compatible" with provided other URLs than the direct URL.

Example

Corresponding FOUNDRY_RELEASE_URL returns 301 Moved or 302 Redirect.
docker run -e FOUNDRY_RELEASE_URL='https://dl/linux/fvtt.zip' felddy/foundryvtt-docker

When downloading, CURL uses --location to respect that 301/302 status code and go to Location to get the zip.

Pitch

Foundry VTT Docker related.

Modules folder indexing not working...

๐Ÿ’ฌ Questions and Help

Hi. When I upload modules directly to the Data folder on our Synology server, and then restart the synology, the new modules are not seen by Foundry. If I open a browser in Foundry and go to modules folder, the new modules are seen but they do not show up in the setup modules list.

Please advise what to do, I don't know if this is a bug or not.

Add flag to use command line option --ignore-gpu-blacklist

๐Ÿš€ Feature Proposal

Per the optimization recommendations at https://prezi.com/view/Wpq1WQv92LC1KNwwAEyG/, put together by Anathema, this can force Foundry to use Hardware acceleration when it might otherwise be attempting to use software rendering, thus improving performance. This would be optional, and it could also cause problems with unsupported graphics cards.

Motivation

Was double-checking my setup and could not verify that this was being performed in the container.

Example

Set the FOUNDRY_IGNORE_GPU_BLACKLIST env variable to true and it will add the --ignore-gpu-blacklist flag to the command line when launching Foundry.

Pitch

Recommended best practice for troubleshooting poor performance by the community lead for Foundry?

CONTAINER_PATCHES parameter not set error.

๐Ÿ› Bug Report

Error appears in logs related to unset CONTAINER_PATCHES variable when this is supposed to be optional. Does not prevent startup.

To Reproduce

Steps to reproduce the behavior:

  • Start a container without the CONTAINER_PATCHES env var set.
  • Observe error in log stream.

Expected behavior

No errors logged for unused parameters.

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:latest

Paste the results here:

com.foundryvtt.version = "0.6.4"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-06-29 19:55:59+00:00"
org.opencontainers.image.licenses = "CC0-1.0"
org.opencontainers.image.revision = "61dd6a9b3a2394716bb7ac367f07f5e953f689c3"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "Foundry Virtual Tabletop"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.6.4"

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

foundry    | ./entrypoint.sh: line 107: CONTAINER_PATCHES: parameter not set

Prevent entrypoint.sh from crawling mount points in data folder

๐Ÿš€ Feature Proposal

adding the -xdev flag to the find command to skip setting permissions on a mounted point

Motivation

Whenever I create a container with the image the find command in entrypoint.sh user for setting permissions will crawl my nfs mounted points that I use for assets, destroying all of the permissions on the drive along with hanging for a very long time while it does so. Some people like me map assets on a network drive and mount it at the root folder so it is accessible to all worlds within a foundry instance. In my case in /data/assets. This is not desirable.

Example

This is the command it runs :

find /data -regex "${CONTAINER_PRESERVE_OWNER:-}" -prune -o -exec chown "${FOUNDRY_UID:-foundry}:${FOUNDRY_GID:-foundry}" {} +

This is the proposed change :

find /data -regex "${CONTAINER_PRESERVE_OWNER:-}" -xdev -prune -o -exec chown "${FOUNDRY_UID:-foundry}:${FOUNDRY_GID:-foundry}" {} +

Pitch

I believe the most common usecase for mounting a folder inside the /data folder is to mount network storage with assets.
I believe this will not impact regular users and prevent having to maintain a patch for the issue.

Thanks for considering it

Foundry site can return usernames that need to be lowercased before use in a URL.

๐Ÿ› Bug Report

Reported by: @shirkie

If FOUNDRY_USERNAME is set to foobar it is possible for FoundryVTT can respond with:
Successfully logged in as: Foobar (note the case change)

We use the reply username since some users set FOUNDRY_USERNAME to their email address.

When the LICENSE_URL is constructed, it is invalid with the capitalized username.

The solution is to lowercase the returned username before it is used in the URL.

To Reproduce

Steps to reproduce the behavior:

  • Have a foundryvtt profile with a capitalized name.
  • Try to use the container.
  • Downloading the license will fail.

Expected behavior

  • License failure will not occur.

Any helpful log output

Paste the results here:

(simulated output)

foundry_1  | Starting felddy/foundryvtt container v0.6.1
foundry_1  | No Foundry Virtual Tabletop installation detected.
foundry_1  | Installing Foundry Virtual Tabletop 0.6.1
foundry_1  | [2020-06-05 14:22:42.739 +0000] INFO : Requesting CSRF tokens from https://foundryvtt.com
foundry_1  | [2020-06-05 14:22:43.351 +0000] INFO : Logging in as: foobar
foundry_1  | [2020-06-05 14:22:44.080 +0000] INFO : Successfully logged in as: Foobar
foundry_1  | [2020-06-05 14:22:44.080 +0000] INFO : Fetching license.
(node:7) UnhandledPromiseRejectionWarning: Error: Unexpected response Not Found
...

Cross origin error in current release version

๐Ÿ› Bug Report

After entering the admin password, the website crashed with a cross-origin error.

To Reproduce

Steps to reproduce the behavior:

Update to the current release version.
Try to activate VTT using the correct admin password.

Expected behavior

Entering the correct credentials should lead me to my vtt setup.

License page empty on launch

Hi,
Not sure if this is a foundry issue or a docker image issue, so I figured I'd ask.
I've configured the image on my remote server as well as nginx, and when I connect I get redirected to the license page as expected. But there's no text on the page, and so no way to proceed. Did I do something wrong in the setup?

My launch command is:

sudo podman run \
        --env FOUNDRY_USERNAME='TTIO' \
        --env FOUNDRY_PASSWORD=<snipped> \
        --env FOUNDRY_ADMIN_KEY=<snipped> \
        --env FOUNDRY_HOSTNAME=<snipped> \
        --env FOUNDRY_PROXY_PORT=443 \
        --env FOUNDRY_PROXY_SSL=true \
        --publish 30000:30000/tcp \
        --volume foundry-vtt:/data \
        -d \
        --name foundry-vtt \
        felddy/foundryvtt:release

The NGINX file is a simple reverse proxy to port 30000, with a https redirect.

Support S3 Pre-signed URLs arguments in leiu of username/password

๐Ÿš€ Feature Proposal

Requested by @kakaroto

Allow users to provide a pre-signed S3 URL as the mechanism to download the foundry release. These URLs may be generated from the user's profile page by clicking on the ๐Ÿ”— icon next to the distribution.

Also update the documentation to note the HISTCONTROL options available in bash. Especially the prepended space to prevent saving a command to history.

See: https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html

Motivation

OPSEC. Users may be wary or providing credentials to a container. Not all users have the ability to do a code review of project and trust the code is not harvesting their credentials. (It's not: โœ‹)

Providing the URL will allow users to sleep that much easier, and we all need that right now.

Example

docker run \
  --env FOUNDRY_RELEASE_URL='https://foundryvtt.s3.amazonaws.com/releases/0.6.2/foundryvtt-0.6.2.zip?AWSAccessKeyId=AKIAISZIIE42YLQZKLEQ&Signature=ctAA11fsXga%2FJUZ%2BblqKl3UJBCQ%3D&Expires=1591839231' \
  --publish 30000:30000/tcp \
  --volume /data:<your_data_dir> \
  felddy/foundryvtt:latest

Pitch

It will make users happier. And we like happy users.

Startup Crash: uv_os_homedir returned ENOENT (no such file or directory)

๐Ÿ› Bug Report

Crash on startup for latest container version.

To Reproduce

Steps to reproduce the behavior:

  • Pull the latest tag and attempt to start the docker container.

Expected behavior

The container starts up and runs.

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:latest

Paste the results here:

com.foundryvtt.version = "0.6.4"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-06-23 19:14:35+00:00"
org.opencontainers.image.licenses = "CC0-1.0"
org.opencontainers.image.revision = "dab35fcf04e63049d8777b2f3bedb10844c9e33c"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "Foundry Virtual Tabletop"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.6.4"

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

foundry    | Downloading Foundry release.
foundry    | Connecting to foundryvtt.s3.amazonaws.com (52.218.213.10:443)
foundry    | saving to 'foundryvtt-0.6.4.zip'
foundry    | foundryvtt-0.6.4.zip   4% |*                               | 4342k  0:00:20 ETA
foundry    | foundryvtt-0.6.4.zip  16% |*****                           | 14.9M  0:00:10 ETA
foundry    | foundryvtt-0.6.4.zip  28% |*********                       | 25.6M  0:00:07 ETA
foundry    | foundryvtt-0.6.4.zip  40% |************                    | 36.4M  0:00:05 ETA
foundry    | foundryvtt-0.6.4.zip  51% |****************                | 47.1M  0:00:04 ETA
foundry    | foundryvtt-0.6.4.zip  63% |********************            | 57.8M  0:00:03 ETA
foundry    | foundryvtt-0.6.4.zip  75% |************************        | 68.5M  0:00:02 ETA
foundry    | foundryvtt-0.6.4.zip  87% |***************************     | 79.2M  0:00:01 ETA
foundry    | foundryvtt-0.6.4.zip  98% |******************************* | 89.8M  0:00:00 ETA
foundry    | foundryvtt-0.6.4.zip 100% |********************************| 90.8M  0:00:00 ETA
foundry    | 'foundryvtt-0.6.4.zip' saved
foundry    | Installing Foundry Virtual Tabletop 0.6.4
foundry    | Switching uid:gid to 111:115 and restarting.
foundry    | Starting felddy/foundryvtt container v0.6.4
foundry    | Foundry Virtual Tabletop 0.6.4 is installed.
foundry    | Generating options.json file.
foundry    | Setting 'Admin Access Key'.
foundry    | Starting Foundry Virtual Tabletop.
foundry    | SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_homedir returned ENOENT (no such file or directory)
foundry    |     at _getEnvDataPath (/home/foundry/resources/app/main.js:128:22)
foundry    |     at getPaths (/home/foundry/resources/app/main.js:55:23)
foundry    |     at Object.<anonymous> (/home/foundry/resources/app/main.js:158:18)
foundry    |     at Module._compile (internal/modules/cjs/loader.js:1138:30)
foundry    |     at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
foundry    |     at Module.load (internal/modules/cjs/loader.js:986:32)
foundry    |     at Function.Module._load (internal/modules/cjs/loader.js:879:14)
foundry    |     at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
foundry    |     at internal/main/run_main_module.js:17:47

Authentication fails if password contains $ - docker-compose build

Hey Felddy

I'm migrating my helm-chart to your container and I have found a bug :)

My password contains $a.

As you know the $a on shell when enclosed by double-quotes are executed trying to retrieve the value of a, and the $ ended stripped.

I have check the download_release.py sending my execution with single-quotes and it works, so that part of the code is 100%.

I also checked the the Dockerfile and it looks 100%

https://github.com/felddy/foundryvtt-docker/blob/develop/Dockerfile#L21

To fix it I just had to enclose the password and username with single-quotes on the commands.

Like so:

docker-compose build \
--build-arg USERNAME='your_username' \
--build-arg PASSWORD='your_password'

I'm doing a PR to fix this as users less skilled in docker may face similar issues.

2020-05-25 09:10:46,845 CRITICAL Unable to log in as <username>, verify your credentials.

Configuration Changes Won't Save

๐Ÿ› Bug Report

When I try to make configuration changes on the setup page (default world, admin password, etc) they don't seem to save. The container restarts but nothing changes once it's back up.

To Reproduce

Steps to reproduce the behavior:

  • Start up a container
  • Change the default world or another value in the "Configuration" pane
  • Save the change
  • Re-enter the "Configuration" pane after the container reboots

Expected behavior

For the changed values to stay changed

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:latest

Paste the results here:

com.foundryvtt.version = "0.8.6"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2021-05-31T15:02:59Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "44f414116ddaf1fb9ba2d8c9f6ebf1bb79fa34a0"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.8.6"

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

I don't see any log output that would relate to this. debug.log doesn't seem to contain anything related to this issue and error.log only seems to have errors from some of my modules.

Authentication skipped although USERNAME/PASSWORD set with RELEASE_URL

๐Ÿ› Bug Report

if [ ! -f /data/Config/license.json ]; then
log "Installation not yet licensed."
mkdir -p /data/Config
set +o nounset # length check will fail
if [[ ${#FOUNDRY_LICENSE_KEY} -ge ${license_min_length} ]]; then
set -o nounset
log "Applying license key passed via FOUNDRY_LICENSE_KEY."
# FOUNDRY_LICENSE_KEY is long enough to be a key
echo "{ \"license\": \"${FOUNDRY_LICENSE_KEY}\" }" | tr -d '-' > /data/Config/license.json
elif [ -f ${cookiejar_file} ]; then
log "Attempting to fetch license key from authenticated account."
if [[ "${FOUNDRY_LICENSE_KEY:-}" ]]; then
# FOUNDRY_LICENSE_KEY can be an index, try passing it.
# CONTAINER_VERBOSE default value should not be quoted.
# shellcheck disable=SC2086
fetched_license_key=$(./get_license.js ${CONTAINER_VERBOSE+--log-level=debug} --select="${FOUNDRY_LICENSE_KEY}" "${cookiejar_file}")
else
# shellcheck disable=SC2086
fetched_license_key=$(./get_license.js ${CONTAINER_VERBOSE+--log-level=debug} "${cookiejar_file}")
fi
echo "{ \"license\": \"${fetched_license_key}\" }" > /data/Config/license.json
else
log_warn "Unable to apply a license key since niether a license key nor credentials were provided. The license key will need to be entered in the browser."
fi
set -o nounset
else
log "Not modifying existing installation license key."
fi

If FOUNDRY_RELEASE_URL, FOUNDRY_USERNAME and FOUNDRY_PASSWORD set, during the installation step/fetching S3 URL, it skipped the initial authentication.

After that, the script won't authenticate again, so there is no cookiejar_file.

So it will run into L186 and log Unable to apply a license key.

log_warn "Unable to apply a license key since niether a license key nor credentials were provided. The license key will need to be entered in the browser."

By the way, niether misspelled ;)

To Reproduce

Steps to reproduce the behavior:

  • Set valid FOUNDRY_RELEASE_URL, FOUNDRY_USERNAME and FOUNDRY_PASSWORD.
  • Open FVTT and it showed the license input page.

Expected behavior

If all set, it will still generate the license file.

Any helpful log output

Entrypoint | 2020-11-02 09:22:30 | [info] Installing Foundry Virtual Tabletop 0.7.5
Entrypoint | 2020-11-02 09:22:32 | [info] Installation not yet licensed.
Entrypoint | 2020-11-02 09:22:32 | [warn] Unable to apply a license key since niether a license key nor credentials were provided.  The license key will need to be entered in the browser.

Container "Unhealthy" in Portainer

๐Ÿ› Bug Report

Portainer labels this container as "unhealthy" with the "Failure count" climbing by one every 30 seconds. When I go into the Portainer event list, it just says "Unsupported event". I don't see anything problems in the actual container logs, and the container otherwise runs well. I am currently running containers on a QNAP NAS via Container Station.

To Reproduce

  • Install the portainer/portainer-ce:latest container (current version 2.0.0)
  • Install felddy/foundryvtt:release
  • In Portainer web interface, go to containers, see the state of FoundryVTT to be "unhealthy" instead of "running."
  • In Portainer web interface, open FoundryVTT container, see "Container Health Status: unhealthy" and "Failure count" increase by one every 30 seconds
  • In Portainer web interface, go to Events and see every 30 seconds:
2020-11-27 23:11:29 | container | Unsupported event
2020-11-27 23:11:29 | container | Exec instance started
2020-11-27 23:11:29 | container | Exec instance created

Expected behavior

Healthy container

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:latest

Paste the results here:

[~] # docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}'     felddy/foundryvtt:release
com.foundryvtt.version = "0.7.7"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-11-13T16:03:01Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "acf4d926c2645b9f810a2dff5169580d2354b78b"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.7.7"

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

Entrypoint | 2020-11-28 05:19:06 | [info] Starting felddy/foundryvtt container v0.7.7,
Entrypoint | 2020-11-28 05:19:06 | [info] Foundry Virtual Tabletop 0.7.7 is installed.,
Entrypoint | 2020-11-28 05:19:06 | [info] Not modifying existing installation license key.,
Entrypoint | 2020-11-28 05:19:06 | [info] Setting data directory permissions.,
Entrypoint | 2020-11-28 05:19:10 | [info] Starting launcher with uid:gid as foundry:foundry.,
Launcher | 2020-11-28 05:19:10 | [info] Generating options.json file.,
Launcher | 2020-11-28 05:19:10 | [info] Setting 'Admin Access Key'.,
Launcher | 2020-11-28 05:19:10 | [info] Starting Foundry Virtual Tabletop.,
FoundryVTT | 2020-11-28 05:19:11 | [info] Foundry Virtual Tabletop - Version 0.7.7,
FoundryVTT | 2020-11-28 05:19:11 | [info] Running on Node.js - Version 12.19.0,
FoundryVTT | 2020-11-28 05:19:11 | [info] Loading data from user directory - /data,
FoundryVTT | 2020-11-28 05:19:11 | [info] Application Options:,
{,
  "port": 30000,,
  "upnp": false,,
  "fullscreen": false,,
  "hostname": "(hidden)",,
  "routePrefix": "foundryvtt",,
  "sslCert": null,,
  "sslKey": null,,
  "awsConfig": null,,
  "dataPath": "/data",,
  "proxySSL": true,,
  "proxyPort": 443,,
  "minifyStaticFiles": false,,
  "updateChannel": "release",,
  "language": "en.core",,
  "world": null,,
  "serviceConfig": null,,
  "isElectron": false,,
  "isNode": true,,
  "isSSL": false,,
  "demo": false,,
  "noupdate": false,,
  "adminKey": "****************",
},
FoundryVTT | 2020-11-28 05:19:11 | [info] License verification succeeded,
FoundryVTT | 2020-11-28 05:19:12 | [info] Server started and listening on port 30000

Inspecting container includes this:

    "State": {
        "Dead": false,
        "Error": "",
        "ExitCode": 0,
        "FinishedAt": "2020-11-28T05:18:56.087416684Z",
        "Health": {
            "FailingStreak": 27,
            "Log": [
                {
                    "End": "2020-11-27T23:33:09.088843651-06:00",
                    "ExitCode": 1,
                    "Output": "",
                    "Start": "2020-11-27T23:33:09.001680468-06:00"
                },
                {
                    "End": "2020-11-27T23:33:39.184889219-06:00",
                    "ExitCode": 1,
                    "Output": "",
                    "Start": "2020-11-27T23:33:39.092357315-06:00"
                },
                {
                    "End": "2020-11-27T23:34:09.290409289-06:00",
                    "ExitCode": 1,
                    "Output": "",
                    "Start": "2020-11-27T23:34:09.189952448-06:00"
                },
                {
                    "End": "2020-11-27T23:34:39.393606688-06:00",
                    "ExitCode": 1,
                    "Output": "",
                    "Start": "2020-11-27T23:34:39.297397814-06:00"
                },
                {
                    "End": "2020-11-27T23:35:09.489496139-06:00",
                    "ExitCode": 1,
                    "Output": "",
                    "Start": "2020-11-27T23:35:09.398550595-06:00"
                }
            ],
            "Status": "unhealthy"
        },
        "OOMKilled": false,
        "Paused": false,
        "Pid": 9716,
        "Restarting": false,
        "Running": true,
        "StartedAt": "2020-11-28T05:19:06.401790056Z",
        "Status": "running"
    }

Brainstorm: Preload modules/systems/worlds

Hey Felddy.

I would like to brains storm with you something that I was thinking to add but I'm not sure if would make a lot of sense.

As we are using containers let's imagine that I have my 5gb assets folder or have a world world ready to play and would like to add to a clean server for any weird reason.

I was thinking a mechanism similar to what you do with foundry.zip now to incase some environment variables are passed with the URL of the location of the file it would fetch it and unzip on the proper directories o form the /data/Data.

This could also work for doing some git clones too so you don't need to go for the interface and select the mechanics and you can have a setup fully configured based on the environments variable and you could just "docker-compose up" or in may case "helm install foundry-vtt/" and couple seconds later everything is there.

What do you think about it?

Thanks.

Issues with traefik reverse proxy and nginx-proxy

๐Ÿ’ฌ Questions and Help

Hey there. I'm trying to make foundryvtt run in my docker environment with nginx-proxy or traefik as reverse proxy (I've tried on two different servers), but it seems that I'm unable to get a valid ssl certificate.
Here are the error messages from both proxies:

Traefik

traefik    | time="2020-11-27T09:40:39+01:00" level=error msg="Unable to obtain ACME certificate for domains \"sub.domain.tld\": unable to generate a certificate for the domains [sub.domain.tld]: error: one or more domains had a problem:\n[sub.domain.tld] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: The key authorization file from the server did not match this challenge \"4mkuOAtxpL7zv4TxQbdpj1oSbybHxb72M546moVM0bI.xIYdb4NK6tj3L953MqLSs6i7yY1p0v43kP5ZBrOOlHU\" != \"error_kas_28\", url: \n" rule="Host(`sub.domain.tld`)" providerName=http.acme routerName=foundryvtt-secure@docker

nginx-proxy

nginx-proxy          | 2020/11/27 15:41:34 [warn] 44#44: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: "/etc/nginx/certs/sub.domain.tld.crt"
nginx-proxy          | 2020/11/27 15:41:35 [error] 44#44: *4266 no live upstreams while connecting to upstream, client: 149.224.201.106, server: sub.domain.tld, request: "GET / HTTP/2.0", upstream: "http://sub.domain.tld/", host: "sub.domain.tld"

Here is my docker-compose file:

foundry:
   image: felddy/foundryvtt:release
   container_name: foundryvtt
   init: true
   restart: "unless-stopped"
   volumes:
     - foundry_data:/data
   environment:
     - FOUNDRY_HOSTNAME=sub.domain.tld
     - FOUNDRY_PROXY_SSL=true
     - TIMEZONE=Europe/Berlin
   ports:
     - "30000:30000"
   secrets:
     - source: config_json
       target: config.json
   labels:
     - "traefik.enable=true"
     - "traefik.http.routers.foundryvtt.entrypoints=http"
     - "traefik.http.routers.foundryvtt.rule=Host(`sub.domain.tld`)"
     - "traefik.http.middlewares.foundryvtt-https-redirect.redirectscheme.scheme=https"
     - "traefik.http.routers.foundryvtt.middlewares=foundryvtt-https-redirect"
     - "traefik.http.routers.foundryvtt-secure.entrypoints=https"
     - "traefik.http.routers.foundryvtt-secure.rule=Host(`sub.domain.tld`)"
     - "traefik.http.routers.foundryvtt-secure.tls=true"
     - "traefik.http.routers.foundryvtt-secure.tls.certresolver=http"
     - "traefik.http.routers.foundryvtt-secure.service=foundryvtt"
     - "traefik.http.services.foundryvtt.loadbalancer.server.port=30000"
     - "traefik.docker.network=web"

For nginx-proxy erase everything under label and insert under environments

- VIRTUAL_HOST=sub.domain.tld
- LETSENCRYPT_HOST=sub.domain.tld
- [email protected]
- VIRTUAL_PORT=30000

I'm honest. I don't know what the problem is. For me, it seems that there is something with the container, since every other container on both server are running without any problems.
Maybe someone can point me in the right direction.

Thanks for your help in advance.

If the optional FOUNDRY_VERSION variable is omitted by the user, container fails to startup due to parameter not set

When removing the FOUNDRY_VERSION environment variable, even though it's listed as optional it led to failures on start up because it was missing.

When I set up the Docker container on my Synology NAS, the UI did set it to a default value of 0.6.5 as expected. However, I wanted to remove this variable or else tools such as Watchtower, which auto update containers, would not work properly. Watchtower would update the container, but since it recreates using the same container settings and environment variables, the Foundry software would remain at the previous version, instead of updating to the updated version as intended.

To Reproduce

Steps to reproduce the behavior:

  • Remove FOUNDRY_VERSION from your docker install/launch environment
  • Launch the container

Expected behavior

When lacking the FOUNDRY_VERSION variable there should be a sane default to fall back to. In this case, the version matching the image I have.

Any helpful log output

Output when running without FOUNDRY_VERSION explicitly set by the user:

Entrypoint \| 2020-08-27 02:20:34 \| [info] Starting felddy/foundryvtt container v0.6.5 | stdout
Entrypoint \| 2020-08-27 02:20:34 \| [info] Foundry Virtual Tabletop 0.6.5 is installed. | stdout
./entrypoint.sh: line 55: FOUNDRY_VERSION: parameter not set | stdout

TURN server doesn't run

๐Ÿ› Bug Report

When using the A/V service, a TURN server is supposed to startup and bind to udp:33478
I've enabled A/V in my world and no TURN server is spawned.

How to set data folder to write mode

๐Ÿ’ฌ Questions and Help

Is it possible to set the data folder to rw permission? When I up my image, the permission of the data folder change to docker user, and it's not possible anymore to change unless I do it in Foundry.

Reading from secrets fails after pivot to unprivileged user

๐Ÿ› Bug Report

When the entrypoint.sh drops privileges via su-exec, and calls itself, it loses the ability to read from /run/secrets/config.json which is mode 0600 and owned by root:root. This causes a failure of the unprivileged user to read the secrets file, resulting in unpopulated variables, and unconfigured options (eg - admin access key).

To Reproduce

  • Follow instructions from README on setting up docker-compose with secrets
  • Attempt to start the container with docker-compose up

Expected behavior

Data from secrets should be correctly populated.

As an aside, I'd strongly suggest splitting the entrypoint.sh out into two files - one to do the bootstrapping with elevated privileges, and one that's executed with reduced privs that actually runs the application. This will make it vastly easier to understand what should be done and what privs are expected, at each stage.

I can see a few ways of solving this problem (roughly in order of preference):

  • perform all work that needs access to secret data before privileges are dropped
  • export the variables that hold the associated values, so that the sub-process has access to them without needing access to the secrets file
  • modify permissions on the secrets file so that the sub-process can access the file directly

Any helpful log output

Version info (release tag):

com.foundryvtt.version = "0.6.5"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-07-26 20:39:57+00:00"
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "dad0abfe061e9dbae536bf986cd1533a8c2f97e5"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "Foundry Virtual Tabletop"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.6.5"

Log output illustrating problems:

foundry_1  | Entrypoint | 2020-08-02 07:01:24 | [info] Starting felddy/foundryvtt container v0.6.5
foundry_1  | Entrypoint | 2020-08-02 07:01:24 | [info] Reading configured secrets from: /run/secrets/config.json
foundry_1  | Entrypoint | 2020-08-02 07:01:25 | [info] No Foundry Virtual Tabletop installation detected.
foundry_1  | Entrypoint | 2020-08-02 07:01:25 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
foundry_1  | Authenticate | 2020-08-02 07:01:25 | [debug] Saving cookies to: cookiejar.json
foundry_1  | Authenticate | 2020-08-02 07:01:25 | [info] Requesting CSRF tokens from https://foundryvtt.com
foundry_1  | Authenticate | 2020-08-02 07:01:25 | [debug] Fetching: https://foundryvtt.com
foundry_1  | Authenticate | 2020-08-02 07:01:26 | [info] Logging in as: <redacted>
foundry_1  | Authenticate | 2020-08-02 07:01:26 | [debug] Fetching: https://foundryvtt.com/auth/login/
foundry_1  | Authenticate | 2020-08-02 07:01:26 | [debug] Community URL: /community/<redacted>
foundry_1  | Authenticate | 2020-08-02 07:01:26 | [info] Successfully logged in as: <redacted>
foundry_1  | ReleaseURL | 2020-08-02 07:01:26 | [debug] Loading cookies from: cookiejar.json
foundry_1  | ReleaseURL | 2020-08-02 07:01:26 | [info] Fetching S3 pre-signed release URL for 0.6.5...
foundry_1  | ReleaseURL | 2020-08-02 07:01:26 | [debug] Fetching: https://foundryvtt.com/releases/download?version=0.6.5&platform=linux
foundry_1  | ReleaseURL | 2020-08-02 07:01:26 | [debug] S3 presigned URL: https://foundryvtt.s3.amazonaws.com/releases/0.6.5/foundryvtt-0.6.5.zip?<redacted>
foundry_1  | Entrypoint | 2020-08-02 07:01:26 | [info] Using CONTAINER_CACHE: /data/container_cache
foundry_1  | Entrypoint | 2020-08-02 07:01:26 | [info] Downloading Foundry Virtual Tabletop release.
foundry_1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
foundry_1  |                                  Dload  Upload   Total   Spent    Left  Speed
foundry_1  |
foundry_1  |   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
foundry_1  |   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
foundry_1  | Entrypoint | 2020-08-02 07:01:27 | [info] Installing Foundry Virtual Tabletop 0.6.5
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Preserving release archive file in cache.
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Not modifying existing installation license key.
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Setting data directory permissions.
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Switching uid:gid to foundry:foundry and restarting.
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Starting felddy/foundryvtt container v0.6.5
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Reading configured secrets from: /run/secrets/config.json
foundry_1  | jq: error: Could not open file /run/secrets/config.json: Permission denied
foundry_1  | jq: error: Could not open file /run/secrets/config.json: Permission denied
foundry_1  | jq: error: Could not open file /run/secrets/config.json: Permission denied
foundry_1  | jq: error: Could not open file /run/secrets/config.json: Permission denied
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Foundry Virtual Tabletop 0.6.5 is installed.
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Not modifying existing installation license key.
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Generating options.json file.
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [warn] Warning: No 'Admin Access Key' has been configured.
foundry_1  | Entrypoint | 2020-08-02 07:01:29 | [info] Starting Foundry Virtual Tabletop.
foundry_1  | FoundryVTT | 2020-08-02 07:01:30 | [info] Foundry Virtual Tabletop - Version 0.6.5
foundry_1  | FoundryVTT | 2020-08-02 07:01:30 | [info] Running on Node.js - Version 12.18.2
foundry_1  | FoundryVTT | 2020-08-02 07:01:30 | [info] Loading data from user directory - /data
foundry_1  | FoundryVTT | 2020-08-02 07:01:30 | [info] Application Options:
foundry_1  | {
foundry_1  |   "port": 30000,
foundry_1  |   "upnp": false,
foundry_1  |   "fullscreen": false,
foundry_1  |   "hostname": "<redacted>",
foundry_1  |   "routePrefix": null,
foundry_1  |   "sslCert": null,
foundry_1  |   "sslKey": null,
foundry_1  |   "awsConfig": null,
foundry_1  |   "dataPath": "/data",
foundry_1  |   "proxySSL": false,
foundry_1  |   "proxyPort": null,
foundry_1  |   "updateChannel": "release",
foundry_1  |   "noUpdate": true,
foundry_1  |   "world": null,
foundry_1  |   "isElectron": false,
foundry_1  |   "isNode": true,
foundry_1  |   "isSSL": false
foundry_1  | }
foundry_1  | FoundryVTT | 2020-08-02 07:01:31 | [warn] Software license requires signature.
foundry_1  | FoundryVTT | 2020-08-02 07:01:31 | [info] Server started and listening on port 30000

node:12-alpine linux/386 architecture breaking all container builds

๐Ÿ’ฅ Regression Report

The linux/386 platform build is breaking. This was caused by nodejs/docker-node#1344

The platform was disabled as a workaround in 2d6e989

  • ๐Ÿ‘€ Watching upstream for resolution.

Last working version

Worked up to version: 0.7.3

Stopped working in version: 0.7.4

To Reproduce

Steps to reproduce the behavior:

  • Make a release

Expected behavior

Expected that 386 architecture would be supported.

Any helpful log output

Please run this command:

#20 [linux/386 optional-release-stage 1/5] FROM docker.io/library/node:12-al...
#20 resolve docker.io/library/node:12-alpine 0.4s done
#20 ERROR: no match for platform in manifest sha256:53bbb1eeb8bc916ee27f9e01c542788699121bd7b5a9d9f39eaff64c2fcd0412: not found

Permissions for /data not populating on host system properly?

๐Ÿ’ฌ Questions and Help

When I set up my docker run command, I told it to use FOUNDRY_PUID and FOUNDRY_GUID as 1000, which is my personal user account. However, the web host that's handling proxy is running from a different user (normal linux www-data). Neither seems to be what the container is using as the mount point for the /data folder on the host system is shown as the following:

drwxr-xr-x 5 421 421 4096 Dec 1 20:30 foundryvtt

(yes, the user and group are showing as a right aligned '421' instead of normal left aligned alpha characters) I don't see anything like this in my console manager's user or group lists, but I'm sure it's something Docker related

While mildly annoying that I can't manipulate the directory without elevated permissions, I'm also thinking this could or could not have an issue with where I attempted to upload a map it uploads, but I can't seem to view it on the board (this could also be new user syndrome)

Prefer FOUNDRY_RELEASE_URL to fetching by USERNAME/PASSWORD

๐Ÿš€ Feature Proposal

Current behavior is that use FOUNDRY_USERNAME/FOUNDRY_PASSWORD (and FOUNDRY_VERSION if necessary) to fetch release URL even if you already set FOUNDRY_RELEASE_URL env var.

if [[ "${FOUNDRY_USERNAME:-}" && "${FOUNDRY_PASSWORD:-}" ]]; then
log "Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate."
# CONTAINER_VERBOSE default value should not be quoted.
# shellcheck disable=SC2086
./authenticate.js ${CONTAINER_VERBOSE+--log-level=debug} "${FOUNDRY_USERNAME}" "${FOUNDRY_PASSWORD}" "${cookiejar_file}"
# shellcheck disable=SC2086
s3_url=$(./get_release_url.js ${CONTAINER_VERBOSE+--log-level=debug} "${cookiejar_file}" "${FOUNDRY_VERSION}")
elif [ "${FOUNDRY_RELEASE_URL:-}" ]; then
log "Using FOUNDRY_RELEASE_URL to download release."
s3_url="${FOUNDRY_RELEASE_URL}"
fi

Requested feature is that always prefer FOUNDRY_RELEASE_URL if set, if it's invalid, use USERNAME/PASSWORD/VERSION to fetch S3 release URL, i.e.

 if [ "${FOUNDRY_RELEASE_URL:-}" ]; then 
   log "Using FOUNDRY_RELEASE_URL to download release." 
   s3_url="${FOUNDRY_RELEASE_URL}" 
 elif [[ "${FOUNDRY_USERNAME:-}" && "${FOUNDRY_PASSWORD:-}" ]]; then 
   log "Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate." 
   # CONTAINER_VERBOSE default value should not be quoted. 
   # shellcheck disable=SC2086 
   ./authenticate.js ${CONTAINER_VERBOSE+--log-level=debug} "${FOUNDRY_USERNAME}" "${FOUNDRY_PASSWORD}" "${cookiejar_file}" 
   # shellcheck disable=SC2086 
   s3_url=$(./get_release_url.js ${CONTAINER_VERBOSE+--log-level=debug} "${cookiejar_file}" "${FOUNDRY_VERSION}") 
 fi 

Motivation

FOUNDRY_RELEASE_URL is a more detailed option, should be at higher priority than USERNAME/PASSWORD and especially because it explicitly specifies version other than the default VERSION argument or env var.

Example

docker run -e FOUNDRY_RELEASE_URL='https://dl/linux/fvtt.zip' -e FOUNDRY_USERNAME='myAccount' -e FOUNDRY_PASSWORD='myPassword' felddy/foundryvtt

It should use https://dl/linux/fvtt.zip to download instead of fetching release URL by USERNAME/ACCOUNT.

Pitch

Foundry VTT Docker behavior related.

Node 16 base Alpine image is incompatible with some arm/v7 servers

๐Ÿ› Bug Report

I use a raspi4 for my Foundry hosting, I have no problems using felddy/foundryvtt:0.7.9 (I have tried to recrate it after the present bug and had no problem.

But trying a docker-compose up --build of the following configuration I get an Illegal instruction (core dumped)

  foundryvtt85:
    image: felddy/foundryvtt:beta
    hostname: vehrka_foundry_85_cheraserver
    init: true
    restart: "unless-stopped"
    volumes:
      - type: bind
        source: /home/perico/share/foundrydata_8_5
        target: /data
      - type: bind
        source: /etc/letsencrypt
        target: /etc/foundryssl
    environment:
      - CONTAINER_CACHE=/data/container_cache
      - CONTAINER_PRESERVE_CONFIG=true
      - FOUNDRY_UID=1001
    ports:
      - target: "30000"
        published: "30000"
        protocol: tcp
    secrets:
      - source: config_json
        target: config.json

To Reproduce

Steps to reproduce the behavior:

  • Do this
    • run docker-compose up --build foundryvtt85 for the above configuration

Expected behavior

Expected to work as the 0.7.9 version does.

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:beta

Paste the results here:

com.foundryvtt.version = "0.8.5"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2021-05-21T19:43:06Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "6b2080cb273fabff368ac7c862b68cabbc64aea9"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.8.5"

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

foundryvtt85_1  | Entrypoint | 7923-11-24 00:40:56 | [debug] Timezone set to: UTC
foundryvtt85_1  | Entrypoint | 7923-11-26 17:32:08 | [info] Starting felddy/foundryvtt container v0.8.5
foundryvtt85_1  | Entrypoint | 7923-12-08 13:58:48 | [debug] CONTAINER_VERBOSE set.  Debug logging enabled.
foundryvtt85_1  | Entrypoint | 7923-09-15 17:15:04 | [info] Reading configured secrets from: /run/secrets/config.json
foundryvtt85_1  | Entrypoint | 7923-10-24 11:57:12 | [info] No Foundry Virtual Tabletop installation detected.
foundryvtt85_1  | Entrypoint | 7923-11-09 01:08:40 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
foundryvtt85_1  |
foundryvtt85_1  |
foundryvtt85_1  | #
foundryvtt85_1  | # Fatal error in , line 0
foundryvtt85_1  | # unreachable code
foundryvtt85_1  | #
foundryvtt85_1  | #
foundryvtt85_1  | #
foundryvtt85_1  | #FailureMessage Object: 0xbef7750c
foundryvtt85_1  | Illegal instruction (core dumped) 

Missing SSL support

๐Ÿ’ฌ Questions and Help

I suspect this is less bug and more user error. I'm setting up FoundryVTT through docker, and using apache to handle the reverse proxy. I can connect and download and access resources, but in the log, when I enter the map I get the following error:

The WebRTC server was requested to start, but Foundry Virtual Tabletop is not running in SSL mode which is required.

When I'd been trying to do this without docker, I had successfully gotten past this after getting a cert for the subdomain it's using through letsencrypt. The cert is still valid, and all I had to do in apache was repoint where the proxy needed to look at (from another physical IP to localhost).

I'm thinking there's either a way I need to be able to pass information about the subdomain's ssl cert to the container or force it to use ssl mode, but i'm not sure how to do it

Health Check for docker container falsely reports unhealthy when foundryvtt is running with inbuilt https server

๐Ÿ› Bug Report

The health check provided by check_health.sh does not provide the correct container status when the container is running using https (not behind nginx or other such server).

Https means setting the paths for both sslKey and sslCert and using the inbuilt ssl server.

To Reproduce

Steps to reproduce the behavior:

  • Start container using a docker-compose.yml specifying the environment variables for sslKey and sslCert

  • Inspect container using docker ps <container-id> or similar command interface such as portainer
    foundryvtt-containers-unhealth-2020-10-25

  • See the container status is unhealthy

Expected behavior

Expect to see the container status as healthy especially when it is idle.

Checking Health With HTTPS

You can observe the container is actually healthy by getting a shell into the container and running curl -k --cookie-jar healthcheck-cookiejar.txt --cookie healthcheck-cookiejar.txt --fail https://localhost:30000/api/status which on the image tag felddy/foundryvtt-docker:0.7.5 release produces this result {"version":"0.7.5"}.

The -k argument may not be the best to use from a security standpoint as you might be using a self signed certificate, but this can be worked around by passing the sslCert and sslKey variables into the check_health.sh script if correct https validation is needed to be performed.

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:latest

Paste the results here:

com.docker.compose.config-hash = "8bc8ddd3796576d04e2f1092fbc0dcd2123a3a2316f481fa0f0c94341cefc1e4"
com.docker.compose.container-number = "1"
com.docker.compose.oneoff = "False"
com.docker.compose.project = "foundryvtt"
com.docker.compose.project.config_files = "docker-compose.yml"
com.docker.compose.project.working_dir = "/home/christian/Docker/foundryvtt"
com.docker.compose.service = "foundryvtt"
com.docker.compose.version = "1.27.4"
com.foundryvtt.version = "0.7.5"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.vendor = "Geekpad"

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

This shows the container is idle and currently accepting connections

FoundryVTT | 2020-10-25 16:48:19 | [info] License verification succeeded
FoundryVTT | 2020-10-25 16:48:20 | [info] Server started and listening on port 30000
FoundryVTT | 2020-10-25 16:48:30 | [info] Created client session 68xp6fdwr2dmhslhn4xz7htl
FoundryVTT | 2020-10-25 16:48:31 | [info] No core software update is currently available.
FoundryVTT | 2020-10-25 16:53:14 | [info] Created client session w2gv92i94osfp55zdc6gglcm

Tries to re-install every restart.

๐Ÿ› Bug Report

I installed using FOUNDRY_RELEASE_URL which worked the first time, but when I restarted the container it tried to download again but the URL was no longer valid. I have a volume mount for /data, but no other volume mount, so it isn't surprising that the actual install wasn't retained.

To Reproduce

  1. Run with FOUNDRY_RELEASE_URL and /data mounted.
  2. Wait for the URL to expire.
  3. Restart the container.
  4. Notice that it says No Foundry Virtual Tabletop installation detected. and tries to download/install again.
  5. Notice you get a 403.

Expected behavior

The download and install are saved to a volume so I don't have to re-download and re-install every run.


This may just be a documentation issue. Should I be mounting another volume besides /data?

Container doesn't populate resolv.conf properly

๐Ÿ› Bug Report

I'd like to supply my own dns server with the container using the --dns attribute. Yet this is not correctly picked up and inserted into the /etc/resolv.conf. This makes it impossible for the container to run in bridge networking mode

To Reproduce

Steps to reproduce the behavior:

  • Run the container using --dns 8.8.8.8
  • The contain will not run properly as it cannot resolve the DNS for foundryvtt.com

Expected behavior

I'm expecting the DNS to be populated into the /etc/resolv.conf. I don't know how ever why it isn't
This works fine for all my other containers I'm running.

Any helpful log output

I use docker-compose

version: "3.3"

secrets:
  config_json:
    file: /share/Container/foundryvtt-secrets.json

services:
  foundry:
    image: felddy/foundryvtt:0.7.8
    hostname: foundryvtt
    mac_address: 24:5E:BE:00:00:F6
    dns:
    - 192.168.1.2
    - 8.8.8.8
    - 8.8.4.4
    networks:
        qnet-static-eth0-79e6cc:
            ipv4_address: 192.168.1.246
    volumes:
      - type: bind
        source: /share/Container/foundryvtt
        target: /data
    environment:
      - FOUNDRY_LICENSE_KEY=*
      - CONTAINER_CACHE=/data/container_cache
      - CONTAINER_PATCHES=/data/container_patches
    secrets:
      - source: config_json
        target: config.json
        
networks:
  qnet-static-eth0-79e6cc:
    external: true

Paste the results here:

Entrypoint | 2020-12-25 09:30:07 | [info] Starting felddy/foundryvtt container v0.7.8                                                                        
Entrypoint | 2020-12-25 09:30:07 | [info] Reading configured secrets from: /run/secrets/config.json                                                          
Entrypoint | 2020-12-25 09:30:09 | [info] No Foundry Virtual Tabletop installation detected.                                                                 
Entrypoint | 2020-12-25 09:30:09 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.                                                       
Authenticate | 2020-12-25 09:30:14 | [info] Requesting CSRF tokens from https://foundryvtt.com                                                               
Authenticate | 2020-12-25 09:30:19 | [error] Unable to authenticate: request to https://foundryvtt.com/ failed, reason: getaddrinfo EAI_AGAIN foundryvtt.com

The /etc/resolv.conf

nameserver 127.0.0.11
options ndots:0 

Container composition hangs for zip user interaction when issued "stop" and then "up".

๐Ÿ› Bug Report

This is an attempt to document the problem described in PR #146 by

@dankreek :

I noticed while using the container in a docker-compose stack that if I do a stop then an up the container freezes while asking the user to overwrite the Foundry application files.

I am unable to reproduce it, but hope that I can get some log output from @dankreek demonstrating the behavior.

PR #146 should fix the issue as described, but the container should not be able to get into this state to begin with. If it detects an existing installation it should not try to unzip a new release. I'd like to track the root cause down.

To Reproduce

Steps to reproduce the behavior:

  • up the container using a composition.
  • stop the composition.
  • up the composition.

Expected behavior

  • Container should start normally with up.
  • Container should stop normally with stop.
  • Container should continue running with up without reinstalling FoundryVTT.

I am seeing the expected behavior. See logs below.

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:release

Paste the results here:

com.foundryvtt.version = "0.7.9"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-12-19T18:22:45Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "d7bbea8063e5cbf8cc93ef114aca843be45d299d"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.7.9"

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

โฑ docker-compose -f docker-compose-mine.yml up
Creating network "foundryvtt-docker_default" with the default driver
Creating foundryvtt-docker_foundry_1 ... done
Attaching to foundryvtt-docker_foundry_1
foundry_1  | Entrypoint | 2021-02-11 15:49:00 | [debug] Timezone set to: US/Eastern
foundry_1  | Entrypoint | 2021-02-11 15:49:00 | [info] Starting felddy/foundryvtt container v0.7.9
foundry_1  | Entrypoint | 2021-02-11 15:49:00 | [debug] CONTAINER_VERBOSE set.  Debug logging enabled.
foundry_1  | Entrypoint | 2021-02-11 15:49:00 | [info] Reading configured secrets from: /run/secrets/config.json
foundry_1  | Entrypoint | 2021-02-11 15:49:01 | [info] No Foundry Virtual Tabletop installation detected.
foundry_1  | Entrypoint | 2021-02-11 15:49:01 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
foundry_1  | Authenticate | 2021-02-11 15:49:01 | [debug] Saving cookies to: cookiejar.json
foundry_1  | Authenticate | 2021-02-11 15:49:01 | [info] Requesting CSRF tokens from https://foundryvtt.com
foundry_1  | Authenticate | 2021-02-11 15:49:01 | [debug] Fetching: https://foundryvtt.com
foundry_1  | Authenticate | 2021-02-11 15:49:02 | [info] Logging in as: xxx
foundry_1  | Authenticate | 2021-02-11 15:49:02 | [debug] Fetching: https://foundryvtt.com/auth/login/
foundry_1  | Authenticate | 2021-02-11 15:49:02 | [debug] Community URL: /community/xxx
foundry_1  | Authenticate | 2021-02-11 15:49:02 | [info] Successfully logged in as: xxx
foundry_1  | Entrypoint | 2021-02-11 15:49:02 | [info] Using authenticated credentials to download release.
foundry_1  | ReleaseURL | 2021-02-11 15:49:02 | [debug] Loading cookies from: cookiejar.json
foundry_1  | ReleaseURL | 2021-02-11 15:49:02 | [info] Fetching S3 pre-signed release URL for 0.7.9...
foundry_1  | ReleaseURL | 2021-02-11 15:49:02 | [debug] Fetching: https://foundryvtt.com/releases/download?version=0.7.9&platform=linux
foundry_1  | ReleaseURL | 2021-02-11 15:49:03 | [debug] S3 presigned URL: ...
foundry_1  | Entrypoint | 2021-02-11 15:49:03 | [info] Using CONTAINER_CACHE: /data/container_cache
foundry_1  | Entrypoint | 2021-02-11 15:49:03 | [info] Downloading Foundry Virtual Tabletop release.
foundry_1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
foundry_1  |                                  Dload  Upload   Total   Spent    Left  Speed
foundry_1  | 
foundry_1  |   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
foundry_1  |   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
foundry_1  | Entrypoint | 2021-02-11 15:49:03 | [info] Installing Foundry Virtual Tabletop 0.7.9
foundry_1  | Entrypoint | 2021-02-11 15:49:06 | [debug] Installation completed.
foundry_1  | Entrypoint | 2021-02-11 15:49:06 | [info] Preserving release archive file in cache.
foundry_1  | Entrypoint | 2021-02-11 15:49:06 | [debug] Editing server update error message.
foundry_1  | Entrypoint | 2021-02-11 15:49:06 | [info] Not modifying existing installation license key.
foundry_1  | Entrypoint | 2021-02-11 15:49:06 | [info] Setting data directory permissions.
foundry_1  | Entrypoint | 2021-02-11 15:49:23 | [debug] Completed setting directory permissions.
foundry_1  | Entrypoint | 2021-02-11 15:49:23 | [info] Starting launcher with uid:gid as 501:20.
foundry_1  | Launcher | 2021-02-11 15:49:23 | [debug] Ensuring /data/Config directory exists.
foundry_1  | Launcher | 2021-02-11 15:49:23 | [info] Generating options.json file.
foundry_1  | Launcher | 2021-02-11 15:49:23 | [info] Setting 'Admin Access Key'.
foundry_1  | Launcher | 2021-02-11 15:49:23 | [info] Starting Foundry Virtual Tabletop.
foundry_1  | FoundryVTT | 2021-02-11 15:49:25 | [info] Foundry Virtual Tabletop - Version 0.7.9
foundry_1  | FoundryVTT | 2021-02-11 15:49:25 | [info] Running on Node.js - Version 12.20.0
foundry_1  | FoundryVTT | 2021-02-11 15:49:25 | [info] Loading data from user directory - /data
foundry_1  | FoundryVTT | 2021-02-11 15:49:25 | [info] Application Options:
foundry_1  | {
...
foundry_1  | }
foundry_1  | FoundryVTT | 2021-02-11 15:49:25 | [info] License verification succeeded
foundry_1  | FoundryVTT | 2021-02-11 15:49:25 | [info] Server started and listening on port 30000
docker-compose -f docker-compose-mine.yml stop
foundryvtt-docker_foundry_1 exited with code 143
โฑ docker-compose -f docker-compose-mine.yml up
Starting foundryvtt-docker_foundry_1 ... done
Attaching to foundryvtt-docker_foundry_1
foundry_1  | Entrypoint | 2021-02-11 15:52:08 | [debug] Timezone set to: US/Eastern
foundry_1  | Entrypoint | 2021-02-11 15:52:08 | [info] Starting felddy/foundryvtt container v0.7.9
foundry_1  | Entrypoint | 2021-02-11 15:52:08 | [debug] CONTAINER_VERBOSE set.  Debug logging enabled.
foundry_1  | Entrypoint | 2021-02-11 15:52:08 | [info] Reading configured secrets from: /run/secrets/config.json
foundry_1  | Entrypoint | 2021-02-11 15:52:09 | [info] Foundry Virtual Tabletop 0.7.9 is installed.
foundry_1  | Entrypoint | 2021-02-11 15:52:09 | [info] Not modifying existing installation license key.
foundry_1  | Entrypoint | 2021-02-11 15:52:09 | [info] Setting data directory permissions.
foundry_1  | Entrypoint | 2021-02-11 15:52:27 | [debug] Completed setting directory permissions.
foundry_1  | Entrypoint | 2021-02-11 15:52:27 | [info] Starting launcher with uid:gid as 501:20.
foundry_1  | Launcher | 2021-02-11 15:52:27 | [debug] Ensuring /data/Config directory exists.
foundry_1  | Launcher | 2021-02-11 15:52:27 | [info] Generating options.json file.
foundry_1  | Launcher | 2021-02-11 15:52:27 | [info] Setting 'Admin Access Key'.
foundry_1  | Launcher | 2021-02-11 15:52:27 | [info] Starting Foundry Virtual Tabletop.
foundry_1  | FoundryVTT | 2021-02-11 15:52:28 | [info] Foundry Virtual Tabletop - Version 0.7.9
foundry_1  | FoundryVTT | 2021-02-11 15:52:28 | [info] Running on Node.js - Version 12.20.0
foundry_1  | FoundryVTT | 2021-02-11 15:52:28 | [info] Loading data from user directory - /data
foundry_1  | FoundryVTT | 2021-02-11 15:52:28 | [info] Application Options:
foundry_1  | {
...
foundry_1  | }
foundry_1  | FoundryVTT | 2021-02-11 15:52:28 | [info] License verification succeeded
foundry_1  | FoundryVTT | 2021-02-11 15:52:29 | [info] Server started and listening on port 30000

Container Patch Scripts for Prebuilt Images

๐Ÿš€ Feature Proposal

Enable some method of running container patch scripts for containers built with credentials.

Motivation

I prefer to build the containers with foundry installed using my credentials but also enjoy the convenience of the patch scripts. I personally patched entrypoint.sh to run the patch scripts every launch not just when foundry is being installed but figured there might be a better mechanism for this. Potentially running them during container build. Figured I would propose the option.

Example

The best implementation of this I see is adding patch scripts as a build ARG just like the credentials are. This would enable the scripts to be run just once while also providing nearly the same experience as passing the urls as environment variables.

Pitch

It is a simple extension of a preexisting feature. Should add little to no maintenance cost on the project. I would be willing to give it a go for my own personal usage if anyone is interested here.

Download/Installing Foundry during the build stage.

Hi Felddy,

I saw that you have changed the behaviour of the image pulling for the .js alternative and with that dropped the capability of a fetch-install during the build using the old command.

docker-compose build \
--build-arg USERNAME='user' \
--build-arg PASSWORD='mYPa$$'

Do you plan to re-add it in any other way?

I'm checking too ensure that the K8S chart reflects how it works and I would like to avoid asking for the users to provide passwords on the vales.yaml or parameter and deliver it as a environment variable plain text to the container during it's execution, that it's not safe.

Unable to update lock within the stale threshold

๐Ÿ’ฌ Questions and Help

Mark --
First off; thank you for creating and maintaining this image.

I just updated to 0.7.5 and on my docker-compose up, the server hangs and I see:

foundry    | FoundryVTT | 2020-10-22 11:18:37 | [info] License verification succeeded
foundry    | FoundryVTT | 2020-10-22 11:18:37 | [info] Server started and listening on port 30000
foundry    | FoundryVTT | 2020-10-22 11:18:42 | [error] Unable to update lock within the stale threshold
foundry    | Error: Unable to update lock within the stale threshold
foundry    |     at /home/foundry/resources/app/node_modules/proper-lockfile/lib/lockfile.js:136:25
foundry    |     at /home/foundry/resources/app/node_modules/proper-lockfile/node_modules/graceful-fs/polyfills.js:285:20
foundry    |     at FSReqCallback.oncomplete (fs.js:169:5)

Of note -- my Foundry data is stored on a network mounted drive, and has worked properly for a while now, but it seems like it may be relevant here. Help?

auto accept license

Hi, is there any way to automatically accept the license on startup? I feel like if I've already done it, I shouldn't have to do it again.

Mabye this is more of a foundry quirk, than something related to your container?

Setting image to :beta pulled :release version instead

๐Ÿ› Bug Report

Possibly I don't understand how the image works, but my assumption was that today (Oct 3, 2020), using :beta would pull version 0.7.3

To Reproduce

Steps to reproduce the behavior:

  • Create container
  • Set image to felddy/foundryvtt-docker:beta

Expected behavior

Foundry version 0.7.3 is installed in the container

Any helpful log output

Please run this command:

docker inspect --format='{{range $k, $v := .Config.Labels}}
    {{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
    felddy/foundryvtt:latest

Paste the results here:

Run the container with CONTAINER_VERBOSE set to true,and paste any useful
log output here:

License retrieval fails if more than one license is owned

๐Ÿ› Bug Report

The license key retrieval retrieves the text contents of a CSS selector

const license_with_dashes = $("pre.license-key code").text();

If there are multiple pres, it concatenates the contents of each and writes that into the license file, resulting in an invalid license

To Reproduce

Steps to reproduce the behavior:

  • Buy a second license ;)
  • Then run the container

Expected behavior

Ability to specify the license key as an ARG or in the secret. I am currently looking at the code to make that happen and provide a PR if sucessful, but I have to admit that Docker is not my strong suit

Generate the initial options.json even if CONTAINER_PRESERVE_CONFIG set to true

๐Ÿš€ Feature Proposal

if [[ "${CONTAINER_PRESERVE_CONFIG:-}" == "true" ]]; then

It only checks CONTAINER_PRESERVE_CONFIG as for now, but didn't check if the file options.json/admin.txt exists. So it won't generate the initial config files if CONTAINER_PRESERVE_CONFIG set to true.

I think it's better to also check if the config files exist, else update/generate.

e.g.:

if [[ "${CONTAINER_PRESERVE_CONFIG:-}" == "true" && -e options.json && -e admin.txt ]]; then

Motivation

It's more convenient to use if generate the initial configs but preserve it form regen without modifying container env var.

Example

Running with "-e CONTAINER_PRESERVE_CONFIG=true", it generates the initial config files.

After start, modify the options.json by FVTT setup panel and the change preserves.

Pitch

FVTT docker container related.

Unable to run server on any port other than default

๐Ÿ’ฌ Questions and Help

Running using docker-compose, setting port to something like 30002 in the yaml file and also changing it in options.json file, when restarting the image, it resets back to port 30000. How would I run an instance using a different port?

foundry:
    container_name: fvtt
    image: felddy/foundryvtt:release
    restart: "unless-stopped"
    volumes:
      - '/data/docker/foundryvtt:/data'
    environment:
      - FOUNDRY_PASSWORD=password
      - FOUNDRY_USERNAME=user
      - FOUNDRY_ADMIN_KEY=anotherpassword
    ports:
      - "30002:30002/tcp"
    network_mode: host

Flag to bypass "Setting data directory permissions" step

๐Ÿš€ Feature Proposal

I would like a flag that would have the startup script skip the chmod of the data directory on startup

Motivation

I mount the data directories from NFS, and I've already set the proper permissions on all files. With hundreds upon hundreds of shared files, it takes about three to four minutes on my saves

Example

On environments where you know the uid/gid of the files ahead of time, you could opt to skip this stick

Pitch

Makes restarting containers, or setting up new containers with shared data much faster, and for minimal effort

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.