Toggle Sidebar
News Feed
  • My bad. I did not read the post properly. Glad you have it working.

    A question on security. CIFS/SMB 1.0 is being killed off by M$ for security reasons (and performance). It looks from "man mount.cifs" that there is a "vers=" parameter where you can upgrade the version from 1.0 (default) to something higher. Samba 4 supports SMB 3.0. Samba 3.6 supports 2.0 if explicitly set using "max protocol = SMB2". Is it worth trying the "vers" parameter?

    As an aside, in ClearOS Windows Networking, if you enable Windows 10 Domain Logins, you lock the protocol to SMB1/NT1.

  • Tony Ellis
    Tony Ellis's reply was accepted as an answer

    Re: Can't mount remote share via /etc/fstab

    Nick, I don't think the manual mount would have worked without cifs-utils being already installed

    Marcel - the problem is that "defaults' doesn't standalone but should have proceeded the username with a comma..
    An example from my Fedora workstation

  • Nick, I don't think the manual mount would have worked without cifs-utils being already installed

    Marcel - the problem is that "defaults' doesn't standalone but should have proceeded the username with a comma..
    An example from my Fedora workstation

  • 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...

    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

    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...

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

    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

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

    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...

  • I always find it hard to find out what is included with which product and level of support. I'd love to see some sort of matrix so an easy comparison was possible including the cost. I know some things are wrong. I dodn't think you could even purchase the Master/Slave app in Community but it is listed here at $175/y. Note it is the same in Home but free in Business at all levels so it is cheaper to run Business Bronze than Home + Master/Slave. IDS updates cost $100/y but are included in Business Silver.

  • 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: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 upfaded 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.

  • 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.