Web GUI approach

[FlotterCodername]

There are a bunch questions that should be addressed rather sooner than later:

Root privilige handling.

I'd rather not run the whole thing as root. Maybe better to have a separate process that can execute pre-defined stuff with root priviliges.

The multi-user problem

@danmons knows the project in and out. Do we have to ensure that only one user is doing stuff at the same time?

CSS

I can do some basic stuff, but it's not going to look cream-of-the-crop. Help very much appreciated

Generating web GUI options from TUI

I have a very basic proof-of-concept of this working, but it's really going to need some specific begin-end comment markers and separators (e.g. between tool name and description) to work well.

Picture for any interested parties

[birdybro]

I'm not very familiar with cockpit, couldn't all of this functionality be done in the cockpit interface instead? More curious about it than anything.

https://cockpit-project.org/guide/latest/cockpit-spawn

[sairuk]

I am also not very familiar with cockpit at all, more of a cli junkie.

With that in mind here it is a question of how closely could we integrate this project and cockpit for consistency if we were not to go with a dedicated project webui? Which from what I can see if what @FlotterCodername is trying to achieve.

I suppose at its core it is all just web tech after all so I am sure we could potentially extend the pre-existing power/ui of cockpit to provide a web based experience for the end users? Instead of running it as a completely new/additional project.

[FlotterCodername]

I've put a few updates atop the original post, namely clarifying why it's Python-based and that my thing is not "official" or similar.
I am not too keen on creating an extensions to Cockpit, less because I'm not as comfortable in JS, but more because of the maintenance that you have to put in when working in someone else's (Cockpit's) backyard.

[danmons]

I'm not very familiar with cockpit, couldn't all of this functionality be done in the cockpit interface instead? More curious about it than anything.

I think trying to hammer RetroNAS features into Cockpit might be difficult/problematic? While it can spawn processes, it's more of a systems management tool than what RetroNAS does (combination of ansible and scripts to install things in specific ways). Unsure. I'm also not a web developer (just a dirty sysadmin who writes terrible quality code, as you can all see clearly now). So I don't think I'm even very qualified to have an opinion.

Happy for the community to do as they please, really. If an independent tool works, that's fine by me. If Cockpit is easier, also fine by me.

Do we have to ensure that only one user is doing stuff at the same time?

I don't think so. My assumption is that the actual install/configuration side of RetroNAS will be one person at a time. Once a tool is installed, then multiple systems can use it, but that's then outside of what RetroNAS does.

I don't do any explicit safety checking or locking in my scripts (some of the tools might - e.g.: Debian's APT and DPKG have internal locking that prevent two installs happening at once, but I don't add to that in things like source code compilers/installers). In theory two people could SSH in and fire off things at the same time, and that would probably be bad. So I just kind of stick my head in the sand and pretend they never will. :)

We can just make a note in the documentation that on the admin/install side it's only designed for one install/configure session at a time, versus the client side usage where as many systems can connect as people want.

[birdybro]

just a dirty sysadmin who writes terrible quality code

Sort of same here, no worries bud. :D

[sairuk]

Thanks for moving this to discussions, appreciate the work done.

There are a number of points in ideas.md that would be within scope for this.

As mentioned above did you consider opportunities to extend the cockpit application to leverage its functionality prior to beginning a fresh project? It may be a reasonable approach.

I am curious if we think having multiple webui's available and presumably the daemons to back them may not be warranted based on resource availability, confusion to the end user etc.

These question has been rolling around in my head since I sawthe FTP web based client and dnsmasq were listed in ideas.md

[FlotterCodername]

The cockpit extension is an approach to consider, just maybe not for me to shepherd (just work on it? sure).
I know as far as approaches and frameworks etc. go, I know Dan welcomes anything, so long as it doesn't interfere with what he is doing (i.e. shell and ansible-side).

[sairuk]

I'd like to clarify I think this is a good initiative, and arguably a necessity these days.

If something like this were to continue I'd like,

• a simple dev path to ensure that the webui is kept in sync main RetroNAS shell project.
• functional integration with all new feature sets
• automatic dialog generation (you've mentioned this)
• long-term maintainability to be considered

Whatever the solution looks like in the end I wouldn't see web/shell as mutually exclusive. Once something like this is available and fully featured, it has the potential to become the predominate ui. I'd expect uptake would be immediate. As such I am trying to stay mindful at this early stage of long-term project maintainability and complexity for both devs and users.

I'd think if we were going to start the security (ref to unpriv users, root sep) discussion that is a much bigger (potentially uncatchable) fish, there is a lot in this project security-wise that is moreso 'feel good' vs 'useful' with known exploits for a lot of these older protocols.

[FlotterCodername]

Had a lot of fun working this web GUI the past few days, but I'm going to shift away from it for now, for a couple of reasons (mostly my own).

• Dash (library I used) has some annoying quirks and doesn't do a whole lot of heavy lifting for responsive design.
• Project structure concerns. My experiment had no backend-frontend separation. You'd probably want a separate backend exposing API endpoints to functionality so that others can also build upon that with their own frontends. Much cleaner to work with and running the backend as root is way less problematic.
• The only thing that's related to RetroNAS itself: Missing separation of UI dialog trees, configuration data etc. It takes quite some time to interpret all of this and put into a workable form (dialog items, shell variables...). Having all of this available in a data format is going to be necessary in the long run. It'd be much easier to generate a GUI/TUI from data than to generate GUI from a TUI.

[sairuk]

It'd be much easier to generate a GUI/TUI from data than to generate GUI from a TUI.

I was mulling this exact thing over last night and looking at if we could generate dialogs and case statements from an associative array, later maybe json data through jq or similar.

[sairuk]

I am still interested in pursuing this as a primary frontend eventually; moving away from dialog, I can't speak for @danmons but I think in the long run we'd need to do this. I think this is becoming more relevant as we start to talk about offering dnsmasq/dhcp etc support

I have been thinking about the backend, particularly your root separation question and if it is to be a standalone I think its worth testing as a solution with lighttpd which is already included in the project.

Component(s)

• lighttpd
• responsive webui
• json/db datastore
• queue/drop file in a watched dir, txt file of keywords
• systemd path+service file that picks up the drop file
• system service file (as root) executes installers/ansible-playbook
• minimal api messaging endpoints to communicate success/failure for actions

Thereafter where possible, ansible backed service/software configuration as primary, I'm going to have a play with this concept over the coming weeks, see how well it works.

I am no webdev so i'll just scope out a lighttpd w/python cgi support and a basic bootstrapped interface and we can try out the functionality in a branch

At the same time, I'm curious what I can do with generating dialog strings, for menus which I've just had an idea about so will test it, hopefully we can leverage the same dataset for the TUI and WUI

[sairuk]

I had started writing something in this space but then decided to at least take a look at the extending cockpit idea, seems like its certainly built for it (never used cockpit before RetroNAS)

https://cockpit-project.org/applications

It wasn't horrible to get something on the screen as a package, but it'd need a lot more work. I still haven't settled on a way forward but build a cockpit certainly gets us away from having to write storage.network management ourselves.

If anyone else is up for that, have a crack I am not looking to commit any of my hackery in this space to a repo yet that is for sure.

[sairuk]

References for cockpit development

• https://cockpit-project.org/blog/creating-plugins-for-the-cockpit-user-interface.html
• https://cockpit-project.org/applications
• https://cockpit-project.org/guide/latest/packages.html
• https://cockpit-project.org/external/source/HACKING

[sairuk]

I have knocked out a rudimentary integration with cockpit today, its functional but there is a still a long way to go. We need to do a lot of backend work to make this feasible but the cockpit integration seems to be the way to go for now.

The only goal with this is to replicate the TUI functionality 1:1, there is no ETA for a final version of this we need a more robust approach to generating the code.

This is now available to play with through the Advanced menu,

Please Note: you will need to install cockpit manually first.

[sairuk]

the awesome pixelart nas was donated to the project by a mate of mine.

[sairuk]

updated,

• hooked up the script runner,
• added the ability to set current user password through config screen
• added a log screen that receives stdout from the process (this could be better)
• added an update page, to run romdir and new retronas updater

[sairuk]

most functionality is there now, as per the rest of the project it should not be exposed to a public network,

All that is left is add forms for tcpser and gog but everything else as it stands is functional.

You need to login as your retronas user to run this, there is no name change management anymore. That should be confirmed as part of install otherwise stuff wont run.

[aptonline]

As someone who is totally new to RetroNAS this GUI within Cockpit looks like the way to go in terms of exposing all the features in order to lower the adoption bar for the ‘average user’. Great work and I look forward to watching its progress.