Do you have background status collection enabled in Webmin ⇾ Webmin Configuration: Background Status Collection page?
Machine was up and running for about a month prior to Webmin/Virtualmin being installed, so ipfw was indeed installed prior to Webmin/Virtualmin. Why was that a mistake?[quote=“Stegan, post:20, topic:124400, full:true”]
To me that suggests it was possibly not a clean install. if ipfw was placed on the system prior to installing Webmin/Virtualmin that would have been a mistake.
[/quote]
They’re running on FreeBSD. All bets are off. It’s nothing like a Linux installation using the Virtualmin install script (there is no install script on FreeBSD, but Virtualmin is available in ports). Someone running Virtualmin on FreeBSD needs to know a lot more about their system and the services Virtualmin manages, but it’s entirely reasonable for someone with that knowledge.
Anyway, method of installation shouldn’t prevent this particular feature from working, and we’d like to get to the bottom of it.
1 Like
I’ve got a fair understanding of how FreeBSD works from the console, I wouldn’t call myself an expert, but reasonably knowledgeable. That being said, while Webmin/Virtualmin is working, it’s very possible that FreeBSD is doing something weird under the hood that I can’t find (yet).
Cronjobs typically work the same in FreeBSD as in Linux, so I don’t think it’s the scheduler itself that’s a problem. Maybe the calls to the scheduler from with in *min?
What screws people up is user-spaces (/usr/local/) vs system-space. (/) All of my user-installed-system-service configuration files are stored in /usr/local/etc/. The only time I need to touch anything in /etc is if it’s a system-level installed services (ex nfs, ssh, rc.conf, syslog, sysctrl, etc.).
from the command line, I do see both webmin crontabs that should be there
[root@vulture ~]# crontab -l
0 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 * * * /usr/local/etc/webmin/status/monitor.pl
44 7 * * * /usr/local/etc/webmin/package-updates/update.pl
[root@vulture ~]#
Really, I’m grasping at straws now, I don’t know exactly what I’m looking for.
Try running the update script directly from the command line. Maybe it’s giving errors and you’re just not looking in the right log for it:
WEBMIN_CONFIG=/etc/webmin /usr/libexec/webmin/virtual-server/scriptlatest.pl
You need to change the path to the script to match your actual system, and maybe also the WEBMIN_CONFIG path. I don’t know what it’d be on a FreeBSD system.
If that works without error and your scripts get updated, then it’s something wrong with the scheduled job.
So, for me, it would be
WEBMIN_CONFIG=/usr/local/etc/ /usr/local/etc/webmin/virtual-server/scriptlatest.pl
When I ran that, it returned nothing.
[root@vulture ~]# WEBMIN_CONFIG=/usr/local/etc/ /usr/local/etc/webmin/virtual-server/scriptlatest.pl
[root@vulture ~]#
This did prompt me to check the perl version
[root@vulture ~]# perl -v | grep “This is”
This is perl 5, version 36, subversion 3 (v5.36.3) built for amd64-freebsd-thread-multi
[root@vulture ~]#
[root@vulture ~]# pkg search perl | grep “Practical Extraction and Report Language”
perl5-5.36.3_1 Practical Extraction and Report Language
perl5-devel-5.39.0.62_3 Practical Extraction and Report Language
perl5.34-5.34.3_3 Practical Extraction and Report Language
perl5.38-5.38.2_1 Practical Extraction and Report Language
[root@vulture ~]#
[root@vulture ~]# pkg update
Updating FreeBSD repository catalogue…
FreeBSD repository is up to date.
All repositories are up to date.
[root@vulture ~]#
[root@vulture ~]# pkg upgrade
Updating FreeBSD repository catalogue…
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (10 candidates): 100%
Processing candidates (10 candidates): 100%
Checking integrity… done (0 conflicting)
Your packages are up to date.
[root@vulture ~]#
Just out of curiosity, is there a complete list of dependencies for Webmin/Virtualmin/Usermin? I can probably find if I am missing something.
I don’t think that can be right.
Is there no webmin subdirectory there?
Yes. My webmin config lives in /usr/local/etc/webmin/. This is normal for FreeBSD-based systems.
With that in mind, scriptlatest.pl lives in /usr/local/etc/webmin/virtual-server/
[root@vulture ~]# ls -lash /usr/local/etc/webmin/virtual-server/ | grep script
4 -rwxr-xr-x 1 root bin 589B Jan 11 12:39 scriptlatest.pl
4 -rwxr-xr-x 1 root bin 585B Jan 11 12:39 scriptwarn.pl
[root@vulture ~]#
Then WEBMIN_CONFIG should probably be /usr/local/etc/webmin/. It’s been so long since I’ve seen a tarball installation of Webmin, I don’t recall where it ends up.
Amended my previously command to the following
WEBMIN_CONFIG=/usr/local/etc/webmin/ /usr/local/etc/webmin/virtual-server/scriptlatest.pl
It ran for about 5s and then dropped me back to the prompt.
Did it update install scripts to the latest?
Also, the latest Virtualmin version is 7.9.0.
Just checked, nothing updated that I can tell.
Still running 7.7. So, it appears the script isn’t downloading. This brings me back to my firewall. Is the update script running on an odd port? Is there a verbose switch for the script (so I can at least see where it’s failing)?
I went and perused /usr/local/etc/webmin/miniserv.conf and the last two lines have the following;
websockets_/xterm/ws-555=host=127.0.0.1 port=555 wspath=/ user=admin time=1705031696
websockets_/xterm/ws-556=host=127.0.0.1 port=556 wspath=/ user=admin time=1705031759
Is this significant? Do I need to allow this in my fw?
That has nothing to do with install scripts. That’s for the terminal backend.
I’d be surprised if you need firewall rules for local traffic. But, if the terminal doesn’t work, it might be that (but might be something else, I doubt it’s been tested on FreeBSD).
OK, that makes sense.
Try adding --debug flag when running the script, i.e.:
WEBMIN_CONFIG=/usr/local/etc/webmin/ /usr/local/etc/webmin/virtual-server/scriptlatest.pl --debug
Now we’re getting somewhere! http://latest-scripts.virtualmin.com has kindly told me to go do something with myself elsewhere! 
[root@vulture /usr/local/webmin]# WEBMIN_CONFIG=/usr/local/etc/webmin/ /usr/local/etc/webmin/virtual-server/scriptlatest.pl --debug
Failed to fetch http://latest-scripts.virtualmin.com/scripts.txt : HTTP/1.1 401 Unauthorized
[root@vulture /usr/local/webmin]# fetch http://latest-scripts.virtualmin.com/scripts.txt
Authentication required for <http://latest-scripts.virtualmin.com:80/>!
Login: ^Cfetch: transfer interrupted
[root@vulture /usr/local/webmin]# wget http://latest-scripts.virtualmin.com/scripts.txt --2024-01-16 00:26:08-- http://latest-scripts.virtualmin.com/scripts.txt
Resolving latest-scripts.virtualmin.com (latest-scripts.virtualmin.com)... 45.63.20.211
Connecting to latest-scripts.virtualmin.com (latest-scripts.virtualmin.com)|45.63.20.211|:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Username/Password Authentication Failed.
[root@vulture /usr/local/webmin]#
@Ilia @Jamie shouldn’t that be going to http://latest-scripts.virtualmin.com/gpl/scripts.txt?
I don’t see code to handle that in https://github.com/virtualmin/virtualmin-gpl/blob/master/virtual-server-lib.pl
I thought we’d discussed this a while back. Surely this hasn’t not worked for all that time?
While this may still be unrelated. I noticed that even after downgrading my install back to GPL, The Webmin/Virtualmin sysinfo is reporting that I am still using 7.7 PRO. Could the scripts inability to poll updates be related to this?