I hear that Fedora 18 will come with Samba 4

[Richard Sharpe-2]

Hi folks,

Is anyone making sure that the transition from Samba 3 to Samba 4
after an upgrade works fine?

How about the knowledge transition from Samba 3 to Samba 4?

I ask because the transition from Fedora 14 to Fedora 16 was
horrendous. It has taken a while to get back to a comfortable
environment.

I would not like to see the transition to Samba 4 on F18 cause people
too much heartache.

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

[Andrew Bartlett]

On Wed, 2012-08-01 at 21:10 -0700, Richard Sharpe wrote:
> Hi folks,
>
> Is anyone making sure that the transition from Samba 3 to Samba 4
> after an upgrade works fine?

As Fedora isn't shipping the AD DC, their users really won't notice
much.  The extra client libraries have already been shipped for ages in
support of OpenChange.  

The same applies to the next debian release, which while it has a Samba4
AD DC included (at least for now), the primary purpose remains
OpenChange client support.  (Debian will only ships the ntvfs-based DC
in thier next release)

In both cases, the challenge for us will be to explain to our users why
the package in their distribution isn't the full Samba 4.0, and how to
replace it if they need an AD DC.

Users of the file server really won't notice much at all - while lots of
great work has gone on under the hood, the tdb databases used etc is
unchanged, as far as I'm aware.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

[Richard Sharpe-2]

On Wed, Aug 1, 2012 at 9:32 PM, Andrew Bartlett <[hidden email]> wrote:

> On Wed, 2012-08-01 at 21:10 -0700, Richard Sharpe wrote:
>> Hi folks,
>>
>> Is anyone making sure that the transition from Samba 3 to Samba 4
>> after an upgrade works fine?
>
> As Fedora isn't shipping the AD DC, their users really won't notice
> much.  The extra client libraries have already been shipped for ages in
> support of OpenChange.
>
> The same applies to the next debian release, which while it has a Samba4
> AD DC included (at least for now), the primary purpose remains
> OpenChange client support.  (Debian will only ships the ntvfs-based DC
> in thier next release)
>
> In both cases, the challenge for us will be to explain to our users why
> the package in their distribution isn't the full Samba 4.0, and how to
> replace it if they need an AD DC.
>
> Users of the file server really won't notice much at all - while lots of
> great work has gone on under the hood, the tdb databases used etc is
> unchanged, as far as I'm aware.

OK, this is good.

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

[Alexander Bokovoy]

Hi,

On Thu, Aug 2, 2012 at 7:32 AM, Andrew Bartlett <[hidden email]> wrote:

> On Wed, 2012-08-01 at 21:10 -0700, Richard Sharpe wrote:
>> Hi folks,
>>
>> Is anyone making sure that the transition from Samba 3 to Samba 4
>> after an upgrade works fine?
>
> As Fedora isn't shipping the AD DC, their users really won't notice
> much.  The extra client libraries have already been shipped for ages in
> support of OpenChange.
>
> The same applies to the next debian release, which while it has a Samba4
> AD DC included (at least for now), the primary purpose remains
> OpenChange client support.  (Debian will only ships the ntvfs-based DC
> in thier next release)
>
> In both cases, the challenge for us will be to explain to our users why
> the package in their distribution isn't the full Samba 4.0, and how to
> replace it if they need an AD DC.

We have added some readme files to the packages that explain why and
how it is done. Andreas takes great deal to test that packages
actually build both with AD DC disabled and enabled in Fedora. So, one
could rebuild the package and get fully working Samba 4.0 AD DC with
embedded Heimdal version. However, that package will be incompatible
with certain other packages that use Samba libraries et al due to
Kerberos API drift. I'm thinking on adding some guards through the
generated names and versioning so that once you rebuild samba package
with AD DC functionality, it will supersede stock samba package in
Fedora so that no updates will break the install. You'd need to
rebuild src.rpm then to get updates for yourself. So much we can do
before we'll get MIT Kerberos working as embedded KDC for Samba 4.0.

> Users of the file server really won't notice much at all - while lots of
> great work has gone on under the hood, the tdb databases used etc is
> unchanged, as far as I'm aware.
There is one change in registry.tdb that breaks downgrades since
registry format changed between 3.6 and 4.0 smbd. This applies to both
AD DC case and (F18-default) build without AD DC
--
/ Alexander Bokovoy

[Andreas Schneider-15]

On Wednesday 01 August 2012 21:10:23 Richard Sharpe wrote:
> Hi folks,

Hi Richard,

> Is anyone making sure that the transition from Samba 3 to Samba 4
> after an upgrade works fine?

Samba 4 AD DC functionality relies heavily on Heimdal Kerberos implementation.
Samba 4 includes the embedded Heimdal, if your system misses it, like we have
in Fedora. When embedded Heimdal is in use, all Samba 4 code is compiled
against this Kerberos implementation, including client side libraries and
tools, and traditional file serving smbd daemon we know as 'samba' package in
Fedora.

Fedora uses MIT Kerberos implementation, both server and client side. Heimdal
and MIT Kerberos are targetting to implement the same Kerberos V protocol but
have their own extensions API and certain semantical differences. They also
have slightly different meaning to Kerberos credential cache files format
where Kerberos-aware applications store their Kerberos keys. While this is not
an issue for client-server communication over a network (a Heimdal client does
talk the same Kerberos V protocol that MIT Kerberos server understands and
vice versa), interoperability of the client or server code using the same
credential cache files on the same system is much less supported for advanced
features like S4U2Proxy and S4U2Self.

It is generally not advisable to load two different API implementations into
the same address space either. When the rest of the system libraries is
compiled against MIT Kerberos, use of them within Samba 4 code brings in MIT
Kerberos as well. This happens, for example, when linking against OpenLDAP
client libraries and using SASL authentication.

As part of work we are doing on FreeIPA v3, we have made possible to compile
Samba 4 code against MIT Kerberos implementation. Unfortunately, MIT Kerberos
does not give option of embedding Kerebros KDC server within another process
which is required for Samba 4 AD DC functionality. Thus, when compiled with
MIT Kerberos, Samba 4 currently does not provide Active Directory Domain
Controller functionality at all, only client side libraries and tools to the
extent that does not involve AD DC operations. Also, smbd is compiled against
MIT Kerberos and provides functionality equivalent to what is provided by
Samba 3's smbd.

We are intending to make possible use of AD DC functionality with MIT Kerberos
but this is longer term project that requires cooperation between Samba, MIT,
and FreeIPA.


So Samba 4.0.0 in F18 will proivde the same as Samba 3.6.6 and in addition the
new client libraries and python bindings.


Cheers,


        -- andreas

--
Andreas Schneider                   GPG-ID: F33E3FC6
Samba Team                             [hidden email]
www.samba.org