ravenclaw900 / dietpi-dashboard Goto Github PK
View Code? Open in Web Editor NEWA lightweight, standalone web dashboard for DietPi
License: GNU General Public License v3.0
A lightweight, standalone web dashboard for DietPi
License: GNU General Public License v3.0
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.
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?
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.
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
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.
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:
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.
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?
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.
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...
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.
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
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
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
expiry = <some value>
in /opt/dietpi-dashboard/config.toml
Error log
not necessary
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.
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'.
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.
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.
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
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
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
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
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.
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
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.
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
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.
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
-renaming a file
biscuit
) (#155 (comment))serde
without serde_derive
and/or serde_json
(#186)biscuit
library for JWT creation and validation (can't require serde
)psutil
, can be augmented with other crates for missing functionality). (#36)chartist
or uplot
chart libraryselect!
instead of spawning threads on page visitsunwrap
(#236)/
in the graph. (https://dietpi.com/blog/?p=1137#comment-581)/dev
, downloading large file) (#270)Probably more to come, suggestions welcome.
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?
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
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
.
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.
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?
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:
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.
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
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:
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...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
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?
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...
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.
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
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
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
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..."
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
.
I think that one of the most important sensor that should be visualized in th system diagnostic tab should be CPU temp.
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 ๐.
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>
Hello
An interesting feature would be to be able to manage several dietpi hosts from the same page.
thank you for your work
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.