 Thank you. So I thought I'd give you a little bit of talk about Samba 4, about some of the challenges we have with moving people from Samba 3 to Samba 4, and on Crank software that where the way you naturally use the software is a reasonable, secure way to use the software. Now as I've said up there, they're war stories, they'll be a little bit of fun in that, but also you know I come to this with a fair bit of a background but I also want to hear a lot from you guys. I would like you to ask questions during the talk, as I said to those of you who are already in here, I would like to give whoever's running with the microphone a lot of exercise today, and I would particularly like questions, heckles if we can derail this totally, I will be very impressed. So I now work at Catalyst, I've been in Wellington for 18 months now, and Catalyst supports me in doing Samba 4 development which is really cool. I've been a Samba team member since 2001, so I've been at this a long time, not as long as Tridge, but you know long enough to be feeling a bit jaded about some of these things at points, and I'm going to be sort of sharing a little bit of where we've gone in that journey. These views are my own but I do very much thank Catalyst and my fellow Samba team members, because we could not produce this amazing software without the support of the whole team, a number of whom are in the audience today. Samba's Active Directory DC I think is a great success. Well okay we didn't really get it to any kind of on time, but Windows desktops are still a reality. They're not the same reality I was worried about a decade ago. I'm seeing the world change around, sorry about the way those slides are turned out, but at least outside this room you know we still have Windows desktops as the dominant metaphor in our government departments, in our corporate offices, and they need Active Directory to manage them. They also need servers that typically end up running Windows from time to time, those need Active Directory to manage them well, and so we need to have some kind of Directory server that manages all this well and it's not a bolt-on, clutch together kind of thing, and in doing to try and do all this we actually produced Samba's first product rather unexpectedly, because the Samba team had for quite some time been quite happy with the idea that we were a kit of parts, that an OEM or someone else would put our stuff together and that that would all work really well for folks. Now that motto worked really well for some NAS vendors, but I don't think it's worked really well for our direct users, and I've taken a rather different attitude with our Active Directory code. Instead we try to produce something that when you install it actually works, which I don't think should be revolutionary, but it seems to have been. We've got a lot of ground to cover. Samba's Active Directory Domain Controller is an LDAP server, Kerberos server, Windows Domain Controller, it's so many things, but it is fundamentally a centralized identity management server. Authentication and authorization are what it does, but it's also a file server, it's also still a print server, and it is importantly the thing that Windows machines join natively. You can't join a Windows machine to anything else without the minimum fiddling in the registry and for anything other than Samba 3 doing far more. So Samba's important and Samba's an important part of our ecosystem, and I think it's actually a success because I think we've actually gone and created something which I titled to want to gain the paper committee's attention of pushing the users into the pit of success, which was that you should almost fall into a working well configured system almost by default, not by carefully studying the best practice guides and doing all the extra steps. Because even if software is complex, even if the protocols are fiendishly complex, even if sites have got different requirements and things, I want the initial install, that one that you do when you first get going to be a success simply, because the alternative I think is quite a disaster. You should really be doing where that first install, you ask some questions, you add your first user and you have something that you can use. And all the details, the things that had to be done because they had to be done are taken care of for you rather than laid out in wiki pages and guides and other things that you have to manually substitute your way through. All steps should be scripted, not left as please run this command and this command and remember to put your password in here, not that one. Don't leave any steps manual, not even the steps you think are safe to leave for someone to do on their own, because every time you do that someone will mess them up. And then they'll be back at your mailing list wondering why didn't it work and you're back wasting time. We write computers to do things automatically, so why do we create systems that require administrators to go and do things manually? But most importantly, I think that the initial install needs to be secure. It's one of my real bug bears is that for so many systems, the initial install is not secure, might be easy to use, but doesn't have things like password policy. Passwords I think should expire by default. You may or may not agree with me as to where password policy is a good thing, but I think it should be on by default and you turn it off if you feel there's a reason why it doesn't matter at your site. Password complexity should be required because you will forget that you set the initial replication password as password or many other things and your system will go on and be live and nothing will be telling you, hey, that was a really bad idea. Administrators shouldn't be choosing the passwords that one computer component uses to talk to another. They should negotiate between themselves and set something really secure. Replications should be encrypted by default. You shouldn't have to go and think about extra steps to get these basic levels of security around the products. And I think success is also dealing with complexity and dealing with it well. I don't say that the protocols that I work with and we put into SAMBA are simple protocols. They are not. Some of the most fiendish protocols we have out there, they get the reputation they deserve, but they should be made simple for administrators to use in the outset. Kerberos is a great security system. I think it's still one of the best security systems out there. I think it is still being improved and I think it has a great future. And yet it scares the bejeevers of most cis admins. We need to hide that complexity behind things that just work so that we can get the install up without people saying I'm not going to bother with Kerberos because I don't have the time and space in my head for it. We should have kind of software. It should be simple to operate and simple to start. And I don't expect as cis admins to be expert about the whole thing while they're getting started and that I don't think should be revolutionary but too often we expect the administrator to take a lump of text like that and to turn it into something that's secure for their site. Now this is where I wanted to get the runners going. I should have got prizes. I would like you to tell me, you may have got a which of those things in this lump of text you have here present possible security issues that you may wish to correct if you're trying to build a real production implementation. You got any takers? One in the top of the middle. Sorry? It needs SSL on the LDAP. Yes. Any others? I think credentials equal secret. Indeed indeed the the replication password is indeed secret. RID zero is in a security hole but it is going to be a problem when you add the second one if you get to change it to RID one. Any others? SSL being missing is on the provider line on the on the first first line. It should say LDAPS. Indeed using the administrator credentials as the replication password rather than creating a separate replication user because if you did this you would never change your admin password because it first meant going and breaking your database by changing the passwords because you would break replication in trying to replicate in the new configuration and it would all just end in tears. And yet, indeed so I've highlighted those, you've picked them up well, is this just motherhood statements? Are the alternatives just easier? I think that they're superficially easier yet all the wiki guides that I find have these kind of errors in them and that's the best that we've been providing our users so far. What do I mean by I just think that well at least to me I think the things I was just saying shouldn't be news to anyone in the room here and would try and build the and try and that um I feel like I felt rather weird saying we should have all these things as if I was saying something new and yet I find so much software and so many solutions out there not built with those things thought of and dealt with. Well yeah but it's a phrase, true, language matters. So I think this shouldn't be impressive but it seems to be impressive based on where we've come from. The world of SAMBA domain controllers was one where none of these things really were present. So I'll rag on the open LDAP SAMBA pattern a bit because but it's not really fair. It's a bit like complaining about PostgreSQL or MySQL not coming like schemas. Open LDAP is a great tool and I have great respect for its authors. I know its authors quite well and personally but I worry that we haven't built something around open LDAP and we haven't built it around SAMBA as another tool and that we had to get to the stage of SAMBA taking over the whole shop. Does SAMBA not use open LDAP? Can you grab the mic just for your mic's just coming from it. Does SAMBA not use open LDAP? So SAMBA 4 now no longer uses open LDAP. In solving some of these problems we went for a disastrously large case of not invented here and rewrote the lot. I'm not sure how well that's ending up for us. It has meant that when Windows's protocols have varied a lot we've been able to just go with each of the variations and subtle differences and just do them internally. I've got a very good friend, Nadia, who is working for the Open LDAP company SIMAS to produce an active directory domain controller that uses Open LDAP but that fortunately we won't make the admins configure it. We'll just automatically configure all the parts. But yeah we've gone from an externally configured Open LDAP that wasn't our problem and then did that's what I'm going to be talking about to basically doing all the things internally and yeah with a giant cup full of not invented here. So yeah can you get the mic? I was just saying they didn't reinvent all of Kerberos. Now Kerberos we did a little bit better. We simply take the Kerberos system as essentially a library and are able to use it for the things that we needed to do. Fortunately that was we had better relationships with the Hamdoll Kerberos project at that stage. So what's the name of the Open LDAP AD project I was mentioning before? I don't know whether it's got a particular name but it's something that SIMAS Corporation is doing and Nadir and Vinovas doing some work on that. We generally call it the Open LDAP before Open LDAP back in for want of a better description. Good, being derailed nicely. I thought I'd make a very controversial statement here. How much do you think that SAMBA Open LDAP basically take up is not because it doesn't have a nice GUI like AD like Active Directory? Because I mean SWAT never really was much good to be honest. Yeah so how much was our old you mean the old SAMBA 3 Open LDAP combination? Yeah but I mean just as a general more you know SAMBA 4 even you know how much of it is the fact that you know for a lot of admins coming from Windows side of things they go to something like SAMBA 4 and they look at it and go okay now I'm not even going to bother to go down that route. It certainly is a big hole missing those missing those GUIs we have we have a few excuses we so say we can use the Windows GUIs and they actually work quite well although it feels quite dirty telling admins well you've gone and replaced your Windows server and you still run the Windows GUIs to admin it. Some of our admins prefer being able to use some command line tools but we could do with that. We actually ditched our only thing that approached the GUI in SAMBA which was SWAT because we couldn't keep up with modern web security and we never and we have had a few replacement things that never quite got off the ground. It's something that I'd like to see more of but we never really nothing's quite appeared. Okay so throughout nine directory server console I've certainly had some high praise for the Apache. Apache directory studio is actually a really good LDAP client and that's the best one I've found for trying to show people how our LDAP server works because I was trying to do a class once and this has been said oh use of Apache directory studio despite being Java I was very impressed shows my biases but I so what I'm thinking is that many of the things I can plan about really can be done but they have in the past required the configuration of non-default modules and a pile of things that were never that never made the wiki guides the people would blog about having combined all these things as a great achievement they and so they go and they write and they write about it but nobody seems to find that as the default way they build it it's suddenly you know it's a research task so it's a bit of a sales pitch I think that we solve some of the problems here very well but we have lost some other things the not invented here on the LDAP server is really cost us in performance and flexibility we've now built an active directory domain controller and it's an active directory domain controller it isn't much more isn't much less we go and rail about open source being all about flexibility but we have built rather a very nice solid steel box I do have a lot of praise for free IPA I think they've built some very nice things in a similar space they can't handle windows clients directly they sort of say go and trust an active directory and hopefully it's same before someday but the communities are close but they are two different products but what we've done is we changed the active directory DC from a choose your own wiki adventure into something that's consistent and reproducible we changed the constraints from allowing almost anything in the database to a sensible for some degree of sensible you've got to use Microsoft schema and strictly defined constraints as to you know things like you can't have the same username twice we changed security from being optional and after the fact to being on by default we changed replication from being hard and easy to leave insecure to being relatively simple to configure but unfortunately the protocols underneath are fiendishly complex I much rather that we were able to use open LDAP's replication protocols they are much simpler design our drs replication is a nightmare of and not one I would wish on anybody but unfortunately if we want to interoperate with windows we have to do it the passion I'm talking about and I think that most people in the room here understand is is this one I've got here that we have windows machines talking to samba and Linux machines talking directly to the old app server the samba the samba domain is providing an mt4 like domain and that's actually the only reason ever worked because and the reason a lot of these changes happened for samba active directory was that windows clients directly talked to LDAP so we're no longer able to have a totally different LDAP directory because the LDAP port was occupied and needed to look like active directory and has advantages you got replication for free and it solved some really key problems in heterogeneous networks you got Linux machines talking directly to a Linux like LDAP server it was good for the things it did and it's still available what I talk of a samba 3 and LDAP is something we still ship and support but it doesn't give you active directory and so windows clients you have are increasingly not working it's they're meant to work yeah meant just about set registers things and have everything happen but you know there's code in in in Microsoft's windows client that's there specifically and only for samba and we try and get tested before they release each time but there've been issues but it's only loose pattern it never was a tool or a script it was never a document of best practices just documents of the practices people have had and you might not even get a single source of password you might get a samba password and LDAP password if you've not got the synchronization set up they will be different the problem was that things was somebody else's problem so open LDAP is just a data store and it's doing its job really well as a data store and samba just used an externally managed LDAP server we came these things were written in the environment we had the university LDAP server and you weren't you weren't in control of that but you're allowed to connect some things to it and they're willing to be nice to you allow you to to put extra attributes in and things but you know someone else that already built that was had it working so although all the modules and things were there they weren't running by default and you know I think we could do better because I think that smart administrators do actually have trouble collecting the software following internet guides customizing and getting something to work I'm not saying that you guys aren't smart I'm just saying that even the smartest folks have had terrible trouble getting this all to come together well and certainly if you have it's been a great stress and inconvenience and more than should have should have happened because we've missed this box in the middle the constraints the things that make it all fit into regular patterns that we can reproduce and work with didn't belong to the LDAP server and didn't belong to the samba server they sat in a box in the middle that no one was taking care about and no guide was filling up the internet with but it was more than just constraints missing constraints are an important part I believe of a of a good database default ACLs I found I looked at open LDAP and I found the default ACL across the whole directory when you start the one that you're going to build everything else on is two star by self right seems reasonable enough it's a phone book you can update your phone number do you want to be able to update your UID number hey Darryl what number would you like anyone for zero so they're just some simple things that just you know another guides fortunately don't include that but it's you know the starting point matters for these things some guides even forget to mention that you're better secure those passwords and the password histories remember and some things didn't have password sync there are modules you can enable but again they're in there they're extra things to do so then we came along to doing upgrades and installing samba 4 is really easy if you've got a fresh domain now how many people here have a fresh fresh company fresh out of the box they just want to install a directory server for ah you've all got existing sites and want to upgrade oh okay so with things are going to get more difficult so if you had that mythical fresh company that they brought you into samba tool domain provision is really good and it gets you a fresh server all up and going in a matter of a few moments i spent some time on sunday working with the folks who were the open stack folks and we did up a simple template for nova boot and and cloud and it and you know one commander i was having a whole server installed and uh and samba installed on i was quite impressed because i didn't know the open stack bit it was nice to see it was as simple as i hoped but upgrading samba turns out to be a wee bit more difficult given the variety we've had to start with the flexibility really has come back to bite us given infinite flexibility our administrators have been infinitely flexible we've had duplicate sids we've had mixed domains where you've had two different domains occurring in the same LDAP server and some users appearing to come from one and some users appearing to come from the other we've had incorrect sids um we've had duplicate user names people have been able to because at the only constraint you typically have in a LDAP directory by default is that you can't have two DNs the same and unless you make your DNs UID based or if you create separate folders for staff and students or or or things like that you can then have two users the same name now these may well be test users or other things that you have disappeared into the midst of time it probably wouldn't have worked with samba or anything else but i'll position the database until we try and do something as so unfortunate as to upgrade it into a database with uniqueness constraints and the other real doozy that really hits people from the unix world is that users in active directory and indeed in any windows domain but in matters particularly as we go to samba 4 cannot have the same name as a group so we had a number of different users coming through and hitting that case of hey i've got a username and a group name and the whole thing failed we had a lot of invalid account flags we've had a lot of things that have been manipulated by different tools that weren't samba and so we'd combine flags that were normally mutually exclusive we had a lot of accounts who are marked both as both as people and as workstations at the same time and a number of other interesting accommodations i mean one of the biggest challenges is that because samba was just reading and writing a a database that was common lots and different tools manipulated our data and that was really good it was flexible it was all those great things that people want out of their directory but it did make migration a lot more difficult we had users with the administrator but without the administrator seed value because in a windows domain all administrators have id 500 then if they're not 500 they're not the administrator but people had to use a call administrator with a different id we had net bias domains that looked like dns domains that one was technically permitted but we were trying really hard to discourage that and of course people using custom schema and things like that these things that you are using the domains well but they accumulated a lot of history over the time so our upgrade tool became the first physics tool for our samba database it was the first time anyone had ever actually gone over the database and saying do these things make sense so as you know some of and so we what we started doing is we started going the tool from where the database constraints were hitting it to actually putting it first up in the tool before we got anywhere we would import the full list of user names group names and actually do set operations because it was easier to get into that than to get halfway through importing all the users give them a cryptic error message out of the old app back end and then having that all fail so we did a bit of this you know and and and we got somewhere we may actually get most of our domains upgraded in the end lots of hand fiddling but you know not too bad in the end some domains did take a fair bit of time I had one domain of a large institution in the US that was taking eight hours to do the import now I strongly suspect we could have improved a lot of things to help with that but they had about 30 000 users and we had a rather inefficient database but they got all the users in they cleaned out cleaned everything up we automated as many of the fixes as possible so those accounts that were both workstations and normal accounts I basically said if your workstation a normal account may have a dollar at the end well you're probably a workstation account we'll just put you in as that lots of little fixes like that and it seems to have worked the upgrade process was scriptable the results were actually reproducible so people would go through we'd improve the script and we'd improve the database and they automated it all it actually worked out fairly well in the end and it was a success for our users we strongly encouraged testing we basically told people go and take a laptop go and take go and do your upgrade going take a server and put them on an isolated network separate to the rest of your land do the upgrade there check everything's works and then do the upgrade of your main infrastructure because once you do that you can't go back there are things in windows that notice when you've moved to active directory and they won't talk back to NT4 many many sites have migrated some quite large it's actually it's actually worked quite well and basically people are pleased to be able to still keep their their modern windows clients working and working well with SAMBA but there are still a few things we could have done better we don't migrate non-samba data at the moment and I really want to write this script I was sure some admin was going to come along and say hey I'll write an extra bit of the tool that will go and fetch all the other compatible attributes at least put those across and maybe someone else would have written a tool that would have grabbed a bit of extra schema or some of the common other things and got them migrated but people seem to do that and cut few site-specific hacks but no one came back to us with a patch that made me sad we got a few posix attributes across but not as much as I would have liked there isn't any automated schema migration and that really could have been better but one of the biggest things that we've noticed in the upgrade from SAMBA 3 to SAMBA 4 is our most users are surprisingly well not at all surprisingly actually rather formed of posix behaviors they're running SAMBA because it runs on unix and so they've been very disappointed at our poor handling of posix related things we've done very well at creating a windows clone and then forgotten that our market isn't the market for windows clones so we don't do distributed allocation of UID numbers we've kept on saying oh it's too hard you know there are you know you could have race conditions all the rest and we basically threw up our hands when we should have at least appointed a single master's responsible for doing that most of our sites really have two or three DCs the race conditions are not that bad if you know we we chose we can't prove this is correct over doing something useful at all for our admins and I think that was a mistake we don't automatically fill in things like home directories of some kind of template the other things that you need off when you're adding a new user and when we ran windbind on the DC we originally ran one that was our rewrite that had very poor handling of local users one of the things we kept on telling our administrators don't run the file server or anything on your DC except the DC so you'd largely not need to know about UID numbers and GID numbers on the DC because no one would be using it but people want to actually create a combined file server DC because they want to do the small office server that only has one server so admins were pretty grumpy about that and we've now gone and finished up using the windbind D from samba 3 but we still haven't made it really work well for some of our administrator expectations we also don't have sysfoil replication and this is our biggest missing feature where we really have you know thrown at thrown admins under a bus is we not only have no sysfoil replication at those pure marks of protocol level we don't have anything at all we have nothing official from the samba team about how you should replicate the sysfoil share you know some people do things with rsync and sysfoil reset some people do other other things but we haven't just come up with a scripted correct solution that we say everyone should use and we and that's unfortunate because we've done so well on the other bits where we did exactly that we are also working on the appropriate microsoft protocols but it will take some time it does extend we need more out of our base protocols to be able to implement this one every time that a number of us get together in redmond to work with microsoft a little bit more progress is made as we get some key developers together in one room but waiting for september each year for progress is it's painful the other sort of regret i have is that the simplicity came with quite a development cost we wrote our own dns server and now we have to maintain our own dns server because we forgot our own rules we asked the admins to manually configure bind with some very good examples all provided but we asked them to do that and that turned out to be the hardest the single hardest part of configuring an active directory domain controller was actually putting a couple of snippets into into a bind configuration file and getting that to start so we ended up writing a simple dns server and that's now the default dns server and we have and we now maintain that it's really good as a simple dns server and we encourage its use because it's simple but it's part of me that wonders should i have just scripted the startup of bind you know if i knew what was meant to be in the config file why don't i write the config file start it up connect it to the port and have it listen as a child process we've done that with other parts of samba now we start win bind d that way we start s and bd that way and maybe i will go back and start bind that way at some point just to show that it's possible and show that we don't need to be reinventing dns as well but the key lesson i think was the attitude change in samba that attitude that we had for a good time of script it automate it get it to be really simple i think that's something that where samba has transitioned successfully from a kid of parts to a product and it's hard to do in other spaces people tell us that file servers are much more bespoke in all manner of things but it really has worked well but i also do feel for our admins where we get to the end of the bit where samba is all you know nicely got it managed and they're on their own and that's that's not as fortunate and we need to do more to ease people off into the areas where where they need to do some parts themselves beyond samba and beyond windows i would recommend you look at free IPA it's developed as a fairly large stack out of red hat it's based on 389 which was fedora directory server was sun directory nescape and sun directories server long ago iplanet in many previous names a good solid directory and the free IPA project has done some amazing things about also just install so install that in a trial that i was doing inside catalyst recently and it asks very similar questions and it does produce a kerberos server a ldap server a webgooey i need to look into more about how about what it can and can't do but i'm pretty impressed with that and i think open ldap could do the same the parts are available if you want to build a not a non ad active directory that needs to be scripted and automated and samba's actually got some of the code that we need i've actually written inside samba code for setting up the multi master replication between multiple dcs because there was a time when we thought we were genuinely going to use open ldap as the only back end to samba or as the one that would replicate and i actually worked with a developer to actually produce all the config files that produces all of the all the separate replication users with their random passwords and generates it all up so um that's all just sitting in there and no one really knows it exists so i thought i'd just give people a wave and say you know if you want to do this there's some code to steal now i've only got about 10 minutes left but i thought i quickly whipped through a samba status update as that's probably what you've got but i would appreciate more heckling and questions but i'll quickly go through this while you're thinking of them samba 4.2 is due soon finally end of life for the venerable samba 3.6 series we've got improved security some particularly crypto on some of our dcrpc stuff that'll make sure that we have less games able to be played when people are man in the middle in our connections winbind is starting to do secure connections uh to the dc which should again just keep us a little bit more safe on networks that may not be as safe as we thought they were the file server is going very nicely we're getting leases appearing samba 4.2 this is an important feature for file server performance because it means that a file say large you know dvd or or or even an outlook pst file can be quite reliably kept on the client machine while it's being used if it's only being used by one client at a time and we know that that cache is valid the previous solution this was called op locks the problem was that that protocol was poorly implemented by the programs that used it they would often go and break their own op lock and have to and have to release the file back to the server so that's really good to see in we've got snapper support which makes it much easier to get to the previous versions of files in your file system because you've got an outside utility that's creating the the snapshots and we can simply interface that and export those out to windows shares i think that's really neat because i like stuff that just works larger io sizes improved performance and cdb thanks to some great work with amity and others is now integrated into our main tree so cdb is no longer a separate project to samba it's a a supported part of samba itself vfs fruit apple has decided to use sm2 as their main file sharing protocol they've ditched afp and so this is a module that helps make things a little bit smoother when working with apple clients and with working with any legacy clients still using afp make sure that we use the right extended attributes when clients ask them that matches up with multi protocol access in the adc we've got bad password lockout and that's really important some enterprise environments we now got the common wind bind which will gets us a little bit closer to being able to get towards domain trusts and we finish this middle conference we no longer have the ridiculous situation where we had two load palm tools that gave two different ideas of the defaults we now have one of those and some great work from my colleague Garmin sam who's at back at wellington hold in the fort it did some great work ensuring that our documentation always matches our defaults by extracting out the defaults from the documentation and put it and and comparing them in a test suite and another um and ensures that our uh list of parameters always matches the documentation by generating the list of parameters from the documentation so you can't add a parameter to sand without at least starting on the man page which means you're likely to finish it um to do on the active directory domain controller is interforest trusts uh we're getting close um and there's been some successful work doing interforest trust between free IPA and sand before which i'm very excited about uh some domain support is coming along soon we're not quite sure which that's been when it's something i've been working on for a while but i haven't finished landing the patches and finished doing the work we're going to work on performance um our performance isn't great at very large scale so there's the open LDAP effort that i was describing earlier um and um we'll see where that goes or we need to do some other things to improve that um and as i say there's still to do is is better projects integration because i think that's where we really need to go with the dc so that's a quick you know very quick summary of where we're up with sambar um you know i work for catalyst catalyst has been great in supporting me in the same work i've done this is some of the other amazing technologies that catalyst works with um if you're interested in working at catalyst on sambar then talk to me in the hallway track because i'm looking for someone to try and join me in that team i'd like to have a good candidate to be able to put to the bosses um but in the meantime i was wondering can i have some further questions okay one over there and then up the back um i was wondering if recently there's been done any work on the i think you had a python api for accessing the functionality of sambar so if you wanted to do some sort of web interface for it um you so we do have we do have a python api and um additionally most of the things a web interface would need to do would actually be best accessed over ldap and so you can also use the ldap apis to access um access our database most of the things are an administrative tool we want to do it would actually be changing ldap attributes um but we have a great we do have a great python api and that's being used by projects like free ipa open change and also to be able to build tools exactly like that so that's that's there and available and up the outside outside with the dns server you've made does that make automatic updates for host names the dns server will accept automatic updates from windows clients for host names using the protocols that windows clients use to a normal windows dns server and so that will update those um and people have also managed to glue it together with dhcp i think we could simplify that um by using the more standard method but people have managed to script up using kerberos and the full works to to do that and had that work and sambar uses that to update its own uses kerberos to update its own records because we've got to pass special records we've got to keep in place and so we also do dynamic updates for that okay thanks thank you any further questions um so the question was about cooperation with well can you just repeat the question please yeah is there any is there any cooperation between the sambar development team and distributions such as as red hat when it comes to the creation of sambar packages and if that is the case how comes rel7 was released without a sambar tool which makes the configuration so much harder okay so um we have quite close cooperation with our with the distributions um red hats um and in particularly as you would have seen on um earlier in the week i've done the packaging for the the debian uh sambar merge and i work i'm on that packaging team i don't do as much these days but um we're closely with with the debian based distributions we've got a number of team members at red hat um the issues with regard to what things red hat chooses to ship as mostly a policy decision from inside red hat red hat has specifically decided not to ship the active directed domain control controller component until they can rip out the harm dole kerberos that we've used for the kdc and attempt to implement mit kerberos for that that has um they were sort of talking about that when i left them about five years ago and they're still making slow progress towards it the approach that they've taken has they've needed to implement a number of other things in the meantime to enable to be tested we've they've re-registered our test system to move from uh compiler based uh preprocessor based override of sockets to a ld preload for example so some great improvements needed to get there but uh they are still a very long way from implementing an active directory dc and the sambar tool is essentially used for controlling the active directory dc you shouldn't normally need it for operating a file server but you won't be able to run an active directory dc on red hat with their packages you'll need to go and get the packages from enterprise sambar.com our great friends at cernet are providing good packages there and so that's the only way you'll get that or building from source will be the way you get our active directory dc on red hat platforms to the time being i wish that work had gone gone faster but that's a policy matter for them so the same the same thing i mean centos rebadges red hat packages you'll need to go to enterprise sambar to get an active directory dc for that platform on the plus side they were the first to package sambar before at all debian took us nine months to get anything done because they were only doing the file server side so um yeah packaging has been a bit of a challenge for us and i wish we'd managed to come up with a halfway house that they could have lived with um other questions one over here i think this will be yeah where are the times this will be the last question yeah so what is the recommended method to upgrade if you still got a sambar three um domain uh domain controller and you want to want to want to implement the samber for domain controller what you know what's what's the same tool classic upgrades the tool and um basically what you would do is is point that at uh it generally won't write to the database you could point it to your existing elab server with a read only account um you know for safety just to be sure and then run the upgrade on a separate network like never start sambar on your main production network so once you've got the data in you've got it on a separate network then attach a laptop that you had on your old domain to that network and then see how things go check things are working for you to get the upgrade to you know get the script to pass and then when you're happy with that you go back to your main network and you you do your server flip um one of the things that surprised me but shouldn't have was that of course everyone was using the opportunity to go to new hardware so um and that seems to be how people have done it as they then go and run the upgrade on the new hardware and turn those on once once it's because it's scriptable they want they you can know that you'll run it once then you'll get the current passwords some people have done some work to do you know partial migrations where you can do one site on another site um we should probably improve some of that because larger sites it would be very handy rather than having to do it pulling all nighter I'll take this opportunity then to thank Andrew it was a wonderful presentation thank you very much