 Hello, I'm Steve Gallagher and this is an ORA server, past, present, and future. So, what are we going to talk about today? What we're going to talk about today is where have we been, where are we now, and where are we going? So, let's begin with the past. In the beginning, the technology world was without form and void. It was very boring. I felt that most people did things with their own two hands. Terrifying. But over time, complex life appeared. And we started developing these new technologies, these new capabilities, and we have these two massive monstrous organizations that are behind much of it. And driving our technology, but stomping on a lot of things in their way. And we got a good start. We started finally doing some really interesting things with technology. We started doing more than just word processing and lemonade stand. People started using technology for more complicated things. They started using it for managing their networks. They started creating networks. And as they started doing more and more interesting things, they started feeling like, I don't have a whole lot of control over this stuff. I mean, I can do these cool things, but all of my innovation is kind of held up. It's kind of limited by what these two titanic organizations say you should be able to do with this stuff. But then something happened. Something very, very big happened and the world changed. Litics. It was brought forth like fire from the heavens. And suddenly we had control. We had the ability to make some of our own choices and to decide for ourselves what our fate would be, what we can do with our technology. And we did. And it was good. And we started to develop all these new, powerful innovations. Things that we would never have thought of when we were basically a two-company world. And this is kind of where Fedora and Rel really began. And Red Hat Linux. Red Hat Linux was ultimately one of the first very successful Linux distributions. And it was very heavily driven by server people. It was driven by IT people who wanted to take this new technology and make it their own and power their applications. And from there we got really big ideas. We've done some amazing things. Back over. Yeah. From there we've done some really amazing things. We've put satellites in orbit to play music. We have built new and amazing drones. We have built robots. We have created technologies to balance our checkbook to make sure that all these cool applications and video games work. We have built the internet on the back of this technology. And IT administrators have been at the heart of it. Making sure that those things stay up and running to make sure that your paycheck, when you get it, is correct. Make sure that when Wall Street execs get their book, you don't want to pass on that one. To make sure that everything stays up and running. They were our first constituency. This set of people for whom the most important thing in the world was making sure that everything else in the world kept running. But time passes. Fedora and the Red Hat Linux community, they evolved and they became more diverse. We started as a group of people who wanted to keep everything running. But those same ideas that inspired us, that ability to innovate and create for ourselves, meant that we had plenty of new ideas and a lot of that evolved into, well, I can do anything I want in my server. Why can't I do anything I want on my desktop as well? And so we had a very large constituency start growing up in the Fedora community that was very heavily focused on the desktop. And because this is so visible and so, and comparatively so easy to get into, this grew much faster. And we started having a situation where in Fedora, we had these two often competing constituencies because, of course, a desktop person wants to move fast and break things. They want to get the newest and most exciting things out to their users and change everything whenever they realize something is broken. And that is a fantastic thing. But at the same time, it was slowly starting to relegate those old timers and those initials, those first constituents, the IT administrators, into stop energy, starting to create a feeling where they weren't any longer the main focus and that all their ability to contribute was to say, no, no, no, no, wait, wait, you really have to keep the firewall off. Or no, no, no, the default has to be set this way or it's not secure. And this led to a lot of friction on both sides. And so about two years ago, Ed Plock in Charleston, we started talking about a new plan. And that was that maybe Fedora, the OS, does not have to be one thing to all people, which, as anyone can tell you, will never be the case. Instead, we decided to try a new thing. We decided to try to split Fedora into three pieces, into three deliverables, three additions. And these are the Fedora server addition, which was going to focus on that first constituency. The old guard, the people that have machines that they need to stand up and make sure are still running five and six and seven years from now. And the ones that want to have hardened defaults, and the ones that want to build a platform to build long-running software on. And then we built, that's right. And then we also split out to the workstation. And that was going to be a platform that was going to be very heavily focused on desktop, with a particular focus on developers and content creators and, you know, as the maker people would like to say, the doers of the world. And then we also had ideas for how we were going to build into the new world of containers and rapid deployment DevOps model. And for that, we also spun up the cloud addition. And that's doing some really exciting things, too. And there's a lot of talks about that this week, and I encourage you to go to them. So that's where we are today. We now have this segment of the Fedora project all to ourselves. And I speak, talking to the IT administrators and the people, you know, in this room who at least started out in those places where they were maintaining software for other people. And God bless you. And so that brings us to where we are today. I'm going to talk a little bit about some of the neat technologies that we've built into the Fedora server addition, which began at Fedora 21. We've had now two releases, Fedora 21 and 22. And the 23 alpha was just released yesterday. Many of you were instrumental in doing that, so give yourselves a round of applause. So let's talk a little bit about some of the really visible features of Fedora server today. The first one, and probably the most visible, is the cockpit admin console. One of the key fundamental tenets about the Fedora server project is that we said right from the beginning, everything we do on Fedora server and everything we ship as part of the Fedora server must be capable of running heavy loads. Our expectation is that if people start deploying this, they're going to be deploying this in a data center where they may not even have physical access most of the time. And so the idea is that everything we ship has to be accessible remotely in some manner. But at the same time, we have an environment where Linux classically has not been terribly novice-friendly. It has not been a place where even someone who has a high level of skill in another operating system can readily come over and say, oh, okay, I can do those same things here. And so cockpit has become one of these places where we're trying to address some of that. We're making a discoverable graphical user interface that is remotely accessible. It's web-based with some really cool JavaScript tricks and hacks. But it allows us to provide an interface that is at least competitive with some of our more obvious competition out there. And it allows us a place where you can come in, you can manage the OS in a way that is really accessible to human beings. You can come in and you don't have to learn a dozen MDADM commands and three LVM commands in order to set up that extra hard drive on the system. You can boot into cockpit and use a very easy graphical management tool. Similarly, you can configure your networks and monitor your logs and take care of your service management through the cockpit interface without ever having to get into a shell. And with a sufficient amount of on-screen prompting that really just walks you through the process. I like to say that one of the things that Microsoft has always done better than Fedora, better than Red Hat Enterprise Linux is their Windows Server console. When you start with that server manager, when you boot up Windows Server, the first thing it does is pop up a nice little UI that says, hey, here's a bunch of things you might want to do with the server. Click here to do them, and then it walks you through a wizard. Up until cockpit, when we start up a Red Hat Linux system or a Fedora system, we give you a console prompt and if you're lucky, somebody has bothered to give you a Linux for Dummies book. And it's really, really hard to get over that initial hurdle of, well, where do I go from here? So cockpit is really meant to be that place. And additionally, now with some of the stuff that we're doing in conjunction with the atomic project and the add-in cloud group, we're also using cockpit to manage our container story. We're doing things like being able to pull down containers from the Docker registry and start them directly from this UI again without ever having to look at a console. So we can get a lot of those really neat services that are available on the registry deployed trivially onto these systems. And again, you can do this without three advanced degrees, and that's a major advancement from where we used to be. I can't tell you how many... Since it would be a release of server edition in 21, the first real public release of Cockpit, people are talking about it. It is seeing lots and lots of press in the tech press. It's people are coming in... I wish they would start sending mail in the Cockpit development instead of me directly, but I'm getting lots of mail. I'm getting at least three or four queries about it every week directly. And so it really is catching attention and it's doing a lot of really cool stuff. Another piece of really cool stuff it's doing is again with the cloud group, we're focusing pretty heavily on Kubernetes. And one of the things that Cockpit does, and I wanted to originally have an animation but I couldn't get one up and running this week, but it has a really neat topography graph that you can monitor in Cockpit. So when you tweak your Kubernetes configuration, you can watch live as the services come up, where they are running, whether or not any of them had an issue because they're not plugged into the rest of the environment. And you can get a quick heads-up view of exactly what your cluster looks like. This is beautiful. I've been told also that free IDA guys are looking into doing something similar for their replication setup. And that'll be exciting too. So as he's rocked over, they're nodding. So really there's a lot of cool stuff going on in Cockpit. Now, I talked about server being the focus being on those services that you really need to have stable and sustainable for years and years. And really there is no better example for that than an identity management service. In the North server we've elected to use the free IDA identity management system as our implementation of a full domain controller. This is becoming really our formal answer to where do we compete with Active Directory. And so with the North server, we've made it really, really easy to get at least a proof of concept or small business domain controller setup with close to the click of a button. We haven't quite managed to get it plugged into Cockpit yet, but that's coming pretty soon. And what this gives us is a really, really powerful interface for managing which users you have, how they are grouped, what machines they have access to. In the case of pseudo-policy, we have the ability to determine what actions they are allowed to perform on individual machines. We have the ability to tell, we have, as I understand, time-based rules coming very soon. But pretty soon. And we have a lot of ability to do authorization and really manage at a fine-grade level how you interact with your Linux-based environment. And a lot of that comes from its integration between free IDA and RealmD and SSSD and some of these other related technologies. And we're working on other ways to improve on that. But it's, again, a nice, simplified and very discoverable web UI. It doesn't require a rapid environment on the system, but it lets us do a great deal from... without, again, any huge background in the technologies under the hood. And it's vastly simplified setting up such critical infrastructure as things like your Kerberos single sign-on and thanks to advances in things like HipsLong and GSS proxy to expand this into a more federated solution as well. So we're working very hard going forward to make sure that all of the other stuff that we do in Fedora Server will build upon the domain controller world. From here on out, any service that we produce, our plan is that we won't ship it unless it can basically be plugged in into free IDA trivially. It should require nothing more than saying, the free IDA server is at this address and that this system will be coming up. Yes, thank you. And, well, this is a... essentially what Microsoft has had for years is that everyone has always assumed that Active Directory is available, so everything always supports Active Directory. We want to take free IDA and say that this... we will presume in the Fedora Server world that IPA is present in your environment and we will do everything we can to make that more and more comfortable and more and more easy to do. I've said this privately a few times, but my personal goal is that in Fedora's 24 and 25, it should really be... it should be assumed that if you want to get anything really done, you should have an IPA domain controller. And by Fedora 26, I'd like to say that it shouldn't be possible to bother... to live without it. That's an ambitious goal and I see the free IPA guys a little nervous, so... I probably should have warned you about that ahead of time. Do you mean that for, like, if somebody wants to sell, like, an HTTP server, then they also need to run an HTTP server? Not exactly. What I want to make sure is that if we build a generic HTTP server role, which I don't know that we will, because that's kind of a complicated story, but what it should be is that if you deploy that HTTP framework with Fedora server, it should, by default, come with gss... with mod-off-gss-api enabled so that you can use IDM... free IPA identities to back it. You can choose not to, but the default case in all situations should be that it be assumed that this is in play. You can always... This is open source and all these packages, these are available as packages. The idea here is that we're trying to do we're calling it deployment rather than packaging, where you get all of this stuff and it's preconfigured in a way that we think is reasonable, follows modern security standards, and we'll cover at least 80% of the cases so that out of the box you don't need to know how all this works out of the hood. So we should... The default case on all Fedora server deployments should be it just works. So let's talk a little bit about where we want to go next. World domination. What are we going to do tonight, Pinky? Now, what do I mean by world domination? What I mean is that I want Fedora server as a platform to be the default place where new long lived applications do their prototyping, do their work, and try things out and get their first initial deployment on. So it's very clearly a place where it's no secret that Red Hat Enterprise Linux drives from Fedora down the road. And I want the default behavior that people can expect certain things from Fedora server that we can reasonably expect and we will likely follow the Red Hat Enterprise Linux and that they want to do the work necessary in Fedora server to make sure that their applications will work on the day that that downstream release occurs that out of the gate they will have a jump on their competitors because they were ready on the same day, not they start looking at it during the beta process. And that will help us because one of the problems that Red Hat Enterprise Linux has, of course, is they'll release 7.0 companies will finally start looking at it and realize, oh, well, we need this from the kernel or we need this from libc in order to do this and so there's a lag time between when applications can deploy and then when, of course, users can then start testing them. So if we can work with all these people to do this work in Fedora and in CentOS and for those communities that are not going to that wants to self-manage then we have an opportunity to get people to jump ahead and frankly if people want to do some really exciting new work they need to be doing it in Fedora where they have the opportunity to get there first. So that's what I mean by world domination is I want people to look at and say this is the next big thing we're going to do where are we going to do it? Well, Fedora, of course. So what are we going to do next specifically in the Fedora project and how are we going to get to this and some of that? I think part of it is going to be server roles and we're making it easier for independent folks at ISB to develop them themselves and I would love to be able to say and to see some of these coming out of those upstream as well. In Fedora 23 Alpha which we released yesterday we have a new server role for memory caching even. This is the first prototype of a role that we are deploying as a container and I'll talk a little bit in a couple of minutes as to why that's really exciting but it was proving out that we can use these same mechanisms we don't have to necessarily deploy on bare metal and we can be prepared for a future in which maybe you migrate to another form of Fedora, another form of first example atomic. Things we want to work on probably for next release we've been talking about developing one of the major pieces that we want to plug into the free IPA world is build the ability to declare a server the home directory server for your IDM deployment and essentially just trivially set that up and then help with some additions to free IPA that I want to talk to you about later be able to automatically push that out to the clients so they can just so there's basically no there's automatic discovery and no difficulty trivially just setting up a new system to use network map home directories this is really useful in labs school computer labs government buildings love to have shared machines that people log into and this is a very common use case that we have always just basically told our customers well here's a how to it worked two years ago it probably still works but I would much rather have that be a core piece of the OS beyond that I'm working with Adam Williamson who's been doing the packaging of own cloud in Fedora and one of the things I'd love to see there is the ability to deploy your own personal cloud storage and cloud feature server with basically no hassle I followed his instructions and I've set up a few own cloud services myself but it is pretty hard basically all of it should be automated so I think this would be another really big use case for our customers and for our users and eventually down the line for Red Hat's customers finally you're on the wrong slide sorry oh right and so I'm also talking with some of the folks over at CoLab who are working on developing a container solution for a groupware server their email and calendaring and also content management in there so that basically I would love for Fedora to be able to say out of the box we have an answer to Microsoft Exchange and best of all it's not Microsoft Exchange is it Microsoft Exchange running on one? security no and the idea should be that these are things that basically every business has to deploy at some point why are we making it so hard? I mean we have a lot of excellent and brilliant people in the Fedora community but we've never been really great at focusing their attention on integration we've been great at developing technology but not at necessarily delivering technology and so that's where I think our major focus has to be the last point on this slide is about a general purpose file server which we also get a lot of requests for and this is a very big concept because this means different things to different people are we talking about Samba are we talking about NFS are we talking about SEP are we talking about all of them and do we configure them all from a single role so this is still very much of infancy and we're trying to figure out where to go with that which is why I think we're going to focus on solving at least a few particular use cases before we get to a general purpose case Two words I'm sure they are but I would add to the slide to be IoT and Big Data Do several things Those are those are things that are not yet on the sorry for the recording the question was what about IoT and Big Data and the answer is we don't currently have formal plans around those simply because we don't actually have anyone who is pushing for them in the community if that's you we would love to hear from you and I don't mean that sarcastically I mean everything in Fedora happens because somebody wants it enough that they put up some of the time to do it and right now we don't really have an IoT constituency in the server working group we don't have a Big Data constituency but those are absolutely things that we would love to support we just don't have the expertise handed so what are some of the techniques that we're going to use to get to this wonderful world domination future one of the things that we're really focusing on is we want to start really defining the Fedora server as a platform that provides a certain set of interfaces as opposed to a distribution that provides a set of packages what we want to do is we want to gather up a listing of what are the interfaces that we feel are sufficiently stable that we can say if you build using these they're not going to change next release in fact they may not change we will say at least three releases will maintain compatibility for this and we will publish this documentation in a common place something like I hate to keep going back to referring to Microsoft but there are certain things that they do very well and one of those is the MSDN you only have to go one place to figure out what are all the interfaces I can use to write my software to do something really like that and if there are any documentation people in the room I'm sure they're twitching because of course that's a lot of work and it's not something I'm attempting to push directly onto them but this needs to come from the engineering groups as well but I think by being able to start defining a platform you start being able to define what is in Fedora and what is on Fedora and being able to really give a better and clearer view of what you can rely on so how are we going to do some of that a major piece of that is there's some folks working on things like the Vapagail and other technologies that can detect ABI and ABI changes automatically so what we're doing is we're working on a series of Taskatron tasks that will automatically run on every Koji build not scratch builds but every Koji build and report back to you whether or not as compared to the currently stable release of that package have you broken the ABI, have you changed it in any way have you is it a clear ABI break or is it maybe this interface changed but it's opaque these are important things and the thing that we're really shooting for here is that if such breakage happens we'll turn off the ability to the update automatically that any kind of update that happens after that point must require human intervention to say no I'm sure do this and that should help us avoid some of the classic but nor are we too fast problems because really what that amounts to is well yeah we move fast and we break things but did we really need to break that we should have to think about are we breaking this for a reason or are we breaking this just because it's the newest thing and if it's just because it's the newest thing maybe we have to maybe we have to look at maintaining a compatibility there for a while a couple of other things that I'd like to work with again the free idea people on is improved certificate management we've got a number of services that we ship into our servers and roles that we deploy and what I'd like to do is be able to then as we continue our assumptions that we're going to be work deploying in a domain controlled by free idea I'd like to make sure that we have this role where we're pulling certificates the proper way that when we roll a client machine with that we automatically update the cockpit self-signed certificate with one that's signed by the domain so that we don't have all those self-signed significant problems so these are things and again not entirely on the free idea people these are things that I've been working on a few hacks to rally for example and I'm going to be trying to push a few patches upstream to accomplish some of this but I think everybody in this room knows that certificate management is hard, painful, necessary but something nobody wants to deal with is they can help it so I think anything we can do there by starting to be able to make these assumptions that certain infrastructure is in place we can start to reduce that impact on end users so that they only have to worry about the certificates for the applications they create and not for anything that you're providing and the last and most exciting piece I think one of the things that we're working on with I talked about how we're using the memcache role as a prototype we want to start building out as many of the roles that we deploy on the north server as kubernetes as nulacule apps or atomic apps that are powered essentially by a local kubernetes cluster a one machine kubernetes cluster where the idea is that you start your small business or your home office and you deploy IPA, you run a few of these roles but as you grow we want to make sure that you're able to grow into the new atomic environment so the new cloud-based kubernetes and open-shift environments and the idea should be that if we do this right all we should really need to be able to do is point these roles at the new kubernetes cluster and then just simply migrate the services into the cluster with minimal effort on the part of the admins and take away that huge barrier right now it's very much you're either a traditional admin or your whole world is the cloud but getting from A to B is really hard and for many people are a big retooling of their environment and if we can allow them to step there in their own time and in their own comfort then I think we help people migrate into these new workflows so that is that was stuff I was hoping to get in for Fedora 23 but at this point I'm probably going to end up doing my working raw hide and I suspect it will land for Fedora 24 but I certainly appreciate as much help as anyone because this is a big effort but I think it's going to have a lot of long-term impact so the implementation is not going to be on the cloud side? no the idea is that that will be part of the build systems and the update system so that you shouldn't get this stuff on your client this stuff should not make it to your client it should be solved before it gets pushed to the repositories right so it's more like yes and Taskmatron is a service being provided by Fedora QA to do automatic testing of certain things particularly in the build system sorry for the recording the question was how does the ABI automatic detection work it's going to be done as part of the build system before it gets into customers hands I keep saying customers I don't know why I do that because this certainly is all effects red-headed presidents downstream but it very much affects our Fedora as well and if we don't have people working in developing in Fedora we don't have downstream mileage so that is pretty much everything I had to say I would love to hear any of your other questions I know if you came up during the talk but so what about Adil do you see that as specifically interesting server or is it just kind of football server as well as other today's decisions alright so the question was the Babagail and the ABI detection do I see that as being specifically interesting to server or is that useful to all of the other I think it is absolutely useful all over the place and probably it belongs I know where you're actually going here is which work group should be owning this and driving it and ultimately like I said before Fedora is done by those who do the work and right now the Fedora server group is the group that really wants to see this done so they've kind of adopted it as our puppy and we will raise it to a dog and then if somebody else wants to adopt that dog great but it is definitely specifically interesting to us but it is not exclusively interesting can we name that dog Kerberos I think that one is taken but I'll get back to you how difficult is it to write these roles how difficult is it to write these roles that's that's an excellent question at the moment impossible and that's simply because they were of moderate complexity but we were the upstream for role kit the packaging service that is providing this is completely redesigning how we do this so that it was moderately difficult and they generally had to be built in tree we're completely rebuilding it so that now you can build third party out of tree roles with minimal effort so at the end when we're done with this I'm hoping that it should be very easy it's just going to be writing a little bit of Python my goal is that it should be writing in a little bit of Python that implements the deploy function and the decommission function and that everything else should be pretty much handled by the infrastructure so I was originally going to be giving a write your first server role workshop on Saturday however because we decided to completely revamp this I've turned that into a role kit hackfest because anything we talked about on Saturday would no longer be true on Sunday so as of right now fairly complicated by them but with the new design that we've got very easy and most easy to make it for the person that owns this technology to do it because they'll be most familiar essentially it's like I said the deploy which is basically an installer it's basically an installer from Python you can do exactly whatever it is you want can I provide a bit of perspective on what ratings means to server well so as I talked about before as far as providing a platform I'm worried to go into the ring 0, ring 1, ring 2 numerology because nobody can see and nobody yet has come up with a firm definition of what those mean but Fedora server at least for whatever ring number it turns out to be I want those interfaces and not the packet again but the interfaces to be Fedora server so maybe that's that is definitely a ring things that are built on top of those services are certainly an outer ring and they may they may be built in Fedora or they may be built in Copper or they may be third party ISVs that are closed source as long as they're using the known interfaces so to me the only ring that is really important is that platform that we have a defined platform interface and that can correspond to a ring I can't I am largely coming up with this on the spot so my opinion may change by the end of the day but I think that's about where I I'm not sure I would bother with describing more than two rings in terms of what is interesting to the server either inside the interface lines or outside it was all about the platform it was all about the platform in the back you're excited to contest the server API with how do I contrast the server API effort with the next standard base I don't honestly the next standard base is interesting I suspect that when all of a sudden it will end up being a subset probably a wholly encompassed or mostly encompassed subset of what is the server interface line but we are we are aiming to include certain things like the roll kid interface and like cockpit as actually being part of the interface we provide and those are certainly not anything that the LSB would ever likely can include is that a sufficient answer I think to restate the question I guess the question is how do we measure which interface is qualified as opposed to the classic problem that LSB has never been able to really solve that I don't have a good answer for that to a certain degree it's going to be designed by committee it will ultimately be the decision of the server working group and whether or not they feel that something is sufficiently ubiquitous as to be worthy of focusing efforts on maintaining it for a long period and that's kind of a I'll know when I see it situation but I don't have a better answer at the moment I have a comment the way I thought it would make sense to do this in Fedora workstation is to identify some important third party apps like for example Chrome, virtual box maybe come to my mind and just make sure that they continue working from one Fedora release to another and that saves the stability for your work right and the saving was from a workstation perspective one of the ways that they're looking at this is from the consumer side pick a selection of highly important applications and then just make sure that the API to support them continues to do so and that's certainly one way to look at it and I think that's kind of what we're doing with the roles as well the server interface will always make sure that it's capable of supporting the roles that we have configured to deploy on them and that's a bit of a chicken and egg problem because of course as we start allowing third party roles then we have to start figuring out where exactly the interface line is to say well you should really be using these I think it's a balancing act how much of one we do to take first to the other and again that's likely a decided when we come across it situation we've got two minutes, we've probably got time for one more question is your email really the same as what the worker is talking about? no, no it is not I forgot I did the last page jump back to the first page there's a way to go there everybody has a question if you're particularly interested it is sgallh.org project.org or at redhat.com thank you for your time