I think this case has been resolved by re-install dnsmasq
yum remove dnsmasq
yum install dnsmasq app-dhcp app-dns
I am not sure with this case, probably after install ClearOS V66, I found a black screen and default IP Address is dhcp so the server can not be accessed to run setup wizard. then I think it would be easier if there is a dhcp server, so I connect it to the other ClearOS server witch I have testing for wpad configuration to get dhcp IP address, all running normally until the configuration is complete.
after the ClearOS is installed in the network and all clients are connected, avast alerts appear on all clients.
The error is triggered by a Samba SID cleanup script. In this particular case, it's harmless but I would still like to get to the bottom of it. Could you create the following test script (e.g. in /tmp/mytest.php):
// B O O T S T R A P
Many thanks Fred! FYI: Fred also provided us with updated ffmpeg and x265 RPM spec files. I have been able to get a variant built in our development (mock) environment, so we should be able to get things going through the build system soon.
The 2.6.32-431 series (RHEL6.5) was not the best kernel series. We held it back on the Professional Edition for quite some time and ended up supplementing it with newer drivers. The 2.6.32-504 series (RHEL 6.6) seems to be much much better so far.
1777 should be the permissions for both /tmp and /var/tmp. Over the years, I have seen "spontaneous" permission changes on /tmp (on vanilla CentOS). It's probably some update script buried somewhere in an RPM doing something like "chmod 755 /tmp/$my_variable_filename" but "$my_variable_filename" is empty. That's speculation though.
Here's more information on the crappy 6.6.0 update.
The underlying OpenLDAP engine was upgraded from 2.4.23 to 2.4.39. Inside the OpenLDAP RPM, there's an upgrade script that converts the existing LDAP database to the new version. The good news is that the upgrade works. The bad news is that in some circumstances (which we haven't determined), files in /var/lib/ldap are left with incorrect permissions and LDAP will refuse to start. In ClearOS 5, the startup script would automatically fix these permissions issues -- we ported that feature to ClearOS 6. That update will be hitting the repos shortly. In the meantime, you can run:
chown -R ldap.ldap /var/lib/ldap
service slapd restart
service nslcd restart
service nscd restart
Network API and LDAP
In a bid to get rid of some duplicate code, the OpenLDAP startup script started using the Network API. If you had all of the following configured, the LDAP server would refuse to start:
- The network running in Standalone Mode (Standalone - No Firewall is not affected)
- Both an External and LAN interface defined
- The Directory Server configured to allow connections from the LAN (default is localhost only)
The quick workaround: go to "Server -> Directory Server" in the menu and set the Publish Policy to either i) Not Published (localhost) or ii) All Networks
The update to resolve this issue is also on its way to the repos.
Network Vendor Info
The network vendor information detection was also causing some parsing grief. This update was already pushed to the repos and is available.