Frontail is dead - long live the UI but

Setup, Configuration and Use Beginners
1

Many of you might have noticed that frontail has been removed from the latest openHABian release, mostly because frontail has security issues and since the latest release the UI has received an integrated log viewer which is great and very convenient.

Don’t get me wrong: having the logs in the UI is a great extension but… this leaves a gap at least for me:

  • I often used frontail to view log messages during startup of openHAB. Now I can only see the log messages when openHAP IS UP and I cannot see any issues during startup without going to the system itself.

  • I have the feeling that the UI only shows the events or am I wrong? I am missing everything that is logged to /var/log/openhab/openhab.log? I actually missed quite a number of error today because I didn’t see them in the log. Or is this configurable (at least I did not see it)

  • Is there an alternative that anyone can recommend to install instead of frontail to view “tail -f /var/log/openhab/openhab.log” via a web console as it would be much more convenient at least for me.

PS: Besides that, here is a hint to the maintainers (including myself): we need to cleanup the openHAB and openHABian documentation because some pages still mention frontail.

5 Likes
2

That’s very strange. The logging in the UI should be the same as the openhab.log (it is for me anyway).

3

Not entirely, but that’s because of the way it is done.

I have adjusted the log4j2.xml configuration in the /var/lib/openhab/etc directory (on an RPi) to contain something like this:

                <!-- Event log appender -->
                <RollingRandomAccessFile fileName="${sys:openhab.logdir}/events.log" filePattern="${sys:openhab.logdir}/events.log.%i.gz" name="EVENT">
                        <!-- Regex filter added below -->
                        <RegexFilter onMatch="DENY" onMismatch="ACCEPT" regex=".*(Systeminfo|openHABianDevice(?!_OHNumberofThreads)).*"/>

                        <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n"/>
                        <Policies>
                                <OnStartupTriggeringPolicy/>
                                <SizeBasedTriggeringPolicy size="16 MB"/>
                        </Policies>
                        <DefaultRolloverStrategy max="7"/>
                </RollingRandomAccessFile>

As the number of threads on my system changes constantly, it also creates a lot of logging in the events.log. The extra RegexFilter filters that out. As Frontail is actually reading from the filesystem, it would not see these log entries. The new built-in logger does see them all, leading to bad performance of the logger and a lot of overload. Filtering in the UI does not solve this. There is a need for a better filtering mechanism on the server side.

4

I agree - the server side needs a number of features to further improve the system, but there was limited time to make core modifications for 4.3.

3 Likes
5

I know, and I understand that. I was very happy to see this first version included. But at the same time, I feel it is premature to forcefully remove Frontail at this point for the reasons above.

6

Sorry - I had no hand in that. I only did the UI implementation. I guess there’s nothing to stop you adding Frontail back on any linux system though.

7

I know you didn’t. And yes, it can be added back. I was just commenting about the parity of functionality. And while I love all the effort, there is no parity yet. But you created something wonderful already and I am sure it will improve going forward.

5 Likes
8

I only found the lack of frontail today when I upgraded openHAB / openHABian with openhabian-config and then I I had an issue with openHAB which is why I tried to reach*:9001 which did not respond which started my research finding this news.md (which I am sure I have overlooked when I started openhabian-config … my bad):

So I don’t think we want to add frontail back.

9

You might give this a try

10

I read through these before making up my mind. I indeed don’t think we should keep it in the long run. At the same time, it is my understanding these vulnarabilities are important if frontail would be directly exposed to the internet. If it hits you from inside your network, you have a bigger problem.

So, using frontail should go with a warning. But it is too drastic to just remove it at this point. In the mid term, yes, we should remove it, ideally by having feature parity with the built-in log viewer.

1 Like
11

How would you watch the startup logs before the UI is up and running? You need something external…

12

If something is written to the log, it means the part of OH that is writing logs (karaf) is up and running. Would it not be possible to have the websocket with logging up and running very early on as well? I didn’t look into this in any detail. It probably is not simple as it also relies on UI components already up and running. That’s also why I wrote ‘ideally’. It needs to be analyzed further.

1 Like
13

For the moment maybe it would help if Main UI log viewer would not come up with a blank screen but with a list of the last 100 log entries so that you can at least review openhab starting warn and error messages a minute later?

Another workaround might be to have a semi-static html file (refresh by timer or manual refresh) which simply reads the logs directly from file system. At least for startup of openhab this will do the job.

2 Likes
14

For the moment maybe it would help if Main UI log viewer would not come up with a blank screen but with a list of the last 100 log entries so that you can at least review openhab starting warn and error messages a minute later?

I’m using log to review problems AFTER they occurred, so coming up empty is kinda useless. I agree, there should be some kind of parameter to specify how many previous events should be displayed upon clicking on log-viewer. But let’s not forget, overall for version 4.3: JOB WELL DONE !! Thank you.

15

This is the primary issue I see. I love the convenience of the new log viewer for quick checking and basic debugging, but I will also need some other viewing solution running in parallel for this very reason. Maybe over the holiday I’ll have time to look at some of the many options out there.

5 Likes
16

Coordinate with @rlkoshak pls

17

It should show everything. I just tested it and I’m getting both openhab.log and events.log.

I did some research on this before @chris’s PR popped up (like the very next day). My top three contenders right now are:

But in the tailon and log.io cases the repos for these haven’t been updated since last year. Are we going to end up in the same boat? Lodgy, at least with my experiments, has been a little challenging to get to run as a daemon (it keeps crashing on me but I’ve not been able to tell if I’m doing something wrong).

Everything else is super heavy weight and won’t fit on an RPi with OH running too.

I’d love to learn about more alternatives if anyone has run across some. I’m a little uncomfortable picking up a replacement which itself may already have been abandonded.

I never really used Frontail, did it go back in the log file some way when you bring it up? I thought it just started reading newly written stuff but could be wrong.

I need to look into the three alternatives above to see how they work.

First let me say that I wasn’t involved with the removeal of Frontail but I kind of support it. I probably would have waiteda little bit with a warning before just removing it but I wasn’t involved so it doesn’t matter what I would have done.

Also, once @chris published his PR I put this on the back burner and have been looking more at a replacement for FireMotD which is also become abandonded (FastFetch is the leading candidate there, I’m learning the openHABian scripts though to figure out how to install it instead of FireModD so it’s slow going).

Anyway, given the lack of lots of options, maybe it’s time to step back and think outside-the-box. Maybe we are falling into our own XY Problem.

The end goal is to see the logs in the browser to include logs from OH before MainUI is up. I’d add it would be great to get errors when logging itself fails to come up because of some problem with the logging config (as happened to me after upgrading to 4.3 release).

What if instead of just a log viewer we had soemthing like a web based ssh or teminal access? That might solve two problems (remote access to the OS and access to the logs). Note I haven’t looked into these sorts of options yet and I do have some security concerns.

Just throwing that out since I think the people who have the most invested in the solution are on this thread.

1 Like
18

Actually, I’ve “cleaned up” the log files of unnecessary (for ME) INFO events trough log:set in Karaf. So my LOG is kinda “clean” and contains mostly Log of events from rules and of course WARNINGS and ERRORS. When some automation event fails to happen, I can easily review trough log. Via frontail (my still works, because it was installed manually) from phone or any other device at my hand …

19

hmm, what is actually shown in the viewer then? What could the case that I don’t?

20

image
image1564×615 149 KB

You can see it’s a mix of openhab.log and events.log.

It gets populated via a websocket. Maybe there’s something interfearing with that? I can’t say. I think it’s the case that it doesn’t work through myopenhab.org. Are you connecting locally?