OpenWrt Forum Archive

Topic: LuCi web gui based on angular js

The content of this topic has been archived between 18 Apr 2018 and 22 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

zo0ok wrote:

Yes, that is correctly understood and I don't have much more to add to it.
I agree that "it" can be ok for development, but not for production. At least in theory. If it is a truly good idea for OpenWrt I don't know.
Maybe my intentions were not clear because I am an innovator who is not afraid to make a leap.

There is no misunderstanding between the two (or three) of us. I fully understood the choices beforehand. In light of this, neither of you gave a straight answer to the precise answer. Why do you feel it mandatory to make the Web GUI/configuration interface of a router completely self contained in general? What if said GUI could have mobile apps for connecting to the router? What if the GUI was native JS compiled to a single HTML file, so the "installation by the user" would involve clicking "save as..."? I'm still waiting for your detailed arguments on the topic.

Although, I have yet to see a case when an industrial user will start configuring routers one by one on the field by their smart phones in their pocket. Or more precisely, using a non-smart phone or one which they do not own but rather they have just borrowed for the setup on a desert island.

I know a few professionals working in the field of industrial network design and deployment and they use netbooks because of the above reasons. Note that they have all kinds of funky tools preloaded. Do note that automated/bulk remote management of equipment is much more feasible than logging in and altering settings in each router one by one from a GUI anyway. So ideally you shouldn't be doing much besides equipment replacement on site, because power cycling can also be done remotely if you are classy. I hear you crying for basic status indication, however most devices have LEDs for this purpose and at a higher level, the only important status is whether the device can be managed remotely or not. If the cabling is in error or there exist complex interference, the technician will need to bring specialized equipment anyway. If the device shows signs of a hardware fault or a software bug, it will need to be replaced and inspected at HQ because it is usually difficult to debug or even just tell apart on site. The usual and cheapest procedure goes like if power cycling didn't help, replace components until the system starts working again, inspect or recycle the ruins later.

If I'd need to adjust settings on a desert island, I would have surely had all tools already loaded on my devices. Or even have a backup on the distributed storage of them locally, but that's besides the point.

bkil... first, I am neither a significant contributor to the OpenWrt project, nor am I a network professional. Please consider my answer being my opinion in the light of what I personally expect OpenWrt to be.

I think one target audience for OpenWrt are people with one or possibly a few standard routers in their home. They want to use OpenWrt instead of OEM firmware for different (good or bad) reasons. I think most people here agree that OpenWrt is not as newbie friendly as we would want it to be. Adding notes (here and there) on the Wiki telling: before you make your changes you need to download Xxx from the internet and install it on your client device (specific instructions for iOS, Android, Windows, Linux, Mac OS, etc) would not improve newbie friendliness. As a more advanced and long term user of OpenWrt, I would also not prefer it.

That said, I use ssh to my OpenWrt devices a lot (I feel comfortable with it, most people might not), and I also recognise that LuCl is not the best imaginable GUI for my routers.

When it comes to professionals... automated and bulk management... I guess a start would be to work with shell scripts, ssh, and possibly the web service / rpc capabilities that are already there (I honestly don't know much about how it works).

If you want to innovate/design a remote-central-control-center for OpenWrt, it sounds very cool! And I think it would be good if OpenWrt exposes relevant functions as (REST) APIs (again, I don't know the current state). But I think it will always have lower priority (to OpenWrt as a project) than
1) The shell and core system
2) An integrated and self contained web administration tool

Perhaps I am missing the point?

zo0ok wrote:

I think one target audience for OpenWrt are people with one or possibly a few standard routers in their home. They want to use OpenWrt instead of OEM firmware for different (good or bad) reasons. I think most people here agree that OpenWrt is not as newbie friendly as we would want it to be. Adding notes (here and there) on the Wiki telling: before you make your changes you need to download Xxx from the internet and install it on your client device (specific instructions for iOS, Android, Windows, Linux, Mac OS, etc) would not improve newbie friendliness. As a more advanced and long term user of OpenWrt, I would also not prefer it.

Dear zo0ok,
Excuse me for the possibly intimidating interpretation of the wording of my comments. I did not want to attack neither you personally, nor others with similar views. I'd only like to start a healthy conversation and I need input from the other side as well.

Note that the practice of completely self-containing a firmware is the norm at present. Actually I am satisfied with the functionality that LuCi offers. However, I'm considering a reorganization of certain components and workflows to free up a considerable amount of space.

Let's focus on home users as per your suggestion for now. What should a futuristic ideal life cycle look like?

  • User sees an advertisement for OpenWrt (online banner, viral video, social recommendation or via QR code).

  • Users visit OpenWrt main page in their browser where they can be convinced by a short embedded video

  • User clicks the huge button titled Install OpenWrt. That's all!

  • A native (I mean offline, whether it is binary code or otherwise) installer wizard is downloaded and executed. It could automatically

    1. Find the router

    2. Log in

    3. Detect hardware

    4. Offer to choose a release to install (default last stable). Show relevant success stories from a wiki (or limitations and warnings in case of beta firmware), current number of users, perhaps a general "stars" quality rating of the port

    5. Download the needed OpenWrt image or data (use P2P where available)

    6. Optionally try to find out the intended use case of the user in the form of an interactive dialog with a knowledge base system. Offer a matching set of packages. Perhaps even invoke Image builder here.

    7. Provide various kinds of searchable documentation

    8. Update boot loader via OEM firmware when applicable and generally ensure compatibility

    9. Flash OpenWrt with the correct procedure

    10. Help with first time setup (manage credentials, automatically back up settings, etc

    11. Opt in to share the achievement with friends and register the device in an online database for statistics, bragging rights, to volunteer as tester and to receive regular (security) updates

    12. Download and install the respective PC toolset. The installed toolset could be a portable package for carrying via USB flash or manually syncing between workstations.

      1. An interactive configuration GUI could include a ported regular or angular LuCi or even multiple interfaces at the same time to suite the user, because a PC has gigabytes of space to store all the cruft.

      2. An (automatic) update tool could handle (security) upgrades or provide volunteer testers with their weekly dose of adventure. The user could also switch between given trunk revisions and stable releases.

      3. An unbricking tool could guide through the most common troubleshooting steps and show general and model specific notes, success stories and such.

      4. An error reporting and latent issue monitoring tool could scan logs and guide you in filing bug reports after walking through the most common troubleshooting steps. If allowed, it could also automatically send health reports to developers. It could be used as basic feedback regarding the compatibility of certain patches.

      5. A remote management tool could temporarily donate a device to a developer for debugging or development. It would temporarily format the router to a blank state, isolate it from the user's data and the rest of the network, maintain a tunnel to developer workstations, forward notifications to the owner for manual power cycling where needed. Sometimes an owner should donate a pair of devices in close proximity at the same time to aid in network debugging. Tunneling of the serial port could also be considered. The tool would restore the user's original firmware and settings when development has concluded.

      6. A configuration data management tool could back up or sync settings between devices

      7. Package management tool with links to detailed documentation of each package. We could perhaps reinvoke image builder, reflash and restore settings after each reorganization, transparently to the user. We're only a few steps away from doing away with jffs2.

      8. A benchmark and/or penetration testing tool could help in objectively comparing the performance of the device when it is running various firmware. Concrete numbers sell a firmware even better, especially when sharing with friends.

      9. A no-hands batch deployment tool with which you could migrate a large amount of devices to OpenWrt seeded by your stored configuration. You could plug in a dozen of devices at a time, it does its magic and sounds a bell when you can insert the next dozen. No wires needed in case of using wifi capable devices reset to factory or if passwords are available. It could literally spread OpenWrt through the world.

      10. An uninstall tool could safely revert to stock!

      11. ...(dozens of more use cases)

    13. A few of the use cases above may sometimes warrant rewiring, pressing a button or power cycling, but the respective tool can provide knowledge base, plans, images, videos and interactive feedback on whether the user is doing it right

An installer can also download all emergency data and documentation for offline usage. At present, no matter how small the issue is that you are facing, you will almost surely need to waste hours of your precious time to conduct web searches, do trials, and involve lots of hand holding using various communication channels. And when you panic because you are left alone in the dark, you may resort to doing stupid things. Sometimes having a few steps of plainly worded instructions and a little interactivity at hand could do wonders compared to having a whole book on a subject.

edit #1: note that some of the feats described above could easily be pulled off in HTML5 using any compliant PC or mobile browser, while others could benefit from OS API support.

(Last edited by bkil on 16 May 2015, 09:50)

I'm looking forward to both this and LuCi2, great to see some more choices for web UIs smile

zo0ok wrote:

before you make your changes you need to download Xxx from the internet and install it on your client device (...)
Perhaps I am missing the point?

A web interface based on AngularJS is self-contained. As long as AngularJS, which is just another set of JavaScript files like jQuery or Bootstrap, is available on the router, there is no need for anyone to download anything from the internet -- let alone install something on the client computer. The basic requirement, as it is with LuCI right now, is still only a somewhat capable web browser.

The common user won't notice any difference to a "conventional" web interface like LuCI is right now, except for a significantly smoother operation.

In fact, for all intents and purposes, the AngularJS approach is identical to what LuCI2 is doing, except LuCI2 uses "homemade" routines created specifically for the job whereas AngularJS is independently developed and has a much broader development base. I'm pretty sure had AngularJS (or maybe React) been around when LuCI2 development started, the developers would not have bothered to create their own routines. In a way, AngularJS has overtaken the similar efforts of the LuCI2 development (and I certainly don't mean that as an insult to all the hard work that has gone towards LuCI2, it's just been in development so long that this happened).

(Last edited by metai on 17 May 2015, 11:51)

Hi All!

As an angular developer myself I am slightly confused about the development of this thread.
I see three OpenWrt-administration-scenarios:
1) The current LuCl
2) An AngularJS-based LuCl-replacement
3) Something like bkil envisioned in #28.

I may initially in this thread have been overly pessimistic about the download size of the Angular framework itself, if it was to be hosted on the router. The idea of replacing JQuery with Angular, and replacing LuCl with an Angular-based-LuCl is very appealing to me!
It requires two things:
1) That most things can be done via nice REST APIs (but I guess this is no different from the current LuCl solution)
2) That the entire Angular-LuCl-packages are not significantly bigger than the current LuCl-package.
I like this!

When it comes to the grand ideas that bkil are envisioning, they clearly require things that are not contained within OpenWrt itself (as we think of it today). I am good with that! And bkils ideas will much benefit from the clear REST APIs that will also enable a good Angular-LuCl. But I think the core self-contained WebGui of OpenWrt (be it Angular based or not) is a critical core component of a successful OpenWrt, regardless of the possible progress of bkils ideas.

That said, as much as I appreciate that bkil took the time to share his vision of a future OpenWrt in #28. I have not thought of those things myself. I personally think it sounds like a little royal nightmare. But that is probably just because I AM backwards. And it is not up to me to stop great visionary initiatives if some people want to build them and other people want to use them!

Edit: There are clearly many great ideas in #28!

(Last edited by zo0ok on 16 May 2015, 08:05)

bkil wrote:

A native installer wizard (...)

besides being way into the realm of "wishful thinking" for now, is way outside the scope of this thread. Please let's not dilute this -- IMHO quite important -- thread by making it another multi-leveled "wouldn't OpenWrt be much better if" conversation, at least continue it in a separate place.

(Last edited by metai on 16 May 2015, 08:21)

metai wrote:
bkil wrote:

A native installer wizard (...)

besides being way into the realm of "wishful thinking" for now, is way outside the scope of this thread. Please let's not dilute this -- IMHO quite important -- thread by making it another multi-leveled "wouldn't OpenWrt be much better if" conversation, at least continue it in a separate place.

Sorry for seemingly hijacking the thread. However, I feel that LuCi is such a mature project that it is not as open to innovation as you are. Again there is still no disagreement between most of us. I've been in the works of making plans for such a project for a year now which is actually only a small part of a much bigger picture. I don't think that I will open a new thread for the discussion of such a system because I am not in the need of input at this point in time. I only thought that you would be interested in possible future use cases that you could consider during development and in arguments justifying support.

Let's rephrase native installer wizard to offline installer wizard. I was only implying native executables in my comments to make it easier to imagine because most are not familiar with the power of the web. By using the phrase downloading and installing, we don't need to limit ourselves to languages other than Javascript. Consider that the link of the installer could point to the Chrome Web Store (or App Store/Google Play for your tablet). It could even use ActionScript or a Java applet if you are into that kind of thing. The emphasis is on permitting single-click installation and offline usage. Well, it sounds a bit perverted, but you could very well host the package locally on the device itself.

Great new projects like Luci2 or this AngularJs based one make possible decoupling of the architecture to Model-View-Controller with style. The possibility of serving parts of a given tool from places other than a tightly embedded device is then given. Afterwards, the thought of making local storage of all components optional is evolutionary, not revolutionary. Note that I am not principally against hosting the most basic tools locally - I would rather make that optional. You could think of it as a local cache.

(Last edited by bkil on 16 May 2015, 09:29)

metai wrote:

wouldn't OpenWrt be much better if

I think we agree here metai... my point is that OpenWrt is much better when the router (device) installation is 100% self contained (with or without angular), as it is now.

It would be a huge step backward that the OpenWrt GUI in any way is dependent on any kind of client PC installation or even Internet access. So, anything we can squeeze onto the device, and configure it from any PC/iPad whatever: good.

That said, I don't mind if anyone builds an iOS app for controlling and configuring OpenWrt.

It would be a huge step backward that the OpenWrt GUI in any way is dependent on any kind of client PC installation or even Internet access. So, anything we can squeeze onto the device, and configure it from any PC/iPad whatever: good.

That said, I don't mind if anyone builds an iOS app for controlling and configuring OpenWrt.

I agree with you completely. And this is exactly what we are aiming at, I think everyone of us. It is supposed to be self contained - as in a single firmware file that has everything. But what I think is quite fascinating is that considering the current development towards exposing more stuff through rpc is that it is already possible to build a desktop applet that would for example allow the user to control their firewall on the router by right clicking on a tray icon. This would of course require some kind of local server to which all applets can connect so that they would not have to authenticate with the router every time. But the fact that it is already possible to do it is very good because it also opens up a lot more possibilities.

For example, consider the case with NAT rules. Usually you want to open up a port so that traffic can go in. If you have an app running locally this becomes very easy, it can simply have a nat section where it lists all listening services and allows you to add nat rules on the router automatically. And this is just one example. Both the web gui nat rules and the applet would use exactly the same api so maintaining a separate api for external apps can be completely avoided.

I don't think rpc is going anywhere and rpcd is a very good project indeed. The web gui will continue to be self contained and run on the router. This is a hard fact. But of course to make development of plugins easier it would be possible to load up the gui locally and connect to the router over rpc. But this is mainly to make the life of development team much easier so that they don't need to upload package to the router every time they need to test something. And also, making sure that things work both ways is essential in order to do unit testing.

To understand what I meant, you can check out some of the new unit tests that I have added to the project here:

https://github.com/mkschreder/iopsys-op … est-uci.js

This test runs locally using node js and connects to the router through rpc to test uci ubus module of rpcd. This test assisted me in finding a bug in rpcd that caused the rpcd service to end up in unusable state after doing a revert. So I'm all for this kind of tests. It is now possible to run all currently available tests against the router over rpc using the command "grunt test --host=<routerip> --user=<rpc_login_username> --pass=<rpc_password>" from the luciexpress folder which contains Gruntfile.js. The tests will reveal if some dependencies are missing on the router or if some permissions are not being properly set..

So I think there will be a lot more unit testing just to quickly be able to quality assure a build. It certainly simplifies things and saves time. But for it to be possible we must develop software so that it can both be run both entirely on the router and just as well off it.

(Last edited by mkschreder on 16 May 2015, 12:04)

vandeputp wrote:

sure want and can contribute (limited time available).
There are also other packages i want to release to the public domain written as NodeJS server components to run on the router

in our labs we ar using Linksys WRT54L and a big hurdle is still installing nodeJS, so all info about easy way to do that will help

Ok so I did a quick merge between inteno team public sdk and openwrt trunk. Have uploaded it into https://github.com/mkschreder/openwrt-trunk. So far this is just a quick import of all the inteno router packages into the current openwrt trunk. At least it compiles luciexpress and luciexpress works in virtualbox build. However a lot of functionality is not available in the gui when you fire it up, because it depends on other packages to be installed (such as asterisk for phone stuff and actual wifi interfaces for wifi pages). When building an inteno firmware using the inteno sdk all these things are automatically available, but making the package more generic will require more work.

The best way to contribute right now is to clone the git repo above, try it out, and then send me an email with a pull request for any fixes/changes/plugins. I will be regularly rebasing it on the openwrt trunk to keep it up to date. This also means that it would be possible to directly merge it into main openwrt trunk when time comes for a more complete integration.

Hello,

thankful for your work I'm - some questions I have:

1. What is iopsys or the "iopsys firmware"?
2. Do you run any CI-Service for building OpenWRT-Packages? How do I install your software on OpenWRT Release-Builds (BB) or RC (CC).
3. Do you have a roadmap / backlog for features / missing features / release dates / mile stones?

Keep smiling
yanosz

Really want to use it. It's more user friendly than original openwrt web interface. Especially the mobile web interface. I think openwrt should make it as an official package.

yanosz wrote:

Hello,

thankful for your work I'm - some questions I have:

1. What is iopsys or the "iopsys firmware"?
2. Do you run any CI-Service for building OpenWRT-Packages? How do I install your software on OpenWRT Release-Builds (BB) or RC (CC).
3. Do you have a roadmap / backlog for features / missing features / release dates / mile stones?

Keep smiling
yanosz

We at iopsys maintain our own firmware based on openwrt which is called iopsys. Most of my development is done on iopsys so obviously I make the best use I can of the utilities and ubus calls that are available under iopsys.

All the iopsys packages are open source and can be ported to your version of choice.

To build juci under openwrt use the juci feed that you can add to your collection of feeds:
https://github.com/mkschreder/juci-openwrt-feed.git

To build completely standalone (including uhttpd etc.) use the juci standalone feed:
https://github.com/mkschreder/juci-feed.git

Juci main repo is located here:
https://github.com/mkschreder/luci-express.git

Iopsys main public repo (all the backend packages you need for working system with juci) is located here:
http://ihgsp.inteno.se/git/iopsysAA.git (branch devel)

JUCI core is now pretty stable. I rarely do any significant changes to it now. Most of my work now is done on juci plugins themes and apps. For your own release you can easily create an app and use it with juci-core along with whatever other apps that will work for your platform (apps depend on ubus calls and uci configs that may be missing on your platform)

Official release notes for iopsys:

inteno wrote:

As you are all aware we are working on the development of a new GUI implementation based on an Angular framework (Javascript) communicating using the JSON RPC. The JSON remote procedure call is access control protected and is the API toward UBUS. The new implementation called JUCI, provides for a more responsive user experience as most of the heavy load will be handled by the browser.  The new implementation is now more suited for third party widget development and is more future proof.

Please note that a new and more robust file system was implemented on all releases with new GUI: UBIFS. The UBI file system improves the lifetime of the NAND flash hardware and improves the read/write access time.

We have now a first release with most of the end-user functionality available including: WLAN configuration, SSID, WPA, Channel selection 2,4G channels 1-13, Bandwidth (20,40 2,4G och 20, 40, 80 5G), Port forwarding, DHCP LAN, VoIP, and Dynamic DNS

On the 28th of July we are planning to release a version adding most of the network configuration functions, including multi-WAN etc. Target functions for this release is: Network configuration including IPv6, Bridging, multi-WAN, UPNP, Samba and MiniDLNA

On the 15th of August we plan to ad AP/Client mode and Advanced VoIP, as well as some more extensive testing.

I have been putting great deal of effort recently into making juci generic. Juci now uses shell scripts in ubus backend and I am gradually eliminating the messy questd dependency and refactoring the backend so that it become more generic.

I hve also separated up juci functionality into multiple modules that can be installed separately.

Stay tuned :-)

https://raw.githubusercontent.com/mkschreder/luci-express/devel/media/screenshot.jpg

Finally put some work into the overview page in JUCI. :-)

(latest devel branch)

Some news in this release is a new way to write juci backend functions in lua. It used to be a C backend but I always felt it meant lots and lots of code duplication for the most trivial of things. So I tried writing the backend in a mix of bash and awk.. well that was very slow. So I tried perl and it became 50 times faster than bash.. and finally I have settled for lua again because lua is on par with perl in parsing text and is very very space efficient.

The difference in the use of lua in juci compared to luci is that we never ever generate any of the gui elements on the server. The scripting is only used for the backend and this works really well actually.

(Last edited by mkschreder on 14 Aug 2015, 17:41)

Very cool!

This is great!! Really nice GUI!!

Consider submitting to the devs as an alternate GUI. Would be great to make this readily available to all users of OpenWrt

Wow that looks great!

I bet a lot more people would try it out and help develop if they could test it  more easily. I asked about this before, but it would still be great if JUCI was a package everyone could easily install.

roger_ wrote:

Wow that looks great!

I bet a lot more people would try it out and help develop if they could test it  more easily. I asked about this before, but it would still be great if JUCI was a package everyone could easily install.

It works now on Chaos Calmer. But very basic.

Here I have it running on CC imx23 olinuxino :-)

http://i.imgur.com/wGg5ZVk.jpg

Here is how to install it:

- Add juci feed to your feeds.conf.default
src-git juci https://github.com/mkschreder/juci-openwrt-feed.git

- Update and install the feed
./scripts/feeds update juci
./scripts/feeds install -p juci -a

- select juci core, inteno theme and plugins under JUCI menu in menuconfig

- BUILD!

And it should work. If you then go to your router ip you should see the login screen. By default admin user is used to login but if you don't have password set for admin user you will not be able to login. You can set the username that is allowed to login in /etc/config/rpcd and then do /etc/init.d/rpcd restart.

It would be really really nice to have this as a downloadable package. If it is working well, consider submitting the git feed for inclusion in mainline openwrt.

drawz wrote:

It would be really really nice to have this as a downloadable package.

+1

tmo26 wrote:
drawz wrote:

It would be really really nice to have this as a downloadable package.

+1

+2

build success, but i got login screen with blank page.