Forums

Resolved
0 votes
ClearOS 7.9 has just been released to the Community and systems should update overnight tonight.

This release is a maintenance release but upstream release notes can be found at:
- RedHat for EL7.9
- Centos7.9-2009

ClearOS Apps updated:
App-base, clearos-release - for the update to 7.9
App-dhcp, app-network-map - to bring the MAC databases up to date (normally done every point release)
syswatch - trivial patch to force a DCHP Release/Renew cycle when a DHCP interface comes up.
initscripts - to track upstream

If there are any issues arising, please post them to this thread.
Tuesday, February 09 2021, 04:33 PM
Share this post:
Responses (25)
  • Accepted Answer

    Tuesday, February 09 2021, 08:29 PM - #Permalink
    Resolved
    0 votes
    is https://www.clearos.com/clearfoundation/development/clearos/announcements:releases:start still the place to look for release info? Seems to be out of date. Thanks!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2021, 08:54 PM - #Permalink
    Resolved
    0 votes
    I've no idea how to update that page, so all the information is in the first post here.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 14 2021, 08:32 AM - #Permalink
    Resolved
    0 votes
    Hi Nick,

    So far so good! The first server is a file-sever as DC and some web applications in a ESXI envoirement.
    PC's can join the domain!

    Thank you!
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 14 2021, 12:15 PM - #Permalink
    Resolved
    0 votes
    Thanks for the feedback. We did test domain joining and it worked when tested. It is a key test before a release. Samba has only gone through a minor point release rather than the major point release that it went through 18 months ago so I was not expecting anything to pop up. Not that EL7 is in its maintenance phase I am not expecting any major upstream software updates now, but obviously we'll check with every version release.

    It would be great to have more community involvement with the beta testing. The only feedback we received was to say the update instructions did not work for one poster who promptly walked away from the community. There were no other replies from anyone.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 14 2021, 08:35 PM - #Permalink
    Resolved
    0 votes
    I am in the middle of moving from old system to a new system (bought a secondhand ancient rack server) so I have 2 clearos virtual machines running on esxi, Both upgraded without issues. Or if there were issues I have not noticed them yet :-)
    The reply is currently minimized Show
  • Accepted Answer

    Monday, February 15 2021, 07:23 AM - #Permalink
    Resolved
    0 votes
    Hi Nick,

    I have 1 system with a gui and its giving this error:
    Transaction check error:
    file /usr/share/icons/hicolor/16x16/apps/firefox.png from install of firefox-78.7.0-2.el7.centos.x86_64 conflicts with file from package gconsole-60.3.0-1.v7.2.x86_64
    file /usr/share/icons/hicolor/22x22/apps/firefox.png from install of firefox-78.7.0-2.el7.centos.x86_64 conflicts with file from package gconsole-60.3.0-1.v7.2.x86_64
    file /usr/share/icons/hicolor/24x24/apps/firefox.png from install of firefox-78.7.0-2.el7.centos.x86_64 conflicts with file from package gconsole-60.3.0-1.v7.2.x86_64
    file /usr/share/icons/hicolor/256x256/apps/firefox.png from install of firefox-78.7.0-2.el7.centos.x86_64 conflicts with file from package gconsole-60.3.0-1.v7.2.x86_64
    file /usr/share/icons/hicolor/32x32/apps/firefox.png from install of firefox-78.7.0-2.el7.centos.x86_64 conflicts with file from package gconsole-60.3.0-1.v7.2.x86_64
    file /usr/share/icons/hicolor/48x48/apps/firefox.png from install of firefox-78.7.0-2.el7.centos.x86_64 conflicts with file from package gconsole-60.3.0-1.v7.2.x86_64
    Guess gconsole needs an update?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, February 15 2021, 10:07 AM - #Permalink
    Resolved
    0 votes
    This is a scary one. I can have a look at updating gconsole which is a modified version of Firefox, I believe, but it is scary as it is the normal console on the server. If the update does not work, I have no idea how to troubleshoot.. The other thing is to block the update to Firefox, if it is possible, but really gconsole should be bought up to date. I'll see what I can do.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, February 15 2021, 10:38 AM - #Permalink
    Resolved
    0 votes
    Getting messy. The instructions for updating gconsole in the repo aren't going to work. In the meanwhile, can you try a manual update:
    yum update --exclude=firefox
    If it works, it will get you going. You can then look at a semi-permanent exclude line in /etc/yum.conf but it will mean that no new user can set up the desktop, and any existing user can't upgrade until we either pull firefox from the repo or upgrade gconsole.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, February 15 2021, 10:50 AM - #Permalink
    Resolved
    0 votes
    Hi Nick,

    Switched to chrome, to be sure in future it will not give compatible issues ;-)
    All went well now!

    Thanks!
    The reply is currently minimized Show
  • Accepted Answer

    Monday, February 15 2021, 11:22 AM - #Permalink
    Resolved
    0 votes
    A nice sideways jump!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 16 2021, 08:54 AM - #Permalink
    Resolved
    0 votes
    So the changes between Firefox 60/68 and 78 are really big so it is not just simple case of applying the existing patches to gconsole to bring it up to the firefox78 release. This will need to be studied. In the meanwhile we've pulled firefox-78 from the repos.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 16 2021, 09:30 AM - #Permalink
    Resolved
    0 votes
    Hi Nick,

    Well its not so important, only 1 COS system i own is using FF ;)
    I would not make a big deal of it!

    Cheers
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 16 2021, 02:53 PM - #Permalink
    Resolved
    0 votes
    It still had to be sorted. We do have customers using the graphical desktop as it is one of the many way of managing KVM on ClearOS. This would also block their updates. It was a good catch of yours, thanks.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 21 2021, 12:41 PM - #Permalink
    Resolved
    0 votes
    I noticed that ClearOS 7.9.1 for business was released. ;)
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 21 2021, 12:57 PM - #Permalink
    Resolved
    0 votes
    Yes. There was no real fallout from the Community release so we went ahead with the paid release. We've blocked the Firefox update and removed it from the Community repos.

    I am currently prepping a bunch of other packages which could have been done for 7.9 but weren't - webconfig-httpd, webconfig-php, openldap and ppp to bring them in line with the latest upstream. More interesting is system-mysqld. It brings it in line with upstream but possibly, with a very minor change to the systemd unit file, now allows you to upgrade MariaDB without killing the system database. I won't have time to test that aspect of the upgrade until March, but anyone can test the package just to make sure it still works.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Thursday, February 25 2021, 06:35 PM - #Permalink
    Resolved
    0 votes
    I'm having some real startup issues since the 7.9 update. This is on a server that has been up and running for a few years and the update went automatically. I didn't do anything to initiate any updates.

    I thought it was just my home/test server having issues so I didn't think too much about it, but I just did a reboot of the server at work and it seems that LDAP doesn't automatically start, or at least it doesn't start in a timely manner. I finally remoted into the server with ssh and did a systemctl start slapd and after a minute, it did start. I'm going to play with this a bit more at home tonight because I can't take down a production mail server to test it.


    I'm getting this in the system log:
    Feb 25 11:30:33 mercury prestart.sh: Configuration directory '/etc/openldap/slapd.d' does not exist.



    /usr/libexec/openldap/prestart.sh hasn't changed.



    Has anyone else notice the problem?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 25 2021, 07:37 PM - #Permalink
    Resolved
    0 votes
    There has been no change to openldap from 7.8 -> 7.9. I've only just prepared the update and it is in updates-testing, so not released. It is also just a trivial patch upstream. The message you are seeing about "Configuration directory '/etc/openldap/slapd.d' does not exist." is normal. Since Centos7 is in maintenance mode we should not expect many (any?) major app changes from them. Slapd is covered by servicewatch so should try to start every 5 minutes if it is not running. If slapd does not start, it can stop winbind from starting (which is also covered by servicewatch). Perhaps look for issues in the boot log and/or messages log during boot.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Thursday, February 25 2021, 07:52 PM - #Permalink
    Resolved
    0 votes
    boot.log has a terse message:
    [FAILED] Failed to start OpenLDAP Server Daemon.
    See 'systemctl status slapd.service' for details.

    Like I said, this is a production sever, so I can't just reboot to recreate the error. I'll try my server at home.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Thursday, February 25 2021, 07:54 PM - #Permalink
    Resolved
    0 votes
    other than the directory missing error the messages log has:
    Feb 25 11:25:53 mercury systemd: slapd.service start-pre operation timed out. Terminating.
    Feb 25 11:25:53 mercury systemd: Unit slapd.service entered failed state.
    Feb 25 11:25:53 mercury systemd: slapd.service failed.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Thursday, February 25 2021, 08:17 PM - #Permalink
    Resolved
    0 votes
    I think I'm going to have to open up a different thread on this issue, but here is part of the message log from my system at home. This is a brand new system, just installed on February 18th and it worked great until the 7.9 update.

    Feb 22 11:55:58 callisto prestart.sh: Configuration directory '/etc/openldap/slapd.d' does not exist.
    Feb 22 11:57:29 callisto systemd: slapd.service start-pre operation timed out. Terminating.
    Feb 22 11:57:29 callisto systemd: Unit slapd.service entered failed state.
    Feb 22 11:57:29 callisto systemd: slapd.service failed.

    Maybe openldap hasn't changed, but something changed that is preventing it starting at boot time.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Thursday, February 25 2021, 10:20 PM - #Permalink
    Resolved
    0 votes
    In case anyone else is having a timeout problem with openldap starting on boot, what I had to do was increase the startup timeout value for slapd.
    For some reason, and I will be investigating, slapd is taking nearly 100 second to start at boot. It stops and starts instantly after boot is completed, so I suspect something else is holding it up.

    Anyway, what I did was:

    systemctl edit --full slapd.service

    Then add:
    TimeoutSec=180
    at the end of the [Service] section.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, February 26 2021, 09:03 AM - #Permalink
    Resolved
    0 votes
    Thanks for your investigations. How powerful are your machines (CPU/RAM). I know ClamAV has been getting worse and worse for RAM requirements and it did get to a stage where we were having to increase the timeout on lower spec machines. Eventually ClamAV got a new loading process which dramatically reduced start up times but its RAM requirements keep increasing. It used to run in a 1.5GB machine and won't any more. There has not been an update for ClamAV for a while now, so it has not changed either.

    I rebooted my main server a few days ago. It is quite old (Core I3-4130T, 16GB) and it came up with no problems as did my test Microserver (some 2 core AMD processor, 8GB).

    Did servicewatch (/usr/clearos/apps/base/deploy/servicewatch) kick in and try to restart it. You can check because you should see messages saying "sanity checking slapd" followed by "restarting slapd" in either the messages or system logs (I am not sure which)
    The reply is currently minimized Show
  • Accepted Answer

    Friday, February 26 2021, 11:15 AM - #Permalink
    Resolved
    0 votes
    I've just fired up my ancient server - AMD Athlon(tm) Dual Core Processor 5050e (2 core) and 4GB RAM - and slapd took ~25min to start with nothing obvious in any logs but as it has not started since testing the 7.9 community release, anacron has kicked off a load of jobs including logrotate which does a restart of slapd, so slapd probably was running OK before and just restarted after 25 min. I've rebooted it and slapd came up within a minute of the uptime monitor seeing the system as up.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Friday, February 26 2021, 02:00 PM - #Permalink
    Resolved
    0 votes
    The production server is a Dell PowerEdge R740 with 2 12 Core CPUs and 64Gb RAM, 8 SAS 2Tb drives RAID 6. My Server at home is an older Poweredge 430, with 2 8 core CPUs and 32 Gb RAM, 2 3 Tb SAS drives mirrored. Once it gets trough the self test, it starts in under 3 minutes.
    Even my home server typically completely starts, with all services running, in under 4 minutes. At least it did until the LDAP problem. Without LDAP running ClearOS is severely crippled.
    The reply is currently minimized Show
  • Accepted Answer

    Jim Shanks
    Jim Shanks
    Offline
    Friday, February 26 2021, 02:27 PM - #Permalink
    Resolved
    0 votes
    Yes, on the servers, servicewatch did restart slapd. That was before I did the timeout change. At the same time, servicewatch also restarted winbind and smb, which I would expect, because they cannot start without ldap running.
    I'm going to do a bit more investigating at home tomorrow. I'm sure the problem isn't slow computers or low resources.

    The other thing rather interesting, is that after the systems are up and running, restarting slapd takes about 10 seconds.
    The reply is currently minimized Show
Your Reply