 I'm a member of the OpenSources team actually and I'm talking today about a tool mostly used for OpenSources so far called Kiwi, it's for creating system images. So yeah, what is Kiwi? I also gave a short explanation, first of all it's a command line tool so it's fully intended to promote CDs or DVDs that are fully runable without installation on your system. In the meanwhile it's also possible to create the installation requisitaries, so the regular DVDs with it and maybe you've heard of the Susie Studio, it's an appliance creation tool web based, a colleague of mine will later have a talk about it and yeah it's a backend for it and there's also a YAST, maybe you know a YAST system configuration tool, a YAST graphic user interface for it available so you can, if you don't want to use command line tools you can have a graphic version of it. So what is an image? It's not like this one, it's more or less these kind of images. Kiwi supports creation of all these types of system images. I've also already mentioned the live CD or DVD, same from USB sticks or USB hard drives. You can also have an OEM hard disk image, means you can have a big hard disk image to simply DD on a hard drive and you can mount it to a commuter and everything will be running. Same for network bootable images, PXE for example, virtual machine images like QAmo and BMware are supported also for Zen and these EC2 Amazon stuff. So how are these images useful for you maybe? For example if you want to distribute your software, maybe an open source project or even a program, program pre-air, terrarium project running on Linux, so we can create for example DVD with your software already installed and pre-configured simply distribute it and your customers or your users can evaluate your software. You can actually pre-configure everything so it's running out of the box. You can create rescue systems, for example USB stick where you can boot from to restore your maybe backups from elsewhere and as I already mentioned to pre-install a Linux system on many machines. For example if you are a system administrator and have a computer pool in a university with 20 or 30 machines all the same or maybe even not the same simply dd an image on it and you have a running system. So I will show you a short example how to use PV. It basically needs only three steps until you have your image ready. First of all you have to create a description, a configuration file where you describe what you want to have on your image. Then you run PV to prepare the files as the pre. So it's more or less the same as your running system and that's where you create the image in the type I described before. So if you want to have an ISO or hard disk image or whatever and if you want to have more than one image type you only have to prepare it once so you can create more images from it. So short explanation about the first step. It's more or less simply a directory where you put all the stuff unique for your image in it. This is basically an XML file that contains for example a package list and maybe some services you need for your image and some optional stuff. You can do manipulations of your image on different stages here in the build process I will explain. It can also contain simply files that you want to have on the image and maybe are not packaged into an RPM package or a genuine package for example. There are also files that you may not have in your running system but only in the distribution media for example on an installation CD. You have licensing files or something in the root tree and you may not have them in the system you have running afterwards. And in the open source case for this just-to-first-boot configuration if you will use this just-to-first-boot tool two configurations on the running system on the first boot. So if your customer is booting your image then you may have different audio hardware than you have just-to-first-boot will do that for you. So usually it's a bit boring to show huge configuration files in a presentation but for this example that is by the way included in the documentation of Kiwi not only this one there are many different use cases included but what we need is about 40 lines of description to have an open source live ISO image prepared and these are basically these 40 lines. Everything is contained in an image container and for example we have some meta description for it. The original author of Kiwi's Michael Schaefer I'm doing the presentation at the last point describe your image give it a name and you also can have a long explanation for it it's not included here so we have of course preferences of your system so different image types have different settings so in this case we only have the image type ISO included so that is the already prepared and Kiwi-intuitive boot image you can give it a version you can use different package managers in this case we are using the SUSE tool to install all the APM packages you can also use smart for that that supports as you may know also non-APM distributions or at least medium some other configurations for example the key table to make it fit for the keyboard you expect to be using you can define users in this case we only have a root user you can prepare the password for this user in an encrypted or hashed way you can of course also as regular users pre-configure the most differences between all these images will be the software that is installed on them so we have first of all to define a system repository where all your program packages are stored before the installation in this case we are using the this is a shortcut for open SUSE for the open SUSE installation repository is online it is basically an installation over an HTTP this open SUSE part only shortens the URL a bit and as you can see we have a little tool repository where all the packages for the installation of the image will be you can also use local file systems maybe have a local dvd with all the upends or you have a copied downloaded already this tree there is also file and local directories actually the next part is you select the packages you want to have installed and there are basically three types in this case I have two types of packages this is a pattern this is something that is specifically for open SUSE because that is the reason why it is prefixed by open SUSE we have so called patterns the default pattern means that is the minimal system you need to have a running open SUSE so it is actually a collection of packages you can select additional packages for example this package string if you want to have an editor on this and if you want to have you can manipulate where the packages are where you need them for example in this case you need it in the boot system because it is the boot splash branding so the image is starting already with an open SUSE graphics so that is all for the conflict XML file there are also some shell scripts in this case you only need this conflict SH that does after all the packages are installed in this change route environment it is actually used by changing you need a script you can do anything you can do in a shell script so you can manipulate files you can find some in this case I am talking about this open SUSE image there are some services enabled the run level that is used for booting up so boot in this case up to run level 3 only I think because it is an ASIC system and also SUSE specific art if you are running open SUSE conflict to do the system configuration this is fully configurable so if you don't want to use the SUSE system don't run open SUSE conflict for example so after we created the configuration for our system the actual file system 3 is built up and this is how when TV appears first in this thing you only need these two parameters prepare means we are calling it prepare step there is a third step there is a different parameter you need a directory for that where to store all the packages where to store the image and sorry, mix it up here is the description we have prepared before and the root is of course the root image there to put all the data and this call is running for a while because it is created for root tree this is usually where you can also after it is finally prepared can change root and do manipulations in it and this root tree is then the base for the next step I will show if you want to create more than one image type not only a user image maybe also a USB image then this step you have to be done only once then you have these basically you set up and create more images afterwards the third step create the image call create with the root path from the call before the type you want to have because you can of course configure more than one type as I already told in the description file in this case we want the user image and the destination directory where to put these user images and after that it also takes a while you have a ready image that you can use and for example check it first with vmware or qme if you have an user image for example and your pre-configured image is ready it is actually as easy as I described it here so far we are also only talking about the SUSE way because Kiwi is so far prepared only for open SUSE but it is as I can show you here as I already said not only SIPA is usable but only SMART so you can so far already build up the file system tree with for example Fedora or Debian packages and because the design is quite independent all the distribution specific stuff is stored into special functions that are in the moment prefixed by the name of them is prefixed by SUSE or open SUSE so to enhance Kiwi for really to Fedora or Debian or whatever images is create modules with appropriate prefix to do mostly the bootloader configuration that is definitely different than SUSE for example also Unity mostly the boot stuff is different in different distributions and of course the system configuration because it just is usually not available on other distributions and after these steps are done I think it should be easy to do these other distribution images with it so I can only say please contribute if you are interested in building system images and you may be familiar with other distributions if you are able to program in tol then you will have it easy because Kiwi is completely built in tol only some parts are of course shared script and it is open source and free software because it's licensed as GPR and to contribute you can simply check out it on the Github repository and Baleos DE so if you want to find out more about Kiwi there are two websites the project page on Baleos DE and of course in the open source there will be Kiwi where you can find some more use cases there are also already people that did some projects with it they mostly have done descriptions what they did and wrote it down in Kiwi we find more examples and a quite good documentation I have printed here that's a Kiwi cookbook where you can quite easily create some types of images step by step explained and if you want to install it via RPM you can find them in the open source build service in the project visualization appliances yeah I think I was quite fast so I already am finished with my talk so if you have questions just ask them so at the moment only open source is fully supported yeah but it is of course it is designed platform independent or distribution independent so basically you only need to it is possible for the future there are only these specific parts I and Marcus are not aware of that's a difference between these different distributions I don't know how to set up a meta-assist for example so if you are able to do that you can implement it yeah I think the main problem is that the other distributions already have their own infrastructure set up for things like that RPM has its tools for really nice cities and even insulation cities or DVDs or other images we got the same and further ones so there's no need to adopt a tool for another distribution which maybe don't fit enough you have to put quite a lot of effort into it to allow builds on other distributions so the question is does it have a real benefit in comparison with the tools other distributions already had for quite a while even before Kiwi has been started the only benefit I personally see is the usage of SUSE Studio to build other distributions this is a unique project I don't know a distribution who already has a similar infrastructure it's really cool and if you could manage to implement a build system for other distributions out of studio this would be a great effort for everyone so basically to do that it would be necessary to make it possible to create because in a build service we already are able to build packages actually for other distributions and since it is quite based on a build service yeah but I've tried to build filler packages with the old SUSE build service it's not quite usable as a tool to be used within our distribution so basically you need a spec file you simply come together and sit down and talk about it and maybe we'll find a way to improve it to make this happen I think the main thing that differentiates Kiwi from all the other distribution scripts that are there to build live series is that it is not distribution specific so you have a tool that everybody can use of course it would need adoption but you have to put quite a lot of effort into it to make it happen that it will be able to build other distributions I'm not sure how hard it will be to implement for example I don't think it's too hard as you already mentioned there are scripts doing Fedora images for example and I think near more or less doing the same so we could snip out some the specific parts and plug it into Kiwi so I see a few of this advantage no matter if it's Kiwi or something like that if you have one distribution and you just re-run it for the problem is in history because every distribution already had that tool nobody came together and I definitely liked it to keep it custom by design definitely it's open by design it's a cool project but it's not only just about building distribution images I know from a customer who wants to go this way for filling his appliance adding his own code to the distribution and right now he runs on different generations on SUSE he wants to package his application for different appliance things like that but the big idea on them is also they want to have one description for all the setup and hardware drivers and a lot of stuff involved and appliance stuff and things like that and if they don't want to like or if a customer ask them we don't want to like this box running SUSE linux or whatever then they just replace the part oh take this distribution we made that and that didn't have to get but at least it works with different versions of SUSE linux it would be really great if I now that more and more of the designs for my system automation stuff running Fedora Debian based whatever then it would be much easier to package all the stuff I want to ship and so better flavor in this flavor and things like that and having a generic tool which does all of this would be really nice and since it's scripted I haven't looked a little bit into it and didn't try to adjust these things just fix other walks and should be doable so one question about the framework is the studio part is it already open sourced now or is it still internal is it available it is available but I think it's not really open sourced the studio part but you're planning to make it open sourced or does not plan to make it open sourced that's maybe you can ask in the build service talk later because I'm not involved in the build service actually in the build service in the studio talk later I'm not involved in the studio team you're mentioning open sourced can I also use it for a slash yeah definitely because it's basically the same you only have to define the repository for the slash packages and the configuration is nearly the same they're just cheap open sourced enough some people are like it do you know of real world uses of KB what are people doing with it on the in the Rikki there are some use cases people actually using it so the studio for example ships an appliance system image to do in-house customers can do in-house image creation with it so it is basically its own customer yeah so what about the if you concentrate on Susie what about the de-brand or re-brand process is it already implemented in KB right now because I know we talked about for a year or so back because it's not allowed to rebuild a Susie based distribution if it still contains the Susie signs I'm not sure about that there is a simple I mean that's rights or law stuff so there is a simple way of just requesting permissions to distribute that stuff and there is a tool called Rembrandt which is who has also all branded stuff yeah yeah so we have the choice not to install these packages that are branded it's nothing related to Kiwi from another build source or something like that I guess you can split that I have to set up the old build service source from which you build which only contains packages so we don't have to use there are all the branded packages separate packages there are dependencies from other packages I don't think that you can set the new movement there is the main package then there is the Dash branding Dash upstream that contains the upstream branding then there is Dash openSuser and Dash Slash there is for example these boot splash branding package that is included here separately that's the reason why it is there no questions you still have what and all so you mentioned that it can create live CD images is there any thoughts of support for it creating an installer in it yeah I did not describe that it can also create actually the 11.3 images that will be released in I think 3 months or something like that will be created with Kiwi so installation sources are also possible actually one was already actually it's only less 11 SP1 currently doesn't matter it works and it's actually the part I am working on do you ship this configuration for example I don't think they are included here they are included in usership of packages Kiwi they are I don't think I have them in this computer but even 11.1 no 11.0 to 2 and not only live easel images there are also few a lot of configuration is there installation images too not only installation images only for live images you can check out the installation images description and how to build them is described perfectly in the documentation I am really happy about this you have written it up yes sir now it's written by the so thanks a lot if you are interested use the web pages they are really useful so thanks