 Cymru. Fe hwnna wedi'u o'r amlwg nodi wrth gwybwyd o mynd i gennych chi gweithio. Gallwn i'n ffordd fel ymddydd ychydig i'r dwylo. Andrew Watden's dydd yn yw gyda'r hynau i gael a dywedol i, ac yn dweud eloguno eu cerdd, mae'r cyffin iawn i gael pwyntio gan hefyd. Y rhaid efallai wrth datblygu yn siar ei chweithio, na oes chi'n ddweud, dwi wedi'i ei chweithio i wneud gyda'r awgfyn cyfansol, Si'n gweithio i chi nesaf, dwi wedi ei chweithio i chi wedi lei, dwi wedi'i chweithio i chi'n gweithio. Efallai siar mor chi sefydlu am gyfan i mi a chweithio i chi. I'll repeat the question if you don't have a mic so that people at the mic will be able to hear. And also there are, I think, a couple of people in this room who know far more about some of the internal parts of Samba than I do, so at least I know one of them is in this room. So if I get a really difficult question, I may have to hand it on to my colleague Volker Lendecke here who's sat down at the front coding the new parts of Samba as I stand up here talking about it. So by the time I finish my talk, he may check something in that makes my talk obsolete. But that's just the way it goes. So I like to think of Samba as an incredibly ugly, through-legged kitchen stool. You have no idea how long it took me to work out how to extrude cylinders in open office and create that graphic. It's probably the most impressive graphic at the conference, I think. Anyway, so the three legs of Samba that I'm going to talk about that really are what makes it an interesting product and make it the interoperability glue that fits between Windows and Unix are the basic file service which, to be honest, is the bit that I tend to spend most of my time on and I enjoy. It's a bit like woodworking. In the file service, it mostly works, but it's polishing that last piece of wood. You just want to get it perfect. As you do it, you realise you've chipped another piece off and you have to re-carve parts of it. The other part is authentication, which is incredibly important and becoming more important as we look towards Samba 4, an active directory, the main authentication. So I'll talk a little bit more about that. Also, authentication covers the piece that we have, what I call Samba's secret weapon, which is what allows us to provide a single sign-on environment in Windows networks to put Linux and Unix servers in Windows networks. The only part of the stool is the print service, which is a nightmare beyond human imagining. We think we have pretty much working and I'm going to talk a little bit more about that, but unfortunately I do bear responsibility for large parts of that code, so if you have any particular questions, feel free to stick your hand up and I'll pretend I've forgotten. So, three days. We've been going back 15 years or so, and as I like to say, the file service is a reason for the addition to the project, because that's the bit I work on and it makes me feel important. So we're still working on it. It's amazing to discover that things that we thought we understood, new variants of Windows come out and list the tortoise, a few new things, they've just become incredibly interesting and we have to rewrite pieces of the code to get closer and closer to getting things like Windows to mount it. Of course you can never quite get there because a new service pack will change things faster than you can get there. But it's amazing how much we still have to learn. I mean, we recently discovered a new ripple in the way Windows deletes files that actually isn't out in the current stable code branch, but will be released in the next release that we're planning to do in March. Authentication service really started as something that we needed to do as part of the file service and it was as simple as when Windows NT came out, it had the ability to have security ownership on files and we wanted to be able to show the Windows client who owns this file. This led down a rabbit hole that has led all the way through Windows NT domain service and interactive directory domain authentication, believe it or not. Printing, the original printing was nice and easy, it was basically a copy of file to a share called print or a PRN device, so you copy a file and then just send it onto the spooler. And then a lot of us started working for Hewlett Packard, who was very interested obviously in selling ink, which is the main business. Remember, it's not the printer's easy ink, which is more expensive than gold, I think. So as HP likes to say, print more stuff. So they helped us work out how the point-and-print interface works that is still being used on all current Windows clients. And that was fun. We had a preliminary implementation that was done by a sanity member in France, John Francois, and we kind of said, oh yeah, this is working, it'll take us about three months to finish it. About ten person engineered years later, we had something that actually worked. But by that time, made to be hired as well, so it didn't really matter. So, talking about file service, we think we understand most of what we see on the wire in terms of file service for Windows. There are a few things that are a little mysterious. There are actually still a few flags that are undocumented that we're kind of interested in. So, for example, some of the things that we get to do, we've been looking at different ways to do this. These are some of the weirder Windows-isms. One of them is opened by Inode, which is essentially the ability to do a stat.file again at Inode, and essentially open by that rather than by path name. We don't support that. I think that's to do with the search service that Windows uses, because I think it indexes things by Inode, and then opens them later on by that when you're doing a search. That's something that we might get a little more interested in. Purthfile, encryption and compression. We don't currently support that. That's one of the stranger areas. It might be useful to do. So, personally, I think having Unix, having its own Purthfile encryption and compression and compression file system might be a little more useful and just present the uncompressed file back to the Windows client. So, separate data streams per file is very interesting. How many people know a third of separate data streams per file? So, not so many. So, Windows has this very interesting feature that when you open a file by a name, if you had co-op and co-op at the end of it, you could actually open or create a separate file within a file. So, essentially each file acts as though it is a single-level baratria. This was actually used to bypass IIS security at one point where somebody realised that if you actually requested to open a file and you prepended co-on-co-on-dollar data on the end of it, even if you finally weren't allowed access, they were filtering by name and the co-on-co-on-dollar data confused the filter and allowed you to open it. That's the name of the main data stream within the file. Now, I originally was a big fan of doing separate data streams per file until I saw an absolutely terrifying paper on Windows security which showed a virus hiding inside my file.txt in a stream that was called co-on-co-on-virus.exe. And it turns out that the Windows shell interpreter will actually execute something so long as it has the name .exe on the end of it, even if it's a stream name. So there was this utterly terrifying picture of the Windows Task Manager running showing the myfile.txt as a running process which is not something that most people would immediately flag the problem. Currently I've flip-flopped on that and I followed Ted Child's advice on having separate data streams per file is a really bad idea. The good thing about that is for a while we were worried that we would have to support that because Windows was beginning to use it. But what has turned out is that because the internet has become so much more popular and transferring files on the internet has no way of encoding separate data streams per file. The use of that has essentially been curtailed. I'm hoping we can ignore that. So POSIX, which is what Linux mostly implements with a few additions and a few missions is good enough to map most Windows files sharing semantics. So POSIX locks, despite one horrible feature are actually flexible enough to map Windows locks onto. The interesting thing is you can't map POSIX locks onto Windows locks. Which is why FS clients on Windows really suck going against Windows service because they have no way from the Windows API to map POSIX locks correctly. And also the popular Unix's Linux and 3DSD are starting to add some of the Windows style metadata into the file line-ups which actually makes our life somewhat easier in mapping the Windows semantics into POSIX and vice versa. Because the Windows line-ups is just chock full of stuff that normal POSIX doesn't have. So we have to live on the bleeding edge of the Linux and Unix non-spenders which means that I sometimes publish long and completely governments about how evil and stupid the Unix vendors are. So Ackles was a classic one. I think I actually managed to help get Ackles, POSIX Ackles, in full in its kernel. And this was by the simple experience of there was a POSIX Ackles patch which was done by Andreas Skrubacker in Germany which was being ignored by the main line-ups distributions. But I really, really wanted to have POSIX Ackles in Samba across all the different districts. So eventually what I did was I coded POSIX Ackles in Samba to the Solaris API and then published the code and then started saying on the Samba lists, oh well if you want the real files of those Ackles you have to use Solaris. And within a few months strangely enough the Ackles patch was accepted into the Linux kernel. So yeah, sometimes the kernel people do list the publication application space. Currently we're looking towards the NFS version 4 Ackles model which is actually a much closer match to Windows. Note my saying much closer match, I don't see an exact match because how many people here have actually read or played with the NFSv4 spec? Okay, there's only two protocol leaks in the audience, never mind. Anyway, so I'll just give you a quick idea of what the NFS people did which was they wanted to make NFS more Windows friendly so they decided that they were going to adopt their Ackle model from Windows. But unfortunately what they did was they took published specification from Microsoft as the model of how the Ackles were going to be done and they put that into the NFSv4 spec. Now unfortunately for them it's very close but it's not exactly what Windows does. So now we have sort of three incompatible Ackle models. We have Windows Ackles, we have POSIX Ackles and then we have NFSv4 Ackles which are nearly Windows Ackles but not closing up. Oh and the other wonderful thing about NFSv4 Ackles is that they break POSIX amounts which I don't think they understood what they're going to make. Never mind. So other things that are being added are the birth time field in the previous day which Ackle is using which is essentially the timestamp of when the file was created. A lot of people looking at the Unix stat map page see C time and they think that's create time. It isn't, it's change time. There's no way on Unix to tell when a file was actually created. So birth time is the new method of doing that. Sub-second file timestamps. Windows actually counts timestamps in 100 nanosecond Unix from the year 16-0, something like that. Just in case you have a very old file. The doomsday hope or something. So sub-second file timestamps are actually very useful. I mean one second sucks. So that's far too close to granularity. So that's now becoming added. And we're adding code in December to support that correctly. Another thing that we have that we got into Unix early and also into Rx. None of the other Unix vendors picked this up once by leasing which is the ability for a kernel to guarantee to a process that you are the only opener of this file. That means you can do incredibly aggressive caching on the client. Very useful for benchmarks, as the Netbench benchmark shows. But the cool thing about Netbench is because it uses opportunistic locking file leasing. You can actually get a throughput for your server that is faster than the physical capability of the network wire between the two. That's what you're actually measuring these client memory bandwidth. So NFSv4 also needs file leasing. So there's a much better chance that some of the other kernels that we need that we run on are going to start supporting it and exporting it to user space. Of course the APIs that they all choose to export are certainly going to be completely different amongst every single Unix. But hey, that's just Unix vendor's way of sitting in a circle and watching each other over the head. Like the KD versus KD stuff. My favourite joke about that is... As you may know, I'm a veteran of the original motif versus openlock wars. My favourite joke about that is who won in the war between motif and openlock? The answer is Microsoft Windows of course. So I see the same thing happening with KD and KD. Well done, you guys. More things we use in the iNotify interface which I don't know whether you were in Ambrose or what was taught yesterday. Someone asked a question about it. Interestingly enough, the question he asked, iNotify is a method of opening a directory panel and being notified on any file change underneath that bar in that bar entry. Interestingly enough, the question that he asked was that he wanted higher RPV notification is exactly something that Windows provides. You can actually open a higher level directory and you will be notified about any changes in the complete tree underneath it. So that's kind of interesting that at least some application people want that. So we've got iNotify. There's no little links in the base called iNotify, which was horrible when I was using iNotify, which Volker just bought it from time before. We're hoping that this will be adopted as standard across the other union extenders, but like I say, I don't know much hope. A synchronous IO, again something that Andrew talked about, we currently try and support POSIX standards as much as possible, so a synchronous IO code is actually built on top of the POSIX real-time AIO standard. If we get a better version of that, we may end up building a compatibility layer and using that instead. It was really cool, but actually not very much used because Windows Pilots would not pipeline reads or writes, they would do a read way for a response, do a write way for a response, they wouldn't fill the pipe. Our SMB pipeline code was the only code that we knew of that would actually correctly pipeline reads and writes. But we've got some early reports coming from the main list that Windows Vista actually does correct an async IO normal pipeline reads and writes, so that should make things much more interesting. The other thing is the notification mechanism for that. Both Linux and FreeBSD use an interface called K-Event. The great thing about K-Event is it's spelled exactly the same in both systems, the bad thing about K-Event is it's completely different on both systems. Well done Linux vendors and kernel vendors. So what do we do about the pieces of Windows that is done to map very well to politics? Well, we emulate them essentially. I mean, this is the hard part of Sandler, this is at least to me the fun part, is how to map these somewhat different Windows semantics onto a politics model. So we have to have mandatory file locking because that's what Windows might expect. We have to have some very interesting delete and close semantics. That kind of fun. So with Windows, with politics, when you delete a file, it just disappears from the directory listing. It doesn't matter how many of the people have it open, it's just disappeared. It will remain active until the last open and has closed it and it will go away. With Windows, the semantics are really interesting and different in that you can open a file multiple times and one of the openers can set a slide that says please delete this on close. At that point, we know that opens are allowed, but the file remains in the directory listing until the last open and has closed, then it's deleted. So, I'm sorry? Yeah, there's all sorts of strange little restrictions that are actually part of the underlying Windows. So if August comment was you can't do a stat on it. Yeah, there's all sorts of strange little restrictions underneath that are actually exposing the Windows implementation, which adds credence to my assertion that SMD or SIS is Windows on a wire. Now, the interesting thing about that is we used to ignore it, but the problem is applications depend on it. I mean they do. The biggest and most wonderful example on this is Microsoft Office, which does weird stuff that nothing else does. Microsoft Excel is probably the best test application for a file server I've ever seen, because it does things that nothing else... You will never see anything else do. It's amazing. It's a very interesting application, actually. So, let's see... Oh, share modes, which is another Windows-ism which basically allows you to open a file and say, I don't want to let anyone else open this file while I have it open. I actually found out the history of share modes if anyone's interested. The original creator of the SMD protocol was an IBM employee called Barry Feigenbaum, and at the last one SIS conference, Andrew Triff, the clever part of Sandberg, who works for IBM, he actually got Barry to fly out and give a talk about the original 1.0 SIS protocol. I basically went up and said, why did you do this to us? It's the most horrible thing you could have ever done. It turns out that when they were mapping SMD to DOS 1.0, they realized that most applications weren't written to allow multiple file opens, i.e., a network file server. They already had five important applications in how they would behave in a network environment. So they added share modes to make sure that the clients could exclusively open a file. Because of this, back in 1982 or 1983, everything else has followed from that. Of course, the fact that you can deny other openers is the main reason why cluster Sandberg or cluster SIS is extremely difficult. We actually think we solved that problem now, but I'll talk about that in a little while. The file serving code, I can proudly say, is probably the best testing part of Sandberg. Not that I'm great at my own test code, but we actually have a torture suite, which is part of Sandberg 4. The nice thing about that suite is it's run on every single template on 20 or 30 different systems. So if you break something, you find out what it's immediately like. People occasionally actually read the email that it says. Not often, but you know. So we've sort of had a health state of Sandberg. I think we're broken on 13 platforms right now, but they're platforms that suck anyway. So, here's the new stuff, the thumb stuff that I'm doing a lot of work on at the moment. SIS is in your future. So is there anyone here who doesn't have Windows desktops at all in your organisation? Yes, virtual machines count as Windows files. Sorry, okay. I don't know who you work for, but you know, can I have a job? Sorry. You're so employed and you have no Windows. Ah, you're living in your parent's basement. Ah, that doesn't count. I didn't have any Windows when I was living in my parent's basement either. No, no. Anyway, so everybody has Windows. Everybody has Windows. You know, everybody's going to have Windows. It's a foreseeable future. And essentially, if the Linux desktop is going to thrive or going to survive even, or the Mac desktops, they're going to have to live in this world, right? So, you're an IT support guide and somebody says to you, I want to put these Linux desktop plans in, but they're going to need different servers because Windows won't serve NFS. No, I think we'll just roll out some more Windows, thank you very much. So, essentially SIS is the protocol, SMB SIS is the protocol that's going to go to the desktop. It just is. So, it adds your, really, the sanity on the Mac OS and the Linux plans to make this as seamless as possible in a Windows environment, and also to fix SAMBA so that Linux and Mac clients work a little better against SAMBA servers than they do against Windows servers because, hey, we have both sides of the code. We can do some interesting things. So, let's see. IBM has full-time engineers, Steve French, who's out working at Connectifont, which is where the switcher comes from a couple of weeks ago. Full-time working on Linux 6. Apple has a couple of people working full-time. They came out, we all sat together. There are actually now four different client implementations. One of them hasn't been announced yet, so I'm not going to talk about it, but there are four different six client implementations that are starting to implement extensions to the SIDS protocol that have been defined to make units to unix SIDS a little easier. So, we all collaborate, basically, and we know the servers in fact. Can you ask a question? Great! The first question. I wish I had a prize to give you because it's like... Are you going to organise that? Oh, okay. Just sorry. Just wondered because... So, just look inside. The organisers have done a fantastic job at the conference. I just want to say thank you, because this is a really, really great conference. Anyway, sorry, back to your question. So, the comment is, NFS really sucks very, very badly. Don't you think Sambra is better? I agree! In fact, I gave a talk at the NFS conference called SIFS to the desktop or the death of NFS, which they really love. They thought that was a great talk. So, yeah, I mean, the goal is to make SIFS the dominant desktop protocol. Is it going to dominate on the back end when you've got big Oracle I am talking to, you know, NAS stuff? Almost certainly not. That will be NFS before, or hopefully some more intelligent protocol. You know, pay maybe AFS, who knows. But I think to the desktop, and in small clusters of machines, SIFS really has won that war and will continue to dominate. So, what we really need to do is to do what we can in our own environments, even if there's no windows there at all. So, after running the Unix extensions, I don't like to pre-announce to them, but I think I've already said that, not late. So the goal for the Unix extensions with SIFS is essentially to modify it as little as possible, right? Because we don't own it, right? I mean, Microsoft is the company that's driving most of the changes to SIFS. But they did give away a small piece of the SIFS space. There was originally requested by SCO and I'm talking about the original SCO and I'm talking about the current base SCO which was Caldera. So the original SCO designed some Unix extensions which HP also adopted. And essentially the early design of it was how do you do Unix that and get the metadata that we need? So it's been since expanding, so it will do POSIX locking. So the amazing thing about this and the thing that I'm really proud of is we can run all with the current Unix kernel and the modern version of Samba we can run all of the current POSIX locking performance tests and we can pass them all. I don't think any of us has ever done that. Not even to why all these streams have ever done that. So yes, we do all of POSIX locking completely correctly. We also have an on-the-wire method of getting and setting POSIX icons which is pretty important mainly in pure Unix environments. We also do Unix style extended attributes and while I was at Conectathon we sat down and designed and implemented POSIX variants for open, make-dear and unlink. The interesting things about designing the Sys extensions is working out how POSIX calls interact with Windows-specific calls when they're being done at the same time and then the Mac guys really screwed me over by saying, oh yeah, because we have Cocoa Carbon and whatever it is Cocoa Puffs subsystems or whatever they've got running on their thing we want to be able to do Windows calls and POSIX style calls on the same connection. Sometimes to the same file. Oh great. So that made it a little more interesting. So once we've got the code open running in the best form of RFCs, we're going to wait until the code works then we're going to write down what we did. And at that point, I'm hoping that we will have four clients. The three I can talk about are macOS 10, Linux and HP UX has a Sys client. There's a four that will be coming out soon. Once those all support the Unix extensions what I'm hoping is that the other two hands vendors are basically EMC and NetApp stop implementing that on their server side. I know NetApp is interested I'm not sure about EMC. We'll know if sort of long form server supports the Unix extensions but I'm not holding my breath. So a quick break and then I'm going to slow. So authentication so we started off essentially just wanting to authenticate user first by plain text because windows originally when we first started windows didn't really have any security it was just a username and logged on that was it. Then you had shell or security. We originally adopted the lagline challenge with some help from a friend and engineer in Microsoft's two children nameless. The main controller, the whole main controller thing just we didn't care interested. But what happened was windows NT came out and it had access control lists. We really wanted to have access control lists because we knew we could do that in POSIX. It's a better map to our POSIX model. So we were able to give out access control lists but as soon as we did that what we found was that the windows clients started making as soon as we said oh yeah we support windows accords. They started making all these other calls that we didn't understand. So a lot of work we've done over many years and we ended up with an implementation of a program called DCE distributed computing environment remote procedure calls to implement this and once essentially once you've solved that part of the problem you're like 50 or 60% of the way to doing the full domain control. So it was like well why not finish it. So that was essentially what happened. That's how Samba became an NT4 domain controller because originally we were just a file server and we really didn't care. Now in most enterprises, at least in the US Active Directory is kind of taken over as an authentication source so Samba 3 really gets deployed as a member server in an Active Directory environment. I'll talk about Samba 4 in a little while. So wind bind how many people here are actually running wind bind? The rest of you suck you should be. All right, it's not easy for you to run wind bind right now. It's difficult to set up but hey that's Samba, that's one of the badges of honour if you get Samba branded on your phone if you set it up correctly. So just on the side, the goal for Samba was like we'll do you a great file server and then someone can come along and make some money by doing really really cool GUI administration tools. Unfortunately, nobody seemed to do that. Anyway, a few people have. So wind bind is really the secret weapon of Samba. Wind bind is a single-signal agent. It allows Unix, UIDs and GIDs to be mapped into Windows SIDS. The cool thing about the code that will be coming out and as we test the large scale production systems is that it will handle off-line authentication. So here's the cool thing. You can take a Windows laptop and then its laptop. You can join it to an active directory domain. You can say shut down or hibernate close it, pull out the network cable take it home bring it up again and log on using your cached credentials and everything works. See the users, files or whatever or VPN in, everything will just work. You go back to the office you plug it in again it will refresh your servers credentials for you. Right now the only Linux that has this is the Neval Suzy Linux desktop. Because that's where I was when we developed it. Now hopefully it will be added to a lot of the other Linux vendors. But it is the complete single-signal that you really need for interoperability. It's incredibly cool. It does require a little bit of setup so what I'm hoping is that it gets integrated into other Linux vendors and hopefully I have my hopes although I'm not counting on it I hopefully get it put into Solare so that this will become a standard and will become essentially the single-signal solution for unique servers living in Windows networks. There's some problems. Mainly because posits sucks and the problems are scalability. So let me explain why. I don't know whether you've noticed but sometime around after Windows 2000 shit all the interfaces in Windows for looking up a user or a group stopped being a drop-down list. The GNOMEKD people still haven't got this. They still don't understand. The Apple editor has recently added to Nautilus and when you want to add an entry to an app you have to click on a drop-down menu and it expects to be able to show you every single possible user in a drop-down menu. Oh, great. Imagine that you're running in some of the environments that Active Directory runs. Active Directory is deployed in global networks where you have servers in Canada, US, Europe and Bangalore and the links between them are nasty web pieces of string that go down often. So, oh and you have 150,000 users in the database and that's not even counting the groups. So, now tell me how the drop-down interface that I have in Apple oh, wait 30 minutes while I try to contact every domain controller in the entire world. This is not a scalable solution it's not going to work. Windows has searchable interfaces for all of these things. You bring up an Apple I don't know that in Windows now and you say I want to add a user it says okay, here's a search box search for that user and then you will actually do an efficient lookup. The problem with our environments the Linux and Unix environments is that we only have the POSIX interface and the POSIX interface is done and old and expect to have cheap local lookups. That is no longer the case. So, we have to do things like that the only interface for enumerating users the searching for users is to search through the entire list. The get-gen on Apple which returns the group information one of the things it returns to you is a list, a text-based list of every single user in that group. Mostly when you're making that call you just don't care. You only want to know what's the group idea so it's just incredibly efficient and badly designed for big global networks. This will have to be fixed I don't know how we're going to fix this it will probably be some collaboration with a lot of the Unix vendors Apple's some Unix vendors and the Geolix C people but we have to have a better interface than this because otherwise we're kind of broken. The other thing is Windows are one of the groups within groups which is very important for very large networks. So, we actually have a feature in Windwine where essentially it will unroll that into the full list of users for it. But it's a little clunky so we kind of need better interfaces for that. So, what being a DC is has changed a great deal since Windows NT4 came out and Active Directory is really now mandatory. And that essentially is the goal of the standard 4 is the primary thing to the Active Directory to make control but it's very very hard. So, you know, why is Active Directory so difficult? Why hasn't it been done? Well it's not just one protocol if Active Directory was simply just doing LBAC it would be done by now it would be purchased over an LBAC and it would be finished. The problem is when Windows funds start talking to Active Directory they say I'm in an Active Directory to make they will start doing they will just do one call they will do a call to something called Connections with LBAC which we now have implemented. Then once they get information from that they will start to encourage queries the tickets they get back from that they will then pass into a DC of the sequel tunnel of a SNP the information they get back from that they will then use to do a straight DC or a TCP call the information that comes back from that then starts getting fed into LBAC queries then falls back to doing some more DNS you get the idea. Any one of those steps fail and the client says I can't talk to the nine controllers it's not only Active Directory to make you need the Active Directory data model and the schema Essentially you have all these different components they all have to talk to a common backend store they all have to be completely integrated with each other. You come in and you change the password via LDAP you have to see that and cover us you come in and set the account restriction via DC RPC via LDAP you have to see that everything has to be seamless because that's the way the Windows 5 is expected so all the components on the previous slide they all exist in the free software world I mean pieces of them are everywhere up I think the DC RPC code has now been released by NISL it's all out there but they're not integrated and integrating them together and making them look like that seamless whole is a very hard job so one of the things that Samba 4 is doing is that they're trying to work out how the integration has to work how the components have to fit together now one of the ways that that's being done is by writing and replacing those components so the technical and the high goal code won't render that into the tree the LDAP server is actually new code it's not based on open LDAP wasn't my decision that that's not what my I'm I'm not too keen on that decision I think in the long run we will have to start using start sharing code and start using other people's projects but I'll talk about that in a little while the DC RPC code is very clean very nice it's actually much nicer than the DC RPC code that was published by the opening group so I think we'll end up using our DC RPC code for that so the goal is that eventually what we'll have is we'll have a Samba 4 active directory to make control because the final print service aren't being worked on so much there with Samba 3 member servers and then eventually we'll be able to migrate slowly forward so it reduces the big bang effect of having to say right here Samba 4 everything you knew is wrong all what's wrong this way allows us to say that active directory to make control of the Samba 4 but you can leave all your members' servers in place and they'll add them the same way so basically the problem of printing thank god Cups is one that the printing API is dominated all of the unices which is great because at least it gives us one target that we have to write to so printing these days is essentially just translating the windows primitives into Cups course which is a lot easier in my set so the current windows printing is built on an incredibly baroque set of DC RPC course I have a separate presentation I gave a few years ago on why printing sucks so I'm not going to that too deeply the interesting thing about the windows printing is that it actually is tied greatly into the registry so what this means is we need to have a windows registry on the Samba you're going to make a comment on that? oh five minutes okay I'm going to hurry up yeah there's some issues with printing this is one of the reasons why windows NT on alternative architectures like Alpha and PowerPC never made it because you think the windows display driver people the windows printer driver people are some of the worst code in existence it will do things like set something via a printing RPC core and then expect to read it out of the registry and the two things have to match so this is what led to the creation of the Samba registry mostly our code here just works the only thing that gives us difficulty is what's called server type server type rendering where a client sends an EMF file an enhanced metafile format file over to the server and says to the server here you render this for me we were quite worried about that becoming a standard but it turns out that this mechanism just sucks because what it does is it eats up CPU cycles on your servers so you've got this two giga nerds client sat there doing nothing but capturing key presses the word and then you're pushing all your print rendering onto a completely overloaded server so they seem to step back from that and they seem to be doing more client-side rendering so quick aside for the fourth wave which is stuck off the side of the file service which is the RPC transport so it's kind of a hidden part of windows everything in windows everything remotely in windows these don't have an easy RPC how many people have played with or know anything about Sun's RPC not so many if I'd have asked this 10 years ago the whole room would have known so I guess DC RPC really has one which is a shame because there's a protocol it sucks it's horrible, horrible, nasty and disgusting it's designed for the 1920s processes or whatever when having a network bind order format was so expensive that you can send the bind in any format when you just set a flag to say whether it's big and a little onion which means twice as much code on the server it's horrible anyway, but it's very popular Windows uses it a lot Samba3 right now only supports a tunnel over SMD and Sys we will eventually need to support this overall TCP Samba4 already does so so we need to merge that code Samba3 has some hand-written marshalling code and the RPC is to write a what's called an IDL file which describes the protocol and then have that auto-generated via a programming tool into code because we were stupid we did it by hand to start with and were finally getting rid of that the nice thing about doing it by hand is that you can add in all the security checks that Windows didn't have like have we run off the end of the body yet have we run off the end of the body yet Windows didn't bother with that originally think they do now so it's horrible to extend and we have finally got a proper auto-generated RPC code PIDL compiler for PIDL based IDL compiler from Samba4 so, here's an example I don't know if you can see it but it's actually the registry editor on Windows looking at a Samba box isn't that weird that there you can see it actually looking at the PostFix SMPD service which is a process running on a Samba server and as you can see it looks pretty much like a Windows box but it's actually working against Samba on Linux weird huh very cool well so here's something else that I never thought would be done because it's so hard and disgusting but a commercial company did this and donated the code so here is the Windows performance monitor on the Linux box compiling Samba and it's pulling the information out of slash proc and formatting it as registry data and sending it back via registry calls which is how the Windows performance monitor actually works but it's very handy and here's Samba acting as a universal administration tool so here is the PostFix Daemon being stopped started via the Windows service control manager now you laugh right but tell me how many Windows admins in your organisation would you trust to give root on your Linux service to do this they like this they're used to this you can control what they can do very good let's get on to Samba 4 it's like flying an aeroplane dismantling it and building another aeroplane which is also flying at the same time as you're moving along so it's a bit complicated and also you might crash a lot so it's it's kind of fiddled so where did Samba 4 come from what is it I like to refer to it as the research arm of Samba so basically Tridges smarter than the average bear is looking at the Samba 3 code and he finally got fed up with his drinking crack code from 1991 and said this stuff is garb Jack can do better this, I'm going to do it again so he did it was originally started as a new VFX virtual file system interface that would match the Windows style so the Windows format takes much better and it just kind of grew but it turned out to be a technology worldwide in terms of stuff that we can use in the production code so it created PIDL the IDL generated compiler means that we would place thousands and thousands of lines of generated code with all the generated code which is easier to make sure it's secure it's a lot easier to change and fix etc TALAC this has started to be using other projects it's essentially, as I like to call it C++ object in a kind of a mean way it isn't like C++ but it's a hierarchy a new memory allocator that allows you to use the C++ trick of resource allocation is initialisation and destruction so you can essentially destroy a whole hierarchy of objects by just destroying the top-level context transactional TVB this is going to be extremely important for clustin sandwich where you have multiple sandwich heads plus the TVB's infinite manual getting internet transports behind it LDB which is an LDAC search interface stacked on top of TVB so that it solves the multi-indexing problem that you have with a trivial database and that eventlet which is essentially something that sits on top of all the different, horrible methods of doing asynchronous event notification and makes it a nice, easy news API which actually handles signals the problem is with most of the other apps I asked Trich, I said why did you not look at LibiMent or there's no one out there and he basically said no one handles signals and they can't do it the right way so he wrote his own it's kind of clever enough to do that so what we're doing right now is sandwich always developing these things as they become mature the people mainly working on sandwich 3 sort of go well actually you want to steal that eventually the idea is I think this is my next slide and I'm running out of time again sorry isn't it a fork? people say oh have we got a horrible fork? yes we have a horrible fork it's true, it is a fork but it's actually beneficial because what it does is it allows new technologies new ideas to be tried out in a way that we simply can't do with the production sandwich base unfortunately sandwich is too big for a number of users out there we just can't be as irresponsible as we really are we just can't break it in the way that we really like so sandwich 4 allows things to be weirdly messed up and broken and what we're trying to do is to convert to the two code places so the goal is that we'll eventually ship a working active directory to make control with complete farm print service and when we do that what we call sandwich 4 complete what that code will look like I'm not sure yet probably some kind of mutant hybrid with three heads of both branches merged together probably won't look exactly like sandwich 4 it certainly won't look anything like sandwich 3 just today but hopefully it will be a lot better and more interesting and fun to work on so the questions remain about the AD technology I mean how do we use hynny or MIT corpus which is kind of one the corpus was out there how do we integrate with the DNS and the DHCP server what we need to be able to do active directory properly this is just my first opinion is that we're too small a group of programmers that's probably 5 to 10 really active people we're too small to support all these protocols ourselves we need to merge with other open source projects I don't mind as being the glue we've got all these things together but I think we're too small to be open L bound bind MIT corpus and everything else all in one go we need to share with these other folks so my wonderful also extruded log challenges we face going forward Windows isn't a static target because we have to have a Vista books washing day after Vista shared because we were working we thought perfectly with Vista release number one but they changed a few things between that and the release so we needed to to have some patches put out on that so one of the interesting things is SMV2 which appears to be eating my file service so SMV2 is basically the new Microsoft don't use this use that this is shiny and new file service protocol the way I like to describe that is at least the six we've been on the treadmill that's been run by someone else for quite a while and we finally stack it to the front and we've got our hands on the throttle you can slow it down a bit and so everyone's sort of like oh thank god we're now walking at a steady pace and then someone stands up there from Microsoft and say hey look at this treadmill this one's new you can watch the end look it you've got a static it's got pictures it's new, painted new and sort of breath the struggle and already I see a few of the NAS vendors going oh that's pretty cool maybe I should struggle a bit on that so I'm hoping to sensitively keep the old original SMV SITs alive as long as possible the SMV2 essentially Vista when he talks to a SIT server it adds SMV2 as a new supported protocol and if the server the new server replies yes I support that protocol the entire organization is different it's essentially it's almost like you send out a SITs packet you get a response and then you start sending NFSV4 it's kind of like that it's different it took Trinch and a few other people about six months to work it out so that's quite a while but we do have a working client implementation it wouldn't be too difficult to turn that into a server implementation I'm guessing in three to four months if we had to do a crash program I'm hoping that we don't so there's SMV2 coming along there's always new IP directory calls and some interesting wrinkles coming along in the authentication piece I can't talk too much about that but this just let's just say the client and server are pretty close in time together so as the client's rev the server's rev interesting things turn up and the other thing is the server-side print rendering server-side print rendering is interesting because it depends on Windows DLLs being loaded from the client onto the server when you install a printer and being wrong as Windows processors on the server we can't do that so server-side rendering is a big threat for us for this talk I went over and I looked at new XPS and EMF XPS is a new print service and I couldn't see anything that may depend on server-side rendering so I think it's a new way of doing the rendering in the client it's a whole new print engine but I think when it comes down to it at least the part that we care about which is the network protocol it's simply a new set of rendering on the client so I'm not too worried about that right now although I may get panic calls from HP saying oh my god we need to sell more ink this is not working with Sanda so coming soon one of the interesting things about Sanda is it seems that at least our own treadmill the development treadmill we seem to be accelerating as we go along so cluster Sanda is currently being designed by Trinch as a test base in Sanda 4 it will probably be backported to Sanda 3 with some interesting changes what it allows is for multiple Sanda servers on separate machines to share a common distributed file system running over a Sanda something similar and all of those servers to provide exact window semantics so that's a client opening a word file on one server will be seen as an open word file on another server and one of the IBM guys at Samba XP last year did a brilliant demo using VMware on a machine much more powerful than mine to show open office from a Linux client connecting to one server and a Windows client using Microsoft office connecting to another Samba server and opening the same file on a third server or running on his laptop he had a beefy laptop on a distributed file system and each of the programs could see the others open this file is being opened by another user and you want to wait until they close that kind of thing and it all worked across 1, 2, 3, 4, 5 machines which was pretty cool another thing that we really need to have because of my one buzzword on this line virtualisation what does that mean anyway we need to be able to to me what virtualisation means is when you previously had to manage 300 servers now you've got to manage 3,000 which are the same crappy tools just as a question I ask this in England how many people have actually lost a virtualised server? I just mislead it I managed to do that I had a bunch of virtualised VM virtual machines running and I lost a Windows I knew it was on the network and you know on one of my IP addresses I just couldn't remember where it was so I had to basically scan the address base until something responded up to 6 oh that's where it is so virtualisation is going to suck I think for management so we need to jump on the buzzword bag and make samba very friendly for virtualisation and that means being able to deploy a samba server from a virtual machine and have it pick up its SMV I've got to finish pick up its SMV.com we also need encrypted services because NFSV4 has encrypted transport and we have to be better or at least as good and we're going to do group policies as soon as people have what they need in our Linux world and I'm wondering does Windows admin will love us because they love group policies okay so I can't do it 10 minutes at a time so are there any questions that you didn't want to ask during the talk and you want to ask now questions, comments, yes so the question was are there any benefits in SMV2 or Microsoft making life difficult SMV2 does have things like transaction support and it also has 32 bit reads and runs and the benefits claim on the website are that it is great in large latency connections so fantastic so Trich decided to test this so he brought up Windows Explorer and made a connection looking at a standard directory made a connection by SMV and he counted the packets and then he did the same thing with Vista doing SMV2 on the same directory and the number of round trips to the server is twice as many as SMV2 so I think you can decide what that means in terms of how well it will work on high latency links does that answer your question any other questions you were putting oh I'm sorry yes good point Volker we have a conference coming up if you're very interested in SAMBA you want to get involved in the environment we have the worldwide SAMBA conference coming up which is in Goettingen on April the 23rd to the 25th so go to www.sambaxp.org www.sambaxp.com I can't remember just google search for SAMBAxp and you'll find it there so any other questions or alright thanks very much