Redhat has an article worth reading if you are not familiar with the practice of 'backporting fixes'.

https://access.redhat.com/security/updates/backporting

This is a good read:

https://www.clearos.com/resources/documentation/clearos/content:en_us:kb_bestpractices_vulnerabilities_overview

I'll add this to the CVE database for ClearOS but Nick's answer is spot on. ClearOS is not vulnerable to this if you are patched and up to date. It was fixed long ago.

The short answer, provided in the link above, is that ClearOS backports fixes into existing versions in order to maintain compatibility. Many pen tests and vulnerability scans do not actually test the vulnerability but rather look at the reported version number ONLY. This is what your test likely did. To satisfy a test, you simply need to rebuttal the results. Since the test fails to validate the vulnerability and answer to the auditor that states:

The current version of Apache running on this system is X (find it from command line with rpm -qi packagename) was fixed in httpd-2.4.6-45.el7_3.5.x86_64.rpm. The system is not vulnerable to the CVE specified.

Daniel,

Can you give us some info on the errors in the logs. There were some bug fixes that resolved this but if it is still down for you we need to reproduce and replicate the error. So I need to either affirm in your logs that it is the same or see what is different.

I've already apprised the lead dev on this at ClearCenter so he will look for your reply in this thread.

Thanks for reporting your issue.

UPDATE:

Nick and I have found a method for doing the IP addressing on the docker image that might work. While I was working on other things inside the samba migration path, Nick was working on how to get the addressing compatible between ClearOS and the docker image. He hit a brick wall after exhausting some methods and even exhausting and proving that some of the items I thought might work were untenable. In the end, this left a limited set of options and I tried the stupid and simple one, which failed initially but then found that it would work with a restart of the docker daemon itself.

So with that daemon defeated, we are ready to put it together. The big thing that is left is the Samba Directory to Samba Directory artifacts migration. I've got a busy day today but will hit try and put some end to end testing together tonight and see if we can't come up with a comprehensive howto by the end of the weekend.

Thanks for your input Tony. We do truly value your input and participation in the community. There are so many things that exist at a lower priority than the forums. It is not the last thing on our mind, not by a longshot.

The original website was released in 2009 and then it was revamped in 2014. About every 5 years is what we can afford to muster when it comes to a full refit so it is about time and things ARE lining up for that anniversary refit. So yeah, it is an understatement to say it is long in the tooth.

Now is the time to be very involved as we work on the plan to switch. If you know of a forum technology that will work well, let us know your preference. Here is what we are looking for:

- Must support OAuth
- Must be amenable to a authentication transplant.
- Must be able to migrate old posts and allocate ownership of posts to original post makers.
- Must be able to use BOTH usernames and usernames based on email addresses (similar to GItlab and others)
- Must support CSS stylization.

There are a bunch of desirable things, some of which you mention:

- Better CAPTCHA
- Optimal loading
- Elasticsearch
- Bug escalation mechanism and resolution integration
- Feature request integration

I know that the captcha is there for new users but it shouldn't bother existing accounts. I'll look into it.

I don't like the forum software either but we implemented it at a time when we were trying to get other things integrated. We've been so focused on innovations (GLASS VM Minebox, others) and some significant 'big projects' that the forums have not gotten the TLC that they need. There are going to be some changes that will eventually reach the forums that are on the roadmap, and changing out the forums is part of that roadmap so let me cover where we are and what is on the short-term docket.

- For those who have noticed, ClearVM 2.0 now uses the ClearSDN for authentication. While this doesn't affect forum users (yet), it is worth noting since it is a milestone for changes coming to the forums. We are working towards collapsing authentication across forums and the SDN. In the future, only your SDN account will remain and the forums will be subordinate to that. That makes for a bit of a 'historical post' mess with the data. We are working through that.
- Documentation is changing. Unless you develop apps for ClearOS, you may not have noticed that we have transitioned from Github to Gitlab with the repos now here: https://gitlab.com/clearos . Along with this, gitlab has tight integration with bug tracking and with documentation which we plan to leverage. Ultimately, the bug tracker and milestones will go there as well as documentation which is using 'markdown' instead of 'dokuwiki'. To begin, documents associated with application development are moving there. Ben has been working hard to make this a reality and if you are interested in developing apps for ClearOS, the process is getting easier and easier at a rapid pace. Soon we will have the ability to make the documentation for an app directly associated with the project. This will allow an application maintainer to ALSO maintain their documentation without the convoluted process we have today for documentation.
- The websites are being reworked. One thing that is also happening is that the number of pages for 'all things ClearOS' are going to become more simple and less of them. The new direction is 'simple' and 'to the point'. This work also includes the forums but the forums is quite a bit more complex as well.

That would require a highly customized docker. I'll look into whether or not this is possible to do the inline restore with existing docker images but I kind of doubt it. Typically those docker images are preloaded with "The NEW Install" paradigm. Essentially the following things have to happen on the 'staging' VM/image:

1) Validate that it has the samba and samba-dc packages in addition to the typical samba packages
2) Setup OpenLDAP (which you would want removed from your eventual docker image
3) Configure, import, and validate that it is running in a similar manner in order to be accessible by your current smb.ldap.conf
4) Run the samba-tool classic upgrade against the running slapd and flattened smb.conf.old config

When I did this I still ran into errors but my directory seems intact. But the fact that OpenLDAP is required for the migration is a big 'showstopper' for an elegant transition since you wouldn't want it at ALL running in your ideal endpoint. That being said, there is no need to torture everyone by making them jump through this hoop solo. The ideal thing to do here is to:

a) provide the VM via FTP to everyone to use with simple instructions.
b) provide individuals access to a hosted and snapshot version so that they can use the image like a time share.
c) provide individuals with a method in support where they simply send their configuration backups and we provide them with the outcomes.
d) provide individuals with the exact steps in the 'open source' model so they can do it all themselves if they so desire.

But the correct answer here is likely...

e) all of the above. Let them decide.

SIDE NOTES: I'm having trouble with the group import currently. I failed to import any group memberships even though it imported all the group names. The failure was with the 'flexshare' group name and I believe it fails because it is the same name as the flexshare users which is strictly prohibited. When I refine the steps, I'll contend with this and see if I get different results. Secondly, my workstation (previously joined to the old domain) can log in using cached credentials but cannot complete the login with another user ('no logon servers'). It can also use the RSAT tools to see the domain but since group membership import was broken, is not able to manipulate things.

For those of you following along at home, our evolving steps (distilling old, failed methods and current paradigms) are located here:

https://docs.google.com/document/d/1-qH3pIcVKxO2Qf43jzfJV5LIPaqLkM7qGoWpmRxZBL8

Lastly, the reason for Fedora and not ClearOS is because I cannot traverse Kerberos mismatch properly due to upstream inadequacies in support for DC mode for Samba Directory. The samba-tool, for example, doesn't exist properly which prompted me to go the Fedora route.

Hey,

I wanted to give you all an update of where we are with creating a workaround for the Samba/Windows 10 issue. One of the difficult barriers is the total lack of upstream mechanisms. There are various reasons for this but the short answer is that there isn't good support upstream for Samba Directory (which solves the issue totally). Redhat has their reasons for this but it may be until RHEL 8 that there is domain controller support upstream. For example, you can follow this guide:

https://wiki.samba.org/index.php/Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)#LDAP

But you will get stuck with the fact that there isn't a samba-tool program in upstream which will require you to build Samba from source and then you will have a host of incompatibility problems. So that represents several development tracks that we have worked on and attempted. In the end, it isn't elegant.

My next attempts will focus on getting an existing directory to a docker container. The idea is this, since Samba Directory cannot be made to work well because of upstream, we will containerize the Samba Directory and then use the very stable AD Connector method. This means that that there are two development tracks...

1) The NEW install.

This install looks like this. Install ClearOS, fire up a docker image of a Samba Directory. Install the AD Connector module and connect it to the docker image. The dev that has to happen here is:

- Docker Samba Directory running on its OWN IP address
- If we can get this docker to work, it is preferred: (https://github.com/dperson/samba)

2) The migration

This is tricky. We want to end up in the same state as the 'NEW install' paradigm. To get there we have a full list of problems

- Exploring the migration of the domain off of ClearOS and then onto a Fedora VM with working Samba Directory
- From there either 1) create a way to backup the Samba Directory domain for use by the docker, or 2) join the docker image domain to the migrated domain then decommission the Fedora VM.
- Validate the domain
- Uninstall the DC from ClearOS and move to AD Connector.

If anyone wants to assist here. I will be focusing on the Samba elements so if you know docker and can point me to making the dperson image work on an alias LAN IP address in ClearOS, that would be very useful to me.

ClearOS 7.5 General Release (Community, Home, and Business)

ClearOS 7.5.0 has been generally released. You can read more about this release on the release notes page here:

https://www.clearos.com/resources/documentation/clearos/content:en_us:announcements_releases_clearos_7.5.0_general_release_information

Please post any issues related to this release here.

If you have any issues remaining that were addressed in the Community Release Announcement thread, please transfer those topics here.

For sure this bug is triggered by an update but since only a few are affected, it is hard to know the cause. We have also not been able to reproduce the bug and since the workaround is to not update for those affected, we cannot troubleshoot it without willing participants. Without more data we may not be able to move forward with any fixes for those affected and they will, unfortunately, be resigned to a state of not being able to get updates.

The weekend will afford those using Community in business environments to please move forward and apply the update so that we can troubleshoot the issue. If you are willing to work personally on the issue, please submit a ClearCARE support ticket (preferably with remote credentials) and reference this article. We are not opposed to running a different build of OpenLDAP if that is required but this bug is getting stale without a resolution in site.