Yes Nick, was somewhat surprised when my daily "download only" yum command indicated a large number of rpms available for install including this which has broken my file sharing for Windows clients when installed; 7.4 wasn't a problem... Linux clients can still connect to the shares OK... off now to watch some motor sport, NASCAR and F1... and agreed ClearOS communication is definitely getting worse... perhaps they feel the Community users are not so important to them any more and can be more often ignored, though Ben (thanks Ben) still pops in here regularly...

[root@karien ~]# grep samba /var/log/yum.log

Jul 07 07:56:44 Updated: samba-common-4.7.1-6.2.v7.noarch

Jul 07 07:56:48 Updated: samba-common-libs-4.7.1-6.2.v7.x86_64

Jul 07 07:56:49 Updated: samba-client-libs-4.7.1-6.2.v7.x86_64

Jul 07 07:56:49 Updated: samba-libs-4.7.1-6.2.v7.x86_64

Jul 07 07:56:49 Updated: samba-common-tools-4.7.1-6.2.v7.x86_64

Jul 07 07:56:49 Updated: samba-4.7.1-6.2.v7.x86_64

Jul 07 07:56:56 Updated: samba-dc-libs-4.7.1-6.2.v7.x86_64

Jul 07 07:56:56 Updated: samba-winbind-modules-4.7.1-6.2.v7.x86_64

Jul 07 07:56:56 Updated: samba-winbind-4.7.1-6.2.v7.x86_64

Jul 07 07:57:47 Updated: 1:app-samba-extension-core-2.5.0-1.v7.noarch

Jul 07 07:57:50 Updated: samba-client-4.7.1-6.2.v7.x86_64

Jul 07 07:57:51 Updated: samba-winbind-clients-4.7.1-6.2.v7.x86_64

Jul 07 07:57:51 Updated: samba-dc-4.7.1-6.2.v7.x86_64

Jul 07 07:58:03 Updated: samba-python-4.7.1-6.2.v7.x86_64

Good and bad. I'm glad it is working and thanks for your help with debugging MultiWAN the issue.

Bad because it looks like 7.5 has gone final without an announcement. I missed the meeting on Thursday so I don't know if the decision was taken then to release 7.5, but I would have expected an announcement to the forums. I'll ping Dave but it is 1.30 am there.

Just installed 78 new rpms that have been released since the initial Beta 7.5 install, one of which was a newer kernel... One or more these rpms have fixed my Multi-WAN problem with the Beta - can now run with one static external interface and the other dynamic...

Sat Jul  7 13:24:46 2018  info:  system - syswatch started

Sat Jul  7 13:24:46 2018  info:  config - IP referrer disabled in multi-WAN

Sat Jul  7 13:24:46 2018  info:  config - IP referrer tool is installed

Sat Jul  7 13:24:46 2018  info:  config - debug level - 0

Sat Jul  7 13:24:46 2018  info:  config - retries - 3

Sat Jul  7 13:24:46 2018  info:  config - heartbeat - 15

Sat Jul  7 13:24:46 2018  info:  config - interval - 20 seconds

Sat Jul  7 13:24:46 2018  info:  config - offline interval - 10 seconds

Sat Jul  7 13:24:46 2018  info:  config - referrer IP detection - disabled

Sat Jul  7 13:24:46 2018  info:  config - ping server auto-detect - enabled

Sat Jul  7 13:24:46 2018  info:  config - try pinging gateway - yes

Sat Jul  7 13:24:46 2018  info:  config - number of external networks - 2

Sat Jul  7 13:24:46 2018  info:  config - monitoring external network - enp0s9f1

Sat Jul  7 13:24:46 2018  info:  config - monitoring external network - enp0s9f0

Sat Jul  7 13:24:46 2018  info:  config - number of standby networks - 0

Sat Jul  7 13:24:46 2018  info:    info - loading network configuration

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f1 -  config: ifcfg-enp0s9f1

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f1 -  onboot: enabled

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f1 -    type: static

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f1 -    wifi: disabled

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f1 - gateway: 192.168.0.1

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f0 -  config: ifcfg-enp0s9f0

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f0 -  onboot: enabled

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f0 -    type: dhcp

Sat Jul  7 13:24:46 2018  info:    info - network configuration for enp0s9f0 -    wifi: disabled

Sat Jul  7 13:24:46 2018  info: enp0s9f1 - network - IP address - 192.168.0.28

Sat Jul  7 13:24:46 2018  info: enp0s9f1 - network - gateway - 192.168.0.1

Sat Jul  7 13:24:46 2018  info: enp0s9f1 - network - type - private IP range

Sat Jul  7 13:24:47 2018  info: enp0s9f0 - network - IP address - 192.168.4.28

Sat Jul  7 13:24:47 2018  info: enp0s9f0 - network - gateway - 192.168.4.1

Sat Jul  7 13:24:47 2018  info: enp0s9f0 - network - type - private IP range

Sat Jul  7 13:24:47 2018  info:  system - changing active WAN list - enp0s9f0 enp0s9f1 (was startup)

Sat Jul  7 13:24:47 2018  info:  system - current WANs in use - enp0s9f0 enp0s9f1

Sat Jul  7 13:24:47 2018  info:  system - restarting firewall

Sat Jul  7 13:25:18 2018  info:  system - dynamic DNS updated

Sat Jul  7 13:30:20 2018  info:  system - heartbeat...

Yes, sad to see 6.x go - gradually updating all my machines (except a very few that don't support 64-bit)
In my case having the older drivers on the other machine (alex) meant that I could re-create the necessary directories and copy them from one machine to the other.. Thus was able to add the older drivers back to 'pamela'. Booting into the older 7.4 kernel and using the following commands brought the via-rhine NIC up...

[root@pamela ~]# insmod /usr/lib/modules/3.10.0-693.17.1.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

[root@pamela ~]# ifup enp0s18

So can now boot between kernels on pamela without having to re-install drivers each time... So if booting to an older kernel is important to some-one, then saving the older driver .ko files and restoring them after the upgrade would save time and allow easier transition between kernel booting...

Hi Tony,
We were aware of the risk at the time 7.4 was released that there may be no way to boot to an older kernel. The kmod-r8168 package is slightly modified from ElRepo's version so it does not blacklist the r8169 driver. The intention of this was that if you booted to the older kernel, at least the stock r8169 driver would load against the r8168 NIC.
When ElRepo produced specific 7.4 upgrades they changed the spec file which is why the files all appear as el7_4.elrepo.rpm. Previously it would pick up the %dist parameter from /home/build/.rpmmacros. That way mine were always .clearos7.njh.rpm. I wonder if this change is why specific 7_4.elrepo ones have survived and others have not. There may be other changes to the spec file as well, but I have not investigated.

It is a real pity because in EL6, Redhat hardly ever changed the kernel ABI and I perhaps remember recompiling only once or trice over the whole 6.x cycle. Now with EL7 they appear to be changing with each point release which introduces these issues. I think some of the change was the introduction of a retpoline enabled compiler for the Spectre/Meltdown issue.

Just upgraded another server to 7.5
Interesting difference between the kmod r8169 and kmod via-rhine... kmod r8169 from the ClearOS upgrade, kmod via-rhine from Nick's site...

After the upgrade booting into the new kernel - we see this

[root@pamela ~]# locate r8169.ko

/usr/lib/modules/3.10.0-514.26.2.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko

/usr/lib/modules/3.10.0-693.11.6.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz

/usr/lib/modules/3.10.0-693.17.1.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz

/usr/lib/modules/3.10.0-693.2.2.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz

/usr/lib/modules/3.10.0-862.3.2.v7.x86_64/extra/r8169/r8169.ko

/usr/lib/modules/3.10.0-862.3.2.v7.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz

[root@pamela ~]# locate via-rhine.ko

/usr/lib/modules/3.10.0-862.2.3.el7.x86_64/extra/via-rhine/via-rhine.ko

/usr/lib/modules/3.10.0-862.3.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

The old via-rhine kmod drivers are gone meaning that we cannot reboot to an older kernel and have all the NICs working upon reboot...
Confirmed this with a reboot to an older kernel...) The bridge got burnt this time
Looking in the yum log we can see the previous versions...

/var/log/yum.log-20180222:Mar 13 12:14:37 Installed: kmod-via-rhine-1.5.1-1.v7.x86_64

/var/log/yum.log-20180222:Sep 27 16:09:06 Installed: kmod-via-rhine-1.5.1-2.v7.x86_64

/var/log/yum.log-20180222:Oct 01 12:45:46 Installed: kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64

/var/log/yum.log:Jun 24 15:32:09 Updated: kmod-via-rhine-1.5.1-3.el7_5.elrepo.x86_64

This is different to the last upgrade where the older kmod via-rhine driver was retained...

[root@alex ~]# locate via-rhine.ko

/usr/lib/modules/3.10.0-693.17.1.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

/usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/via-rhine/via-rhine.ko

/usr/lib/modules/3.10.0-862.2.3.el7.x86_64/extra/via-rhine/via-rhine.ko

/usr/lib/modules/3.10.0-862.3.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

No idea why the difference - but does serve as a warning to make sure you have the older driver available if you have a need to boot into an older kernel...
The only way to restore NIC use under the 7.4 kernel

[root@pamela ~]# yum downgrade kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64.rpm

Loaded plugins: clearcenter-marketplace, fastestmirror

ClearCenter Marketplace: fetching repositories...

Examining kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64.rpm: kmod-via-rhine-1.5.1-3.el7_4.elrepo.x86_64

Resolving Dependencies

--> Running transaction check

---> Package kmod-via-rhine.x86_64 0:1.5.1-3.el7_4.elrepo will be a downgrade

---> Package kmod-via-rhine.x86_64 0:1.5.1-3.el7_5.elrepo will be erased

...

This allows us to install the via-rhine driver and bring up the NIC under the older kernel. We now have this...

[root@pamela ~]# locate via-rhine.ko

/usr/lib/modules/3.10.0-693.11.6.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

/usr/lib/modules/3.10.0-693.17.1.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

/usr/lib/modules/3.10.0-693.2.2.v7.x86_64/extra/via-rhine/via-rhine.ko

Of course, rebooting to the 7.5 kernel means we have to install the 7_5 driver yet again and back to the 7.5 driver only...

[root@pamela ~]# locate via-rhine.ko

/usr/lib/modules/3.10.0-862.2.3.el7.x86_64/extra/via-rhine/via-rhine.ko

/usr/lib/modules/3.10.0-862.3.2.v7.x86_64/weak-updates/via-rhine/via-rhine.ko

Nick Howitt wrote:

Yumdownloader downloads the rpm into your working directory so you can inspect it. Being a luddite, I drag it to my Windows desktop and open it with 7z, doubleclick on the cpio file and then again on the "." file and from there you'll see the layout and files in the rpm.

Also from your working directory in ClearOS you can look at the install scripts with:

rpm -qp app-base-core-2.4.24-1.v7.noarch.rpm --scripts

Note I've found you also need to look in app-base-core and you can follow the upgrade script. The script does a load of manipulation of various files and the rpm contains updated yum-repos-d definitions.

I've suddenly remembered there is another dependency, clearos-release, which comes down when you update app-base, and this is the rpm which sets the ClearOS release number.

Ah I see. Interesting going to play bit!

What is the clearos-release app-base?

Y'all figured it out! It's all about updating the various /etc/yum.repos.d/ yum configlets to point to the 7.5 versions, or tweaking the yum exclude lists.

Yumdownloader downloads the rpm into your working directory so you can inspect it. Being a luddite, I drag it to my Windows desktop and open it with 7z, doubleclick on the cpio file and then again on the "." file and from there you'll see the layout and files in the rpm.

Also from your working directory in ClearOS you can look at the install scripts with:

rpm -qp app-base-core-2.4.24-1.v7.noarch.rpm --scripts

Note I've found you also need to look in app-base-core and you can follow the upgrade script. The script does a load of manipulation of various files and the rpm contains updated yum-repos-d definitions.

I've suddenly remembered there is another dependency, clearos-release, which comes down when you update app-base, and this is the rpm which sets the ClearOS release number.

I did a yumdownloader app-base but it just checks the repos and then nothing.. I'm not sure what you trying to say/explain in the first rule of your post. Everything else is clear. Thanks for that info.

Do a "yumdownloader app-base" then try to work it out!

I've tried and failed. It contains the shutdown widgit and the first run wizard.

I thought it also controlled the release number so would bump the release to 7.5 and allow yum to use the 7.5 channel of clearos-centos, but I don't see where it does it. That is why it has to be run first otherwise ClearOS points to the wrong clearos-centos channel and the update fails with dependency errors.

Installed ClearOS 7.5 Beta in a VM with success.

Nick Howitt wrote:

ClearOS 7.5 is now available to download from the updates-testing repo. If you would like to try it out, please run the following commands:
[code]yum --enablerepo=clearos-updates-testing upgrade clearos-release app-base
yum --enablerepo=clearos-updates-testing upgrade[/code
[/edit]

What is the clearos-release app-base? Do we see this in the webgui or is it a underlying code?

Another kernel panic on boot in my VM which I was unable to capture.

Tony Ellis wrote:

... snip ...

Jun 10 16:56:51 alex firewall: Error: /usr/clearos/apps/firewall/deploy/libmultipath.lua:56: bad argument #3 to 'format' (string expected, got nil)

Many thanks Tony. We're on it.

I'm getting two firewall start failures, one for docker and one for wpad. The log from "firewall-start -d":

firewall: Execution time: 0.369s

firewall: Running post-firewall: 110740

firewall: Running /etc/clearos/firewall.d/custom

firewall: Running /etc/clearos/firewall.d/local

firewall: Running /etc/clearos/firewall.d/10-docker

Device "docker0" does not exist.

iptables v1.4.21: host/network `!' not found

Try `iptables -h' or 'iptables --help' for more information.

firewall: Running /etc/clearos/firewall.d/10-snortsam

firewall: Running /etc/clearos/firewall.d/10-wpad

iptables v1.4.21: host/network `.  . ' not found

Try `iptables -h' or 'iptables --help' for more information.

iptables v1.4.21: host/network `.  . ' not found

Try `iptables -h' or 'iptables --help' for more information.

firewall: Running /etc/clearos/firewall.d/90-attack-detector

Docker was not running. If I start docker the docker error goes.

There is not an option to start wpad. Looking at /etc/clearos/firewall.d/10-wpad, it looks like $exempt_ip is returning a blank and even if it returned something, the parameter after -s would be meaningless, because " . $exempt_ip . " needs to evaluate to an IP, subnet or resolvable FQDN.

Also this morning I had a kernel panic and halt during the booting of a VM. I tried and failed to get a screenshot and the logs failed to show anything.

Peter - email sent - most interesting was this... repeated over and over again...

Jun 10 16:56:51 alex firewall: Synchronizing multipath routing tables...

Jun 10 16:56:51 alex firewall: Loading environment

Jun 10 16:56:51 alex firewall: Detected WAN role for interface: enp0s9f0

Jun 10 16:56:51 alex firewall: Detected WAN role for interface: enp0s9f1

Jun 10 16:56:51 alex firewall: Detected WAN backup role for interface: enp0s9f0

Jun 10 16:56:51 alex firewall: Detected WAN backup role for interface: enp0s9f1

Jun 10 16:56:51 alex firewall: Detected LAN role for interface: enp0s10 

Jun 10 16:56:51 alex firewall: Error: /usr/clearos/apps/firewall/deploy/libmultipath.lua:56: bad argument #3 to 'format' (string expected, got nil)

Tony Ellis wrote:

...
After re-booting after the upgrade the firewall immediately went into panic mode and refused any attempts to rectify...

Do you happen to have the screen or log output from the firewall panic? If so, please forward it to developer@clearfoundation.com.

Thanks.

So far a upgrade on a simple inside/outside routed system - everything seems ok. Glad to be on the 3.10.0-862.x.x (3.10.0-862.3.2.v7) kernel series.

Thanks Nick - you will see my box is running at 100% CPU

Asked about testing as was wondering if this MultiWan issue was a known problem, and hence would not waste any more time on it...

ClearOS used to provide details with a Beta release - and list known problems... However, a check of https://www.clearos.com/clearfoundation/development/clearos/announcements:releases:start shows the information there is woefully out-of-date - nobody at ClearOS can be bothered with updating it?

Hi Tony, That is not so good! I released the announcement on behalf of the devs and I don't know what testing they've done. On my side I've upgraded two play VM's and a test box, but I don't have your facilities. I only have a single external connection and can't easily stress my test box. The VM's are irrelevant as I have them with NAT's NIC's to my desktop on 127.0.0.1 and funny ports. I've had one boot failure on a VM and had to reset it.

I'll mention your issue to the devs, but I hope they are following the thread anyway.

Nick a result for you - just updated a test server to ClearOS 7.5

Install    2 Packages (+27 Dependent packages)

Upgrade  419 Packages

Remove     2 Packages

Total download size: 673 M

One major problem - multiwan
This machine through 6.x and 7.x (up-to 7.4) has run successfully with two external interfaces
1) cable modem - static 2) ADSLl2+ modem dynamic
After re-booting after the upgrade the firewall immediately went into panic mode and refused any attempts to rectify...
As a test removed using webconfig the interface to the ADSL modem - no firewall panic
Re-added the ADSL interface using a static address - no firewall panic
Changed ADSL interface back to dynamic - immediate panic...
Nothing to do with kmod drivers as both these external interfaces are Intel e1000...
Have resorted to static at the moment so the machine can do a 'soak' test..

Not good - was this configuration tested? - and don't have any more time to chase this at the moment...

On the kmod front - this machine used the kmod-r8169 and kmod-via-rhine drivers on 7.4
The kmod-r8169 updated OK with the upgrade and used the kmod-via-rhine 7.5 driver from your site Nick - saved me time to compile - thanks
Both interfaces came up OK after the re-boot with the new kmod drivers...
Also a nice surprise - re-booted back to the previous 7.4 kernel - and both older kmod drivers were still on the system and the interfaces all cam up OK - so no "burnt bridges"

Note that this system, like all mine, is not 'typical' ClearOS installations
1. No flexshares or ftp
2. No dnsmasq - use bind and the dhcpd from ISC
3. Samba is not configured the "ClearOS way'
4. No paid apps
5. Several hundred rpms over and above the base ClearOS install
6. Monitoring tools are mostly 'home-grown'
7. Extensive changes made to numerous configuration files
8. Use home-grown attack-detector - the ClearOS one is too resource heavy for my systems

Will re-append with any additional information as a result of prolonged testing over the next day or two...

Edit: This machine can be seen at this url - http://www.sraellis.tk/frame.php?number=28&monitor=alex_sysconfig

Great news Nick.

[EDIT: the yum issue has been solved and I'm upgrading now.]

EDIT 2: this beta version has been working as a gateway for my home's network for 24 hours. I have no issues and everything seems to be working well so far.