Scribe Scribe 2.4.4 is out

[Kal1975]

The GUI getting messed up is because GUI files were changed and the browser is caching the old file and didn't reload the new file(s). Usually happens when Javascript files are involved. As mentioned, using ctrl+f5, or Shift+ctrl+R, tells the browser to refresh/reload those files.

 

[joe scian]

Hi CMKelly - after upgrading latest entware files i get this error in scribe. I had to reinstall scribe but still get this error - everything seems to work ok.

@RT-AX86U-AC30:/tmp/home/root# syslog-ng.conf version check ...Error opening plugin module; module='http', error='libssl.so.1.1: wrong ELF class: ELFCLASS32'

 

[iTyPsIDg]

Hi CMKelly - after upgrading latest entware files i get this error in scribe. I had to reinstall scribe but still get this error - everything seems to work ok.

@RT-AX86U-AC30:/tmp/home/root# syslog-ng.conf version check ...Error opening plugin module; module='http', error='libssl.so.1.1: wrong ELF class: ELFCLASS32'

This helped me.

Scribe - error='libssl.so.1.1: wrong ELF class: ELFCLASS32'

Is @thelonelycoder pushing any updates for this round of Entware updates? This makes 2 Entware updates in a row that have caused problems for other scripts. Not for now. Nothing changed on my end that I have to fix. I have no other plans than stopping, let it update and restarting Entware...

www.snbforums.com

 

[cmkelley]

Hi CMKelly - after upgrading latest entware files i get this error in scribe. I had to reinstall scribe but still get this error - everything seems to work ok.

@RT-AX86U-AC30:/tmp/home/root# syslog-ng.conf version check ...Error opening plugin module; module='http', error='libssl.so.1.1: wrong ELF class: ELFCLASS32'

Great. That's an error with syslog-ng, which is really starting to test my patience. I can't do anything about it, and I don't even know which thing that got updated is the cause, or how to roll it back. I don't know if it's the fault of syslog-ng, or whichever package made it break, but it looks like it's broken until Entware either updates syslog-ng or the package that broke it.

 

[ScottW]

@cmkelly -- Not syslog-ng's fault (this time!), but rather a problem with libssl dependencies -- and the fact that opkg doesn't go multiple levels deep when resolveing dependencies during updates. Force reinstalling the dependent packages and then force reinstalling syslog-ng fixes it. More info in the thread that @iTyPslDg linked above.

 

[cmkelley]

@cmkelly -- Not syslog-ng's fault (this time!), but rather a problem with libssl dependencies -- and the fact that opkg doesn't go multiple levels deep when resolveing dependencies during updates. Force reinstalling the dependent packages and then force reinstalling syslog-ng fixes it. More info in the thread that @iTyPslDg linked above.

THANK YOU!

Nota_bene: BACKUP your /opt/etc/syslog-ng.conf BEFORE doing this! (ask me how I know, good thing I'm paranoid about backups)

If the "@version:" doesn't have a number after the ":", scribe will HOSE your syslog-ng.conf file. Obviously this is a problem with scribe, I'll figure it out and post an update, but until then, double check that the version line looks like "@version:3.38" before running scribe.

Meh. I need to retire so I can devote time to programming.

 

[elorimer]

THANK YOU!

Nota_bene: BACKUP your /opt/etc/syslog-ng.conf BEFORE doing this! (ask me how I know, good thing I'm paranoid about backups)

If the "@version:" doesn't have a number after the ":", scribe will HOSE your syslog-ng.conf file. Obviously this is a problem with scribe, I'll figure it out and post an update, but until then, double check that the version line looks like "@version:3.38" before running scribe.

Meh. I need to retire so I can devote time to programming.

Not meh. Oy.

But yes, not syslog-ng or scribe.

 

[cmkelley]

@cmkelly -- Not syslog-ng's fault (this time!), but rather a problem with libssl dependencies -- and the fact that opkg doesn't go multiple levels deep when resolveing dependencies during updates. Force reinstalling the dependent packages and then force reinstalling syslog-ng fixes it. More info in the thread that @iTyPslDg linked above.

Yep, that fixed it. I needed the more extensive fix vibroverbus described, so I scripted it for anyone else who might have more than a couple things installed that depend on libopenssl

https://www.snbforums.com/threads/error-libssl-so-1-1-wrong-elf-class-elfclass32.84052/post-831002

 

[ScottW]

Yep, that fixed it. I needed the more extensive fix vibroverbus described, so I scripted it for anyone else who might have more than a couple things installed that depend on libopenssl

https://www.snbforums.com/threads/error-libssl-so-1-1-wrong-elf-class-elfclass32.84052/post-831002

That’s a good step and does catch the syslog-ng case since it’s a first-level dependency. But I think the problem for many in this update was indirect (second or third level) dependencies. For example, a package that depended on another package which depended on libopenssl. So it’s a recursive, multi-level problem and each level needs to be done in order.

Oh - and the dependency chain also goes "up" (opkg depends <pkg>) multiple levels as well as "down" (opkg what-depends <pkg>). @ryzhov_al had some good tips about that here:
https://www.snbforums.com/threads/w...ing-shared-libraries-error.84067/#post-828900

The other thing that I think made this particular update (libopenssl) so consequential was not just that so many things use it, but that the old version/path was deleted by the new version update, basically pulling the rug out from under the packages that used it or one of its dependent packages.

 

[XIII]

So it’s a recursive, multi-level problem and each level needs to be done in order.

Indeed. I was stupid/unlucky and did it in the wrong order, seriously breaking Entware.

(Solved it by renaming the Entware folder on my USB drive and starting from scratch)

 

[cmkelley]

That’s a good step and does catch the syslog-ng case since it’s a first-level dependency. But I think the problem for many in this update was indirect (second or third level) dependencies. For example, a package that depended on another package which depended on libopenssl. So it’s a recursive, multi-level problem and each level needs to be done in order.

Oh - and the dependency chain also goes "up" (opkg depends <pkg>) multiple levels as well as "down" (opkg what-depends <pkg>). @ryzhov_al had some good tips about that here:
https://www.snbforums.com/threads/w...ing-shared-libraries-error.84067/#post-828900

The other thing that I think made this particular update (libopenssl) so consequential was not just that so many things use it, but that the old version/path was deleted by the new version update, basically pulling the rug out from under the packages that used it or one of its dependent packages.

I *think* Entware is smart enough to get the sub-dependencies - the output of "opkg whatdepends libopenssl" on my machine is:

Root set:
  libopenssl
What depends on root set
        syslog-ng 3.38.1-1a     depends on libopenssl
        pixelserv-tls 2.4-2     depends on libopenssl
        libcurl 7.86.0-1        depends on libopenssl
        ntpd 4.2.8p15-4a        depends on libopenssl
        lynx 2.8.9rel.1-2       depends on libopenssl
        curl 7.86.0-1   depends on libcurl
        bind-libs 9.18.11-3     depends on libopenssl
        drill 1.8.3-1   depends on libopenssl
        git 2.34.7-1    depends on libopenssl
        libldns 1.8.3-1 depends on libopenssl
        bind-dig 9.18.11-3      depends on bind-libs
        git-http 2.34.7-1       depends on libopenssl
        ntp-utils 4.2.8p15-4a   depends on libopenssl

So my method gets all of those, including curl, which depends on libcurl (which depends on libopenssl) and bing-dig, which depends on bind-libs (which again, depends on libopenssl). I think (though I'm a bit out of my depth here), that we only needs to worry about going "down," and I think opkg whatdepends creates a full multilevel list. The things that libopenssl depends on ('up') shouldn't need reinstalling when libopenssl is updated.

 

[ScottW]

I *think* Entware is smart enough to get the sub-dependencies...

I think (though I'm a bit out of my depth here), that we only needs to worry about going "down,"

It does look like "whatdepends" is recursive, so that's good.

And this is beyond my depth as well, but what is @ryzhov_al saying here? I interpreted that to mean that "upgrade" (as well as "opkg depends") resolves only (1) level of upstream dependencies. True? (In particular, look at post #7)

Entware - "Wrong ELF class" or "Error while loading shared libraries" error

Entware uses lightweight opkg package manager, which is too primitive to track down dependencies change. Let say, some program depends on `libssl.so.1.0` file but it was replaced by `libssl.so.1.1` while running `opkg upgrade`. So, you program will fail to start next time because of...

www.snbforums.com

Or... Maybe he's saying "upgrade" gets the upstream dependencies but not downstream, and is separately saying that "depends" only reveals one level up? If so, then an "upgrade" followed by your recursive downstream upgrade would catch everything. But I'm not sure yet.

 

[cmkelley]

It does look like "whatdepends" is recursive, so that's good.

And this is beyond my depth as well, but what is @ryzhov_al saying here? I interpreted that to mean that "upgrade" (as well as "opkg depends") resolves only (1) level of upstream dependencies. True? (In particular, look at post #7)

Entware - "Wrong ELF class" or "Error while loading shared libraries" error

Entware uses lightweight opkg package manager, which is too primitive to track down dependencies change. Let say, some program depends on `libssl.so.1.0` file but it was replaced by `libssl.so.1.1` while running `opkg upgrade`. So, you program will fail to start next time because of...

www.snbforums.com

Or... Maybe he's saying "upgrade" gets the upstream dependencies but not downstream, and is separately saying that "depends" only reveals one level up? If so, then an "upgrade" followed by your recursive downstream upgrade would catch everything. But I'm not sure yet.

"depends" definitely only reveals one level up. You can tell by the recursive example he posted. As for what "upgrade" catches, I don't know. Obviously it doesn't go down to all levels or the libopenssl upgrade would have cascaded down to syslog-ng. Kinda sounds like "upgrade" only gets the packages that have changed and doesn't go up or down at all.

 

[ryzhov_al]

And this is beyond my depth as well, but what is @ryzhov_al saying here? I interpreted that to mean that "upgrade" (as well as "opkg depends") resolves only (1) level of upstream dependencies. True? (In particular, look at post #7)

Package manager upgrades all installed packages if newer version available, no matter what dependency depth is.

When some package (curl for example) doesn't change its version, but dependent library got some significant update (libopenssl), `opkg upgrade` can break local deployment. You'll get a new library name (libopenssl) and old package (curl), which doesn't know about the fact that library name has changed.

We always keep repo in consistent state, so, solution is to re-install package (curl) to update local binaries.

 

[elorimer]

We always keep repo in consistent state, so, solution is to re-install package (curl) to update local binaries.

Yes, and this particular trap was that syslog-ng wasn't updated and made such a call from a module nobody is using. For most updating through amtm update-upgrade isn't smart enough to do this. @cmkelly's script worked fine for this and a couple other broke things. Looking forward to having that or something similar folded inito the amtm process.

 

[JGrana]

Anyone running 388.2 B1 on an AX88U Pro?
I recently needed to replace a failing AX88U - went with the new Pro version.
In setting up the new router, in addition to things like unbound-manager and YazDHCP, I always install scribe/uiScribe.
I also brought over some of my aliases.

One of them does a tail -f of /tmp/syslog.log.

I noticed there was nothing in the log. In looking further, I see that /tmp/syslog.log is a link to /jffs/syslog.log - which is an empty directory…

Did I miss something in recent firmware updates? Or, have I somehow done something in my setup of the new router?

For now, I am tailing /opt/var/log/messages - but I don’t see any startup information after a reboot/boot (I undestand why ;-)

 

[visortgw]

Anyone running 388.2 B1 on an AX88U Pro?
I recently needed to replace a failing AX88U - went with the new Pro version.
In setting up the new router, in addition to things like unbound-manager and YazDHCP, I always install scribe/uiScribe.
I also brought over some of my aliases.

One of them does a tail -f of /tmp/syslog.log.

I noticed there was nothing in the log. In looking further, I see that /tmp/syslog.log is a link to /jffs/syslog.log - which is an empty directory…

Did I miss something in recent firmware updates? Or, have I somehow done something in my setup of the new router?

For now, I am tailing /opt/var/log/messages - but I don’t see any startup information after a reboot/boot (I undestand why ;-)

The symbolic links are correct on newer routers, such as my GT-AX6000:

# ls -al /tmp/syslog*
lrwxrwxrwx    1 TheS1R   root            16 May  5  2018 /tmp/syslog.log -> /jffs/syslog.log
lrwxrwxrwx    1 TheS1R   root            18 May  5  2018 /tmp/syslog.log-1 -> /jffs/syslog.log-1

As far as the actual logs in /jffs, they are files on my router, not empty directories:

# ls -al /jffs/syslog*
-rw-rw-rw-    1 TheS1R   root         62531 Mar 28 10:22 /jffs/syslog.log
-rw-rw-rw-    1 TheS1R   root        150624 Mar 28 10:00 /jffs/syslog.log-1

Is it possible that log directory needs to be configured in scribe?

(NOTE: I am NOT currently running scribe on this router.)

UPDATE: I just confirmed that installing scribe changes the log files to empty directories.

 

[JGrana]

@visortgw thanks for checking. Glad it wasn’t something I did!
@cmkelley - any ideas on how to get the syslog.logs back?

 

[dave14305]

any ideas on how to get the syslog.logs back?

He probably needs to identify models that write directly to /jffs/syslog.log instead of /tmp/syslog.log.

Skynet made this change, as an example:

Support models that have jffs as syslog location · Adamm00/IPSet_ASUS@6ebf3da

Skynet - Advanced IP Blocking For ASUS Routers Using IPSet. - Support models that have jffs as syslog location · Adamm00/IPSet_ASUS@6ebf3da

github.com

 

[visortgw]

@visortgw thanks for checking. Glad it wasn’t something I did!
@cmkelley - any ideas on how to get the syslog.logs back?

Temporarily, uninstall scribe.