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.
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.
Share this post:
Responses (25)
-
Accepted Answer
is https://sfj48-fkj200.heiksthsd.cf/clearfoundation/development/clearos/announcements:releases:start still the place to look for release info? Seems to be out of date. Thanks! -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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. -
Accepted Answer
-
Accepted Answer
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? -
Accepted Answer
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. -
Accepted Answer
Getting messy. The instructions for updating gconsole in the repo aren't going to work. In the meanwhile, can you try a manual update:
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.yum update --exclude=firefox
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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. -
Accepted Answer
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? -
Accepted Answer
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. -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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. -
Accepted Answer
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. -
Accepted Answer
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) -
Accepted Answer
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. -
Accepted Answer
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. -
Accepted Answer
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.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »