[PENDING]I'd like to contribute

I am finally ready to give it a go.

At first I will be only focusing on what will be new features for LUCI that I am missing at the moment.

Please do not expect results soon though. I am terribly slow.
Also I need to get accustomed to the coding guidelines being applied here.
What I do have is some experience on the front end so what ever I make should hopefully be worth merging into the master branch.

At first I am thinking to make the Lucy System log more interactive. With tail and filters.
Where can I get more information on how to make a client side call that will give syslog data?

Currently Luci just appears to call logread and dmesg in order to obtain the logs. See /usr/lib/lua/luci/sys.lua One can get direct output from the kernel via /dev/kmsg and I believe logread uses ubus to read the logs, see https://openwrt.org/docs/techref/ubus

I am approaching this from a client side perspective. Is there an API that a client can call?

I strongly believe that LUCY should shed lua (or what ever is running on the device to render html) ties as much as possible.

I will admit that I have not yet seen any code yet and thus I might be missing the mark here big time.

No, unless you make one.

How about OpenWISP?

Ok then. API it is then. Where do I start my research?

In my believe, the less ties with other stuff the better

I might try hitching a ride with the luci cli component. Sure it is a tie in but at least clean enough I hope

Maybe better to see how the luci sys log page is generated. Reuse that code to create

would that be a good way forward that is likely to be merged?

I already told you how it's generated: it just uses logread and dmesg.

yes thank you. I did not mean to ask again on how to get syslog data. I meant rather than reinventing the wheel I will take a look at the already existing code that does it.

But I did mean to ask if an api with a schema like api/log/system/? and a query string is something the community might benefit from.
I can make it return XML or JSON or both based on a QS param.

Or is that not something that is deemed useful?

1 Like

To be honest, there's little point trying to get a consensus on whether a feature you want to add might be useful or not. If you think it'd be useful and you're going to put in the work to implement it then do the work and submit a pull request to the appropriate github repo. If it does turn out to be an improvement over what already exists then it may get merged, but keep in mind there's no certainties.

1 Like

I'll try going the github route. I am not sure if anyone here cares about the opinion of a newcomer but I must say this was quite a cold shower.

Why, though? All I see is a bunch of perfectly reasonable replies to posed questions.

1 Like

Hi Thanks for wanting to get your hands dirty in luci's code. Pleas don't be put off by the brusk manna some posts can be ritten in. People on this forum are really nice. It's just people want to get there point across as succinctly as they can. They are all volunteers with dayjobs and stuff like that. People have bin really helpfull to me when I have asked for a11y changes in luci.

As you are new I think you were looking for some encouragement.

I am not a dev I am just a blind dude that likes to tinker around with flashing routers.

I cant help out with code, but what I can tell you is coding for OpenWrt/LUCI is not like coding for a website.
When building luci apps and making changes to luci size is everything. Some of the routers have just 8 mb of flash so building anything that has to use a big lib or framework is a no no.

Where most people start is digging around on github and getting to understand just how luci works. The way luci shows the logs is just by calling logread and then put ing the plane text on the screen.

If you would like to add anything to this it would have to be small.

You will not have to worry so mutch about this if you made a luci addon {package} You could call it luci-app-logreadplus.

I hope this helps.
Good luck mate.

If any of this is rong other people pleas chime in.
We need to get people intrested in contributeing to OpenWrt!


Come to think of it as a screen reader user it would be good to beable to hide the date and time when reading the log becase I have to wate ages for my screenreeder to read out the hole lot befor it gets to the good bits.
EG I will post what my screen reader reads from my log.
{Sun May 8 10:04:55 2022 daemon.info hostapd: wlan0: STA 5e:a0:f6:37:3a:43 IEEE 802.11: associated (aid 4)

Sun May 8 10:04:56 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 5e:a0:f6:37:3a:43

Sun May 8 10:04:56 2022 daemon.info hostapd: wlan0: STA 5e:a0:f6:37:3a:43 WPA: pairwise key handshake completed (RSN)

So my screenreader has to read all of that out to me. Now heres what It would read as if I could hide the time and date
{daemon.info hostapd: wlan0: STA 5e:a0:f6:37:3a:43 IEEE 802.11: associated (aid 4)

daemon.notice hostapd: wlan0: AP-STA-CONNECTED 5e:a0:f6:37:3a:43

daemon.info hostapd: wlan0: STA 5e:a0:f6:37:3a:43 WPA: pairwise key handshake completed (RSN)
To get how that would be for me you have to read out loud every char in the blocks of text.

1 Like

Based on the ubus suggestion made earlier on this thread I am now considering to making firefox add on(s).

Tiny javascript code that basically does what needs to be done.
Easy for people to inspect as to keep it on the up and up and easy to install/deinstall.
So no changes needed to the code base.

And yes a little encouragement, like the most resent posts, is what motivates. thank you!

But it seems there already is an API. the exact ubus as suggested earlier.

I never realized until recently as I was not looking in the correct places.

Take a look at the current DNS leases (EDIT, I meant DHCP lease) overview. And how it polls.

Sure not all the new standards in API communication are employed. But I have given my self the freedom with having over more than 28 years of web development experience I will call this an API.
Because is it an interface? yes
to what? application / program

first thing on my mind would be to have ubus be more intuitively approachable.
More along the lines of what the current luci path displays, ubus is supposed to give all the relevant data regarding that.

I am thinking of a wrapper around ubus then.

Does this make sense?

Wrappers can also be done client side. As to not give up on the add on concept