ravenclaw900 / dietpi-dashboard

A lightweight, standalone web dashboard for DietPi

DietPi-Dashboard

A web dashboard for DietPi

Installation

To install, use one of the precompiled releases, nightly builds or compile it yourself

Downloading

Release:

curl -fL "$(curl -sSf 'https://api.github.com/repos/ravenclaw900/DietPi-Dashboard/releases/latest' | mawk -F\" "/\"browser_download_url\": \".*dietpi-dashboard-$G_HW_ARCH_NAME\"/{print \$4}")" -o dietpi-dashboard # Download latest binary for current architecture
chmod +x dietpi-dashboard # Make binary executable
./dietpi-dashboard # Run binary

Nightly:

curl -fL "https://nightly.link/ravenclaw900/DietPi-Dashboard/workflows/push-build/main/dietpi-dashboard-$G_HW_ARCH_NAME.zip" -o dietpi-dashboard.zip # Download latest nightly build for current architecture
unzip dietpi-dashboard.zip # Unzip binary
rm dietpi-dashboard.zip # Remove archive
chmod +x dietpi-dashboard # Make binary executable
./dietpi-dashboard # Run binary

Compiling

Prereq:

dietpi-software install 9 16 17 # Install Node.js (webpage), Build-Essential (gcc), and Git (git clone), respectively
corepack enable # Enable pnpm package manager, for node dependencies
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # Install Rust (backend)
source ~/.cargo/env # Update $PATH
cargo install just # Install just command runner, for build file

Compiling:

git clone https://github.com/ravenclaw900/DietPi-Dashboard # Download source code
cd DietPi-Dashboard # Change directories
cargo build --release # Compile binary for your platform
./target/release/dietpi-dashboard # Run binary

Note that there will be a difference between self-compiled binaries and the nightly/release builds. The nightly/release builds are statically linked with the musl libc implementation, while self-compiled binaries will be dynamically linked with glibc. This should not affect functionality in any way.

Open dashboard:

http://<your.IP>:5252

dietpi-dashboard's Issues

[Bug] Terminal exits service

As we found already on the PR at the DietPi repo. There is an exit signal btw:

Main PID: 50144 (code=killed, signal=HUP)

So a SIGHUP is sent to the main process.

Part of a problem is that in systemd units, SHELL == /bin/sh despite User=root being defined. Not sure how to force it to use users real shell. We should use /bin/bash here hardcoded, since this also it the only shell where the banner and the command shortcuts are known to work. But forcing/setting the variable does not fix the crash, so it is a dedicated issue.

I'm not sure where the SIGHUP signal is coming from, but probably we can force systemd to keep the service active when it is received.

---

While SIGHUP is often used to reload a service, here it stops it, i.e. kill -HUP <PID> stops the process started form console. So this signal seems to be sent only when it is started via web UI. Not sure if a systemd unit has somehow issues with the PTY 🤔.

---

I guess (*cmd.write().await).kill().unwrap(); usually kills the shell process only, however, I wonder it this can in some circumstances kill the parent process? The writer does already .write_all("exit".as_bytes()), which should usually be sufficient. Probably we need to add some debug code to check what's going on. I'll now try to run it with strace.

Can't change the port

Hi,

I use the DietPi-Dashboard provided with DietPi v7.8.2 on NannoPI NEO 3. I also run another software on port 8088, so I tried to change it in /opt/dietpi-dashboard/config.toml - if I started from the same directory, e.g., /opt/dietpi-dashboard - it works with the new port, but if I start it from another directory or as a service it tries to use the default 8088 port and fails.

Regards

Add HOSTNAME to the webpage header ?

Just a small enhancement request. I am running DietPi on several SBCs, and I love using this dashboard, and sometimes have multiple open. But in the browser tabs they all just say "DietPi Dashboard" (with the IP if you mouse over) but it would be nice if in the webpage itself in the header to the right of the DietPi icon it could display the hostname of the SBC it's connected to.
I find myself often jumping to the "management" section to verify which SBC i am on at the moment.

Thanks for any consideration.

Spring board for known (+ custom) web applications

Since we have some users who want to use something like Heimdall, to have a page with tiles/links to various web applications, but Heimdall is difficult to implement into dietpi-software in a compatible way, probably we can implement it into DietPi-Dashboard:

• We could scan for installed (dietpi-)software titles where we know the subpath or the port, and show a related tile with link (using the dashboard access host + known default port and/or subpath) and a hardcoded logo.
• We could allow to edit the link, probably even the logo.
• We could allow to add custom tiles with link and logo.
• We could allow to reorder the tiles.

The last three parts would require a server-side storing of the info, so something which DietPi-Dashboard does not do at all. Of course it could be also done just via config.toml for now, so that it is possible to override the default link of a defined web application.

[Request] Add support for password protection

Since the DietPi-Dashboard allows server administration and currently runs as root user, it makes sense to protect access. It doesn't run on a common port, so behind a NAT usually port forwarding needs to be enabled, but in other cases like a VPS the port might be publicly accessible OOTB and in other cases you may want to access DietPi-Dashboard remotely (while then I would always recommend a VPN).

Concepts:

• It should be optional since users may want to implement authentication at a proxy level. I would however enable it by default during DietPi-Software installs, using the global software password.
• Easy to implement would be probably classic HTTP authentication with username and password, with the known limitation of either unencrypted store or unencrypted transfer (as long as HTTPS is not enabled). I'm pretty sure the used Rust crates already support it natively or another crate can be found quickly which does it.
• I personally would prefer a simpler solution with password only, but not username. This is an admin interface, hence only a single person should have access. This is however not natively supported via HTTP authentication, hence it would require a custom implementation, or a crate which serves it. In theory it could be kept simple: Show an input box, take the input and hash/encrypt it, then compare against the value stored in the config file, which as well contains the hashed/encrypted password only. The limitation/problem is the same then, when we use encryption or hashing with salt: Either the password needs to be sent unencrypted and encrypted server-side for comparison, which is a problem on plain HTTP, or the password cannot be encrypted/salted, but only hashed (without salt) client-side and stored like that as well server-side. This is since of course the encryption key or hash salt can only be stored on the server either. If we enforce strict 0600 mode on the config file, I'm actually fine with a sha512 hash only. A more complex compromise would be sha512 hashed transfer, but salted/encrypted storing in the config file. The client then does the hashing only and the server does the salted hashing/encryption with the key/salt stored as well in the config file to have more more secure there. Again another way would be to send the key/salt hashed to the client to encrypt the password, lol this would be a whole own secure password transfer implementation 😄. Probably better to go with known HTTP authentication...

[Visual] [Software] Enhance output colors on software installs/removals

These are currently difficult to read on dark mode:

When enabling light mode, it looks good.

[Bug] Panic when accessing process list on ARMv8

Nov 06 21:20:46 Building-ARMv8-Bullseye dietpi-dashboard[4777]: thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Load(Error { source: Kind(InvalidData), context: Some(Message { text: "Unknown process state 0" }) })', /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/ops/function.rs:150:5

Ran into this when testing on ARMv8 Bullseye with the musl builds and regular nightly builds. On all other architectures it works fine, both builds.

Dashboard service discovery

It would be nice if DietPi-Dashboard would make itself discoverable by mDNS/Bonjour browsers by setting up an avahi-daemon service file. Something like (/etc/avahi/services/dietpi_dashboard.service):

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<!-- See avahi.service(5) for more information about this configuration file -->
<service-group>
  <name replace-wildcards="yes">DietPi dashboard (%h)</name>
  <service>
    <type>_http._tcp</type>
    <port>5252</port>
    <txt-record>vendor=DietPi</txt-record>
    <txt-record>model=Pi</txt-record>
  </service>
</service-group>

[Bug] Services page crashes on Buster and Stretch

Nov 06 16:36:19 VM-Buster dietpi-dashboard[2597]: thread 'tokio-runtime-worker' panicked at 'called `Option::unwrap()` on a `None` value', src/systemdata.rs:333:54
Nov 06 16:36:19 VM-Buster dietpi-dashboard[2597]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Works fine on Bullseye, but on Buster and Stretch it crashes with above error as fast as the services page is accessed.

[bug] rename a blank file, delete it

Creating a bug report/issue

Required Information

• DietPi version |
  G_DIETPI_VERSION_CORE=8
  G_DIETPI_VERSION_SUB=0
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'

• Distro version |
  bullseye

• Kernel version |
  5.10.0-10-amd64 #1 SMP Debian 5.10.84-1

• SBC model |
  Native PC (x86_64)

• Power supply used |
  battery laptop

• SDcard used |
  HDD 160gb

Additional Information (if applicable)

• Software title | dietpi-dashboard
• Was the software title installed freshly or updated/migrated?
  installed freshly
• Can this issue be replicated on a fresh installation of DietPi?
  yes
  535e7b02-4f83-4c3e-a095-1a76da643fa2

Steps to reproduce

1. renaming a file, leaving the name blank, in dietpi-dashboard using file browser deletes the file from the system, even canceling the rename window

Expected behaviour

-renaming a file

Actual behaviour

• deletes the file from the system

Extra details

• ...

[Request] Shortcuts to any installed web services?

This is very much a "nice to have" but would be super cool if any installed software that has a web UI can be listed on the main page as little shortcuts that can be clicked. Something along the lines of what Heimdall looks like?

https://github.com/linuxserver/Heimdall

Set a token expiry time doesn't work

I set a token expire time in config.yml.
For testing I set it to really low values (0 and 1 and 10)
But I still can access the dashboard after closing the tab or even the whole browser, and waited for the set time.

It only worked correctly in Incognito / private mode (I tested Firefox and Chrome), but this makes sense, because the token gets immediatly deleted after closing the tab, no matter which time is configured inside the dashboard.

Version of DietPi-Dashboard: 0.5.1

Nightly or stable: both, but only stable worked correct, nightly didn't showed statistics, which is another problem not related to this ;)

Version of DietPi: 8.2.2

Device architecture: armv8

To Reproduce

1. Install dashboard
2. add expiry = <some value> in /opt/dietpi-dashboard/config.toml
3. restart dashboard service
4. browse to dashboard in browser
5. insert password
6. close the tab/brwoser and reopen page for dashboard
7. no password needed

Error log
not necessary

[Config] Dark mode config option + persistent store

It would be great if the dark mode could be disabled via config file, respectively an initial default set by this, so that it can be still toggled via web UI. This goes hand in hand with the ability to have it stored in the browser so that reloading the page or opening at a later time does not reset it.

Adding and passing a setting in the backend is not an issue, but I'm stuck about how to pass this to the frontend. An own API/route only to get the setting is overkill, but there is no other direct way how the frontend can communicate with the backend, is it? In theory it could be passed via response header, but that would also mean that a request is done in JavaScript for that as it isn't possible to read/know headers which where send with the current page or script.

HTML, CSS and JavaScript is all statically created at compile time, right? The only other and probably best solution is to pass it via socketData.darkMode to be retrieved once in socketOpenListener and stored in localStorage from where it is read by the frontend?

[Request] please add cpu temperature meter

I think that one of the most important sensor that should be visualized in th system diagnostic tab should be CPU temp.

Dashboard crashes with almost every request made.

Describe the bug:
The dietpi-dashboard process aborts every now and then, not finding a file or directory.

Version of DietPi-Dashboard: 0.5.0

Nightly or stable: Nightly & Stable

Version of DietPi: 5.10.92-v8+

Device architecture: Cortex-A53 (ARMv8) 64-bit SoC

To Reproduce

1. Run ./dietpi-dashboard.
2. Make a request to the software by clicking a tab in the web dashboard.
3. Software crashes, see error.

Error log
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/systemdata.rs:362:34
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Aborted

dietpi-dashbard crashed itself

I installed dietpi dashboard on my raspberry pi-B2 & intel nuc both devices yesterday night. after running some time correctly on both devices. this app itself killed & the log file show this type of error

Nov 13 18:14:43 DietPi dietpi-dashboard[409]: thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Protocol("Connection reset without closing handshake")', src/sockets.rs:295:58
Nov 13 18:14:43 DietPi dietpi-dashboard[409]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Nov 13 18:14:43 DietPi systemd[1]: dietpi-dashboard.service: Main process exited, code=killed, status=6/ABRT
Nov 13 18:14:43 DietPi systemd[1]: dietpi-dashboard.service: Failed with result 'signal'.
Nov 13 18:14:43 DietPi systemd[1]: dietpi-dashboard.service: Consumed 4.519s CPU time.

after restart dietpi-dashboard it is again start & start running. so i do not have any idea why this app killed by both dietpi systems.
& in another device the error log is like this

Nov 13 17:34:12 DietPi dietpi-dashboard[41875]: thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" })', src/sockets.rs:295:58
Nov 13 17:34:12 DietPi dietpi-dashboard[41875]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Nov 13 17:34:12 DietPi systemd[1]: dietpi-dashboard.service: Main process exited, code=killed, status=6/ABRT
Nov 13 17:34:12 DietPi systemd[1]: dietpi-dashboard.service: Failed with result 'signal'.
Nov 13 17:34:12 DietPi systemd[1]: dietpi-dashboard.service: Consumed 13.059s CPU time.

[Visual] Allow to change color/style mode

Currently we have a pretty dark mode design, which is fine. Mid/Long term it would be great to have a toggle to enable a bright mode and/or even change the accent colour from green to something else. We just need to assure that the DietPi logo keeps looking good 😄.

Linking the original request by @GvY85: MichaIng/DietPi#448 (comment)

I personally would give this a low priority currently, and concentrate on stability first, but of course if someone is in mood to start with this, we are always open to pull requests.

[Bug] Terminal sometimes freezes

The terminal page seems to freeze if there's a large amount of input, either from a running command or from a lot of typing. However, input is still sent through the websocket. Need to test if this is a backend or frontend problem.

[Request] Adding base URL support for reverse proxy possibility

I'd like to add the dashboard to my reverse proxy. With the nodes update its even easier to access all my RPI from one URL. I'd think it would make it much easier if it also could be added to a reverse proxy.

EDIT: btw I Had a problem displaying other nodes on the single web ui. fyi It was caused by my ad blocker not allowing other domains. Might want to add a warning for other users. It displays this message forever: "Connecting to API..."

RAM usage seems to be way off for processes

RAM usage seems to be way off on my Rpi 2.

For example the dashboard shows cloudflared with 795MiB and tailscaled with 788MiB. Both are more than the 720MiB the RPi can actually use.

compared to htop showing cloudflared with 21MB and tailscaled with 18MB.

Logout-Button?

Why is there no possibility to log out of the dashboard?

If you close the browser tab (or even the whole browser) and open the dashboard again, you (and anyone else who uses the computer) are still logged in (and you can delete files, shutdown the server and so on....)

I don't get it...

Dashboard keeps crashing :(

Hi guys, it's not working for me... keeps crashing... any ideas how to fix this?

this is the log, version 0.4.1:

Jan 30 12:38:12 server dietpi-dashboard[2452]: thread 'tokio-runtime-worker' panicked at 'thread 'called `Result::unwrap()` on an `Err` value: ()', tokio-runtime-workersrc/sockets.rs' panicked at ':called `Result::unwrap()` on an `Err` value: ()299', :src/sockets.rs58:
Jan 30 12:38:12 server dietpi-dashboard[2452]: 299note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Jan 30 12:38:12 server dietpi-dashboard[2452]: :58
Jan 30 12:38:12 server systemd[1]: dietpi-dashboard.service: Main process exited, code=killed, status=6/ABRT
Jan 30 12:38:12 server systemd[1]: dietpi-dashboard.service: Failed with result 'signal'.
Jan 30 12:38:12 server systemd[1]: dietpi-dashboard.service: Consumed 3.734s CPU time.
Jan 30 13:29:18 server systemd[1]: Started Web Dashboard (DietPi).
Jan 30 13:29:18 server dietpi-dashboard[4965]: 2022-01-30 12:29:18,225 INFO  [warp::server] Server::run; addr=0.0.0.0:5252
Jan 30 13:29:18 server dietpi-dashboard[4965]: 2022-01-30 12:29:18,225 INFO  [warp::server] listening on http://0.0.0.0:5252
Jan 30 13:29:25 server dietpi-dashboard[4965]: 2022-01-30 12:29:25,797 INFO  [dietpi_dashboard] Request to /
Jan 30 13:29:25 server dietpi-dashboard[4965]: 2022-01-30 12:29:25,831 INFO  [dietpi_dashboard] Request to /assets/index.78a32cef.js
Jan 30 13:29:25 server dietpi-dashboard[4965]: 2022-01-30 12:29:25,832 INFO  [dietpi_dashboard] Request to /assets/index.69f8c40f.css
Jan 30 13:29:25 server dietpi-dashboard[4965]: 2022-01-30 12:29:25,932 INFO  [dietpi_dashboard] Request to /assets/xterm.6fe708e6.js
Jan 30 13:29:26 server dietpi-dashboard[4965]: 2022-01-30 12:29:26,031 INFO  [dietpi_dashboard] Request to /assets/xterm.6fe708e6.js
Jan 30 13:29:26 server dietpi-dashboard[4965]: 2022-01-30 12:29:26,035 INFO  [dietpi_dashboard] Request to /ws
Jan 30 13:29:26 server dietpi-dashboard[4965]: 2022-01-30 12:29:26,036 INFO  [dietpi_dashboard] Request to /assets/dietpi.4cc58251.png
Jan 30 13:29:28 server dietpi-dashboard[4965]: 2022-01-30 12:29:28,365 INFO  [dietpi_dashboard] Request to /login/
Jan 30 13:31:32 server dietpi-dashboard[4965]: 2022-01-30 12:31:32,381 INFO  [dietpi_dashboard] Request to /
Jan 30 13:31:32 server dietpi-dashboard[4965]: 2022-01-30 12:31:32,391 INFO  [dietpi_dashboard] Request to /assets/index.78a32cef.js
Jan 30 13:31:32 server dietpi-dashboard[4965]: 2022-01-30 12:31:32,392 INFO  [dietpi_dashboard] Request to /assets/index.69f8c40f.css
Jan 30 13:31:32 server dietpi-dashboard[4965]: 2022-01-30 12:31:32,486 INFO  [dietpi_dashboard] Request to /assets/xterm.6fe708e6.js
Jan 30 13:31:32 server dietpi-dashboard[4965]: 2022-01-30 12:31:32,581 INFO  [dietpi_dashboard] Request to /assets/xterm.6fe708e6.js
Jan 30 13:31:32 server dietpi-dashboard[4965]: 2022-01-30 12:31:32,585 INFO  [dietpi_dashboard] Request to /ws
Jan 30 13:31:32 server dietpi-dashboard[4965]: 2022-01-30 12:31:32,586 INFO  [dietpi_dashboard] Request to /assets/dietpi.4cc58251.png
Jan 30 14:04:42 server dietpi-dashboard[4965]: thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: ()', src/sockets.rs:299:58
Jan 30 14:04:42 server dietpi-dashboard[4965]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Jan 30 14:04:42 server systemd[1]: dietpi-dashboard.service: Main process exited, code=killed, status=6/ABRT
Jan 30 14:04:42 server systemd[1]: dietpi-dashboard.service: Failed with result 'signal'.
Jan 30 14:04:42 server systemd[1]: dietpi-dashboard.service: Consumed 17.626s CPU time.
Jan 30 14:44:11 server systemd[1]: Started Web Dashboard (DietPi).
Jan 30 14:44:11 server dietpi-dashboard[11688]: 2022-01-30 13:44:11,833 INFO  [warp::server] Server::run; addr=0.0.0.0:5252
Jan 30 14:44:11 server dietpi-dashboard[11688]: 2022-01-30 13:44:11,833 INFO  [warp::server] listening on http://0.0.0.0:5252

[Suggestion] Change table header colors from white to black

As white text on the bright lime is hard to read. The CSS is somehow auto-generated and the class defined here, right?

So I guess there is no way to add color: #000 to the class? Then I'd add it manually to each table header.

[Visual] enhance text allignment on Management > System Info

On the "Management" page of the dashboard, there is a 'system information' block (two columns it looks like). The 'uptime' line is constantly refreshed (every second). A zero-value is not printed, nor the unit in textform (the text "seconds"). The whole line - for a short time - much shorter than the secons before or the second after. As a result the two columns have different widths.

This is ugly to see ;-) May be you could use a (shorter) form(at) for the uptime? So that any uptime is the same text width?

feat(frontend): Store passwords for multiple backend nodes in browser

Currently when switching between backend nodes, the password needs to be re-entered every time. Great would be when passwords would be stored per node so that, unless expired, it needs to be entered only a single time when switching between nodes.

TLS support for elliptic curve (ec-384) keys

I just wanted to setup TLS on my server, which doesn't use an RSA key but EC, ec-384 to be precise, but the dashboard doesn't start up with it:

dietpi-dashboard[10205]: thread 'main' panicked at 'error binding to 0.0.0.0:5252: key contains no private key', /cargo/registry/src/github.com-1ecc6299db9ec823/warp-0.3.2/src/server.rs:534:27

=> https://github.com/seanmonstar/warp/blob/master/src/server.rs#L534

It looks like 1ecc6299db9ec823 contains "ecc" and "ec", but I'm sure this is a coincidence while it is a commit ID/hash. Not sure whether warp doesn't support EC keys or whether support can be enabled? The docs do not really give a hint: https://docs.rs/warp/latest/warp/struct.TlsServer.html

Checking the sources, it indeed seems that only plain RSA and PKCS8 format are supported: https://github.com/seanmonstar/warp/blob/master/src/tls.rs#L22

The EC keys look like this:

-----BEGIN EC PARAMETERS-----
XXXXXXX
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
XXXXXXX
-----END EC PRIVATE KEY-----

So indeed it looks like this would be a highly welcome upstream feature, since EC keys are widely supported nowadays and highly superior to RSA keys in terms of security/size factor.

[Suggestion] Store binaries with $(uname -m) suffix

Currently there is a translation from the uname -m output, respectively architecture ID required to script/find the correct download. Using the uname -m output directly allows to skip this, and within DietPi scripts it is available as $G_HW_ARCH_NAME variable OOTB.

• dietpi-dashboard-amd64 => dietpi-dashboard-x86_64
• dietpi-dashboard-armv6 => dietpi-dashboard-armv6l
• dietpi-dashboard-armv7 => dietpi-dashboard-armv7l
• dietpi-dashboard-armv8 => dietpi-dashboard-aarch64

Allow to set log level via config file

Currently log level "info" is hardcoded. A setting to define it via config file would be great. I see debug messages in the code which would be great to enable for our testing and debugging. And on the other hand for production usage, "warning" may be sufficient to reduce journal overhead.

But this is not a blocker feature at all, but of minor importance. I'll see if I can do a PR for this, but of course we should concentrate efforts on stability for now 😉.

Request - Add multiple node dashboard

Hello

An interesting feature would be to be able to manage several dietpi hosts from the same page.

thank you for your work

[Feature] [Processes] Allow to hide kernel and/or userland threads

Kernel threads are often cryptic to users and userland process threads may add a long list of duplicates of a single process, which doesn't help much with getting some overview.

Similar to how it is set by default in htop, it would hence be nice to allow hiding kernel threads and userland threads for the process list, or really show only "processes" (instead of threads) by default, so that it is aligned with what users see in htop.

Temporary Disable(mask/unmask) the dietpi controlled application

I just want to request please add these four commands for all dietpi installed software in dietpi-dashboard.

systemctl stop proftpd

systemctl start proftpd

systemctl mask proftpd

systemctl unmask proftpd

as in my system I have installed proftpd, dropbear, samba share etc. Mostly these item I do not need. As if in dietpi-dashboard these commands added then it is very handy to stop ideal programs. I know stop command already showed in dietpi-dashboard, I want to request please add mask/unmask option also. As even if I stop that application through dietpi-dashboard after reboot it again online only mask/unmask command temporary suspend restarting of application after reboot.

Thanks

The text editor showing white-on-white text when opening a file using dark mode without syntax highlighting.

Describe the bug:
When you use the text editor in dark mode, the text switches from black to white, but the background of the editor stays white, creating white-on-white text which is not readable unless you highlight the text.
Edit: Just checked and This is only the case when not using syntax highlighting.

Version of DietPi-Dashboard: 0.6.0

Nightly or stable: Stable

Version of DietPi: 8.3.1

Device architecture: armv8, exact device is a Raspberry Pi 4 8GB

To Reproduce

1. Open any file in the file browser
2. Select dark mode
3. Turn off syntax highlighting
4. Text is showing as white on the white background

Error log

Additional context
Here are a few screenshots showing what I mean:
Light mode: https://i.imgur.com/69o9Gy4.png
Dark mode: https://i.imgur.com/GYhjDbU.png
Dark mode (highlighting text): https://i.imgur.com/FJp2yms.png
Dark mode (with syntax highlighting on): https://i.imgur.com/urdEulj.png

Because dark mode was the default after installation I thought (and maybe others too) the editor was not working until I switched to light mode.

Terminal auto-login user setting

Running 0.5.1.

It would be great to be able to set a default user to log into a terminal session instead of defaulting to root. Similar to setting a default user in dietpi.txt at first boot.

[Bug] thread 'main' panicked at 'Could not determine the UTC offset on this system.'

DietPI v7.9.3
DietPi-Dashboard - nightly, installed just now after updating to 7.9.3 and updating ports to 5252

dietpi@DietPi:~$ sudo systemctl status dietpi-dashboard
● dietpi-dashboard.service - Web Dashboard (DietPi)
     Loaded: loaded (/etc/systemd/system/dietpi-dashboard.service; enabled; vendor preset: enabled)
     Active: failed (Result: signal) since Thu 2021-12-16 21:09:29 GMT; 1min 5s ago
    Process: 2022734 ExecStart=/opt/dietpi-dashboard/dietpi-dashboard (code=killed, signal=ABRT)
   Main PID: 2022734 (code=killed, signal=ABRT)
        CPU: 7ms

Dec 16 21:09:29 DietPi systemd[1]: Started Web Dashboard (DietPi).
Dec 16 21:09:29 DietPi dietpi-dashboard[2022734]: thread 'main' panicked at 'Could not determine the UTC offset on this system. Possible causes are that the time crate does not implement "local_offset_at" on your system, or that you are running in a multi-threaded environment and the time crate is returning "None" from "local_offset_at" to avoid unsafe behaviour. See the time crate's documentation for more information. (https://time-rs.github.io/internal-api/time/index.html#feature-flags): IndeterminateOffset', /cargo/registry/src/github.com-1ecc6299db9ec823/simple_logger-1.16.0/src/lib.rs:409:85
Dec 16 21:09:29 DietPi dietpi-dashboard[2022734]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Dec 16 21:09:29 DietPi systemd[1]: dietpi-dashboard.service: Main process exited, code=killed, status=6/ABRT
Dec 16 21:09:29 DietPi systemd[1]: dietpi-dashboard.service: Failed with result 'signal'.

[Request] Upload and download files from File Browser

From https://blog.login.gmbh/dietpi-7-8-ist-erschienen-das-sind-die-aenderungen/.
Definitely useful, and would remove the need for a file server in some cases.

Align tokio worker thread number with CPU core number

Currently it is hardcoded to 4: https://github.com/ravenclaw900/DietPi-Dashboard/blob/main/src/backend/src/main.rs#L12
I'm not sure what works best here, usually I'd say that it should match the number of CPU cores. Some say core + 1 is better to always have all cores utilised even if one is waiting for I/O or so. And here the CPU usage is extremely low, so probably CPU cores * 2 is fine for better responsiveness even if multiple clients connect concurrently?

Post an error message when typing in the wrong password

It would be wonderful if the password prompt would give you some indication that the wrong password was input.

Saves you from trying several times wondering why nothing works.

All the best

Allow setting in WebUI to change or remove password

Hey I love dietpi-dashboard on Pi 4 4gb.

I know I can change or remove password by running

sudo nano /opt/dietpi-dashboard/config.toml

But can you please put a settings option to be able to change this easier? Thank you

data isn't saved and no network activity

Describe the bug:
When i refresh the site the statistics graphs are always empty. data isn't logged.
Network activity is not visible at all there is a line through them.

Version of DietPi-Dashboard:
DietPi-Dashboard v0.5.0

Nightly or stable: | Stable

Version of DietPi: 8.1.2

Device architecture:
Its a HPt530 WBT with an AMD embedded 215JJ processor

To Reproduce

1. Go to '...'Dashboard
2. Click on '....'F5 - refresh
3. Scroll down to '....'
4. See error - All de data is gone from the staticics grph

Error log

root@DietPi:/# journalctl -u dietpi-dashboard
-- Journal begins at Thu 2022-02-10 12:16:56 CET, ends at Thu 2022-02-10 17:27:33 CET. --
Feb 10 16:50:02 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /
Feb 10 16:50:02 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/index.592bbc0d.js
Feb 10 16:50:02 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/index.eaf4e9a8.css
Feb 10 16:50:02 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/xterm.7cca9343.js
Feb 10 16:50:03 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /ws
Feb 10 16:50:03 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/dietpi.4cc58251.png
Feb 10 16:56:21 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /
Feb 10 16:56:21 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/index.592bbc0d.js
Feb 10 16:56:21 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/index.eaf4e9a8.css
Feb 10 16:56:21 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/xterm.7cca9343.js
Feb 10 16:56:21 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/dietpi.4cc58251.png
Feb 10 16:56:21 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /ws
Feb 10 16:56:22 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /favicon.png
Feb 10 16:59:05 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /login/
Feb 10 16:59:08 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /login/
Feb 10 16:59:15 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /login/
Feb 10 16:59:32 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /process
Feb 10 16:59:32 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/index.592bbc0d.js
Feb 10 16:59:32 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/index.eaf4e9a8.css
Feb 10 16:59:32 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/xterm.7cca9343.js
Feb 10 16:59:32 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /ws
Feb 10 16:59:32 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /assets/dietpi.4cc58251.png
Feb 10 16:59:32 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /favicon.png
Feb 10 17:12:58 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /ws/term
Feb 10 17:24:21 DietPi dietpi-dashboard[597]: INFO [dietpi_dashboard] Request to /ws/term

Additional context

Request : 2 tables on the Software tab

I think having 2 separate tables on the Software page would work better. The first table would just be installed software and the second table would be available software. This would make for a better user experience...

Make main websocket keep trying to reconnect

get rid of the login in window?

Describe the bug:
Not really a bug, but can I get rid of the login window when I open the dashboard? It's a bit annoying 👎

Version of DietPi-Dashboard: 0.5.0

Nightly or stable: Stable

Thanks

Dashboard gets killed every so often

I'm noticing that every few days, the DietPi Dashboard gets killed for an unknown reason. I'm able to use everything else, SMB shares, Plex, etc... just can't access the Dashboard til I do a systemctl restart dietpi-dashboard.

Here is what I see in the logs for the last few days....

Jan 20 20:04:21 DietPi dietpi-dashboard[2456]: 2022-01-21 01:04:21,130 INFO  [dietpi_dashboard] Request to /assets/dietpi.4cc58251.png
Jan 20 20:04:21 DietPi dietpi-dashboard[2456]: 2022-01-21 01:04:21,132 INFO  [dietpi_dashboard] Request to /ws
Jan 20 20:04:21 DietPi dietpi-dashboard[2456]: 2022-01-21 01:04:21,214 INFO  [dietpi_dashboard] Request to /favicon.png
Jan 20 20:05:15 DietPi systemd[1]: dietpi-dashboard.service: A process of this unit has been killed by the OOM killer.
Jan 20 20:05:16 DietPi systemd[1]: dietpi-dashboard.service: Main process exited, code=killed, status=9/KILL
Jan 20 20:05:16 DietPi systemd[1]: dietpi-dashboard.service: Failed with result 'oom-kill'.
Jan 20 20:05:16 DietPi systemd[1]: dietpi-dashboard.service: Consumed 16.859s CPU time.
Jan 21 16:13:23 DietPi systemd[1]: Started Web Dashboard (DietPi).
Jan 21 16:13:23 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:23,438 INFO  [warp::server] Server::run; addr=0.0.0.0:5252
Jan 21 16:13:23 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:23,438 INFO  [warp::server] listening on http://0.0.0.0:5252
Jan 21 16:13:25 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:25,267 INFO  [dietpi_dashboard] Request to /
Jan 21 16:13:25 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:25,321 INFO  [dietpi_dashboard] Request to /assets/index.78a32cef.js
Jan 21 16:13:25 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:25,322 INFO  [dietpi_dashboard] Request to /assets/index.69f8c40f.css
Jan 21 16:13:25 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:25,324 INFO  [dietpi_dashboard] Request to /assets/xterm.6fe708e6.js
Jan 21 16:13:25 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:25,427 INFO  [dietpi_dashboard] Request to /ws
Jan 21 16:13:25 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:25,432 INFO  [dietpi_dashboard] Request to /assets/dietpi.4cc58251.png
Jan 21 16:13:25 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:25,634 INFO  [dietpi_dashboard] Request to /favicon.png
Jan 21 16:13:27 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:27,701 INFO  [dietpi_dashboard] Request to /login/
Jan 21 16:13:37 DietPi dietpi-dashboard[404428]: 2022-01-21 21:13:37,019 INFO  [dietpi_dashboard] Request to /ws/term

[Management] Update (some) data less often

The management page currently reload all data every second. For the uptime seconds counter this makes sense, for the DietPi version, hostname, architecture not so much, and especially calling dpkg --get-selections every seconds to obtain the installed package count produces quite some CPU load on small SBCs. Two ideas:

1. Obtain/update values which are not expected to change regularly (basically all but uptime seconds) much less often, e.g. via internal counter to reset every X iterations and only update those on specific counter values.
2. Remove the seconds uptime counter, which doesn't seem to important when you have some days uptime, and never reload data, but only when the page itself is opened/reloaded.

The regular update of the seconds counter has the other visual side effect that the table dimensions change whenever the number of seconds changes to 0 (which hides also the "Seconds" text completely) or from one to two digits.

[Bug] File Browser crashes service

Nov 06 18:16:50 VM-Bullseye dietpi-dashboard[47807]: thread 'tokio-runtime-worker' panicked at 'called `Option::unwrap()` on a `None` value', src/sockets.rs:216:47
Nov 06 18:16:50 VM-Bullseye dietpi-dashboard[47807]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Request: dynamic home page based on preferences of typical use

The home page displays measures / metrics.
It would be nice that the selection of the available measures would be customizable by user, or selected from a few templates based on the typical use of the host, that could be determined by specific installed software (category of dietpi-software).

What I mean is this , for a typical local file server, the displayed measures could be al kinds of info about disks, e.g. number of disks, available diskspace, SMARTMON-info. For a typical (internet facing) cloud-server, you might be interested in fail2ban-measures, the amount of incoming and outgoing data, etc. And for users who own a typical media server, theu could have other primary measures of interest.

May-be you could make a few templates per typical use, from which a user can select?

[Visual] Lock the aspect ratio of charts?

Would be good to lock the aspect ratio so charts are not overly tall like this?

[Terminal] Dead bash processes stack up when navigating away

Whenever navigating to and away from the Terminal page, the bash process is not really killed, but remains in the process list with zero memory usage and no ability to kill it (SIGKILL has no effect). This stacks up with every Terminal visit:

Not sure if probably the reader loop locks it up when still reading the socket? I do no yet fully understand at which points the loops are exited when the page is changed: https://github.com/ravenclaw900/DietPi-Dashboard/blob/main/src/backend/src/terminal.rs

v1.0.0 Roadmap

Easy

• Add common private website security headers (#133 (comment)) (52f8e16)
• Allow naming backend nodes/show in title (#75)
• Version nightly releases by commit hash
• Add config file setting for terminal auto-login or manual login (#195) (#202)
• Add customizable token timeout (requires biscuit) (#155 (comment))
• Test serde without serde_derive and/or serde_json (#186)
• Allow setting subnet to run on

Medium

• Add more debug messages (#276)
• Make main websocket keep trying to reconnect (#325)
• See if it's possible to switch to biscuit library for JWT creation and validation (can't require serde)
• Get CPU temp (Maybe switch back to psutil, can be augmented with other crates for missing functionality). (#36)
• Add a message showing if updates are available (#201)
• Allow updating-in-place
• Switch to more lightweight chartist or uplot chart library
• Use select! instead of spawning threads on page visits
• Allow setting path for reverse proxies
• Compress files before storing in binary (#263)

Hard

• Fix file browser (#123)
• Fix terminal login dialog (#198)
• Add more error handling, use less unwrap (#236)
• Fix terminal freezing (#70)
• Allow using drives other than / in the graph. (https://dietpi.com/blog/?p=1137#comment-581)
• Allow cancelling of file browser (e.g. loading /dev, downloading large file) (#270)
• Add links page

Probably more to come, suggestions welcome.

[Bug] Sometimes "Management" kills process

Nov 06 19:40:40 VM-Bullseye strace[52175]: thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: SendError(Some(Request { page: "/management", cmd: "", args: [] }))', src/sockets.rs:309:53
Nov 06 19:40:40 VM-Bullseye strace[52175]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

https://github.com/ravenclaw900/DietPi-Dashboard/blob/921913d/src/backend/src/sockets.rs#L309

Got this two times when switching from "Terminal" to "Management", but I cannot reliably replicate it, currently it works well 🤔. But probably it can be enhanced to detect and handle errors gracefully to avoid the panic. I set the RUST_BACKTRACE=1 variable for further testing, probably it helps.