Res: status of DRS efforts in Samba4 (and a developer tutorial)
Fernando J V da Silva
fernandojvsilva at yahoo.com.br
Wed Sep 16 08:18:35 MDT 2009
Hi,
I had the same problem too ... Thanks everyone for the replies!
After all, it seems that the real problem is concerning the apparmor
permissions in ubuntu, so another option for solving this issue is to
disable it (that was what I did...).
Thanks!
Fernando Silva.
________________________________
De: Eduardo Lima <eduardoll at gmail.com>
Para: Anatoliy Atanasov <anatoliy.atanasov at postpath.com>
Cc: "samba-technical-bounces at lists.samba.org" <samba-technical-bounces at lists.samba.org>; "samba-technical at samba.org" <samba-technical at samba.org>; "fernandojvsilva at yahoo.com.br" <fernandojvsilva at yahoo.com.br>
Enviadas: Quarta-feira, 16 de Setembro de 2009 10:58:28
Assunto: Re: status of DRS efforts in Samba4 (and a developer tutorial)
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>
>
>> >
>>> > 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
>>> >
>
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
More information about the samba-technical
mailing list