feat: Tailscale ping monitor

[SandiyosDev]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

This is a feature proposal to discuss the implementation of a new functionality within Uptime Kuma that would allow the use of custom flags for command-line tools. A prime example of this feature's application is Tailscale integration, as detailed in issue #1981 (Tailscale Ping Integration).

Consider the Tailscale example: by enabling custom flags, users could substitute a standard ICMP ping with tailscale ping, resulting in improved security (respecting ACLs) and better network segmentation. The utility of this feature extends to numerous other scenarios, enhancing Uptime Kuma's adaptability and versatility.

I've initiated this pull request to foster discussion and to collect feedback from maintainers and members alike on these proposed changes.

Proposed Changes

The proposed changes include:

1. Introducing a custom flag option that allows users to define their monitoring commands and expected responses.
2. Demonstrating this feature with a Tailscale implementation, leveraging the "tailscale ping " command as an alternative to the standard ICMP "ping " for device monitoring.

By introducing a feature allowing users to define their own monitoring commands and expected responses, we enable them to utilize specific tools or protocols, such as Tailscale, for their monitoring needs; It extends Uptime Kuma's functionality, catering to a broader range of monitoring requirements and scenarios.

Type of change

• User interface (UI)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update
• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
• I have performed a self-review of my own code and tested it
• My changes generate no new warnings

Checklist

• My code needed automated testing. I have added them (this is optional task)

[DennisGaida]

Are you planning to add code to this PR? I don’t think PRs are meant for empty discussion.

i do believe custom command line parsing might be quite complicated. Even if you were able to call an arbitrary executable from uptime kuma - how would you be able to parse it’s replies and get a response time from that. Would „no error“ mean a good response? What about executables that first output a status line such as „pinging host xyz now“ and only the following lines would be the actual thing (ping)

[louislam]

It is likely for non-docker setup and I think it may be too powerful to run a custom command via Uptime Kuma web interface. Let say someone run a rm -rf * command.

So I would not recommend to implement this. Instead, implementing a new monitor type for tailscale ping is better.

[SandiyosDev]

Based on your suggestions, I would consider implementing a new monitor type for Tailscale ping, however, there is no available npm package that directly supports Tailscale functionality, the best approach might be to use Node's child_process module to execute tailscale ping

Having not worked on uptime kuma in the past, I'd like to ask for your thoughts and suggestions on the best way to approach this. Are there examples or resources you could point me to that would help implement this correctly? I want to ensure that I could handle this in a way that does not mess with the existing design of Uptime Kuma.

[DennisGaida]

I'm not a fan of this feature.

• Running arbitrary commands would be beneficial, but just like @louislam says, it is a huge security risk because someone might run rm -rf
• Scoping this feature to only allow tailscale ping, but without including the tailscale binary (and setup) seems weird to me

Weird: I also wouldn't want the tailscale binary included with uptime-kuma, totally different product / different release cycle, so I think it is sensible to assume it exists. But this would just mean that this monitor calls a maybe existing binary including parameters in the backend, specifically tailscale ping. What happens to all other similar products such as ZeroTier, Cloudflare Access, Nebula, Vanilla Wireguard, ngrok, Pritunl, Twingate, etc. I wouldn't want uptime-kuma to be spammed with all these different product as specific monitors as it would really clutter the interface. Imagine we create 10 different PRs, all with boilerplate implementations of different ping features for different products - doable? Yes.

For this particular instance: Tailscale ping really is different than a regular ping, I totally get that. Personally I am also using Tailscale in my network and I am totally fine with regular pinging my Tailscale IPs / hostnames since this also goes via the same Wireguard channel. It is an ICMP request so it also feels like a regular ping and can be handled by everything (e.g. firewall, Tailscale ACL rules etc.). I don't really see a benefit of using tailscale ping with uptime-kuma, compared to a regular ping.

[SandiyosDev]

• Scoping this feature to only allow tailscale ping, but without including the tailscale binary (and setup) seems weird to me

I get that one of the focuses is that we don't want to overwhelm Uptime Kuma's interface or functionality with a myriad of product-specific monitors.

However, I believe that integrating Tailscale ping as a monitoring type could provide added value for users who use Tailscale and Uptime Kuma concurrently, as a heavy user myself, this offers a more seamless user experience for me, and also other users for the need for workarounds. It also aligns with Uptime Kuma's goa;l of being a user-friendly monitoring solution.

Perhaps we could consider an approach that provides the flexibility of adding product-specific monitors without cluttering the interface or functionality. For instance, we could consider a plugin-like structure where users could add or remove specific monitors based on their needs. One, the core application remains lightweight, and also two, users will have the flexibility to expand functionality as required.

[SandiyosDev]

I understand this might require more discussion and planning. I'm open to any thoughts, suggestions, or directions you both may have.

[DennisGaida]

I honestly don't see the benefit of using tailscale ping compared to a regular ping. Check my tailscale ACL rule which even allows for securing the regular ping:

// uptime allow ICMP to all
{
  "action": "accept",
  "proto":  "1",
  "src":    ["tag:uptime-kuma"],
  "dst":    ["*:*"],
},

I understand your wish and this feature request for a better user experience, I also believe that a plugin-type-system might be beneficial - in this case I am fine with using regular ping.

[louislam]

I think we should stick to my last comment (#3178 (comment)), uses child_process to call tailscale ping, that's it.

I won't say there is no advantage, because in addition to the ping value, ultimately we can use this monitor to check whether it is running under P2P or DERP.

[SandiyosDev]

@DennisGaida, I understand your position on using a regular ping for Tailscale. It's practical and fits within current features.

Regarding the discussion on product-specific monitors, I take your point about potential cluttering. Yet, I believe that the user base could benefit from the option to use specific tools they already use and trust. To strike a balance, I propose we address this by incrementally integrating product-specific monitor types based on user needs, while at the same time considering evolving Uptime Kuma towards a plugin-friendly platform in a future release.

This way, users can develop their own product-specific monitoring types. If a monitor proves robust and widely useful, we could consider including it within Uptime Kuma's repository as an "certified" plugin. I believe this could enhance both usability and simplicity, providing flexibility for users to customize their monitoring setup... perhaps we can start a separate thread for this.

I'll be proceeding with the integration using child_process to call Tailscale ping as suggested by @louislam once I have the time.

[SandiyosDev]

I couldn't see the tailscale monitor type in the "add monitor" page after building in docker, I used my my dockerfile and added the line "COPY ./ /app/" with the changes made with both our commits; I assume that some other changes need to be made within uptime kuma, however, I'll request a review for now.
At this stage, I cannot test it from the web interface, but do let me know if there's anything more that I need to do.

[SandiyosDev]

Hey @CommanderStorm, I handled all the changes suggested, if there's anything more that I should do, please let me know. Otherwise, it is now ready for review.

[CommanderStorm]

I noticed that the actions are not run against this PR, given that this PR targets 1.23.x and not master.
Could you run

npm run lint-fix:js
npm run lint

[SandiyosDev]

I noticed that the actions are not run against this PR, given that this PR targets 1.23.x and not master. Could you run

npm run lint-fix:js
npm run lint

I've ran ESLint and fixed all the linting issues.

[louislam]

I fixed the hostname issue (change from url to hostname), but I am still not able to get it to work.

Error checking Tailscale ping: RangeError [ERR_OUT_OF_RANGE]: The value of "timeout" is out of range. It must be an unsigned integer. Received NaN

[SandiyosDev]

I fixed the hostname issue (change from url to hostname), but I am still not able to get it to work.

Error checking Tailscale ping: RangeError [ERR_OUT_OF_RANGE]: The value of "timeout" is out of range. It must be an unsigned integer. Received NaN

How did you manage to build and run it, I can't seem to find the option for tailscale in the monitor type section.

[louislam]

Normally, you have to setup a development environment in your local.
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#tools

In case you don't want to, you can use this special docker image to test your pr:

docker run --rm -it -v uptime-kuma:/app/data -p 3000:3000 -p 3001:3001 --pull always -e 'UPTIME_KUMA_GH_REPO=SGprooo:feature/custom-flags-implementation' louislam/uptime-kuma:pr-test

https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests

[SandiyosDev]

Normally, you have to setup a development environment in your local. https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#tools

In case you don't want to, you can use this special docker image to test your pr:

docker run --rm -it -v uptime-kuma:/app/data -p 3000:3000 -p 3001:3001 --pull always -e 'UPTIME_KUMA_GH_REPO=SGprooo:feature/custom-flags-implementation' louislam/uptime-kuma:pr-test

https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests

I could not get to the web interface, docker builds and runs correctly up until Uptime Kuma tries to initialize in this section, then the container stops, and the data volume is removed:

2023-07-15T07:21:15Z [SERVER] INFO: Version: 1.22.1
Trace: Error: EACCES: permission denied, mkdir './data/screenshots/'
    at Object.mkdirSync (node:fs:1382:3)
    at Function.init (/app/server/database.js:108:16)
    at /app/server/server.js:171:14
    at Object.<anonymous> (/app/server/server.js:1600:3)
    at Module._compile (node:internal/modules/cjs/loader:1196:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1250:10)
    at Module.load (node:internal/modules/cjs/loader:1074:32)
    at Function.Module._load (node:internal/modules/cjs/loader:909:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:22:47 {
  errno: -13,
  syscall: 'mkdir',
  code: 'EACCES',
  path: './data/screenshots/'
}
    at process.<anonymous> (/app/server/server.js:1839:13)
    at process.emit (node:events:513:28)
    at emit (node:internal/process/promises:140:20)
    at processPromiseRejections (node:internal/process/promises:274:27)
    at processTicksAndRejections (node:internal/process/task_queues:97:32)
If you keep encountering errors, please report to https://github.com/louislam/uptime-kuma/issues
2023-07-15T07:21:15Z [] INFO: Cannot write to error.log
node:events:491
      throw er; // Unhandled 'error' event
      ^

Error: spawn ps ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:285:19)
    at onErrorNT (node:internal/child_process:485:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
    at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
    at onErrorNT (node:internal/child_process:485:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn ps',
  path: 'ps',
  spawnargs: [ '-o', 'pid', '--no-headers', '--ppid', 132 ]
}
npm notice
npm notice New major version of npm available! 8.19.4 -> 9.8.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v9.8.0
npm notice Run npm install -g npm@9.8.0 to update!
npm notice

[louislam]

Please pull the image again and remove the argument -v uptime-kuma:/app/data

docker pull louislam/uptime-kuma:pr-test
docker run --rm -it -p 3000:3000 -p 3001:3001 --pull always -e 'UPTIME_KUMA_GH_REPO=SGprooo:feature/custom-flags-implementation' louislam/uptime-kuma:pr-test