feat: add option for no-logs-no-support #68
Conversation
Signed-off-by: Derek Kaser <[email protected]>
WalkthroughAdds a "No Logs No Support" setting: UI renders the option, localization strings added, Config gains a NoLogsNoSupport flag initialized from NO_LOGS_NO_SUPPORT, and System appends the -no-logs-no-support parameter into generated tailscaled params when enabled. Changes
Sequence DiagramsequenceDiagram
participant User
participant UI as Settings UI
participant Config as Config Object
participant System as System Service
participant Tailscale
User->>UI: toggle "No Logs No Support"
UI->>Config: save NO_LOGS_NO_SUPPORT (0/1)
Config->>Config: NoLogsNoSupport = parsed(NO_LOGS_NO_SUPPORT)
Config->>System: provide config
System->>System: createTailscaledParamsFile()
alt NoLogsNoSupport == true
System->>System: append -no-logs-no-support to params
end
System->>Tailscale: write params file (with/without flag)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Pre-merge checks and finishing touches✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (2)📚 Learning: 2025-11-15T03:15:08.195ZApplied to files:
📚 Learning: 2025-10-25T02:28:03.838ZApplied to files:
🔇 Additional comments (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/usr/local/emhttp/plugins/tailscale/include/Pages/Settings.php(1 hunks)src/usr/local/emhttp/plugins/tailscale/locales/en_US.json(2 hunks)src/usr/local/php/unraid-tailscale-utils/unraid-tailscale-utils/Config.php(2 hunks)src/usr/local/php/unraid-tailscale-utils/unraid-tailscale-utils/System.php(1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: dkaser
Repo: unraid/unraid-tailscale PR: 51
File: src/usr/local/emhttp/plugins/tailscale/rc.tailscale:14-14
Timestamp: 2025-10-25T02:28:03.838Z
Learning: In Tailscale 1.90.2+, the `-hardware-attestation` and `-encrypt-state` flags are valid command-line options for tailscaled, even though they may not be fully documented in public knowledge base articles yet. The `-hardware-attestation` flag uses hardware-backed keys (TPM 2.0) to bind node identity, and `-encrypt-state` encrypts the state file on disk.
📚 Learning: 2025-11-11T00:22:27.117Z
Learnt from: dkaser
Repo: unraid/unraid-tailscale PR: 66
File: src/usr/local/emhttp/plugins/tailscale/include/Pages/Settings.php:218-218
Timestamp: 2025-11-11T00:22:27.117Z
Learning: In the unraid-tailscale plugin, pages with `Tabs="true"` (like Tailscale.page) and their submenu pages (like Tailscale-1-Settings.page) share the same JavaScript scope. JavaScript functions defined in Tailscale.php are accessible in Settings.php because they load in the same browser context.
Applied to files:
src/usr/local/emhttp/plugins/tailscale/include/Pages/Settings.php
📚 Learning: 2025-10-25T02:28:03.838Z
Learnt from: dkaser
Repo: unraid/unraid-tailscale PR: 51
File: src/usr/local/emhttp/plugins/tailscale/rc.tailscale:14-14
Timestamp: 2025-10-25T02:28:03.838Z
Learning: In Tailscale 1.90.2+, the `-hardware-attestation` and `-encrypt-state` flags are valid command-line options for tailscaled, even though they may not be fully documented in public knowledge base articles yet. The `-hardware-attestation` flag uses hardware-backed keys (TPM 2.0) to bind node identity, and `-encrypt-state` encrypts the state file on disk.
Applied to files:
src/usr/local/emhttp/plugins/tailscale/locales/en_US.json
🔇 Additional comments (3)
src/usr/local/php/unraid-tailscale-utils/unraid-tailscale-utils/Config.php (1)
33-33: LGTM!The new
NoLogsNoSupportconfiguration property follows the established patterns:
- Naming convention is consistent (PascalCase for property, UPPER_SNAKE_CASE for config key)
- Default value of
"0"(false) is appropriately safe- Type conversion using
boolval()matches other boolean propertiesAlso applies to: 58-58
src/usr/local/emhttp/plugins/tailscale/include/Pages/Settings.php (1)
72-81: LGTM!The UI implementation correctly follows the established pattern for settings in this file:
- Uses the standard
dl/dt/ddstructure with proper translation keys- Correctly preselects the option based on
$tailscaleConfig->NoLogsNoSupport- Includes helpful inline documentation via the context translation
- Appropriately placed in the advanced view section alongside other system settings
The setting will trigger a Tailscale restart when applied via the existing form submission mechanism.
src/usr/local/emhttp/plugins/tailscale/locales/en_US.json (1)
52-52: LGTM!The translation strings are well-crafted:
- Label "No Logs No Support" is clear and concise
- Context description accurately explains that the feature disables telemetry and affects support eligibility
- Keys follow the established naming convention (
settings.Xandsettings.context.X)- JSON structure is valid
Also applies to: 67-67
| if ($config->NoLogsNoSupport) { | ||
| $custom_params .= "--no-logs-no-support "; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the Tailscale flag name and format.
The implementation correctly appends the flag to custom parameters. However, please verify that --no-logs-no-support is the correct flag name for the Tailscale daemon. Note the inconsistency: line 368 uses a single dash (-port) while line 372 uses double dashes (--no-logs-no-support). While this may be intentional if Tailscale uses different conventions for different flags, it should be confirmed.
🌐 Web query:
What is the correct Tailscale daemon flag to disable telemetry and opt out of support? Is it --no-logs-no-support or -no-logs-no-support?
💡 Result:
Use the double-dash form: --no-logs-no-support. It disables telemetry/upload and opts you out of support. You can also set TS_NO_LOGS_NO_SUPPORT=true as an environment variable. [1][2]
Sources:
[1] Tailscaled daemon flags (tailscale.com).
[2] Opt‑out of client logging (tailscale.com).
I need to verify the context around line 368 to check the inconsistency mentioned in the review comment.
---
🏁 Script executed:
```shell
#!/bin/bash
# Get context around lines 368-373 to see both flags mentioned in the review
fd -e php -x cat {} \; | grep -n -B5 -A5 "no-logs-no-support" | head -30
Length of output: 423
I found the actual code. Now I need to verify if -port is the correct flag format for Tailscale.
I need to search specifically for tailscaled daemon flags, as the previous search returned client command flags rather than daemon startup options.
Based on my verification, I found evidence that clarifies the inconsistency. The correct tailscaled daemon flag format uses --port (double dash) and --tun (double dash), not the single-dash -port used in the code.
The web search and prior verification confirm that tailscaled accepts command-line flags like --tun=NAME for specifying the TUN device name, and the initial web query confirmed that on Windows, PORT=N can be set as an environment variable to change the default UDP listen port.
Fix the inconsistent flag format in the port parameter.
The code uses -port (single dash) on line 789, but tailscaled daemon expects --port (double dash) to match the proper flag convention. This is inconsistent with line 793's correct --no-logs-no-support format. Update line 789 from -port to --port for consistency and correctness.
🤖 Prompt for AI Agents
In src/usr/local/php/unraid-tailscale-utils/unraid-tailscale-utils/System.php
around lines 371 to 373 (and specifically the daemon flag usage at line ~789),
the port flag is using a single dash "-port" which is inconsistent with other
daemon flags like "--no-logs-no-support" and incorrect for tailscaled; change
the port flag to use a double-dash "--port" (e.g., replace "-port" with
"--port") so the daemon startup parameters use the correct tailscaled flag
format and match the rest of the code.
There was a problem hiding this comment.
Either one or two leading dashes is acceptable for this (see the output of tailscaled -h). I will update the flag to use one dash to be consistent with the other parameters used in the command.
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
tailscaled command line flags single dash double dash both accepted
💡 Result:
Short answer: tailscaled/tailscale use GNU-style long flags with double dashes (e.g. --port, --tun, --accept-routes). Single-dash short forms (like -port) are not generally supported — the docs and examples show double-dash flags. [1][2]
Sources:
- tailscaled flags and how to set them (examples: --tun, --port, --socks5-server). [Tailscale docs]. [1]
- Tailscale CLI reference showing commands/flags (examples: --accept-routes, --advertise-routes, --auth-key). [Tailscale docs]. [2]
@dkaser, thank you for the clarification! I appreciate you checking the tailscaled -h output directly. Using a consistent single-dash format across all the daemon parameters makes sense for code maintainability.
✏️ Learnings added
Learnt from: dkaser
Repo: unraid/unraid-tailscale PR: 68
File: src/usr/local/php/unraid-tailscale-utils/unraid-tailscale-utils/System.php:371-373
Timestamp: 2025-11-15T03:15:08.195Z
Learning: In the unraid-tailscale project, tailscaled accepts both single-dash and double-dash formats for command-line flags (e.g., both `-port` and `--port` are valid). The project uses single-dash format for consistency across daemon parameters in the System.php file.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: dkaser
Repo: unraid/unraid-tailscale PR: 51
File: src/usr/local/emhttp/plugins/tailscale/rc.tailscale:14-14
Timestamp: 2025-10-25T02:28:03.838Z
Learning: In Tailscale 1.90.2+, the `-hardware-attestation` and `-encrypt-state` flags are valid command-line options for tailscaled, even though they may not be fully documented in public knowledge base articles yet. The `-hardware-attestation` flag uses hardware-backed keys (TPM 2.0) to bind node identity, and `-encrypt-state` encrypts the state file on disk.
Signed-off-by: Derek Kaser <[email protected]>
Summary by CodeRabbit
New Features
Localization
Behavior