Value for APP_HOST: <web-container-ip-address> is not clear

[prologic]

Going through the README I noticed:

      APP_HOST: <web-container-ip-address>

As part of the example docker-compose.yml. Looking around at other apps that have been submitted here I see IP address of 10.21.21.X.

How are we determining the IP address space here? How do I choose a valid IP? This makes no sense to me 🤦‍♂️

[nevets963]

Hey @prologic

Currently we set every container to have a static IP, like so:

umbrel-apps/agora/docker-compose.yml

Line 65 in ac96696

ipv4_address: $APP_AGORA_IP

And then the env. var. for this IP we store in the app's exports.sh script:

umbrel-apps/agora/exports.sh

Line 1 in ac96696

export APP_AGORA_IP="10.21.21.87"

Finally, the app_proxy service is pointing the Web UI container for that app. In this case (with Agora) it's the IP defined inside: $APP_AGORA_IP

I hope this helps!
Steve

[prologic]

@nevets963 Hey Steve! Cool thanks for the explanation, that should go on the README somewhere.

Now... Sorry to be blunt, but this is kind of nuts 😅 How do you determine what the IP address should be for new App submitters? Grep for 10\.21\.21\. in this repo and pick the next logical IP?

Why aren't we using Docker's built-in DNS SD (DNS Service Discovery) here and built-in in networking?

I must admit, defining static ips for services in a Docker environment is really super weird to me. I normally run Docker Swarm clusters and we just don't do this (like at all).

[prologic]

Looks like (if I'm not mistaken) there are 3 potential Apps in this repo that have IP address collisions if I'm understand what you're saying correctly:

$ grep -h -o -R -E '10\.21\.21\.[0-9]+' | sort | uniq -c | sort -n -r -k 1
      2 10.21.21.81
      2 10.21.21.75
      2 10.21.21.12
      1 10.21.21.98

🤔

[prologic]

Okay if I were to submit an app the next logical IP address should be 10.21.21.106 right?

$ grep -h -o -R -E '10\.21\.21\.[0-9]+' | sort -n -t. -k 4 | tail -n 3
10.21.21.103
10.21.21.104
10.21.21.105

[prologic]

Some more related questions:

• How do I deal with things like cookie secrets, passwords and so forth? Is there a way to securely generate these at app install time or are they hard coded in the exports.sh?
• Can I rely on APP_DOMAIN to be the FQDN of the app with a valid resolvable and routable domain to the app? My app needs to know the base url so this bit is important or things just don't work.
• How do we set other user-defined configuration values? Does the user get a change to do this? If so , how?

[nevets963]

Hi @prologic

Currently we use these hard-coded IPs for legacy reasons however this will eventually go and we'll be using DNS. When developers submit an App Submission PR we will take care of the IPs for you and allocate IPs that are not used so you don't need to worry about this.

I just looked up those 'duplicates', but they're only harmless re-definitions and infact 1 typo (with LNDg).

Re your questions:

How do I deal with things like cookie secrets, passwords and so forth? Is there a way to securely generate these at app install time or are they hard coded in the exports.sh?

Some apps simply use a default password for a certain internal component. Here is 1 example:

umbrel-apps/photoprism/docker-compose.yml

Line 28 in 04c31a4

PHOTOPRISM_DATABASE_PASSWORD: "photoprism"

We also provide a variable called $APP_SEED which is some deterministic entropy you could use.

Can I rely on APP_DOMAIN to be the FQDN of the app with a valid resolvable and routable domain to the app? My app needs to know the base url so this bit is important or things just don't work.

$APP_DOMAIN is the device's hostname with .local appended. So this is reliable with devices and networks that can resolve mDNS requests (which is vast majority these days).

How do we set other user-defined configuration values? Does the user get a change to do this? If so , how?

User-defined configuration is managed by the app. If you have state e.g. to store settings, then you can store this state persistently on the host using a volume defined in the docker-compose.yml file. As an example, here MySQL stores its state like so:

umbrel-apps/photoprism/docker-compose.yml

Lines 44 to 45 in 04c31a4

	volumes:
	- "${APP_DATA_DIR}/database:/var/lib/mysql"

[prologic]

Currently we use these hard-coded IPs for legacy reasons however this will eventually go and we'll be using DNS. When developers submit an App Submission PR we will take care of the IPs for you and allocate IPs that are not used so you don't need to worry about this.

Okay! 👌

How do I deal with things like cookie secrets, passwords and so forth? Is there a way to securely generate these at app install time or are they hard coded in the exports.sh?

Some apps simply use a default password for a certain internal component. Here is 1 example:

umbrel-apps/photoprism/docker-compose.yml

Line 28 in 04c31a4

PHOTOPRISM_DATABASE_PASSWORD: "photoprism"

This is not suitable for things like JWT Signing tokens, Cookie Secrets.

Is there any other recommended way to set these more securely?

We also provide a variable called $APP_SEED which is some deterministic entropy you could use.

How do I use this?

Can I rely on APP_DOMAIN to be the FQDN of the app with a valid resolvable and routable domain to the app? My app needs to know the base url so this bit is important or things just don't work.

$APP_DOMAIN is the device's hostname with .local appended. So this is reliable with devices and networks that can resolve mDNS requests (which is vast majority these days).

This is not what I thought it was then.

Is there a FQDN for an installed App that is publicly routable and resolvable? My app needs to know this up-front.

How do we set other user-defined configuration values? Does the user get a change to do this? If so , how?

User-defined configuration is managed by the app. If you have state e.g. to store settings, then you can store this state persistently on the host using a volume defined in the docker-compose.yml file. As an example, here MySQL stores its state like so:

This is not what I mean by "user defined" configuration. For example the Vultr App Marketplace prompts the user for configuration values (defined. by the App Vendor). Is there something like for this Umbrel Apps?

---

Finally, I cannot use Umbrel in it's current form nor recommend it because Umbrel (by default) in *insecure.

Please see my comment. This needs to be addressed before I even continue this journey. I'm not going to contribute apps to a platform that is insecure by design 😢 As I said in the comment, a minimal way to fix this would be to setup Let's Encrypt for secure ingress for NGINX so that traffic path is secure, right now it's wide open and sniffable (regardless of the network).

[nevets963]

We also provide a variable called $APP_SEED which is some deterministic entropy you could use.

How do I use this?

If you for example use Signed Cookies (using perhaps: https://www.npmjs.com/package/cookie-parser) then the $APP_SEED can be past to the container as an env. var. and then you can use that in your application. e.g. cookieParser(process.env.APP_SEED)

Is there a FQDN for an installed App that is publicly routable and resolvable? My app needs to know this up-front.

Not currently. The primary usecase for Umbrel (atm) are users running the server in their home on a Raspberry Pi. Their home server is running behind a gateway and not publically accessible via clearnet - only accessible via the LAN. In Umbrel v0.5 we made it much easier to run Umbrel anywhere (including the cloud) as we unbundled Bitcoin from Umbrel. We however, didn't introduce any additional features to support HTTPS out of the box for this usage model.

The comments/summary from @lukechilds details why running TLS on a LAN is difficult: getumbrel/umbrel#546 (comment)

We're open to suggestions here - maybe we've missed something re running TLS on a LAN?

This is not what I mean by "user defined" configuration. For example the Vultr App Marketplace prompts the user for configuration values (defined. by the App Vendor). Is there something like for this Umbrel Apps?

No, not at this time. I can however see the potential usecases, setting passwords, or setting some specific configuration applicable to the underlying hardware (max threads, max memory, etc).