We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Distribution Image building with KIWI

00:00

Formal Metadata

Title
Distribution Image building with KIWI
Title of Series
Number of Parts
97
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The OpenSuSE KIWI Image System provides a complete operating system image solution for Linux supported hardware platforms as well as for virtualisation systems like Xen, Qemu or VMware. The KIWI architecture was designed as a two level system. The first stage, based on a valid software package source, creates a so called physical extend according to the provided image description. The second stage creates from a required physical extend an operating system image. The result of the second stage is called a logical extend or short an image. There are already a lot of projects using the KIWI image system today including the very popular SUSE Studio online appliance builder. This talk briefly introduces the KIWI image system and shows how to create images based on distributions other than openSUSE.
5
15
Thumbnail
48:33
41
Thumbnail
35:21
47
48
Thumbnail
1:03:30
50
75
Thumbnail
50:56
94
Revision controlClient (computing)Data miningSystem programmingFront and back endsConfiguration spaceGraphical user interfaceMedical imagingSource codeComputer fileRepository (publishing)Regular graphWeb 2.0Computer animation
Execution unitInclusion mapSystem programmingMedical imagingSystem administratorVirtual machineSystem programmingType theoryBootingCommutatorSoftwareHard disk driveProjective planeCuboidBackupOpen sourceNeuroinformatikUniverse (mathematics)Row (database)AreaSineDistribution (mathematics)Computer programmingLimit (category theory)File viewerMultiplication signLinearizationVideo gameComputer animation
InformationConfiguration spaceFile systemBootingHard disk drivePay televisionBitSystem programmingComputer filePresentation of a groupDifferent (Kate Ryan album)Uniform resource locatorCASE <Informatik>Repository (publishing)Line (geometry)RootkitMedical imagingLevel (video gaming)Process (computing)HypermediaNetwork topologyPasswordSoftwareKeyboard shortcutOpen setProcedural programmingMereologyDistribution (mathematics)Computer hardwareType theoryDescriptive statisticsDirectory serviceElectronic mailing listService (economics)Revision controlData managementTable (information)Meta elementAuthorizationSet (mathematics)Food energyFerry CorstenMetreOrder (biology)Key (cryptography)Point (geometry)InternetworkingGroup actionComputer programmingNegative numberSelf-organizationLecture/Conference
Moment of inertiaMedical imagingFile systemDescriptive statisticsMereologyConfiguration spaceLocal ringNetwork topologyComputer fileParameter (computer programming)System programmingRight angleDirectory serviceType theoryCASE <Informatik>Group actionScripting languageLevel (video gaming)Gastropod shellService (economics)BootingRootkitSystem callMathematicsIntegrated development environmentPattern languageDefault (computer science)Selectivity (electronic)AdditionText editorOpen setOpen sourceProjective planeMultiplication signEmailVideo gameShared memoryTime zoneDenial-of-service attackFood energySurfaceRoundness (object)Sound effectSource codeRevision controlComputer animationLecture/Conference
Type theoryFile systemSpecial functionsOpen sourceBuildingService (economics)BootingDifferent (Kate Ryan album)Configuration spaceProjective planeComputer programmingMereologyVisualization (computer graphics)Gastropod shellScripting languageFreewareSoftwareDistribution (mathematics)Medical imagingNetwork topologyLatent heatSystem programmingMoment (mathematics)Module (mathematics)Repository (publishing)WebsiteWeb pageWikiCASE <Informatik>Descriptive statisticsOnline helpContent (media)Fitness functionSystem administratorRadio-frequency identificationGoodness of fitOffice suiteComputer animationLecture/Conference
Execution unitPlanningBuildingDistribution (mathematics)Service (economics)Medical imagingSource codeComputer fileScripting languageFlow separationSign (mathematics)Descriptive statisticsDigitizingMetadataEmulatorReal numberPairwise comparisonBitProjective planeRight anglePhysical lawMereologySimilarity (geometry)Axiom of choiceElectric generatorCartesian coordinate systemDifferent (Kate Ryan album)CuboidRevision controlConfiguration spaceMoment (mathematics)WikiCASE <Informatik>Cross-platformDevice driverOpen sourceSeries (mathematics)Latent heatSystem programmingVideoconferencingOpen setRepository (publishing)Design by contractCodeClient (computing)TunisSoftware frameworkGoodness of fitCellular automatonVideo gameText editorComputer hardwareTask (computing)Meta elementGame theoryMusical ensembleConstructor (object-oriented programming)Negative numberHome pageWeightWaveProcess (computing)SupersymmetryComputer animationLecture/Conference
Computer fileSource codeMedical imagingNeuroinformatikInsertion lossConfiguration spaceLinear multistep methodMereologyAuthorizationGreatest elementWeb pageProcess (computing)Shared memoryKey (cryptography)Touch typingEvent horizonCASE <Informatik>Ferry CorstenMetropolitan area networkInstallation artComputer animationLecture/Conference
Transcript: English(auto-generated)
I'm a member of the OpenSoupher team actually and I'm talking today about a tool mostly used for OpenSoupher 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 intertromable CDs or DVDs that are fully runnable without installation on your system.
In the meantime, it's also possible to create the installation repositories, so the regular version of the DVDs with it. And maybe you've heard of the SUSE studio, it's a client's 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 Yast or a system configuration tool, a Yast graphical user interface for it, so you can, if you don't want to use command line tools, you can have a graphical version of it.
So what is an image? Not like this one, it's more or less these kind of images. Kiwi supports creation of all these types of system images. I already mentioned the live CD or DVD, same booting 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. So for network bootable images, PXE for example, virtual machine images like new AMU and VMware are supported, also for SAN and this EC2 Amazon stuff.
So how are these images useful for you maybe? For example, if you want to distribute your software, maybe you have an open source project or even a proprietary project running in minutes, so you can create for example
DVD with your software already installed and pre-configured, simply distributed 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 pre-address your 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 maybe 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 in a short example how to use Kiwi. It basically needs only three steps till you have your image ready.
First of all you have to create a description, which means a configuration file where you describe what you want to have on your image. Then you run Kiwi to prepare the file system tree, so it's more or less the same as your running system
and the step three is create the image in the type you described before. So if you want to have an ESO or a hard disk image or whatever. 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 you need for your image in it
and 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 during the build process I will explain. It can also contain simply files that you want to have on your image and they maybe are not packaged into an RPM package or a JVM package for example.
There are also files that you maybe do 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 but you will not have them in the system you have running afterwards.
And in the openSUSE case for this just to first boot configuration if you will use this just to first boot tool
to do configurations on the running system on the first boot. So if your customer is booting your image then maybe you 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 however for this example that is by the way included in the documentation of the key not only this one, there are many different use cases included it only needs about 40 lines of description to have a openSUSE live ESO image prepared.
And these are basically these 40 lines. Everything is contained in the image container and for example we have some meta description for it. The author is the original author of Kivy's Michael Schaeffer.
I'm doing the presentation on this one. 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 ESO included that is the already prepared and in Kivy included boot image
you can give it a version you can use different package managers in this case we are using the SUSE tool super to install all the RPM packages you can also use smart for that that supports as you maybe know also non-RPM distributions
or at least Debian. 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, hashed way. You can of course also add a usual as regular users pre-configured.
The most differences between all these images will be the software that is installed on them. So we have first of all you have 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 where the procedure is online. This is basically an installation over a HTTP this open SUSE part only shortens the URL of it and as you can see we have the elevator 2 repository
where all the packages for the installation of the image will be... You can also use local file systems maybe you have a local DVD with all the APIs on it or you have copied, downloaded already these three.
There is also file and local directories actually. The next part is you select the packages you want to install and there are basically three types
in this case only two types of packages. This is a pattern, this is something that is specifically for open SUSE that's the reason why it is prefixed by open SUSE.
We have so called patterns and the default pattern means that is the minimal system you need to have a running open SUSE. So it's actually a collection of packages. You can select additional packages for example this package win
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's the boot splash branding so that your image is starting already with an open SUSE graphics.
So that's all for the config.xml file. There are also some shell scripts in this case you only need this config.sh that does... After all the packages are installed
in this change group environment it is actually used by change group. You need a script you can do anything you can do in a shell script so you can manipulate files. You can for example in this case I'm talking about this open SUSE image
there are some services enabled. The run level that is used for booting up so it boots in this case up to run level 3 only I think because it's a basic system. And also SUSE specific parts you're running open SUSE config
to do the system configuration with it. This is fully configurable so if you don't want to use the SUSE system don't run open SUSE config for example. So after we created the configuration for our system
the actual file system tree is built up and this is how or when TD appears first you only need these two parameters.
Prepare means we are calling it in the prepare step. The third step is a different one right now. You need a directory for that where to store all the packages. Not the packages, where to store the image.
Sorry, mixed it up. Here's the description we have prepared before and the root is of course the root image to go to all the data. And this call is running for a while
because it's created a full root tree. This is usually where you can also after it is finally prepared you 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 has to be done only once then you have basically your setup and create more images of the root.
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 type and the destination directory where to put this user image type. And after that it also takes a while
you have a ready image that you can use and you can for example check it first with VM there or QM if you have an user image for example and your pre-configured image is ready.
It's actually as easy as I described it here. So far we were only talking about the SUSE way because Kiwi is so far prepared only for OpenSUSE
but as I already said not only super is usable but only smart so you can so far already build up the file system tree
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 OpenSUSE 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 UNIT-LD 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 always 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 Perl then you will have it easy because Kiwi is completely built in Perl
only some parts are of course shell scripts and it is open source and free software because it is licensed with GPL and to contribute you can simply check out it
on the git repository and Berlioz.de so if you want to find out more about Kiwi there are two websites the project webpage on Berlioz.de and of course in the open source wiki
where you can find some more use cases there are also already people that did some projects with it they mostly have done descriptions of what they did and wrote it down in the wiki you find more examples and a quite good documentation
I have printed here it'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 I think I was quite fast so I am already finished with my talk
so if you have questions just ask them so at the moment only OpenSUSE is fully supported? yeah, but of course it is designed platform independent or distribution independent so basically you only need to
yeah, if there is only the specific parts I and Marcus are not aware that are different between these different distributions I don't know how to set up a metadata system for example
so if you are able to do that you can implement it and it should be easy to do that 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 building ICDs
and even installation CDs or DVDs or other images we got the same in third of all so there is no real need to adapt a tool from another distribution which maybe don't fit enough or 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 because 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 basically to do that it would be necessary to make it possible to create images because in the build service we already are able to build packages actually for other distributions and since it is quite based on the build service
yeah but I've tried to build to build all packages with the openSUSE build service and it's not quite usable as the tools we use within our distribution so basically you need a spec file to come together and sit down for a while 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 because as you already mentioned there are scripts doing video images for example and I think you're more or less doing the same so we could snip out the specific parts and plug it into Kiwi somehow
yeah? I see a few advantage no matter if it's Kiwi or something else if you have one description and you just rerun it but the problem is in history because every distribution always had their tools nobody came together and I definitely like the approach
to keep it open by design definitely the same example is newer it's open by design it's a good contract but it's only just about building distribution images I learned from a customer who wants to go this way for filling his appliance and adding his own code to a distribution
and right now he runs on different generations of SUSE he wants to just package his application all the stuff for different things like that but the big idea on them is also they want to have one description for all the setup and their hardware drivers a lot of stuff involved and things like that and if the customer asks
oh we don't want 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 a get but at least it works with different versions of SUSE Linux it would be really great if I now that more and more digitization is coming, maybe it's another topic if someone asks, I have to have
this appliance for my system emulation stuff running Fedora Debian based, whatever then it would be much easier to package all the stuff I want to ship and sell and this flavor and things like that and having a generic tool which does all of this would be really nice since it's scripted I have looked a little bit into it
and I didn't try to adjust these things, just fix other works and it 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 Ok, but you're planning to make it open source or does novel plan to make it open source? Maybe you can ask in the build service talk later because I'm not involved in the build service actually, in the build service and then in the studio talk later, I'm not involved in the studio team
You mentioned open source, can I also use it for SLES? Yeah, definitely because it's basically the same, you only have to define the repository for the SLES packages and the configuration is nearly the same
They're just cheap open source knockoffs Yeah Some people are like it Do you know of real world uses of kibis, what are people doing with it? On the wiki
there are some use cases people actually using it Yeah The SUSE 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 So what about if you concentrate on SUSE what about the debrand or rebrand process, is it already implemented in kibis right now because I know we talked about it for a year or so back
because it's not allowed to rebuild a SUSE based distribution and spread it if it still contains the SUSE signs Is it already implemented? I'm not sure about that Well There is a simple I mean that's rights or law
stuff, so there is a simple way of just requesting permissions to distribute the stuff and there is a tool called Rembrand which is Yeah, maybe the choice not to install
these packages that are branded It's nothing related to kibis From another build service source or something like that I guess you can split that I have to to set up your own build service source from which you build which only contains packages you can rebrand it or something like that You simply don't have to
use, all the branded packages are separate packages Of course, but there are dependencies from other packages, I don't think that you can simply remove them Oh you can, you can There is the main package, then there is dash branding, dash upstream
that contains the upstream branding, then there is dash oconsuso and dash slats or whatever There is for example these foot splash branding package that is included here separately, that's the reason why it is there
Bill, no questions? Please do have a bottom up So you mentioned that it can create live CD images Is there any thoughts or support for
creating an installer? Yeah I did not describe that, you can also create the or actually the LMM.3 images that will be released in 3 months or something like that will be created with
TV, so installation sources are also possible in the meanwhile Actually there is one loss already Actually? Ah okay it is only less LMM SP1 that is currently okay, doesn't matter It works And that is actually the part I am working on
Do you ship this XML configuration files as example? I don't think They are included in user shared of packages PD They are I don't think in this computer even LMM.1 to no, LMM.0 to
2 and not only live ESO images also live USB sticks and a lot of configuration is there And for the installation images too? Not for the installation images, only for the live images Exactly You can check out the installation images Okay
And how to put them is described perfectly in the documentation I am really happy about this documentation I think Now it is written by the original author Marcus Schaeffer Thanks a lot
If you are interested in use the packages They are really useful So thanks