I installed a RHEL 8 beta to grab an impression of what is coming up from the next major version and I didn’t find a samba-dc packge. After a little search I found this article:
In short it says Red Hat will not provide such package in the future because AD is complex to deploy and to support. They could reconsider their decision if the market conditions will change.
That sounds a bit scary and I’m eager to listen other opinions/experiences about
reconsidering the choice of providing and recompiling our Samba DC package by ourselves
joining other projects/people that provide (or will provide) Samba AD (e.g. starting a CentOS SIG?)
There are a few things to consider. Most of our users have Windows clients. Even I (as a true opensource advocate) understand that you can not ignore the need of support for those windows clients.
If I am not mistaken, Red Hat favors FreeIPA over Samba4.
The big question is: how will those Windows clients react in the case you switch to FreeIPA as accountprovider? I am not that familiar with FreeIPA, but only if windows clients can be fully supported, it is an option to consider this (did I just add enough ifs and maybes? just to make clear a point)
Some comment on the options you mention:
The pro’s and con’s are almost obvious: Compiling Samba DC packages will add a lot of work, not to mention risks of mistakes.
Joining other projects (either Samba4 DC or Azure) will put us in a vulnarable position that we become dependent on other parties. With Azure you can even add “free profiling” by one of the biggest datagrabbers on this planet.
At first glance I would opt for the first option: keep everything in our own hands and compile Samab4 packages ourselves. But this is for a the bigest part my gut-feeling and not based on any data or solid information. So maybe we should start getting information to make an educated decision.
In the Armonk tonight?
Ok, my puns are quite awful, but considering the recent IBM takeover of RedHat, this seems to me the first crumb for the new development path.
IBM is Apple business partner by 5 years and FreeIPA is the base of Redhat Identity Management. I think that they will cut the rope.
So AD connection interesting, but not AD replacement. Therefore, Samba4 not so interesting anymore.
Also CIFS will be replaced with other kind of file sharing tools?
Surely this is true in the past and in the present, at least in the SME world.
Yes, in summary, this is the RHEL choice. Is this the future for us too?
Does it make sense to develop an AD replacement in 2019?
What is the future of identity management? What about desktop/clients?
The support to 7 will last until June 30, 2024: do we need to provide an AD replacement in NS8 to push it forward until 2030?
I agree with this: data protection and privacy could be an issue.
Perhaps an AD SIG could be interesting for the CentOS community (and more). If CentOS provides a Samba 4 DC RPM everyone can take it and build (and support – which is more expensive) his solution.
As being “all-in-one” here leads to a complex implementation (as you might have noticed ) I’d evaluate also an alternative approach: developing a new open source project to provide AD DC in cloud and on premise. We already used this approach for Dartagnan ¹ and NethServer Subscription ².
Does it sound interesting?
Not so easy …Nextcloud is a good alternative sometimes, especially for small offices / home users. Established infrastructure are less likely to migrate to other protocols.
AFAIK, FreeIPA connects to an AD provider, it’s not a replacement.
Linux client will use FreeIPA as DC, Windows client will use directly the Windows AD.
I am not sure that CentOS people would be interested into a SIG like that. We suggested it time ago and it wasn’t accepted. We can discuss it with them at fosdem as well.
Said that
Looks hard and really time-consuming
Even if it looks like the easiest, I would avoid. They have already a lot of money
Full updates of CentOS 7 will end with Q4 2020, so end of next year. Maintenace updates and EOL will be 30.06.2024. So there is some time for a dicision, but not to much.
Maybe a dumb question, but there are samba-dc-4.9.4 pckages for fedora 29 and 30.
It looks like fedora will keep the samba-dc–option.
Is there a chance to compile this source-packages for centos?
I believe you had this idea already, but I’m interested why not.
I tried to search the differences and found some,but no one said it’s impossible.
Sono nuovo del mondo Linux, mi sono avvicinato a Nethesis principalmente perché nelle presentazioni della versione 7 si parlava del supporto a DC.
Il mondo Enterprise e in particolare quello delle PMI (nel quale mi muovo) è al 93% in mano a Windows (statistiche ufficiali di www.netmarketshare.com) e ormai per quasi il 50% su Windows 10, quindi ignorare questa realtà vuol dire restringere notevolmente il campo di azione. Non sono in grado di dire quale possa essere la soluzione, ma credo che una soluzione debba essere trovata pena l’auto relegarsi a un mercato di nicchia.
Scusate se scrivo in Italiano, ma in un blog italiano per italiani forse non è così grave, e il mio Inglese è davvero terribile, doveri usare Google translate.
I’m new to the Linux world, I approached Nethesis mainly because in the presentations of version 7 we talked about DC support.
The Enterprise world and in particular that of SMEs (in which I move) is 93% in Windows hands (official statistics of www.netmarketshare.com 3) and now for almost 50% on Windows 10, so ignoring this reality means significantly narrowing the scope of action. I’m not able to say what the solution could be, but I think that a solution must be found under penalty of being relegated to a niche market.
Sorry if I write in Italian, but in an Italian blog for Italians maybe it’s not so bad, and my English is really terrible, duties to use Google translate.
Red Hat has evaluated the RFE and came to conclusion that including Samba AD DC into Red Hat Enterprise Linux would create a significant support challenge due to complexity and broad set of the use cases that are expected to be supported by the solution. To avoid undesirable customer experience, Red Hat will not include Samba AD DC into Red Hat Enterprise Linux in any foreseeable future. Based on this conclusion this RFE is now being closed.
Red Hat acknowledges the value of Samba AD DC to Red Hat customers and welcomes partners that have targeted expertise in this area to join forces to provide an integrated Identity Management solution for heterogeneous environments that would meet the variety of customer use cases. All interested parties are welcome to contact Red Hat via available communication channels.
Based on the feedback and desire of Red Hat customers to invest into development of this technology, or if market conditions or partner integration will not be sufficient to meet customer requirements, Red Hat might reconsider its position in future.
Hello, I’m just back from FOSDEM 2019 and my pockets are full of stickers and ideas.
@robb and I met some people from CentOS, RedHat and Samba. They don’t have off-the-shelf solutions for us, but if we roll up our sleeves they can help us: that means if we test and validate new solutions they will fix the bugs.
Yes, not really new words, but I really appreciated their helpfulness, something that you can feel only when you see people face-to-face.
I try to sum up in the following table what are the macro solutions. Pros/Cons columns are just the starting points for our discussion.
id
solution description
pros
cons
all-in-one
confirm and enhance the all-in-one NS7 approach: provide the DC in a Linux Container
well-established
system complexity: hard to develop and to support
storage-sig
No Linux Container anymore. Join the CentOS storage SIG, bringing the Fedora 29 DC package to CentOS 7 and 8
become official; simple system design
experimental; a DC host can be also file server for “light” workloads only
no-dc-at-all
do not provide a DC package at all: observe the RHEL8 choice
simple to develop and support
NS8 not attractive anymore for Windows sysadmins
…
other solutions?
Every solution needs to be considered carefully and requires further analysis.
Here we have different options for the implementation
keep the actual systemd-nspawn Linux Container (filesystem + network namespace + systemd)
use buildah and podman to pack the DC ¹ in a more lightweight container (no systemd)
provide an “SCL-like” package ², which installs just the DC component under the /opt directory and runs on the same filesystem namespace. Only the IP address has its separate namespace (see ip netns).
Both “/opt” and “podman” ideas aim to simplify the development and support issues, because it’s difficult to operate on completely separate systemd machine.
… also known as the “no Linux Container” solution
The CentOS storage SIG could receive the samba-dc package of Fedora 29. They are willing to grant us access to their build system. An “official” CentOS package is likely to be more widespread and tested.
The MIT Kerberos compilation is a new feature of Samba4 and is still experimental, but could be safer in the long term because of the better support given by Red Hat to the MIT library. It also fits perfectly with the rest of the system (though Samba binaries can also locate and work Heimdal libraries ²).
smbd from the samba3 branch is the reliable and stable file server that everyone is using in NS7. But when samba4 runs as DC a different smbd process provides the file server implementation. We have to test it carefully. My proposal is to allow a DC to be also file server up to N clients. For bigger installations separate DC and file server machines must be deployed. This is what Samba recommends.
This is an hard choice. I’d avoid it for sure! But we must evaluate it anyway. As it was proposed during the NethServer Conference at FOSDEM 2019, we should collect real usage data to measure how much it would impact on NethServer adoption.
I would need also another piece of information: the commitment required for the development / test / maintenance phase of the different solutions
for example if (with min 0 max 100)
no-dc-at-all is 0/0/0 and how much could you estimate the impact on developers time of the different options?
I apologize for the silly question, and I hope I’m explaining myself. I know that it is very difficult to estimate, but just to get a rough idea of the weight that the different options would have on development. tnx
Just wanted to thank everyone on this thread for the hard work they are putting into this future issue. If I may I’d like to confirm a few things.
When potentially could the loss of AD in Nethserver become an issue, as in how many months or years could this become an issue?
If support from Red Hat was removed from newer versions, and if Nethserver cannot find a resolution, could conceivably an upgrade to a newer version of Nethserver remove Samba if it was installed or would Samba still remain but just not be upgrade? I guess I’m wondering if Nethserver modules not supported any longer are automatically removed if they are installed.
I know you are all working hard to understand this issue and find resolution. From my standpoint I’ve recently implemented Samba 4 (LDAP with AD) in our small office using Nethserver and it’s working extremely well for us. But in order that I be aware of future issues that may affect our office I’d like to understand when support by Red Hat could begin to impact our use of Nethsever as our domain controller? I’ll be keeping my eye on this thread and will let people smarter than me continue their investigation, but I would like to ensure I know when this will become critical so I can plan for mitigation if the need should arise.
) I’d evaluate also an alternative approach: developing a new open source project to provide AD DC in cloud and on premise. We already used this approach for Dartagnan ¹ and NethServer Subscription ².
Not so easy …Nextcloud is a good alternative sometimes, especially for small offices / home users. Established infrastructure are less likely to migrate to other protocols.