playwright failed to install on FreeBSD

[tschettervictor]

⚠️ Please verify that this bug has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

Description

I am running the custom install on freebsd. It installed fine about a month ago, but I'm just recently installed it again. When i run the node server.js command, i get the below error.

Error: Unsupported platform: freebsd
at /usr/local/uptime-kuma/node_modules/playwright-core/lib/server/registry/index.js:258:388
at Object. (/usr/local/uptime-kuma/node_modules/playwright-core/lib/server/registry/index.js:270:3)
at Module._compile (node:internal/modules/cjs/loader:1254:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
at Module.load (node:internal/modules/cjs/loader:1117:32)
at Module._load (node:internal/modules/cjs/loader:958:12)
at Module.require (node:internal/modules/cjs/loader:1141:19)
at require (node:internal/modules/cjs/helpers:110:18)
at Object. (/usr/local/uptime-kuma/node_modules/playwright-core/lib/server/index.js:84:17)
at Module._compile (node:internal/modules/cjs/loader:1254:14)

👟 Reproduction steps

Install using the custom install commands on the uptimekuma github page, then try to run the node command.

👀 Expected behavior

I expect uptime kuma to run without errors.

😓 Actual Behavior

It errors out with "Unsupported platform. FreeBSD"

🐻 Uptime-Kuma Version

Unknown.

💻 Operating System and Arch

FreeBSD 13.2 Jail

🌐 Browser

Brave

🐋 Docker Version

N/A

🟩 NodeJS Version

18.16.0

[CommanderStorm]

We don't test for FreeBSD today. We haven't seen enough interest in this platform so far. (similar to playwrigts reasoning)

Browser downloading is apparently not supported by playwrigt upstream.
See microsoft/playwright#5084

Could you test the fix proposed by editing your global .npmrc?

[CommanderStorm]

Another way to likely fix this is to downgrade to 1.22 ⇒ not having this https://github.com/louislam/uptime-kuma/pull/3308/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519 change

[tschettervictor]

We don't test for FreeBSD today. We haven't seen enough interest in this platform so far. (similar to playwrigts reasoning)

Browser downloading is apparently not supported by playwrigt upstream. See microsoft/playwright#5084

Could you test the fix proposed by editing your global .npmrc?

This does not work. The .npmrc file was at /uptime-kuma/.npmrc

Will try the downgrade. How does one go about downgrading?

Or, how do I install the 1.22 release using the instruction for non-docker installs.

[CommanderStorm]

How does one go about downgrading?

If this has never worked for you, you don't have to deal with backing up, as you don't have significant sate to recover from.
In this case, just run the installation steps for the current versions but targeting another version.
Note that npm run setup is short for git checkout 1.23.0 && npm ci --production && npm run download-dist

If this worked before, defintively do an backup by copying the data folder first.

[tschettervictor]

git checkout 1.22.0 && npm ci --production && npm run download-dist

I can confirm that 1.22.0 works. Thank you.
I hope a fix can be implemented in future versions.

[tschettervictor]

Closing. 1.22.0 works on FreeBSD.

1.23.0 doesn’t as of August 23/2023.

[tschettervictor]

Just curious if this will be resolved in the future. Current release still not working.

[CommanderStorm]

It will be resolved once https://github.com/microsoft/playwright supports this platform or if someone does the work to make playwright into an optional dependency (still working on the platforms for which playwright works).

The ever-increasing complexity is getting to us and I doubt that the core team will get to this, as native FreeBSD is quite a niche platform.
Note that Docker should work on said platform, as this ships with another OS and just shares the kernel.
If you or someone in the future would like to contribute, here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

[louislam]

Checked their source code, it should be able to skip the error by the env var PLAYWRIGHT_BROWSERS_PATH.

https://github.com/microsoft/playwright/blob/9fe037fb63a87844e94bc4111d1a0717b22f4623/packages/playwright-core/src/server/registry/index.ts#L280-L299

[tschettervictor]

What would you set that var as?

[CommanderStorm]

See https://playwright.dev/docs/browsers#managing-browser-binaries

[rob4226]

Isn't playwrite for E2E testing? Why is it being called when running a production server with/server/server.js? I would also expect it to not even be installed with npm install --production.

Anyway, fortunately I was able to get uptime-kuma working again with FreeBSD by setting an environment variable like this before starting the server:

setenv PLAYWRIGHT_BROWSERS_PATH /nonexistent

---

If using the BSD rc.d framework to control uptime-kuma as a service, you can add this to it's rc.d script file (ex: /usr/local/etc/rc.d/uptimekuma):

# Replace ${name} with the name of your rc service:
${name}_env="PLAYWRIGHT_BROWSERS_PATH=/nonexistent"

---

Another possible solution (I haven't tried), based on microsoft/playwright#5084 (comment), is to use a global .npmrc to skip browsers install:

playwright_skip_browser_download=1
playwright_browsers_path=/nonexistent

[CommanderStorm]

Isn't playwrite for E2E testing? Why is it being called when running a production server with /server/server.js

Because the Real Browser monitoring type is exactly that: a real browser

[tschettervictor]

Isn't playwrite for E2E testing? Why is it being called when running a production server with/server/server.js? I would also expect it to not even be installed with npm install --production.

Anyway, fortunately I was able to get uptime-kuma working again with FreeBSD by setting an environment variable like this before starting the server:

setenv PLAYWRIGHT_BROWSERS_PATH /nonexistent

If using the BSD rc.d framework to control uptime-kuma as a service, you can add this to it's rc.d script file (ex: /usr/local/etc/rc.d/uptimekuma):

# Replace ${name} with the name of your rc service:
${name}_env="PLAYWRIGHT_BROWSERS_PATH=/nonexistent"

Another possible solution (I haven't tried), based on microsoft/playwright#5084 (comment), is to use a global .npmrc to skip browsers install:

playwright_skip_browser_download=1
playwright_browsers_path=/nonexistent

I can confirm that setting that variable in the rc.d script solves the problem for now.

[rob4226]

Real Browser

Oo ok, I wasn't aware of that feature.

[jmpalacios]

Isn't playwrite for E2E testing? Why is it being called when running a production server with/server/server.js? I would also expect it to not even be installed with npm install --production.

Anyway, fortunately I was able to get uptime-kuma working again with FreeBSD by setting an environment variable like this before starting the server:

setenv PLAYWRIGHT_BROWSERS_PATH /nonexistent

If using the BSD rc.d framework to control uptime-kuma as a service, you can add this to it's rc.d script file (ex: /usr/local/etc/rc.d/uptimekuma):

# Replace ${name} with the name of your rc service:
${name}_env="PLAYWRIGHT_BROWSERS_PATH=/nonexistent"

Another possible solution (I haven't tried), based on microsoft/playwright#5084 (comment), is to use a global .npmrc to skip browsers install:

playwright_skip_browser_download=1
playwright_browsers_path=/nonexistent

Hey Rob!

How far have you gotten in writing an rc(8) FreeBSD script for uptime-kuma? Would you care to share? And maybe even consider creating a port for the whole thing? I'd be more than willing to collaborate, test, etc.

Please let me know if you're interested, thanks!

[tschettervictor]

I created one a while ago. The playwright browser path is necessary to run on FreeBSD. It should all work.

#!/bin/sh

# Uptime-Kuma FreeBSD Service Script

# PROVIDE: uptimekuma
# REQUIRE: NETWORKING
# KEYWORD: shutdown

. /etc/rc.subr

: ${uptimekuma_enable:="NO"}

uptimekuma_env="PLAYWRIGHT_BROWSERS_PATH=/nonexistent"
name="uptimekuma"
rcvar="uptimekuma_enable"
pidfile="/var/run/${name}/${name}.pid"
uptimekuma_chdir=/usr/local/uptime-kuma
HOME=/usr/local/uptime-kuma
command="/usr/sbin/daemon"
PATH=${PATH}:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
export LC_CTYPE="en_US.UTF-8"
command_args="-r -u ${name} -P ${pidfile} /usr/local/bin/node /usr/local/uptime-kuma/server/server.js --name uptime-kuma -- --port=3001 --host=0.0.0.0"

load_rc_config $name

run_rc_command "$1"

[jmpalacios]

That's awesome, thanks, I'll give it a try shortly!

And yes, so far I've gotten uptime-kuma running on a 13.2 FreeBSD jail manually by exporting PLAYWRIGHT_BROWSERS_PATH and starting the Node server right on the shell, passing my desired host as the first argument.

But getting this to work automatically via rc(8) upon jail start is most definitely the end goal, hoping I can configure the behavior via rc.conf(5).

I'll keep this thread posted.

[tschettervictor]

This rc script should be all you need. It's worked fine for me.

[jmpalacios]

This is what my rc script is currently looking like:

#!/bin/sh

# Uptime-Kuma FreeBSD Service Script

# PROVIDE: uptime-kuma
# REQUIRE: NETWORKING
# KEYWORD: shutdown
#
# Add the following line to /etc/rc.conf to enable uptime-kuma:
# uptime_kuma_enable="YES"
#
# Optional settings:
# uptime_kuma_home (path): Uptime Kuma installation directory
# uptime_kuma_browsers_path (path): Microsoft Playwright's browsers path (https://playwright.dev/docs/browsers#managing-browser-binaries)

#set -vx

. /etc/rc.subr

name=uptime_kuma
rcvar=${name}_enable

load_rc_config $name

: ${uptime_kuma_enable:="NO"}
: ${uptime_kuma_home:=/usr/local/share/uptime-kuma}
: ${uptime_kuma_browsers_path:=/nonexistent}

${name}_chdir=$uptime_kuma_home
pidfile=/var/run/${name}.pid
command=/usr/sbin/daemon
command_args="-r -u ${name} -P ${pidfile} /usr/local/bin/node $uptime_kuma_home/server/server.js --name uptime-kuma -- --port=3001 --host=0.0.0.0"

#export HOME=$uptime_kuma_home
export PATH=${PATH}:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
export LC_CTYPE="en_US.UTF-8"
export PLAYWRIGHT_BROWSERS_PATH="$uptime_kuma_browsers_path"

run_rc_command "$1"

But uptime-kuma is failing to start because the chdir is not being set, it's evaluating to an empty string, and I've been unable to figure out why. Any ideas?

Thanks!

[jmpalacios]

The problem I'm having with the chdir is in defining the uptime_kuma_chdir variable as ${name}_chdir, which gets evaluated by sh in a weird way, kind of as trying to execute a command (given a "not found" error message I'm seeing for the fully evaluated string).

I just tried defining it as eval ${name}_chdir=${uptime_kuma_home}, but that created a strange endless loop that exhausted file descriptors and almost killed my entire NAS!

[jmpalacios]

I've now fixed the rc script to define the chdir variable as eval ${name}_chdir=$uptime_kuma_home, and it's working fine, so I'm not too sure why my previous attempt caused all of the host's file descriptors to be exhausted.

I'm still testing it, though, especially around being able to customize the path to the uptime-kuma data directory, in case you're running the service in a jail and want to mount external directories into it, which is my case.

As soon as I have that sorted out, I'll share the result here.

[rob4226]

Hey Rob!

How far have you gotten in writing an rc(8) FreeBSD script for uptime-kuma? Would you care to share? And maybe even consider creating a port for the whole thing? I'd be more than willing to collaborate, test, etc.

Please let me know if you're interested, thanks!

Hey @jmpalacios here is my rc service file I created at /usr/local/etc/rc.d/uptimekuma and expects the uptime-kuma repo to be cloned to /usr/local/uptime-kuma.

Then uptimekuma_enable="YES" needs to go in /etc/rc.conf.

#!/bin/sh

# PROVIDE: uptimekuma
# REQUIRE: DAEMON NETWORKING
# BEFORE: LOGIN
# KEYWORD: shutdown

# Uptime Kuma
# A fancy self-hosted monitoring tool
#
# https://github.com/louislam/uptime-kuma
# https://uptime.kuma.pet/
#
# Creating a service for uptime-kuma. It is installed by cloning the git repo.
# See below on how to update the git repo.
#
# The usual command to start uptime kuma:
# node server/server.js --host=0.0.0.0

# Create a system user:
# pw adduser uptime_kuma -d /nonexistent -s /usr/sbin/nologin -c "System user for Uptime Kuma self-hosted monitoring tool"

# Updating Uptime Kuma ---------------------------------------------------------
# https://github.com/louislam/uptime-kuma/wiki/%F0%9F%86%99-How-to-Update
# cd /usr/local/uptime-kuma

# Update from git
# git fetch --all
# git checkout 1.21.2 --force

# Install dependencies and prebuilt
# npm i --omit=dev
# npm run download-dist
# ------------------------------------------------------------------------------

. /etc/rc.subr

name="uptimekuma"
rcvar=uptimekuma_enable

: ${uptimekuma_enable:="NO"}
: ${uptimekuma_user:="www"}
: ${uptimekuma_group:="www"}

uptimekuma_user=uptime_kuma
uptimekuma_group=uptime_kuma

# 12.4.2023 After updating to latest got error on FreeBSD bc it uses playwright
# but setting this environment variable allows it to work again:
# https://github.com/louislam/uptime-kuma/issues/3642#issuecomment-1839704192
uptimekuma_env="PLAYWRIGHT_BROWSERS_PATH=/nonexistent"

# daemon(8) - wrapper class to run commands detached from the controlling terminal
pidfile="/var/run/${name}/${name}.pid"
node="/usr/local/bin/node"
repo_path="/usr/local/uptime-kuma" # Where cloned the uptimekuma git repo to.
script="${node} ${repo_path}/server/server.js --host=0.0.0.0"

# NOTE To get uptime kuma to load correctly it needs to be started inside the
# repo's directory:
uptimekuma_chdir="${repo_path}"

command=/usr/sbin/daemon
procname="daemon"
command_args="-f -P ${pidfile} ${script}"

start_precmd="${name}_precmd"

uptimekuma_precmd()
{
    if [ ! -d /var/run/${name} ]; then
        mkdir -p /var/run/${name}
        chown ${uptimekuma_user}:${uptimekuma_user} /var/run/${name}
    fi
    install -o ${uptimekuma_user} /dev/null ${pidfile}
}

load_rc_config $name
run_rc_command "$1"

I would like to make a FreeBSD port (mostly to make this service file easily available) but any software that involves installing npm packages is almost impossible to fit correctly into the port framework (have tried before). This is mostly due to network activity only being allowed at a certain phase durring the installation process.

[jmpalacios]

Hey @rob4226!

Thank you for that rc script. Mine looks very similar, only that I simplify paths somewhat, e.g. pidfile="/var/run/${name}.pid" rather than pidfile="/var/run/${name}/${name}.pid", to eliminate the need for a precmd() function.

My rc script is still not ready, though, as I'm looking to extend it with facilities to abstract the host & port kuma will run on, but most importantly to add some way (that I still haven't fully figured out) of abstracting the path to kuma's data directory (e.g. in case you want to mount it into a jail at a custom path, as I intend to do… which may reintroduce the need for a precmd() function :/). I haven't had a chance to resume working on that, though.

On the other hand, I was also looking to create a FreeBSD port for this, to simplify jail deployment to a simple pkg install command, which is the reason why my rc script doesn't perform the Git clone of the sources. I have to admit, though, that I'm still learning the FreeBSD ports creation process (so far I've mostly just consumed them), so I wasn't aware creating one for Node-based applications was so hard.

What I'd figured is that the package's distfile could be fetched as a tarball from the GitHub CDN, and then the setup steps (e.g. npm run setup) could be taken care of in a pkg post-install script. Wouldn't that work?

[rob4226]

@jmpalacios Why don't you use rc vars like you did with : ${uptime_kuma_home:=/usr/local/share/uptime-kuma} so you can specify the host/port/etc... in the rc.conf of any jails you have like:

# rc.conf
uptimekuma_enable="YES"
uptimekuma_host="0.0.0.0"
uptimekuma_port="8080"

# /usr/local/etc/rc.d/uptimekuma

#  (Optional) To run on a different host add uptimekuma_host="0.0.0.0" to /etc/rc.config
#  (Optional) To run on a different port add uptimekuma_port="8080" to /etc/rc.config
: ${uptimekuma_host="127.0.0.1"}  # Defaults to localhost
: ${uptimekuma_port="3001"} # Defaults to port 3001

Well actually what I meant is it's very difficult to make a port that uses npm install and also abides by the rules required to upload it to the FreeBSD port tree. If you want to make a port that only you use, then you don't have to worry about those rules so it should be pretty straight forward to make a port for this.

[jmpalacios]

@jmpalacios Why don't you use rc vars like you did with : ${uptime_kuma_home:=/usr/local/share/uptime-kuma} so you can specify the host/port/etc... in the rc.conf of any jails you have like:

# rc.conf
uptimekuma_enable="YES"
uptimekuma_host="0.0.0.0"
uptimekuma_port="8080"

# /usr/local/etc/rc.d/uptimekuma

#  (Optional) To run on a different host add uptimekuma_host="0.0.0.0" to /etc/rc.config
#  (Optional) To run on a different port add uptimekuma_port="8080" to /etc/rc.config
: ${uptimekuma_host="127.0.0.1"}  # Defaults to localhost
: ${uptimekuma_port="3001"} # Defaults to port 3001

Oh, absolutely, that's exactly what I intend! I just haven't had a chance to go back to work on the script to add those abstractions just yet ;)

Well actually what I meant is it's very difficult to make a port that uses npm install and also abides by the rules required to upload it to the FreeBSD port tree. If you want to make a port that only you use, then you don't have to worry about those rules so it should be pretty straight forward to make a port for this.

I guess it's my unfamiliarity with those FreeBSD ports rules that prevent me from seeing the problem you're pointing out. What rules and/or conventions would be broken by fetching a distfile from the GitHub CDN, and calling "npm run setup" in a post-install port/pgk hook?

[rob4226]

@jmpalacios

I guess it's my unfamiliarity with those FreeBSD ports rules that prevent me from seeing the problem you're pointing out. What rules and/or conventions would be broken by fetching a distfile from the GitHub CDN, and calling "npm run setup" in a post-install port/pgk hook?

All network connections must be done before it is installed. I'm not sure what npm run setup here does but I assume it makes network connections. If it doesn't then you should be fine. You can test all this on FreeBSD using Poudriere test port. That will tell you if your port violates any rules. Even if it does violate some rules, you can still use the port for your personal use, it just won't be accepted in the official port tree.

[CommanderStorm]

Chiming in:
npm run setup does do network requests, for exampe to the git server. see

uptime-kuma/package.json

Line 52 in 56aa81e

"setup": "git checkout 1.23.11 && npm ci --production && npm run download-dist",

[jmpalacios]

npm run setup is one of the steps in Kuma's installation process, recommended by the project itself. And as @CommanderStorm points out, it does perform network requests. I was not aware that post-install hooks were not allowed to do that, I'll read up and test in poudriere.

Thanks!

[tschettervictor]

I wrote a script a while back, and just edited it again to include your rc script. Its designed for the iocage jail manager, and it looks like its working. I have it set so it mounts the data folder outside the jail for easy jail recreation.

[tschettervictor]

Im not a big fan of the pkg system not mounting the data outside the jail. Bastille has a nice template feature that I might compile a template for.

[jmpalacios]

I'd love to deploy Bastille-based jails! But, for the time being, my rig is a TrueNAS CORE server, which uses iocage, and I've been resisting moving my jails to a VM.

So, in the meantime, what I plan to do is figure out a why to provide an abstraction to the data path via the rc(8) startup script, and symlink the data directory within the uptime-kuma checkout to said path in a precmd function.

[tschettervictor]

I'd love to deploy Bastille-based jails! But, for the time being, my rig is a TrueNAS CORE server, which uses iocage, and I've been resisting moving my jails to a VM.

So, in the meantime, what I plan to do is figure out a why to provide an abstraction to the data path via the rc(8) startup script, and symlink the data directory within the uptime-kuma checkout to said path in a precmd function.

Since uptimekuma doesn’t create the data directory when cloning, my script mounts it right after cloning the repo, and then it runs the install command. This also works when reinstalling a new jail. The data folder is mounted and it picks up where it left off.