FAQ: Difference between revisions

From SambaWiki
(adapt FAQ for after the release.)
Line 1: Line 1:
The questions and answers on this page have been extracted from the [http://lists.samba.org/archive/samba-technical/ Samba technical mailing list].
The questions and answers on this page have been extracted from the [http://lists.samba.org/archive/samba-technical/ Samba technical mailing list].


== Can I use Samba4 on my production server right now? ==
== Can I use Samba 4.0 as an AD DC on my production server right now? ==


We are now at the release candidate stage, and a number of users have it in use in a production environment. All the features from the Samba 3.6 series are now available, for example, the file server in the smbd binary.
We have now released Samba 4.0, and a number of users have it in use in a production environment. All the features from the Samba 3.6 series are now available, for example, the file server in the smbd binary.


Of course, caution is generally advised with all our pre-releases, as is participation on our mailing lists to discuss any issues that arise.
Of course, normal Systems Administration caution is generally advised, as an AD Domain is the central hub for authentication on a network, as is participation on our mailing lists to discuss any issues that arise.


We do however encourage people to try Samba4, report bugs, and give feedback.
We do however encourage people to try Samba 4.0 as an AD DC, report bugs, and give feedback.


== When will Samba 4.0.0 be released? ==
== When will Samba 4.0 releases be made? ==


For the current Samba 4.0 and 4.x release plans, please see [[Samba Release Planning]].
When it's ready. It's very hard to say when that will be. It depends on a lot of things and people's spare time.

For the current Samba4 release status, please see [[Release Planning for Samba 4.0]].


== Will Samba 4 eventually have a built-in, full fledged LDAP server? ==
== Will Samba 4 eventually have a built-in, full fledged LDAP server? ==
Line 21: Line 19:
clients first, and hopefully do so while complying with the standards),
clients first, and hopefully do so while complying with the standards),
it will include an LDAPv3 server.
it will include an LDAPv3 server.

== Why is the LDAP backend (used so successfully in classic Samba domains) not supported with the AD DC?==

We certainly appreciate the bind that the LDAP server situation puts our administrators in. We went to great lengths to try and avoid this, but were unable to make it work, while also supporting features such as DRS replication, and many of the finer points of AD's LDAP server. The biggest killer for the feature was the need for runtime schema translation, or for the administrator to load the AD schema and layout on their external LDAP server (which rather defeats the purpose).

The there are three ways out of this difficult situation
* continue to use Samba as a 'classic' domain controller as-is using smbd/nmbd (this code remains and remains supported).
* Add schema extensions to our LDAP server (disabled by default, but supported), and cope with the AD-specified layout restrictions.
* Somehow sync Samba with an existing LDAP server.

There are major challenges with synchronisation of directories - but it certainly may be an option in some situations.

We certainly understand that it appears almost rude, on the face of it, to step up from being an equal partner in the unix-LDAP ecosystem supporting a number of different directory servers to demanding that everyone else use only our internal server. We do wish it didn't have to be this way, and we have left in (with tests) as much of the code we used for the [[Samba4/LDAP Backend|LDAP backend]] experiment as is possible, in case somehow someone builds a workable use case in the future.



== Will it also be possible in the future to extend the server by loading user defined schema's? ==
== Will it also be possible in the future to extend the server by loading user defined schema's? ==
Alternatively, is it planned for samba to support storing everything in a third party directory server?


Yes, user-defined schema may be loaded into the Samba 4.0 AD DC. It is experimental, so you must set
We will not depend on other servers but the aim is to be able to use

them if available.
<pre>dsdb:schema update allowed = yes</pre>

in the smb.conf to permit it.

Revision as of 02:45, 22 December 2012

The questions and answers on this page have been extracted from the Samba technical mailing list.

Can I use Samba 4.0 as an AD DC on my production server right now?

We have now released Samba 4.0, and a number of users have it in use in a production environment. All the features from the Samba 3.6 series are now available, for example, the file server in the smbd binary.

Of course, normal Systems Administration caution is generally advised, as an AD Domain is the central hub for authentication on a network, as is participation on our mailing lists to discuss any issues that arise.

We do however encourage people to try Samba 4.0 as an AD DC, report bugs, and give feedback.

When will Samba 4.0 releases be made?

For the current Samba 4.0 and 4.x release plans, please see Samba Release Planning.

Will Samba 4 eventually have a built-in, full fledged LDAP server?

Yes. While we certainly won't compare ourselves with the standards-based products from other vendors (our aim is to please AD clients first, and hopefully do so while complying with the standards), it will include an LDAPv3 server.

Why is the LDAP backend (used so successfully in classic Samba domains) not supported with the AD DC?

We certainly appreciate the bind that the LDAP server situation puts our administrators in. We went to great lengths to try and avoid this, but were unable to make it work, while also supporting features such as DRS replication, and many of the finer points of AD's LDAP server. The biggest killer for the feature was the need for runtime schema translation, or for the administrator to load the AD schema and layout on their external LDAP server (which rather defeats the purpose).

The there are three ways out of this difficult situation

  • continue to use Samba as a 'classic' domain controller as-is using smbd/nmbd (this code remains and remains supported).
  • Add schema extensions to our LDAP server (disabled by default, but supported), and cope with the AD-specified layout restrictions.
  • Somehow sync Samba with an existing LDAP server.

There are major challenges with synchronisation of directories - but it certainly may be an option in some situations.

We certainly understand that it appears almost rude, on the face of it, to step up from being an equal partner in the unix-LDAP ecosystem supporting a number of different directory servers to demanding that everyone else use only our internal server. We do wish it didn't have to be this way, and we have left in (with tests) as much of the code we used for the LDAP backend experiment as is possible, in case somehow someone builds a workable use case in the future.


Will it also be possible in the future to extend the server by loading user defined schema's?

Yes, user-defined schema may be loaded into the Samba 4.0 AD DC. It is experimental, so you must set

dsdb:schema update allowed = yes

in the smb.conf to permit it.