In lorax-composer version 31.4 we have added the ability to setup a few more things when the image is created. The full documentation is here. It is now possible to modify the kernel boot cmdline, set the timezone, locale, open firewall ports, and enable services.
When you are building an image sometimes you need to add some configuration files, extra tools, etc. The temptation is to just copy them over from your local system and move on, but that isn’t the right answer. Unless you document where the files came from nobody looking at the image in 6 months will remember which version of them was included, where they came from, or even who created them.
The images created by lorax-composer have the root account locked and no other
accounts included. This is to make sure that you cannot accidentally
build and deploy an image without a password. Currently the cockpit-composer GUI
does not support setting up users, but you can easily do this from the cmdline
Weldr aka. Composer can generate custom images suitable for deploying systems, or as images ready to upload the cloud. It works great on Fedora, but on Red Hat Enterpise Linux there’s an additional wrinkle.
Weldr aka. Composer can generate images suitable for uploading to a VMWare ESXi or vSphere system, and running as a virtual machine there. The images have the right format, and include the necessary agents.
Weldr aka. Composer can generate images suitable for uploading to OpenStack cloud deployments, and starting instances there. The images have the right layout, and include cloud-init.
Weldr aka. Composer can generate images suitable for uploading to the Azure cloud, and running an instance there. The images have the right format, and include the necessary agents, as well as cloud-init.
Weldr aka. Composer can generate images suitable for uploading to Amazon Web Services, and starting an EC2 instance. The images have the right partition layout, and include cloud-init.
Making sure we have good translations takes a lot of work during development. This article is a brief guide for developers on how to handle translations in the welder-web project.
Have you ever noticed that Fedora keeps getting bigger and package names keep getting.. gnarlier? Let’s have a look!
A RPM package is not just a pile of files. It’s also a pile of metadata to help with the management of those files. RPM allows the user to track files, verify them, and keep everything internally consistent through dependencies. So how do dependencies work?
lorax-composer now has a command line tool, it is called
composer-cli, and it
can be installed from the lorax-composer
yum install composer-cli. It uses the lorax-composer socket file
to communicate with the API server so it must be run on the same system as
lorax-composer, and by a user who has permission to access the socket. eg. root
or a member of the weldr group.
(tl;dr version: let’s start mapping out the RPM ecosystem as a whole - from high-level abstractions and use cases down to the bits and bytes - so we can make improvements and build the software ecosystem we really want.)
When lorax-composer version
is released it will support 3 output types.
partitioned-disk. Originally I was going to write about adding
support, but it ended up being a bit more
than it needed to be, so after re-arranging the code to support all of the
livemedia-creator output types, we’ll talk about adding partitioned disk
In my previous post about Lorax Composer I said that the docker setup would be useful for keeping track of the progress of the project. It ends up that isn’t true once you start composing images. livemedia-creator and lorax-composer depend on Anaconda for actually installing packages to the images. Because Anaconda depends on system services like device-mapper, among other things, it isn’t possible to use it inside of a container. It needs a full system or a virtual machine.
The file system–a tree-like representation of file data and metadata–is a necessary component of any export from RPM data, even if the export is not to a file system. There are two reasons for this: directory permissions, and symlinks.
The Weldr project is made up of several components. This can make it difficult for curious users to explore its capabilities without spending a bunch of time setting up requirements. Docker can make this process easier (assuming that you already have docker setup and running on your system).
Let’s say you have some content that you want included in Fedora. Let’s say you used to know how to do that, but now everything is different and weird. What’s going on, anyway? How does anything work?
The Weldr project uses IRC to communicate with each other around the world. We have team members in multiple countries and timezones and being available on a chat system is helpful. We are on the FreeNode network in the #weldr channel.
This is a test post.