Getting to Samba 4
The Samba 4 code has been worked on for over five years, and the Active Directory code is reaching a state where it's being run in production at several test sites.
When the Samba Team met at the CIFS conference this year, we had a meeting to put together a plan for shipping a production Samba 4 code-base. Here's how we think it might work.
Currently, the Samba 3 file and print server and the Winbind identity mapping code are the backbone of the current Samba product. The Samba 3 Windows NT4 compatible Domain Controller works well, but is not as widely deployed as it used to be (there are few sites left that don't use Active Directory functionality).
So in brief, the plan is to merge the Samba 3 file server and winbindd code with the current Samba 4 Active Directory code, to produce a product that contains a production file and print server, identity mapping service, and Active Directory compatible Domain Controller. The file server is now fully cluster aware, with complete Windows semantics and is currently being extended to include the new SMB2 protocol and full Windows ACL support.
Obviously this will require quite a lot of merge work, but we believe this may be possible to achieve in 2010. The plan is to keep shipping updates to Samba 3 (the next release is 3.5.0, followed in six months by 3.6.0 and so on), whilst the merge work with the Samba 4 Active Directory code is done in the background. Once we feel we have a stable code-base we will release the merged code as the "production" Samba 4 tree.
This way people with an existing Samba 3 production product or sites will have a stable and predictable upgrade to the Samba 4 release. Our goal is to keep the code-base stable and minimize the impact of these changes on our users and vendors.
We'll probably end up renaming the component products as follows :
o Samba 3 file and print server -> Samba file and print service.
o Samba 3 winbindd -> Samba identity service.
o Samba 4 Active Directory -> Samba Directory service.
Please give us feedback on these plans. After all, we're here to serve our users and customers. We think with this plan we should be able to please at least some of the people some of the time (if not everyone :-).
Once we have a merged code-base, we'll declare victory, ship Samba4 and have the biggest darn release party since Duke Nukem Forever shipped and revolutionized computer gaming ! :-).
Explaining Release Schedules
In talking to Samba users, customers and OEM's creating products based on Samba, I've realized that many people don't understand what our release schedules look like, or what versions of Samba we support.
Our current plans are to release a new "stable" version of Samba (a "dot release" after the 3) every six months. This goal is to be predictable, in the same way that Linux distribution release cycles are predictable. The number after the second dot is the minor (bugfix) release of that six monthly cycle.
So for example, our current "stable" version of Samba is 3.4.3 - this is the third minor bugfix release of the six-monthly release 3.4.0. We're ironing out the final show stopper bugs in 3.4.4 and are hoping to release the fourth bugfix release soon.
At the same time we also maintain bug fix (minor) releases of the previous "stable" version of Samba. This is currently 3.3.9 (3.3 was the six monthly release of the last cycle, and there have been nine minor bug fix releases of this code).
These versions shouldn't be thought of a major new revisions of the Samba code (that'll come in Samba 4), but as a continuing release stream, with the new features and bug fixes that are developed being stabilized for production use every six months.
Earlier versions of Samba (the 3.2.x code stream, currently at 3.2.15) are now in security update only, no new bug fixes or enhancements added, we are just fixing security bugs reported.
Samba 3.0.x is now officially deprecated, and no new security updates will be provided by the Samba Team. Note that vendors who have this version in their distributions have different long-term maintenance policies, and we are happy to work with them on maintaining these older versions, but no new "official" Samba Team releases will be done for this codebase. If you have products based on these older versions, and need security help or have discovered a security issue, please contact us and we'll work with you to help you identify back ports for any fixes you might need.
Our release planning schedules are available on the web here:
Hopefully this makes our release schedules and policies much clearer, and leads nicely into our next topic..
Working with Samba in your product
Samba is used in a great number of file server products shipped by many companies around the world. The Samba Team loves this. In fact it's one of our great points of pride in our code that it's so widely embedded in different vendors products.
If you're using Samba in your product, or even just *thinking* of using Samba in your product - PLEASE CONTACT US ! We don't bite, and our goal is to make Samba more useful to you and help it work better for you and your business.
Whilst we are Free Software advocates ourselves, we won't preach at you to release any of your proprietary code that isn't part of changes to Samba, and we already work with many vendors of proprietary code to make Samba work better for their particular platform or product (many of the Samba Team make our living this way).
If you work with us, you will get bug fixes for free, advice on architecture and performance help and many other advantages that the people who wrote the code can offer, simply at the cost of reaching out and sending us an email. Working closely with us also means that changes you need for your product will get merged into the mainline codebase, saving you the expense of having to keep a separate series of patches that has to be merged when you upgrade to a new release. Many of your Samba using competitors are already doing so and getting this service - don't miss out !
Many of the Samba Team members have a lot of experience in implementing Samba in high availability, high scalability, and complex network environments. By working with us you help support everyone who works within the Samba community and also help keep the Samba code flexible, efficient and customizable to your needs.
Send an initial contact email to Jeremy Allison (email@example.com) and I'll work with you on finding the right Samba Team member to help you out with any issues or help you might need.
In the three months since the last team blog entry, there has been a lot of development activity in the area of the clustered Samba server. Clustered Samba here refers to the coupling of Samba with CTDB, the clustered implementation of TDB, the "Trivial DataBase" of Samba, which is Samba's cluster manager.
Several internal subsystems of CTDB have been reworked. For example Ronnie Sahlberg and Wolfgang Mueller-Fried have greatly reduced the CPU used by CTDB. Stefan Metzmacher (Metze) and Rusty Russell changed the startup and monitoring mechanisms to improve reliability. Finally Ronnie, Martin Schwenke and Michael Adam have improved CTDB's test suite and logging code.
Many lessons have been learned from increased testing and deployment: Priorities have been added to the databases in order to prevent deadlocks. Volker Lendecke improved CTDB's monitoring of Winbind to reduce timeouts. Michael and Metze have gone through continued pains to debug the persistent TDB transaction code and fix a lot of race conditions. Finally, Volker and Michael have re-implemented persistent transactions using a new global lock feature that constitutes the long desired global transaction state.
If you want to produce a clustered version of a CIFS file server, check out clustered Samba - it really is the only proven working product out there !
New Protocol : SMB2
With Windows 7 Microsoft have introduce a new variant of the CIFS protocol, SMB2. Samba is keeping pace, with a sample implementation of SMB2 which will be released for early adopters to test in Samba 3.5.0. A fully finished production version is expected to be available in Samba 3.6.0. Testing SMB2 in Samba 3.5.0 is as simple as setting :
max protocol = SMB2
in the [global] section of your smb.conf. Be warned this is still test code (for example kerberos support is not yet integrated) but should give you a taste of what is to come.
Samba and Windows 7
So you moved early to Windows 7. How brave of you :-). Samba 3.3.x and 3.4.x work well with Windows 7. Any known issues are posted and updated here :
Which will currently tell you how to configure a Windows 7 client to work with a Samba NT-style domain controller.
Happy file sharing !
The Samba Team
Posted at 13:11 | Read more in: Developers