The CUPS print server and the graphical console are the only noteworthy applications in ClearOS that use gnutls, so the impact is quite low. Most applications use OpenSSL instead.
Red Hat has released a bug fix update (details here) and we should have the updated package in our build system shortly. These types of updates are built automatically and pushed to the "clearos-test" repository. From there, we promote the package through the updates system.
The ifcfg-eth0 filename uses eth33. The use case is unusual and certainly something that can only be accomplished via the command line. Syswatch will now honor the DEVICE parameter inside the configuration file.
So what was the bug? The syswatch network monitor only cares about the configuration of external/WAN interfaces. In the buggy 6.5.2 release, syswatch started monitoring all network interfaces! The algorithm for determining network up/down etc. didn't change at all.
Just in case, we're still investigating, but have come up empty so far.
Alexander Petin wrote: In my case it was not harmless because LAN is DHCP enabled, so the interface continue restarts every 10 secs.
Point well taken. It's fairly unusual to use DHCP on a LAN interface, but it's certainly possible. In fact, I do that on test VMs all the time!
Our apologies. The bug fix is on the way. In a couple of hours, you can install the update with:
yum --enablerepo=clearos-test upgrade syswatch
The bug certainly pollutes the log with the following:
Thu Feb 27 17:15:12 2014 info: eth1 - ping check - no gateway found
Thu Feb 27 17:15:13 2014 info: eth1 - waiting for static IP reconnect
... but it's harmless. LAN interfaces don't have gateways defined, so the LAN interfaces in the syswatch output will never be "activated".
It would be very nice to put together a more formal QA Team to catch these issues in the "updates-testing" phase. The syswatch 6.5.2 update was in that testing repo for nearly two weeks with an obvious bug, but nobody noticed (though in fairness, nobody would notice unless looking at the syswatch log). Right now, the Community Edition is taking on too much of a testing role... that's not ideal if we hope to have a stable Community Edition.
It sounds like you are running into the Intrusion Detection (Snort) netfilter issue. Snort will come along and stomp internal data structures used by the Bandwidth and QoS system. Very rude! It's hard to duplicate this problem and we're looking for opportunities to verify that the bug fix resolves the issue. If you want to give the fix a try, run:
Hello everybody. Recently i have got this error: Requested web page or file is too large, when tryed to make order in the shop. Both squid parameters: reply_body_max_size and reaquest_body_max_size are zero. What else can happened and what should i do to resolve this issue?
The ClearOS web-based interface can be used to set the "Maximum File Download Size". If you are a command line guy, the reply_body_max_size should be set to none (not 0).
Richard George wrote: Reading between the lines - and with no ETA being provided by the Red Hat/Samba 4 integration teams, it seems to me that the full addition (transition?) to Samba 4 could be some way off.
There's no official ETA, but at the same time full support seems to be available in RHEL7 Beta.
I note however, that the Samba roadmap (wiki.samba.org/index.php/Samba_Release_Planning) suggests we could be looking at EOL for Samba 3 about Nov/Dec 2014 time. If the RH/S4 team are still working at that time, would it be worth pushing for a continuation of security fixes for S3 beyond Nov?
My gut tells me that the 3.6.x series will be maintained for quite some time beyond 2014. There are a lot of NAS vendors using 3.x, and all will need a longer maintenance period. The work will be done internally by the NAS vendors (and Red Hat), or some kind of collaboration will occur. Regardless, 3.x will be hanging around for quite some time.
And there is then the big question of how to move from COS 6.5 to (projected) COS 7 (which is where, I assume S4 becomes the norm) .. will we need to reinstall?
So far, the upgrade is looking quite clean (knock on wood). The Samba 4 solution can still be configured as a simple file server / NT domain (i.e. the exact same way as it is in ClearOS 6). No Active Directory required. When playing around with ClearOS 7, the NT domain stuff worked right out of the box
Migrating from an NT-domain to Samba 4 Directory... that's another story.
Tim Burgess wrote: Hi Peter, also getting this one, it's because a newer openldap-devel package exists in clearos-addons, but the dependant updated package openldap is currently sitting in clearos-updates-testing which is usually disabled.
This is a limitation of the current build/repo system. When a package is promoted to clearos-updates-testing, the companion packages (xyz-devel) are automatically promoted to clearos-addons. We won't run into this problem with the Koji build system and it's something that we just have to live with for now. Fortunately, it's only an issue for hackers/developers.
With the build system in place and an already existing multi-architecture workflow, supporting 32-bit should be fairly low maintenance. For a variety of reasons, I don't think it's something that ClearCenter would officially support. However, we could have an unsupported 32-bit build floating around if desired.
John wrote: The 64bit version was installed with COS 6.5 ISO files from PXE.
Ahhh... that explains it. The default behavior in the upstream installer is to create a large /home partition. That's not a good default for a typical ClearOS install, of course. The ClearOS ISOs include a tweak to change this default, but the PXE images still use the upstream default.
The PXE images should be corrected by the time 6.6 rolls out. We pulled the ISO creation process out of the build system and went back to the way we it was done in 5.x. We moved the ISO creation back to the build system just a few weeks ago, so we'll be back on track soon.