status of DRS efforts in Samba4 (and a developer tutorial)
Eduardo Lima
eduardoll at gmail.com
Fri Sep 18 11:43:10 MDT 2009
FYI, today I had to perform Tridge's tutorial again and I had to clone a
fresh Samba repository.
Using this fresh repository, quick test was not running well:
FAILED (0 failures and 37 errors in 14 testsuites)
make: *** [quicktest] Error 1
Then I tried to use an older version (d106e728fb0c59900c289055c97f424e4f5d3c75)
and I got the "All OK" output.
Is this an issue?
--
Eduardo Lima
On Wed, Sep 16, 2009 at 10:58, Eduardo Lima <eduardoll at gmail.com> wrote:
> Thanks All,
>
> I joined all the suggestions and made the following solution that worked
> for me:
>
> Inserted the following line into /etc/apparmor.d/usr.sbin.named.
> /var/run/bind/run/* rw,
>
> Copied zone file to
> /var/run/bind/run/
>
> Edited /etc/bind/named.conf.local with the new zone path.
>
> Now it's working well!
>
> Thanks.
>
> --
> Eduardo Lima
> Sent from Campinas, SP, Brazil
>
> On Wed, Sep 16, 2009 at 10:12, Anatoliy Atanasov <
> anatoliy.atanasov at postpath.com> wrote:
>
>> Hi Eduardo,
>>
>> I had the same problem as you.
>> I tried to change permisions on the file/foler etc. and it didn't work.
>> Problme solved when i moved the .zone file in /var/named/ /*where bind
>> files are*/.
>> I am using Fedora 11 at the moment.
>>
>> Cheers,
>> Anatoliy
>> ----- Original Message -----
>> > From: samba-technical-bounces at lists.samba.org <
>> samba-technical-bounces at lists.samba.org>
>> > To: samba-technical at samba.org <samba-technical at samba.org>, Eduardo Lima
>> <eduardoll at gmail.com>
>> > Cc: Fernando Silva <fernandojvsilva at yahoo.com.br>
>> > Sent: Wednesday, September 16, 2009 5:31:45 AM GMT-0800
>> America;Los_Angeles
>> > Subject: Re: status of DRS efforts in Samba4 (and a developer tutorial)
>>
>> > > Hi List,
>> >
>> > I'm starting to work on samba and my first step is to follow the
>> > tutorial
>> > that Tridge wrote.
>> >
>> > At the end of tutorial's Step #4 I'm trying to restart bind9 services
>> > but I
>> > get a "permission denied" message when bind9 tries to use the zone
>> > file I've
>> > created (bind9 restarts successfully but the "permission denied"
>> > message
>> > appears in the log).
>> >
>> > named[21457]: zone ltc.softex/IN: loading from master file
>> > /home/eduardo/prefix.s4/private/ltc.softex.zone failed: permission
>> > denied
>> >
>> > I think this might be the reason why the command
>> >
>> > host -t SRV _ldap._tcp.ltc.softex
>> > <http://tcp.bludom.tridgell.net/>localhost
>> >
>> > is failing to execute:
>> >
>> > _ldap._tcp.ltc.softex SRV record not found at localhost, server
>> > failure
>> >
>> > Is there any other step I have to do to make it work?
>> >
>> > Thanks.
>> >
>> > --
>> > Eduardo Lima
>> > Sent from Campinas, SP, Brazil
>> >
>> > On Thu, Sep 10, 2009 at 23:32, <tridge at samba.org> wrote:
>> >
>> > > Prompted by the message from Rodolfo, I thought it might be useful
>> > to
>> > > give some status on the DRS efforts in Samba4, and a few very rough
>> > > instructions on how to test what we've got at the moment.
>> > >
>> > > First some background. For years we have been slowly building up the
>> > > ability of Samba4 to be an active directory domain controller. One
>> > of
>> > > the key features of a DC is the ability to replicate with other DCs
>> > in
>> > > the same domain, so that if you (for example) add a user on one of
>> > the
>> > > DCs then that user will appear on the other DCs within a few
>> > seconds.
>> > >
>> > > Samba4 has for quite a while had the ability to be a standalone AD
>> > > domain controller, and that is in production use at some sites. That
>> > > is a great achievement, but for more widespread use we really need
>> > the
>> > > ability to do replication, otherwise Samba4 will not be able to be
>> > > added as an additional domain controller to existing Windows
>> > domains.
>> > >
>> > > The key to replication is the DRSUAPI RPC protocols. They implement
>> > a
>> > > multi-master directory service, and have quite complex protocols for
>> > > working out what changes need to be sent between DCs.
>> > >
>> > > Stefan Metzmacher (metze) developed a lot of the base code as part
>> > of
>> > > his thesis work. He did an amazing job, especially since at the time
>> > > we didn't have any protocol documentation and he worked it out by
>> > > looking at wire traces, and from technet overview docs like this
>> > one:
>> > >
>> > >
>> > http://technet.microsoft.com/en-us/library/cc772829(WS.10).aspx<http://technet.microsoft.com/en-us/library/cc772829%28WS.10%29.aspx>
>> <http://
>> > technet.microsoft.com/en-us/library/cc772829%28WS.10%29.aspx>
>> > >
>> > > The code metze wrote forms the basis for a lot of the activity in
>> > the
>> > > Samba4 source tree over the last few weeks. We have finally reached
>> > a
>> > > point in the development of Samba4 where all the various pieces are
>> > > coming together and we can start to make large parts of DRS actually
>> > > work. We're hoping to test a lot of this code at the DRS plugfest on
>> > > Microsoft campus later this month.
>> > >
>> > > The things we currently have working (as of yesterday!) are as
>> > > follows:
>> > >
>> > > 1) as before, we can create a standalone Samba4 domain controller,
>> > > using the usual provision script
>> > >
>> > > 2) now we can use "net vampire" to join another Samba4 machine to
>> > the
>> > > domain. The vampire process pulls a copy of the entire directory
>> > from
>> > > the first machine and uses it to populate its own directory. It
>> > also
>> > > sets up the necessary records for the two machines to use
>> > incremental
>> > > replication from then on to keep themselves in sync. The server
>> > side
>> > > of this is based on some great work by Anatoliy Atanasov, extended
>> > a
>> > > bit by Andrew and myself over the last few days.
>> > >
>> > > 3) we can "net vampire" to both w2k3 and w2k8, and then after the
>> > > vampire is complete Samba can pull incremental changes from the
>> > > windows DC to the Samba database.
>> > >
>> > > We have not yet demonstrated windows pulling incremental changes
>> > from
>> > > Samba, or at least not successfully. Windows has pulled changes, but
>> > > so far it has mostly caused windows to crash soon afterwards! I
>> > think
>> > > we may have fixed the main bugs that caused that in the last couple
>> > of
>> > > days, and I am hopefully that we will demonstrate the first
>> > successful
>> > > replication of samba<->windows in the next week. We are still a long
>> > > way from this being ready for production use of course.
>> > >
>> > > Now I'll give a very rough howto for developers who may be
>> > interested
>> > > in reproducing what we've done. One of the interesting things about
>> > > this howto is that it doesn't now need a windows box. The ability to
>> > > do replication samba4<->samba4 means that interested developers can
>> > > now experiment with DRS replication in a Samba-only environment,
>> > which
>> > > can make debugging and testing much easier. We obviously need to
>> > > ensure it works with Windows as well, but initial development of
>> > > features in a Samba-only environment can really help development.
>> > >
>> > >
>> > > Step 1) Get the latest git tree.
>> > >
>> > > You really do need the latest tree. If your tree is just a few hours
>> > > old then you could be missing major features! The code is developing
>> > > very rapidly.
>> > >
>> > > A basic git checkout would be:
>> > >
>> > > git clone git://git.samba.org/samba.git samba4
>> > >
>> > >
>> > > Step 2) build Samba4 as usual.
>> > >
>> > > Common steps are:
>> > >
>> > > cd samba4/source4
>> > > ./autogen.sh
>> > > ./configure.developer --prefix=$HOME/prefix.s4
>> > > make
>> > > make install
>> > >
>> > > You might also like to run "make test" or "make quicktest". Be
>> > warned
>> > > that "make test" can take a long time (over half an hour on my
>> > laptop)
>> > > and some of the tests will probably fail. "make quicktest" takes
>> > just
>> > > a couple of minutes and at least lets you know that the git tree you
>> > > have works to some extent. If "make quicktest" does not pass
>> > > completely then the tree is probably badly broken.
>> > >
>> > >
>> > > Step 3) provision your Samba domain controller
>> > >
>> > > You will need to decide what domain name you will use. At home I use
>> > a
>> > > DNS domain of "bludom.tridgell.net" with a NBT workgroup name of
>> > > "bludom". My test machine (where I built Samba4) is called "blu"
>> > with
>> > > an IP address of 10.0.0.1. I'll use those names in the example
>> > below.
>> > >
>> > > You could cd to the source4 build directory again, and run something
>> > > like this:
>> > >
>> > > ./setup/provision --realm=bludom.tridgell.net --domain=bludom
>> > > --host-name=blu --host-ip=10.0.0.1 --adminpass=penguin
>> > --server-role="domain
>> > > controller"
>> > >
>> > > If that works you'll see something like this:
>> > >
>> > > Server Role: domain controller
>> > > Hostname: blu
>> > > NetBIOS Domain: BLUDOM
>> > > DNS Domain: bludom.tridgell.net
>> > > DOMAIN SID: S-1-5-21-2939463048-3248118054-807635424
>> > > Admin password: penguin
>> > >
>> > >
>> > > Step 4) Setup DNS
>> > >
>> > > As part of the provision above you will end up with a DNS zone file
>> > in
>> > > $HOME/prefix.s4/private. In my case it's called
>> > > bludom.tridgell.net.zone.
>> > >
>> > > You need to install bind9 on your machine, and enable this zone file
>> > > so that you can resolve DNS names within the bludom domain.
>> > >
>> > > To do that with a modern bind9 install (I'm using the one in Ubuntu
>> > > Jaunty) you would add something like this to
>> > > /etc/bind/named.conf.local:
>> > >
>> > > zone "bludom.tridgell.net" IN {
>> > > type master;
>> > > file
>> > "/home/tridge/prefix.s4/private/bludom.tridgell.net.zone";
>> > > };
>> > >
>> > > Then restart bind9. You might also like to do something like this in
>> > > the options clause in /etc/bind/named.conf.options:
>> > >
>> > > forward only;
>> > > forwarders {
>> > > 192.168.2.10;
>> > > };
>> > >
>> > > where the IP is the address of your LANs DNS server. That will mean
>> > > that your development box will only answer queries for the zone
>> > you've
>> > > configured, and will forward other queries onto your LANs DNS
>> > server.
>> > >
>> > > Next check that your /etc/resolv.conf points to 127.0.0.1 for your
>> > > nameserver and you should be able to run commands like this:
>> > >
>> > > tridge at blu$ host -t SRV _ldap._tcp.bludom.tridgell.net localhost
>> > > Using domain server:
>> > > Name: localhost
>> > > Address: 127.0.0.1#53
>> > > Aliases:
>> > >
>> > > _ldap._tcp.bludom.tridgell.net has SRV record 0 100 389
>> > > blu.bludom.tridgell.net.
>> > >
>> > >
>> > > Step 5) Setup smb.conf
>> > >
>> > > The provision process above will have setup a basic smb.conf in
>> > > $HOME/prefix.s4/etc/smb.conf. You should edit that to add a few more
>> > > useful things to the [global] section like this:
>> > >
>> > > interfaces = 127.0.0.1/8 virbr0
>> > > bind interfaces only = yes
>> > > dreplsrv:periodic_interval = 10
>> > > dreplsrv:periodic_startup_interval = 5
>> > >
>> > > This sets up Samba4 to only listen on loopback and virbr0. The
>> > reason
>> > > we do that is we are going to be starting two copies of Samba on
>> > this
>> > > machine, replicating to each other, and we don't want the two to
>> > > collide when they both try to listen on the same network
>> > > interface. When we setup the 2nd copy of Samba4 we will set it to
>> > > listen on a different interface.
>> > >
>> > > The dreplsrv options and to tell Samba4 to do a replication every 10
>> > > seconds (5 seconds for the first one). This is useful when doing
>> > > initial testing, and is also needed at the moment as (as of today)
>> > > Samba doesn't send DsReplicaSync messages to tell the other DCs to
>> > > replicate when a change happens in the Samba DB. So by doing the
>> > above
>> > > we are just saying "replicate a lot".
>> > >
>> > >
>> > > Step 6) Start the first copy of Samba
>> > >
>> > > In a new terminal, go to the source4 directory again and run this:
>> > >
>> > > sudo bin/samba -i -M single -d4
>> > >
>> > > That starts Samba4, and you will be running a DC in interactive
>> > > mode. That is most useful for debugging/developing this code. It
>> > will
>> > > put out messages like this every 10 seconds:
>> > >
>> > > dreplsrv_periodic_run(): schedule pull replication
>> > > dreplsrv_periodic_run(): run pending_ops
>> > > dreplsrv_periodic_schedule(10) scheduled for: Fri Sep 11 11:12:20
>> > 2009 EST
>> > >
>> > > That is the replication engine running. At the moment we only have
>> > one
>> > > DC, so it isn't doing any real work, but you can see it trying.
>> > >
>> > > When I'm debugging this, I often run this command:
>> > >
>> > > make bin/samba && sudo gdb --args bin/samba -i -M single -d4
>> > >
>> > > that allows me to run Samba4 under gdb, and break into any of the
>> > > interesting DRS routines to watch them happen.
>> > >
>> > >
>> > > Step 7) Setup a 2nd copy of Samba4 on the same machine
>> > >
>> > > This is where we create a 2nd copy of Samba4, running on the same
>> > > machine, and we will setup the two copies to replicate to each
>> > other.
>> > >
>> > > You will need a 2nd network interface for this. You can either
>> > create
>> > > one using ifconfig magic, or you can use an exising one. I use the
>> > > virbr1 interface, which is another interface created by having kvm
>> > > installed on my machine (the first one was virbr0 which I used above
>> > > for the first instance of Samba4).
>> > >
>> > > So I have two interfaces like this:
>> > >
>> > > virbr0 Link encap:Ethernet HWaddr aa:7a:de:62:e6:fc
>> > > inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
>> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > >
>> > > virbr1 Link encap:Ethernet HWaddr 3a:45:04:48:bf:06
>> > > inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0
>> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > >
>> > > We need to create a install directory for the 2nd copy of Samba4. We
>> > > don't need to make it a full copy, the following commands will do
>> > the
>> > > job:
>> > >
>> > > mkdir $HOME/prefix.s4.2
>> > > cd $HOME/prefix.s4.2
>> > > mkdir -p private etc var var/lib var/run var/locks var/ncalrpc
>> > >
>> > > now we need a smb.conf in that 2nd directory
>> > >
>> > > cp $HOME/prefix.s4/etc/smb.conf $HOME/prefix.s4.2/etc/
>> > >
>> > > and we need to edit that smb.conf to look something like this:
>> > >
>> > > [globals]
>> > > netbios name = blu2
>> > > workgroup = bludom
>> > > realm = bludom.tridgell.net
>> > > server role = domain controller
>> > > interfaces = virbr1
>> > > bind interfaces only = yes
>> > > dreplsrv:periodic_interval = 10
>> > > dreplsrv:periodic_startup_interval = 5
>> > >
>> > > ncalrpc dir = /home/tridge/prefix.s4.2/var/ncalrpc
>> > > private dir = /home/tridge/prefix.s4.2/private
>> > > swat directory = /home/tridge/prefix.s4.2/share/swat
>> > > lock dir = /home/tridge/prefix.s4.2/var/locks
>> > > pid directory = /home/tridge/prefix.s4.2/var/run
>> > > winbindd socket directory =
>> > > /home/tridge/prefix.s4.2/var/run/winbindd
>> > > winbindd privileged socket directory =
>> > > /home/tridge/prefix.s4.2/var/lib/winbindd_privileged
>> > > ntp signd socket directory =
>> > > /home/tridge/prefix.s4.2/var/run/ntp_signd
>> > >
>> > > [netlogon]
>> > > path = /home/tridge/prefix.s4/var/locks/sysvol/
>> > > bludom.tridgell.net/scripts
>> > > read only = no
>> > >
>> > > [sysvol]
>> > > path = /home/tridge/prefix.s4/var/locks/sysvol
>> > > read only = no
>> > >
>> > > notice that we are overriding all the directories to point at our
>> > 2nd
>> > > copy. This means that when we use the -s option to Samba tools to
>> > > point at this smb.conf it will also point all the other important
>> > > directories at the right place.
>> > >
>> > > Notice also that we are setting the netbios name to a different name
>> > > from the main name of this machine. The 2nd copy of Samba is called
>> > > 'blu2' whereas the first one is called 'blu'.
>> > >
>> > > You'll need to make sure that 'blu' and 'blu2' resolve to the right
>> > > IPs. For example, check your /etc/hosts and make sure they are
>> > either
>> > > not there (and use DNS) or that they point at the two IPs you are
>> > > using for this test.
>> > >
>> > >
>> > > Step 8) run net vampire
>> > >
>> > > This is the step where we will 'vampire' the first DC into the 2nd
>> > > one, so that the 2nd DC gets a copy of the entire LDAP directory.
>> > The
>> > > command we need is this (run from the source4 directory again):
>> > >
>> > > bin/net -s $HOME/prefix.s4.2/etc/smb.conf vampire
>> > -Uadministrator%penguin
>> > > bludom.tridgell.net -d4
>> > >
>> > > If all goes well you'll see a message like this after a minute or
>> > so:
>> > >
>> > > Vampired domain BLUDOM (S-1-5-21-2939463048-3248118054-807635424)
>> > >
>> > > This is the step that we got working yesterday, so if you get this
>> > > working then you are probably one of the first people in the world
>> > to
>> > > do so!
>> > >
>> > >
>> > > Step 9) check with ldbsearch
>> > >
>> > > Now let's check that the vampire did the right thing. Let's look at
>> > > the administrator account for the two DCs:
>> > >
>> > > bin/ldbsearch -H $HOME/prefix.s4/private/sam.ldb
>> > > samaccountname=administrator
>> > > bin/ldbsearch -H $HOME/prefix.s4.2/private/sam.ldb
>> > > samaccountname=administrator
>> > >
>> > > those two searches should give the same result. Right now there are
>> > > some bugs, and the two are not quite identical, but they are close.
>> > >
>> > >
>> > > Step 10) Start the 2nd copy of Samba
>> > >
>> > > We are now ready to start the 2nd DC, and it should start
>> > replicating
>> > > with the first one. With the first copy of Samba still running in
>> > > another terminal, run this to start the 2nd one:
>> > >
>> > > sudo bin/samba -s $HOME/prefix.s4.2/etc/smb.conf -i -M single -d4
>> > >
>> > > Within 10 seconds you should see messages about the two DCs
>> > > replicating between each other. You may well run into some
>> > > kerberos/DNS bugs (I'm working on that today), but the two DCs
>> > should
>> > > at least startup.
>> > >
>> > > If things are working right, then if you use ldbedit to modify one
>> > of
>> > > the DCs, then the other DC will get the changes within 10
>> > > seconds. This is the bit that is most fragile right now, so don't
>> > > expect it to work perfectly.
>> > >
>> > > If you've reached this stage then congratualtions, you now have a
>> > pair
>> > > of replicating Samba4 DCs. Now it's over to you to help develop this
>> > > further!
>> > >
>> > >
>> > > Step 11) Replicating with windows
>> > >
>> > > You could instead substitute a windows box for one of the DCs in the
>> > > above test. If you do, you'll need to run scripting/bin/setup_dns.sh
>> > > after the vampire step to put the right DNS entries in the windows
>> > DNS
>> > > server. You also may find that the first time windows tries to
>> > > replicate to us that you may crash windows.
>> > >
>> > >
>> > > Step 12) Where to from here?
>> > >
>> > > The above is a good start, but there is _lots_ more to do. For a
>> > > start, the above steps are very fragile. You will probably find
>> > things
>> > > failing quite often, and if you use ldbsearch you'll see that the
>> > > replication isn't perfect. For example the replica may get two
>> > copies
>> > > of the 'cn' attribute for every record, it may be missing the
>> > > parentGUID attributes and many other problems.
>> > >
>> > > It also hasn't yet been made to fully work bi-directionally when one
>> > > of the replicas is a windows box (without crashing windows), and we
>> > > haven't yet tried having 3 or more DCs. We also haven't tried more
>> > > than one domain in a forest, and we don't automatically do all the
>> > > right TSIG-GSS DNS updates (though please look in
>> > > scripting/bin/setup_dns.sh for a start on that).
>> > >
>> > > Anatoliy is working on implementing the "Uptodateness vector", and
>> > > I'm working on trying to get the SPN and DNS stuff right. Andrew
>> > > Bartlett is working on trying to get this integrated into "make
>> > test"
>> > > so that it will stay working, and Metze is watching over us to make
>> > > sure we don't break too much of his great groundwork.
>> > >
>> > > To go from this point to something that could be used in production
>> > > will take a huge effort, but I am delighted that we have come as far
>> > > as we have so quickly. I think we'll be able to make much faster
>> > > progress now that we can demonstrate the first Samba<->Samba DRS
>> > > replication.
>> > >
>> > > Cheers, Tridge
>> > >
>>
>
>
More information about the samba-technical
mailing list