 So, I'm Kendra McDonough, and she's more than an expert in the business, I guess, I'm going to talk about some of the things that we do to use TVN packages in maybe interesting and perhaps unplanned ways to do some, help us do some systems administration things. Once? No, it's not that good, is it? Sort of time. I'm sure that most of us have been in this situation having a bunch of accounts on a bunch of different systems, and then needing to do things across a lot of systems. So, you know, you often end up writing a script like this. Maybe it has to as well. Yeah. So, you know, there kind of has to be a better way. There's some problems with that thing. You know, the names of all these machines are no doubt philosophers, but one of them got spelled wrong. And, you know, just after a couple of minutes I couldn't actually name a list of systems, and in fact when I made it up I got quite a few of them wrong. So, it doesn't scale very well. If we have, maybe it's okay with 10 or 12 systems, but if it's 20 or 40 or 100, it gets a lot harder. It doesn't cope very well with complexly firewall systems where perhaps you can't SSH indirectly. You have to maybe SSH forward through a couple of machines to get to it. Declined by networks or something like that. I wrote another shell script to make it easier to SSH through deeply firewall machines and so on. But it was getting all a bit silly. So, we did some thinking about how we could do it better on deviant development. So, maybe we could write a deviant package to do some of these things. And all of these systems were deviant systems, or almost all of them. So, I started to come up with some other ideas. There's other things to consider as well in this. You know, this centralised management approach is like FAI, which indeed we use. And LDAP for authentication and so on. But these approaches tend to be quite concentrated in the centre. And if LDAP is great, or Kerberos or something is great, if you've got a centrally accessible machine, which you can consider the place where authentication happens. But what happens if you're trying to maintain a machine and the network is down, or your centralised host is down or something, and you're trying to solve this problem? How can you log on to the machines when you don't have that authentication? So, trying to use that centrist approach was going to be too expensive. You know, you need backup links, you need backup machines, and the cost just turns exponential all of a sudden. So, we came up with the idea of using a deviant package for user management. So, we wrapped me in a box, shipped me out, and so the deviant package installs, creates a user account, puts my SSH key in there, and so on. So, we came up with the production line. But we went on, so, okay, I created a deviant package for myself. Then we went further beyond that. We started creating deviant packages for everybody at Catalyst, and then creating meta-packages so that we have groups of users. So, we've got Catalyst Systems Administrators installs, you know, these five people and conflicts with these people who resign, and things like that. It sort of starts to work quite well. So, there's a bunch of other uses for standardisation of systems and so on that you could also use the deviant packages for. The meta-packages that we're using for our systems administrators are very simple. All they contain is a list of packages they depend on or conflict with, and you can do that, you know, for example, nobody at Catalyst seems to like using nano, regardless of it being the thing that gets installed by default on all of our systems. So, you know, somebody sort of adds conflicts with nano into their package. We also use it for packages that do things like all the necessary script and could do a patching on file analysis in a way that fits our standard environment, things like that. And then, once we've got all these deviant packages on there, we begin to be able to manage the systems to know what packages, what versions of everything are installed. So, we came up with a system for gathering host information. Essentially, it gathers package versions names and so on, and then it sort of grew a bit and added a bit more hardware and so on and hardware analysis and protection. Then, we took it a bit further. We started building our applications. So, when we build applications for clients, we build them as deviant packages. So, we get straight into the New Zealand electoral role, for example, which is across about 30 years. So, service, various packages for the database survey and side of the application for the middleware layers on various servers for the front-end layers. So, the whole application ends up being packaged. And if we have to move it across to a new cluster of machines, at some point we can just get installed the electoral role and it's all going. So, we've extended that a lot. So, we use that a lot for much, much more application-y management. These aren't deviant packages in the sense of the packages that are in deviant. Because these are for internal use, we don't insist that everything has a man page. It's not all that useful, for it was to have a man page for a web site. But it's still useful to have them being installable using that to get and we run repositories to help them out and so on. So, this is what a catalyst user package looks like. Installs an account skeleton. You know, the things that people generally want when they set up an account on a machine, bash, bash, I see, vermar see, authorise keys. Then it creates an account when you install a package and it generates a random password for the account and GPG encrypts it. And either it just saves it in a local file in that account or it emails it off to the person concerned. That's going to be a choice. Then, when the package is deleted, so if you go after the remove package, it disables the account but doesn't remove any of the data and if you go after the purge, it removes the account data completely. Yes, sort of model seems to work quite well. If you've got something in conflict, it gets deleted and encouraged so you can upgrade packages and packages that you've deleted. Data that may be important is still there. The host information system that we use also has a package that gets installed on every machine. We have that sent an email to a centralized database every night and we can query it. If anybody is interested, I can show you what it looks like at the moment so we can query package versions and hardware versions and partitioning information and IP addresses and things like that. Looking at this a bit further, you've got to consider what are the security implications of taking this approach. You have to trust the person making the package so these user packages aren't generally made by the general users of the callus. They're made by the systems administrators who have full access to the systems concerned in any case. Because of what goes in the package. Of course, when you install a package, the scripts that are installing it run out of root and potentially a person has full control over the machine while their package is being installed. So it's potentially a source for Trojan privilege installations and like that. But you also have to recognize that whenever you install a package on your machine, that's happening. You have to trust everybody when an Indian creates a package that you're going to install on your machine because you're giving them root the whole time. It's just pretty dodgy, I don't know, it's a pretty dodgy character. What I want to do in the future is to turn these scripts into something so that you can go make user package and it'll pull down a template and basically create the basics of a user package and then you can build it and use it for yourself. And I also want to create a make user package script that will just give a list of dependencies and a list of conflicts on the demand line and it will just create a user package. I think they're very useful and they should be more accessible. Feel free to ask questions. What's your version number? My version number, yeah, I'm just curious. Give me your version number, instead of saying the version number of my package. I think there's 21. Have you got any RC box on yourself? Yeah, lots. Are you suitable for release? Yeah, I was thinking about loading the Debian deposit tree just to see when it's still... The host information system that we have is currently client and master packages. So the client package gets installed on every machine and that sends the information about the machine back to the central point. And then the master package is the website that you can browse it for. Hopefully I'll make these two packages available publicly before the end of the year. What are the IP addresses you're sending back? I don't know. It's sending back IP addresses, the NSPCI output, the partition table and some free space information. Well, don't use this for monitoring free space information or things like that. Yeah, this is sort of standard information about it, so mounts and mount points. The users, the groups, and the most important and most useful thing we do is the list of installed Debian packages and their versions. Daily, yeah. We're configured to run daily. So it's a kind of personal life popcorn in a certain sense. Sorry? It's a kind of internal use personal life popcorn with some more information. Sort of, yeah, sort of. It's not really a popcorn because popcorn is really just tracking the numbers of machines using this package and less version-related information. So I'll show it to you. There's only a few more slides here. Well, yeah, on the server side, it's not like popcorn, I mean on the client side, just something that... On the client side, it's similar to popcorn, but on the server side, it's quite different here. That was actually the end. So, you know, I guess I'm interested in what other people have done in this sort of area. And probably you guys are too? Yeah. Does anybody want to share their experience? Yeah, exactly. It's similar to what I've seen. In September, we preceded file, things like that. So to install a new server on my end, my procedure, I've served with one software on one specific basis and configured the way I like it. Very similar to what it's doing with Meta package or things like that. Meta package for all the software in my machine. Meta package specialised for server or Meta package specialised for software to do that network problems and things like that. But I'm now trying to do more and I would like to share experiences package carrying configuration information. What I mean is, I style something. I don't like very well how it is configured by default. I want to install the next package to configure that problem. What I'm doing now is using scripts and patches. I back it around the patch to make it patching the system from the root so I can patch any file that is inside the machine in the patch. Now if I want to do anything around it, click this package with configuration information He uses a centralized LDAP set of fil for our users and so we have to configure each host to change the plan information to actually look at the LDAP so apparently we are kind of doing the same. So we had an accent package which changed the plan information and the live NSS, and the live NSS LDAP, are you sharing that configuration? Yeah, we injected later to go to LAPify the host and put it into our LAP similar. But yeah, we don't have to use a metadata but this is adding this personal It's kind of a combination of using LAP and having your home directory in some version control system that they have in combination. The main reason we didn't go with an LDAP solution is the problem that many of these machines are located at clients' offices on a client's local area network and many of them are located on the internet so we have strongly partitioned client networks so for one client we have a firewall that's on the internet and then a bunch of layers of machines and firewalls behind that which is usually just found possible to get to straightforwardly. Yeah, we have a centre by centre so that's how it works. In a lot of organisations say a university or something like that you're going to have a lot more possibilities Yeah, except that it doesn't use a metadata that might change the route you're seeing and stuff that's not supported only setting your shell. How does the call back work? How does the information back to HPV email? The email. All of the machines can't be able to see the email that we're setting up just because there's a lot of systems administration tasks that can happen over email so if a call job goes wrong the client expects to be able to see the email for the year so all of the machines have to be able to see the email they don't all have to have access to HTTP for a site or something like that and we generally don't want this information to be we don't want it to be hard to access internally so there's no authentication on this that I can't get on to the site and share with you. For the question I've got I understand the question and the start of the data for my PC and I to share information and I want to waste my time on the things I'm curating everywhere so in fact I use two things I use a meta-package which contains the whole package the dependency that I want to to install on each PC by class so there is a desktop one desktop 3 desktop it's 60 86 desktop AMD 64 and all this kind of thing I install it but it just takes packages works quite well but with Unstable it's a problem that from time to time it's great because the package which is not up to date or something like that it's great because the main package you have to install the main package remember to install it from the breakage period so it's quite an easy you just have to check on the package to synchronise because for Unstable at the same time nothing is broken very complicated and for the configuration file I use the puppet which is like CRMG works pretty well you have the central repository you don't have to be connected you just have to be connected once and once you get this you if you can connect let's say once in a week you access the puppet central repository you pull many configuration files and you configure your system you have your own script it's pretty well done I think it's really a bit memory consuming but why not? and you have a script to extract idea of your account and create account using the vets for the startup and what so it works and what? I understand that I don't not using safe engine because some problems we have it's too centralised in my kingdom many people but everyone has different machines so I try to centralise because someone is responsible and to finish the installation I ask somebody else make this change to FCA to finish my machine that's why I want two voids only thing centralised well is a repository of my personal package I'd like to have a better configuration and everybody can make someone to be an advocate to scale I used to have all my servers all my college testing and stable so it would be a little dangerous to become an edge class I mean that for example it's a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a