Latest update killed Usermin (v1.730)

uBlock Origin should not.. but also you can very easy disable this per site so that is only a client isseu!

For other use forum and websearch more off the same.. ;)

Same error after the update...

Same error for me.

Same errors here... commenting out the embed_noscript() at line 1692 of /usr/libexec/usermin/authentic-theme/authentic-lib.pm Doesn't really "fix" the issue...

It just makes it kinda tolerable. Inbox/Outbox/Spam, etc. selections in left column don't appear...

Where in the UI are you seeing that error about embed_noscript exactly? It doesn't appear in the screenshot.

UPDATED:

@Jamie: (It show up after you enter your login details, its a white page with:) - wrong

It show up before you even see the login page. My previous statement was wrong probably because i didnt clear my browser cache.

Centos 7 (everything updated)

Hi,

This should be the cache issue as embed_noscript() present in authentic-init.pm line 336-394, which is always required. Make sure that you have both Webmin and Usermin themes updated. You can run console script to do it and restart Webmin/Usermin afterwards.

What this code does, is simply showing User Friendly message for the users with disabled JavaScript. https://github.com/qooob/authentic-theme/issues/930.

Ok, we've created new Usermin 1.732 packages that include the fix. You can get them immediately from http://www.webmin.com/devel.html , or wait a bit for the Virtualmin repository to be updated.

So 3 days after your post and 4-5 since this problem pop out - when we will finally have working version of Usermin and Authentic theme?

Please update the theme for Usermin using update script.

I can't reproduce this issue. embed_noscript() is there obviously. Make sure to restart Usermin manually after upgrading the theme.

It just shouldn't happen.

Same problem here.

Okay, guys.

What is the output of

cat /usr/libexec/usermin/authentic-theme/authentic-init.pm |grep embed_noscript

I will try later to undo the change in that file and restart all *Min software separately by command line. I'm not sure if this will change anything because both problems (this one and #54703) didnt go away even after two server reboots. Once i finish that i will post back the results.

Guys, can you just run:

pkill miniserv

and then restart both Webmin and Usermin?

/etc/webmin/restart /etc/usermin/restart

As a temporary fix you can login to the virtualmin / webmin UI and then go to the usemin config page and change usermin theme to gray framed. Restart usermin afterwards and viola, usermin works, albeit with the framed theme.

After changing to Gray Theme, can you run a script and update the theme?

For both Usermin and Webmin.

/usr/libexec/usermin/authentic-theme/theme-update.sh

and

/usr/libexec/webmin/authentic-theme/theme-update.sh

For Debian systems libexec would be changed to share.

Then stop Webmin and Usermin:

pkill miniserv

Then restart both Webmin and Usermin?

/etc/webmin/restart /etc/usermin/restart

Then try setting Authentic Theme as default and try again.

Does it work now?

Also, and I mean no offence to you Ilia the authentic theme looks good but i read somewhere here ages ago that the Authentic theme will become the default theme eventually and there will be no option of using the framed themes afterwards?

I have to say that as much as I love using virtualmin and webmin, and I have been for many years, I’m not really interested in these new types of comparatively slow, complicated and resource heavy themes. I understand they are important for sales etc and many like them but webmin and virtualmin are server management scripts, not fashion items.

So please don’t remove the ability to use the old simple themes in the future. :)

I haven’t tried running the update scripts Ilia, I just wanted to be able to login to usermin and quickly change some mail filters. With the gray theme it worked ok. That was enough for me. Good luck with the fix and upgrades etc though, hope you fix it soon and get the rest of the night off! :)

We're not planning to give up basic theme.

Authentic Theme 19.xx is as fast as Virtualmin Framed Theme, almost in each aspect. I'm planning to make optimisations in the future, to try to make it even faster. It's complex, I agree. I'm not sure, but is it okay with you to use File Manager for example in Gray Theme compared with Authentic? What about Inbuilt Command Shell implementation? What about file editor with line numbers and code highlight? In my humble opinion, It's not just fancy looking stuff, it's functionality that is meant to make work not only more enjoyable but more productive.

Rogi, if it was the theme issue, or at least if I understood it, - I would fix it. I can't reproduce this issue on neither of my systems. I remember it happened on my production server and nothing helped. I checked that the files under authentic-theme folder are up to date. I tried restarting services and even the whole server - it didn't work.

To see that I'm right, just copy/paste the content of the embed_noscript from authentic-init.pm to authentic-lib.pm and see what happens. authentic-lib.pm has explicitly required require "$current_theme/authentic-init.pm"; and I don't see how it would be possible, considering that authentic-init.pm has embed_noscript present.

The reason why you don't have issues with Gray Theme because it's almost never has new functions added in -lib.pl files. I see this as caching issue.

In case it's me, then I'm not sure what I'm doing wrong. The only sign that I see at the moment, is that using Servers Index with Authentic takes a very long time on the initial start. I never tried to deeply investigate that, because it only happens with that module and only on the first start (init). I will do it in the future, but I have serious doubts that it's related in any way to this issue.

Revert back the changes i made and restarted Webmin/Usermin - looks like now its ok. Still the question is left why two server reboots didnt do anything. I mean, i just manually restarted this two services, why same thing didnt happen during server reboot.

Rogi, to answer your question about old themes: Authentic is already the default, but old themes will continue to work for a while. There will be a major overhaul of the ui-lib which will break old themes, but a new "no-theme" theme will be added, which will be lighter than Virtualmin Framed Theme, but probably heavier than some of the older themes.

At this point, I'm reasonably confident that Authentic is faster than any of the framed themes on most pages, because it doesn't reload and reparse the CSS and JavaScript on every page load, while all of the framed themes do (the non-framed old themes do, too, but they're so simplistic as to be fast, anyway). But, it is more resource intensive on the client-side, as it has a lot more JavaScript and styling.

One of the reasons to re-architect ui-lib is to simplify markup (drastically, in many cases), which will make things faster, but it will break old themes. We may be able to keep old themes working by copying the old ui-lib into the theme, but that will mean they'll keep using the old HTML which is pretty rough to deal with.

I don't have a perfect answer on the old theme question; they're really terrible to work with, as the markup is ugly as hell and old school HTML (there are some pre-HTML 4.01 transitional quirks in there, for example), and they're extremely limited in what we can do (realistically, doing things that are possible in an SPA are not possible in a frame-based theme that reloads all the JS/CSS on every page visited...things like realtime graphs just aren't reasonable in old themes).

It's not about being fancy or fashionable, per se, it's about being able to make any improvements at all without breaking things.

So, in short:

There will always be a minimal theme of some sort. That's mandatory for accessibility reasons if nothing else.

New UI features will go into Authentic, probably exclusively. So many things just aren't possible, or would be unusably slow, with the old frame-based model (or the even earlier non-framed design).

I can confirm changing to another theme, running the updater from the command line, and then going back to the authentic theme works like a charm.

Didn't have to restart usermin, etc. I had an existing usermin session running and it came right up...

So...it's beginning to seem like something that has changed (maybe in Authentic theme) is preventing Webmin/Usermin restarts. All of these issues come down to Webmin or Usermin not actually being restarted after changes to the authentic-lib.

We've had tons of reports along these lines, and Jamie's been looking into it. All of the issues I've seen can be solved by really restarting the Webmin/Usermin process, as far as I know...but the usual methods of restarting don't actually work, if you don't forcefully kill the process and start it back up.

So...we need to figure out what's preventing the restart. Jamie, is it possible the new requests from Authentic to present updating CPU/memory/etc. graphs is holding the process open and preventing a restart? Something else? Authentic is a lot more network intensive than any other theme...so, maybe something there. That would potentially be a bug in miniserv or the Webmin/Usermin initscript, but it's just never been triggered by older themes because older themes don't do that much network back and forth.

I have a suspicion that something may be resarting webmin with the old code between when the upgrade script stops the old version and when it starts up the new version. Maybe systemd or upstart is doing some kind of automatic restart of the process?

Is there any commonality to which systems see this problem - like is it common to CentOS or Debian?

I think i saw few post from people using Centos 7 (i'm one of them).

Ok, let me see if I can re-produce this.

I did some testing, but wasn't able to re-produce this or even create a situation where usermin wasn't restarted.

Ilia, does the authentic theme make use of webmin/usermin's code preload feature?

I don't think it does. You mean:

load_theme_library()

In the docs it's stated that it's called automatically by the header function.

Right, so that will load the theme library on every page load. What's surprising is why a restart would fix anything, unless there is some theme code that's loaded when Usermin starts up?

Theme doesn't do anything intentionally to interfere start-up process.

I also noticed, with inthebox, by the way, that once, in the past, this kind of issue popped-up. Nothing helped, nothing. Files physically were there.

Back then, what was happening, is that Webmin had older version of the theme and its libs but Usermin was updated manually to more recent version, to run some tests. It didn't work. I remember, that I made a conclusion, that Usermin reads Webmin's installation of the theme's lib files, using cache or somehow else. After updating the theme for Webmin with the same one that Usermin have had, the problem went away.

Webmin and Usermin should be completely separate, unless there is some browser-level caching?

Browser caching is possible but the error happened on the server side, soit's irrelevant. The error was that some subroutine was missing, while it was there in the new libs files.

I just tried on my production RHEL server to run pkill miniserv and it didnt work. Running pkill -9 miniserv should do it. Same probably should be done in the scripts that restart Webmin/Usermin?

Reading all the conversation still for me there is one thing what doesnt make sense - why two server reboots (at least in my case) didnt do anything while commenting out that line and revert the change back to orig. state plus manual restart of Usermin and Webmin sort this problem.

How is possible that two server reboots didnt sort the problem if we have a case where Usermin (and maybe Webmin) didnt properly restart and based on your opinion this was the main reason why the update caused this problems.

I just dont see any logic behind this.

Seems like familiar issue: https://github.com/qooob/authentic-theme/issues/969

This one related as well, I bet: https://sourceforge.net/p/webadmin/bugs/5055/

Hi Joe, I have read your reply (#26) above and understood. All ok with me, and Happy New Year to all.