Adding a file browser, file text editor and tty command shell for LuCI OpenWrt

For Developers
1

Hi,

To anyone ending up here and these features are still not in LuCI, go in the software tab and install openssh-sftp-server and then install application winscp on your computer, this is the current easiest method.

I would like to discuss the addition of these basic components to LuCI. Many of the more exotic use cases in OpenWRT require manually editing files. This cannot be currently done via the web interface and one must resort to using ssh access to perform these basic tasks.

I know for many of you this is easy as pie but for beginners this represent a medium sized roadblock. Many users will need to learn using the terminal before they can figure the ins and outs of command line file browsing, file editing and the like on top of learning to use shell terminal software like ssh and putty.

There has been a few attemps in the past to bring these features to LuCI with various degrees of success and they are

Inspirations and alternatives from other management web interfaces

https://tsl0922.github.io/ttyd/

Home assistant web ui file browser

Home assistant web ui text editor

Home assistant web ui terminal

Home assistant programming ide in web ui

(just found there's a command line package in the repository ? not tried yet)

I think this could be a good way to bridge the ease of use gap between functionalities that are not supported in LuCI and require intervention in the terminal and completed LuCI apps.

Not to mention the general convenience of being able to do these tasks right from the web ui. In particular I would have links to the most important config files as bookmarks in my browser to fast editing.

2 Likes
2

I admit it could be useful for newcomers but we have to weight in the dependencies - if the firmware becomes too big - for example going past 8MB for small flash targets it's a NOGO from my perspective

1 Like
3

For many pupils, division is a medium sized roadblock. We don't throw pocket calculators at them, but teach them the basics in primary school.

If users want to fully unleash the increased functionality that OpenWrt offers, a basic skillset is beneficial.

2 Likes
4

I think that's a bit of a cop-out.

It would be much more convenient to have an integrated file browser and command line editor built into Luci.

Webmin has a great implementation of this feature. Could the code be ported into OpenWrt?

image
image1110×585 87.6 KB

1 Like
5

Home assistant and promox also sport consoles and file transfer tools in the web interface

I would take the most rudimentary versions of these tools just for quality of life improvements. Surely there's a tiny web app that can do both these things under 50kB considering the router already has a console and file transfer tools builtin.

I know many user like things being hard to use for the sense of accomplishment and being part of some elite club of users. But I think this project is best served by being as convenient and efficient to use as possible.

In the mean time, apache guacamole is probably a good way to side step having to leave the browser but that's extra and unecessary infrastructure to maintain.

6

What benefit do you gain having a file browser on a router?

All config a user would ever need can be done in Luci, including software installation and a normal user does not need to edit configuration files?

1 Like
7

That's based on the idea that a) every app that a user wants is available to configure in luci, or that b) if you want something that can't be configured in luci theb you are an abnormal user.

Those are arrogant assumption.

This is a great idea. I would also add to this list a regedit-like editor for uci. Even in areas that there is a luci front end for, there are often configuration options the front end doesn't expose. The luci interface almost always lags behind the back end development in virtually every area. I'm not criticizing that, it's just a fact. And a general purpose uci editor would allow access to all that without requiring shell expertise.

8

If the use case is editing config files ssh + pico or nano covers that need with no additional interfaces and is generally secure.

Also, all users should be using uci commands, not editing the files directly - uci has some level of protection from serious mistakes screwing up their config.

Of course anyone is welcome to submit packages they have written to the package repository, I just can’t see a use for this type of browser on a network device

9

web based tty makes using uci easier

Sometimes the user only knows about editing the file, even if that's not the most optimal way, that might be the best way to make it work right this second.

Direct web access to files and tty command right in the web interface that's one less road block gone to making things work right now and that's undoubtedly the way to go.

If I get dev time on openwrt, that's one of the thing that would make every openwrt user's life easier

10

What are your thoughts about how such general purpose uci editor would work?

If there is machine-readable metadata about how the uci configurations are allowed to be set, it should allredy be possible to comprehensively validate configuration files and create generic GUIs using the metadata as well as implementing text editor "intellisense"-like functionality and produce documentation. Does the OpenWrt base and individual packages provide such metadata or is the current uci totally ignorant about allowed settings and how settings should be connected to form a technically working configuration?

11

I think firefox's about:config could serve as a good blueprint for a raw config page

Biggest difference I see with uci is that uci can have multiple values for one config (array)

And a common problem with both firefox and uci is that it is not suggesting the user all the configs that could exist but only the ones that already exist. But solving that shouldn't get in the way of just giving the user a quick access to settings.

So, in order of complexity
a dump of uci show
sort/filter by config section (the text before the first ".", like attendedsysupgrade, ddns, dhcp, firewall, fstab, luci etc..)
show the user which configs are set to non-defaults
ability for the user to change any value
validate user input is the right data format
show/suggest user with unset but possible configs

12

No, there is not.

2 Likes
13

Go for it, sounds like it will be a huge package, but if you think you can make it work go ahead

14

This thread is initially about adding file browser, text editor and a console to openwrt's web interface.

Adding a uci configurator would be a nice to have, but already covered by having a functionnal console in the web interface.

And making this discussion about the metadata of the validator of the uci configurator of the web interface, sounds to me like a derailment.

But sure, I can answer that

So the metadata, it's in the wiki already, and it's really nicely formatted.
A simple trip to chatgpt and it can be turned into machine readable code.

Here for example the fstab config

image
image858×677 35.4 KB

Here is what it looks like out of uci

image

So anyway, the wiki data is already so clean we can somewhat easily turn it into machine readable metadata using a large language model like chatgpt

I did a few of the config.sections in this file

Tried to get chatgpt to spit out a script to read it but I just did my first lua hello world a few minutes ago and this doesn't work out of the box

local uci_metadata_file = "uci.metadata"

local function get_metadata(section, option, property)
    local metadata = {}
    for line in io.lines(uci_metadata_file) do
        local s = line:match("^%s*%[(.-)%]") -- section
        if s and s == section then
            local opt, optdata = line:match("^%s*(%S+)%s*=%s*(%b{})")
            if opt and opt == option then
                optdata = optdata:gsub("[{}%s\"]", ""):gsub(",", "\n")
                for k, v in optdata:gmatch("([%w_]+)%s*=%s*([^%s]+)") do
                    metadata[k] = v
                end
                break
            end
        end
    end
    return metadata[property]
end

-- example usage
local section = arg[1]
local option = arg[2]
local property = arg[3]
local value = get_metadata(section, option, property)
print(value)

but it's probably close to working

root@router:~# lua read.uci.metadata.lua dropbear.dropbear verbose description
Set to 1 to enable verbose output by the start script.

This metadata database would weight in at something like 250kb uncompressed

While opkg update downloads

     3 -rw-r--r--    1 root     root        3.4K Mar 24 19:55 Packages.gz
    88 -rw-r--r--    1 root     root       87.7K Jan  4 23:19 Packages.gz.1
    88 -rw-r--r--    1 root     root       87.7K Jan  4 23:19 Packages.gz.2
    61 -rw-r--r--    1 root     root       61.1K Mar 21 20:38 Packages.gz.3
   176 -rw-r--r--    1 root     root      176.0K Mar 21 20:38 Packages.gz.4
   453 -rw-r--r--    1 root     root      453.4K Mar 21 20:39 Packages.gz.5
    12 -rw-r--r--    1 root     root       12.0K Mar 21 20:40 Packages.gz.6
    57 -rw-r--r--    1 root     root       57.2K Mar 21 20:40 Packages.gz.7

So that's not something too crazy to download each time a user would use the uci configurator, which presumably would be far less often than how often a user runs opkg update.

And if there's enough free space on the device, you just leave it there

15

Have you had a chance to develop a package for this?

16

I created a PR with a minimal File Browser for Luci https://github.com/openwrt/luci/pull/6553

Please leave your comments and thoughts.

Some other discussions for file browser:

6 Likes
17

Great news,

File manager is almost part of default openwrt

That's one almost down, two to go !

3 Likes
18

Please note that the PR is minimal and it's not that useful as you may think. There are no edit, no console etc. Just list files, delete, upload and download.

Everything else needs for a significant changes and this will be made on stage 2 later.

20

I find mc to be a good do it all.

21

We don't have any of those features right now. More than happy about it.

Mind, for the feature roadmap, I would love if it supported uploading and downloading more than one file at once (rather than, I assume, selecting upload and browsing for each file). Download is probably good enough, though, if I can just click a download button per file.

Both of those are probably doable with a for-loop in the JS that reads from a select-list of files (checked files in the viewer to download, multi-select in the upload box for uploading). I've done similar before but I don't have experience with the rest of the code that LuCI uses.

1 Like