 How many of you think it's way too hard? Welcome to the Kiwi Talks. My name is Jan Mondstegel. I work in imaging topics since about half a year or three quarters of a year. And I'm going to show you what Kiwi can do for you. First of all, I'd like to ask how many of you actually know what Kiwi is? Quite a lot. How many of you use it to make images? If you want to tell us something about the images you are creating, I'd like to know that. Light image, ISO or USB? ISO images or USB images? ISO for an ISO. But USB in the future. And how about you? You have your artwork and just carry around like music and your documents. Basically your operating system with you if you have USB. We have one or two power users here now. I won't probably tell you many news because you already had all the pain that you can have probably with your configuration. I'm going to talk about this. My presentation is split in basically three parts. First of all, I'm going to talk about the history of Kiwi, how it was developed, why it was developed, by whom it was developed. Then I'm going to give a very brief example of what Kiwi can do for you. If you don't already know this, you too may fall asleep during that minute. And in the last part, I'm going to talk about what I do for Kiwi. Because we wanted to give new functionality to Kiwi that it does not have at the moment. And I'm heavily working on that. So I'm going to talk about, I think, five minutes or at least five minutes about what I'm doing. And if you wish I can show you a current configuration file, but we'll come to that later. So first of all, introduction, what is Kiwi? Kiwi is a command line-based toolkit, which means it has no nice GUI and nothing to click around. But for that reason you can integrate it in the toolchain process. So when you have a win system, for instance, and want to create Isis, automatically you can integrate Kiwi calls in your scripts, in whatever scripts, Bash, Perl, whatever. And it is usable as a base tool for high-level applications. So if you wish to make whatever QT or web front-end to generate your conflicts, you can do so. And run Kiwi as a back-end, which is a really nice thing. But Kiwi is not a product. So there's no point in we don't sell it as Isis and as a complete tool. You can integrate it and it's still under development and you will probably find bugs. So I can repeat what Sify said. Bug reports, bug reports, please file bugs. It's in the Novell Baxilla. It's open-source org system imaging. I have this not in my slides, but you'll find it probably if you search for Kiwi in Baxilla. The original program was developed by Markus Schäfer. The original plan was that he gives his talk about his part of Kiwi himself, but he cannot attend for private reasons. So I'm taking this. And his original idea was that he wanted to create a USB stick just like Francis. He wanted to have this system to go and boot whatever machines he could and carry his data with him and just have his special system on every hardware that he has. Then later, I'm James Wilcox, aka Snor. This was the Kiwi channel. It has the Thin Client project, which is targeted to provide an image as small as possible. And Shikish Kohil, aka CyberOrg, is in active development for the LSTP project, which is LTSP. I joined active development in April and wrote my modules. You won't find my code in the repository at the moment. Just one small module that I use for some utility functions, which are subject to change, of course. And as soon as my code works, I will commit it. It's nothing secret. It's just not yet operational, but it will take two, three, four weeks, maybe. Of course, I will get back to this in the third section. So the current project status is an overview of who uses Kiwi at the moment. The Susie Linux Enterprise Point of Sales project uses Kiwi to create images. Also, the Thin Client project is an official product made with Kiwi. And some hardware vendors use Kiwi to make preload images that they can dump on their disk and give to their customer as a pre-installed machine. We actually have one preload by Lenovo. We made this with Kiwi. It's released. And I mean, they made it with Kiwi. We taught them how to use Kiwi to find all these problems that you have when you use it for the first time. We figured everything out, and now they are using Kiwi to make their product. And there are some community projects. Actually, if you ever tried a KD live Kiwi, this is made by Stefan Binner, a.k.a. Binary. He also uses Kiwi. And whenever he has some questions, he drops over to me because he lives in the room next to mine. And of course, any user who wants to create his custom system can use Kiwi to do so. And yes, exactly, that's what I mean. You tell me if anybody has... I asked that in the front. And I know that as I feel, for instance, you use Kiwi to make a rescue system, which is very interesting. Me again. It's an old X32 ThinkPad, which has no drive. And I really regularly update to the latest OSIMS factory code. And in the evening, before going home, I have to call my colleagues one moment I need to reboot first. Because what if the update kills the kernel or the bootloader? I'm sitting at home. For some reason I need to reboot the machine on boot. I won't have a drive. I can't just recover it. So I did with Kiwi a live booting USB stick, which I just used as a recovery, instead of a recovery CD. I did a recovery boot stick. And right now, when you try to show it, the X server doesn't start up for some reason. Probably I booted it on a different hardware last time, so I need to... But we have one of the boots. I'll show that later. But it's actually, it's a much better rescue system because it's so cool. It has amp player, it has all browsers, it has everything you need. Yes, of course. It's much better if you can listen to the amp. If you can listen to the amp, listen to the music from the one partition, while your file system check is checking the other partition. So that's really cool stuff, and I really appreciate it. You can use it for more than it looks, so it's really cool stuff. I feel it's one of the guys who really gives good input. He sometimes drops over to my office and says, yeah, couldn't we do this like that, blah, blah, blah. And he has really good ideas on that topic because of that rescue system. And of course, but I don't remember that you ever reported an enhancement part on Kiwi. Yes. In your office. In my office, yeah. Right. When you were talking about the history, does the name actually have a meaning? You mean the name Kiwi? That's one of the secrets. You have to ask Marcus himself. I think he told me once while we were cracking a cup of coffee, he told me it's just because it sounds nice. He didn't think of the birds because when you look at the Kiwi and the official Kiwi website, I can show it right now. I plan to show it anyway. If network is still up. We have the official Kiwi website at Berlioz.de, which actually has a picture of a fruit, as you see. And he calls the Kiwi community the developers, so he can try to walk himself and me the fruit lovers. So this is the official webpage. Okay. Now we're going to how does Kiwi work? If you want to use it for the first time, you have to do several things. Because there's no really brief overview, I collected some useful links. We had often troubled that people installed Kiwi and started to edit wrong config XML files, namely the ones in user share packages, Kiwi, user share Kiwi images. And these config files must not be edited. That's why Marcus provides some examples. Since Kiwi version 1.99, he has two examples that he can use as is. And we have the official open-soothed-life DVD, things checked in in Forge SVM. And that's why I collected these links. The website was just a quick hack written on Thursday to collect all the links for the download repository. So you can get examples. These two examples are in the normal documentation. You get this if you install the Kiwi package. And the open-soothed images are in Forge SVM 1. That's nice that we have network here, actually. And you can take this KW live CD configuration file. This is a good point to start if you open this with... Oh, it works. That's how a configuration file looks like. This is quite long. I'll explain a shorter example later. So what else is on the website? We have links to documentation. First of all, the documentation that comes with the Kiwi package, which you'll find in UserShare.Package is Kiwi as Kiwi.pdf, which is really, really, really well written. This is one example for really good documentation, I can tell you, because Markus wrote a lot of documentation and he was convinced by Thomas Schreitle to create it with DocBook. And it's really well written. You can write your own documentation if you have something and put it in this. We wrote some real-life scenario tutorials when I made the preload image. I wrote something about the preload and about the USB. This is actually my contribution to this document. And a few weeks ago, Thomas and Markus started to write a quick start tutorial, which you'll find in the Build Service documentation, actually. This is in this link. You'll find the books in the end. And there's a quick start Kiwi. The problem is that the PDF is not in the repository. So if you want to build it, you have to check out that repository. You have to install the SUSE.Package, which should work by now. We found out that it doesn't... You can't install the package from the online repositories due to missing... If you have the DVD, you can install it. But I think the package got fixed on Thursday and will be available through the updates. And you can take a look at the pre-start, because I have a compiled version with me, which is really an auto-detective way. It doesn't start with technical details. It starts with how can you create what is Kiwi and what do you need. It tells what packages you have to install when you want to make ISO images, when you want to make USB images. There are different sub-packages. And it has some sample calls that you can execute. You can use... For instance, he shows these two examples, which you already have installed. And you can just go there and use these configs and run commands which you find in this documentation, namely these. This should work if you have a valid installation source. So it's pretty straightforward. Just take a look at this quick-start guide and get started. So... Basically, I have to install Kiwi package, Kiwi tools package, and Kiwi desk ISO boot, Kiwi desk USB boot to make ISOs or USB images. There are some others for thin client. There are some for the wise terminals. You probably don't have to use them ever, but if you have a wise terminal and want to make an image for that, you have to use this. It's also available. Your main job is to create the config XML file, the one I showed you before. You can start from scratch and create your own, or you can just take one and modify it. That's the usual way. You check out one, you take the Kiwi KW live DVD, or you take some other that you like, or it's almost what you need and just tweak it a little bit and you get your own image. The build system looks like this. In an overview, you need source repositories for the RPMs as input, and you need the config XML file basically. You also need some other files, which are shown in another slide. You need a build host with at least about five gigabytes, this sort of minimum, better as 10, better as more, of course, that you don't have to read the old image and create a new one and have enough space on your disk. And what comes out of it is an image. This is not necessarily a CD. Actually, it's just a nice image. Can be a virtual machine image, or a USB image, or an ISO image, and among some others. So it's just because it looks nice. Okay, that's a slide explaining sufficient resource, especially hard disk. Of course, it helps if you have a lot of memory. I built an image on a machine with 512 megs. It took, I don't know, 40 minutes or so, and the same image on a 1-dig machine took 20 minutes or less. So memory matters, and hard disk drive. It's the main thing. You don't need a quick CPU. The configuration directory contains several files. The most important one config is in there, containing every information that your image needs. Package list, repositories, user names, user IDs. We can switch back to this. I can explain it on an example. What was it? Here, I think. I'm starting with an image tag containing description, who made it. It's to contact the name of the image, then preferences, specifying which image is to be available. In this case, ISO is the default. But you can also use as an option OEM image, which is used for the preloads, and DMX for virtual machine, same for Zencunnels or USB for the USB stick. One morning at that point, if you make USB sticks and you install Kiwi, you may have a machine without SquashFS and without AUFS. You have to install these manually. They are not required by the package. Markus says he says who wants to make USB and uses SquashFS, he probably knows what he does. And the package should not require these. Then you specify version, size, what package manager you want to use. Actually, they support smart and super. Both have some features. There are some things better in smart, some things better in super. Sometimes it doesn't work with the one, but with the other. When you use super, the version is important. You must have a recent version of super. And package management is a topic for itself. In this particular case, we have two profiles for KDE and GNOME, because Kulu used this configuration to make the KDE, the OpenSusan Live DVD, which is one for KDE and one for GNOME. But the main thing which you have to do is the packages section here. You have to specify which packages shall be installed in the image. You can use a package list if you have one. You can specify a package name for each package, which makes the list very long. Or you can use OpenSusan patterns, which are resolved, but sometimes you run in trouble with that. And you can specify packages that you don't want to install by saying ignore name. When you have a package that you know, it's not in the repository, but it's required by some pattern. Then you say ignore and it is ignored. I don't think that we have an ignore here, but I can look in the... Yeah, as we see, Kulu used the package list and didn't rely on the patterns because they caused trouble sometimes. Especially in the installation repository and the patterns are not in sync, which happens sometimes when you deal with the leading edge repository. That's pretty hot in here. Okay. Now, I'll briefly give a real-life example and imagine the following situation. You wrote a program for your diploma pieces or whatever and have to demonstrate it. Say we have a distributed system, you want to demonstrate something which has client server application and you need two machines for this. Your process that you have two machines in the lab, but you cannot make sure that they are installed correctly and you can't be there the day before filling with the machine. Then in the evening some other guy comes uninstall the package that you need and you run into trouble when you give your demonstration nothing works and you fail, which is very black and white, of course, but it doesn't look good if you have half an hour demonstration and need 20 minutes to set up your system. So what you can do is you can create images for both machines with your own package, your own software that you wrote into your image that you don't need to do anything more than just booting it. This can be done in two ways. The most convenient one is if you have an RPM package then you just link your and the best way is, of course, to have this in a build service account. I have to say that because I'm on the build service team. When you register this particular build service repository as an additional installation source require your package and build your image. Everything's fine. If you have no RPM get a build service account and make one. If that's too much work, of course you can tweak your package manually by just adding every bit of software that you're really copying files to a user bin or user share or something, which is more work, maybe. If it's a simple program, it's less work, of course. And it's also possible. And it's not so complicated because you can use overlay files which are copied as you provide them on your image. I'll show that in the conflict tree later. So the scenarios that you have are a mounted DVD or a mounted online repository. You have your build service home project containing your package. You have a build machine using QB and you create your own image on USB stick that you can boot and make your demonstration from hardware and you don't have to care about what the machines are. You don't have to prepare anything the night before. You just plug in your USB sticks, move from them. Of course you have to make sure that the machines actually can move from USB. Some old machines don't. And then everything's fine. You can use the A++ if that's possible. And now, first of all, I'm going to show the structure in the demo. As you can see here, this is a directory. This is the demo. I wanted to show this one. This is a very, very, very basic example done by Marcus. It comes with QB. You have basically the config.xml containing all the information that we talked about, the config.sh which is a script that runs after the base system is installed. And you have the root folder. Now this is interesting because are we already running out of time? Thank you very much. You have a root folder containing the .etc folder. And in this .etc folder, you have some things to this config. And these files are put in the image as is. So you can overwrite the default images by them. If you want some file lying in user bin something, you just put it under that root folder, root user bin something, and it appears in your image as is. So this is the second way how you can get your own programs into the image. How do you take care of all the files? Do we have to set them correctly? That's one point which was discussed recently. QB runs as root. You have to run QB as root. And I think that all of these files belong to root. You can look at that with the root folder. And everything else. So you can change the ownership of these files and I think the image contains them with the right ownership. So you may want to ask this on the mailing list or on the YouTube channel. If you have to know this for some purpose. But if you have to know that from the mailing list or just ask on the QB channel. Some guys will be around and help you for sure. No problems if you use SMB image. If I use? SMB image. Which is? Security and security. I don't know about that. Sorry. You may drop a mail on the QB mailing list for that. And you can probably answer everything. Because he knows the code and he has it in his brain. I don't know. What else can QB do for us? Now it's getting autobit. Interesting. It's about how we create our products. We have a system internal called QBit. Which is our package and media factory. We have built clients. And we have a scheduler running, collecting built RPMs in raw trees. We have trees for each architecture containing all the RPMs. And to make a product out of this you have to gather one installation repository. Which is when you use QB at the moment you have to provide one. Either you have the DVD or you have the online repositories. But you have to use fixed repository with metadata that you can install from. And this is a weak point because QB actually cannot create repositories. This is what I'm working on. I want to teach QB how to make our repositories. To put some automatism and autobit functionality into QB that you will finally be able to create your own installation repository from raw RPM directories, from other repositories from directories containing plain RPMs with no metadata and no version information and nothing. And finally create one repository and apply some overlay mechanisms. You say you have 10 repositories priorities from 1 to 10 and you want to take packages from the one with the highest priority first. But you may want to override for some special cases. You have a package in priority one and priority five and you know you want to use it from the priority five repository no matter that it's available in the other one and you have to put all these information in the config XML file and I write a module that handles these problems. And that's why it says it's not yet because it's work in progress. I think I already told that. Yes I should have shown this before. Product creation at the moment is what I told with what the autobit team does. Creating installation repositories creating images from that. There are steps. You have to create metadata. You have to collect packages. You have to have all those dependencies in the parts to make sure that everything is installable. And finally you have an installation repository from which you create FTP repositories, DVDs, Victorian files, whatever that we distribute as such. And the new the new approach will be that we have a Kiwi module we have to expand the syntax of the config XML and the information into it. This is already done. I'm working on a module that evaluates this data and creates the repository which is still work in progress. And we have priority for repositories when you have 10 repositories and you have files in more than can have files which are in every repository and you want to take it from a special one. Then another important thing is in script hooks some packages have to be dealt differently installation images for instance is one of them which has to be unpacked and then the script has to be run after it and has to do certain things moving files or copying files. So we have to provide script hooks that you can write a script provided in some URL and which is one after the packages is downloaded and copied to the right place. And as I said you have to allow exceptions when you make something for good example is if you have two architectures for 64 bit and 32 bit and you have some 32 bit packages that you need on the 64 bit image. For instance if you want to use Firefox in the flash plugin that's one of the problems where you have to I think you have to install the 32 bit Firefox and the 32 bit flash plugin because the 64 bit flash plugin doesn't work for some reason and you have to be able to provide these exceptions. That's just one exception, there are some others. Of course we still need autobit knowledge but we have to find another way to put it into the image. There's some automation done and I can show you current and what we expected the conflict with me. This is one of the files that I use that I use for testing for my the main thing is the new tag InstSource. Within the InstSource we specify it looks up here at the moment because it contains a lot of comments. The main thing is the InstRepo where you specify a repository and a priority for the repository and for FTP you need a username and a password and in this case some location in our local system and some other which is a KDE WinService repository and here we have a local repository on the hard disk of the machine that I'm testing with and I provided a package list which is down here it's very simple at the moment because I wanted to resolve some issues with the work in some cases I just include two packages and test if these packages are available in all repositories I have to make sure it's picked from the right ones for the right architectures it must be available for all architectures that you have required so this is a really meaningful work in progress testing environment and another interesting part is the meta data tag which is which specifies meta packages and meta files and for meta files we have the script talk here we say a target is the directory where the meta file is copied to and extracted and the script which is run after it in this case we have a this is a package because I changed that to a full path to non-relative rules because we said we provide a full rule for the scripts but probably copied it a week ago or so so when this module is finally finished you'll be able to make your own repository not only your usage but also your own repository the problem is that there are rare use cases for the community because you probably don't have your own auto build running and maybe interesting if you want to make a repository for where you have say 10 or 15 rpms that you want to distribute with your own with your own CD you will provide a consistent tree with meta data everything correct and this packages include it and you will do the same task with an online repository that you build your image from so it's monski internal nevertheless I'm going to commit this to the kibir repository when it's finished and when it works you all may look at the code and report bugs and tell me if it's rubbish yeah I know that your opinion I know you would say that doesn't work yes it's rfc 1925 again it has to work so what and now finally if you have time you don't want to go to the lunch break yet you may ask any questions I'll try to answer them or redirect you to the person who can and it plants on yasdape declaration yes and there is actually a yas module called a yas 2 I forgot that thanks for the question the yas addon creator no the yas product creator sorry the yas product creator is a frontend module written by yoshi superman which is basically a frontend to create a kivi config xml file so you can actually test this and put some your own packages in there and create your image basically creates a meta data to the repository based on an existing repository with existing meta data it does not work with plain rpm trees but it's still it's already available here I should have mentioned that in the first section and the follow up question is there some relation with auto yas since this is a pretty similar xml file to create the configuration of the installation target as far as I know the auto yas is completely different it's something that uses a completely different format the auto yas file just creates a target z file from an image it does use some sort of some sort of xml file but it has nothing to do with kivi that's for sure so there's no connection between the auto yas and the prology well it would have been nice since there are some similarities for example a package selection for an image file or a target system that you want to automatically install would be nice if there's some basically I think they should just both use the usual package selecting GUI you have in yas and just use this as a module or something like that if you have created an image or created an auto yas then you have a module basically probably the installer would have to be extended to be able not to install but to just write a package list might be pretty trivial I think the product creator actually uses the same module I also think I've used auto yas once the yas module for auto yas I used it once and it looked very much like a package we already just discussed this internally by the way if we can merge something from auto yas to product creator but I don't know how at the time what's the plan to how fast this should be integrated or whatever yeah do you still then have to run Kiwi from command line to then create your image and then jump your image onto the USB stick for instance you have buttons in the product creator which runs Kiwi without you don't notice this you don't have to run it manually that's what you need you simply create a button and it does the right thing it's the do the right thing button anything else? no tricky questions? from you Simon show it first of all I'll show my very last slide this is a collection of ways to reach the Kiwi developers this is the Reno channel which is usually has at least markers in it sometimes myself and Snork and CyroOrc and some others then we have you can ask on the WillService main list which is at the moment not the right place for Kiwi questions but you can reach me through that middle list for instance and Marcus runs two lists Kiwi users and Kiwi devils on this various game and of course you can drop me an email any question that I can answer I'll redirect to you so now we can show a system actually from you Simon I didn't try it you didn't try it you said it works if it doesn't work I'll hit you this side where's the connector? and if you want to show this system just this one existed call it Raspberry System yes Marcus this is the boot cycle when you start booting it it should the unit I've been in that case is a plain shell script but we also use grub on the Willis P-Stick as the boot level actually it's consistent but it's quite slow to do so it's slow stick and it's slow machine unfortunately I can't do this machine for me because the device doesn't support it or it's disabled for some submenu or submenus yes yes yes these outputs come from the Kiwi init.rv shell script you can see checking files system I think the file system is created on the home page which takes a while before test so we have so it's a sub-sector graphics script yes yes yes yes yes yes yes RPC-1 it runs it RPC-1 wasn't it reconfigured actually I had that problem I only configured the X at the first boot and I wanted my RSC system to use more of one machine so I said I need this option RPC-1 but we need another option that just forces it to reconfigure X It's just a much better rescue system. You can surf the internet, if you put the right packages on it, you can listen to any free music while it's happily checking your file system. So, it's much better than the old one. I like it very much. That's why I use it.