Overview

Once every true-linux engineer gets a trouble: there is no any software in his distro or it's built without needed options. I am keen on the phrase: "Only source control gives you freedom".

Of course, you can build this software on your computer without any src-packages, directly (with simplification: configure, make, make install). But it's a non-reproducible solution, also hard for distribution.

The better way is to make distro-aligned package that can be built if needed and that produces lightly distributed binary-packages. It's about debian-source packages(debian,ubuntu,etc), pkgbuild (for arch), ebuild for gentoo, src-rpm for red hat-based, and many others.

I will use cri-o like a specimen.

Before reading the text below I strongly recommend to get familiarized with the official Debian policy manual placed here and debhelper manpage.

Also you will be required to setup some variables like DEBMAIL and DEBFULLNAME for proper data in changelog and other places.

Overview

Sometimes all of us need to make a graphical installer for one's own linux distro. It goes without saying that you are able to use a distro-specific installer like Anaconda for RedHat-based or DebianInstaller for debian-based. On the other hand Calamares is a graphical installer which is not aligned with only one package manager.

I want to share my experience how to make a universal install solution with GUI. I did not find any complete article about it, hence, I reinvented the wheel.

Долго держался, не публиковал этот материал. Последний каплей стало вот это: Как Unix-way убивает десктопный Linux

Попалось мне обсуждение на habr Q&A habr Q&A
Очень понравился вот этот ответ от пользователя xolst9.

Стал вспоминать свой опыт и решил развернуто выразить свой взгляд на проблему.
В основном буду писать о Gentoo-linux, но во многом это верно и для Arch linux. С ним у меня опыт по-меньше, но этот дистриб я также считаю отличной учебной партой.

Tested on the following configuration:
Server: ubuntu 20.04
Clients: ubuntu 16.04, 18.04, 20.04

It doesn’t require a lot of software to create it.

Intro

Every Linux professional write scripts. Someеimes light, linear. Sometimes complex script with functions and libs(yes, you can write your bash-library for use in other scripts).

But some of the scripts need a configuration file to work. For instance, I wrote a script that builds the ubuntu image for pxe, and I need to change the build process without build-script changes. The best way to resolve this task is to add configuration files.

Intro

PXE is a great solution for booting a diskless computer (or a computer without an OS installed). This method is often used for terminal stations and OS mass installation.

Stock ubuntu (16.04) in pxe-mode can mount rootfs only from NFS. But this is not a great idea: any difficulties with the network/NFS server and the user gets problems.

In my opinion, it's best to use other protocols, such as http/ftp. Once booting, you will have an independent system

The basics of porting

Originally, Buildroot offers a limited number of packages. It makes sense — there is everything you need, but any other packages can be added.

To add a package, create 2 description files, an optional checksum file, and add a link to the package in the general package list. There are hooks at different stages of the build. At the same time, Buildroot can recognize the needed type of packages:

Intro

Like I said earlier in previos articles, Buildroot is a great system for embedded Linux development. But sometimes strange things can happen.

Once upon a workday, I got the following task: add printing system in firmware (Kraftway terminal Linux next generation). Ok, so I had to add cups + cups filter and to build firmware. I set a postscript-printer and got an error "Filter failed". Trivial tasks turned into serious work.

In this article, I wrote my own way of solving this problem. It may be useful for other developers and IT-specialist and, also, for a deeper understanding of the Buildroot.

If you are a Buildroot beginner, I recommend reading my previous articles.

Update 1 may 2020

Revisioned versions of this patches applied to master.

Introduction

In my previous article (Monitor linux) I wrote, what is this distro and how it works. Now i will write how to do it. It's may be interesting for everyone, who want to study buildroot.

Target goals

The result we get from article is the following:

• Firmware (non-volatile image with restorable config)
• Easy management via web-interface
• Cross-platform (qemu x86_64, arm-based SBC like rasberry 4, beagle bone black and asus tinker board)
• Support without extra effort

About

This is small cross-platform linux-distro with zabbix server. It's a simple way to deploy powerful monitoring system on ARM platfornms and x86_64.

Worked as firmware (non-changeable systemd image with config files), have web-interface for system management like network settings, password and other.

Who is interested

• System admins/engineers who need to fast deploy of zabbix server.
• Everyone, who want to deploy zabbix on ARM.
• Enthusiasts

Введение

При разработке под linux возникают задачи создания интерактивных скриптов, выполняемых при включении или завершении работы системы. В system V это делалось легко, но с systemd вносит коррективы. Зато оно умеет свои таймеры.

История задачи

Небольшие по размеру фирмы с одной стороны, нуждаются в качественном мониторинге своей инфраструктуры (особенно в свете повсеместной виртуализации ), с другой стороны, для них финансово тяжело закупать новое оборудование. Также часто встречаются проблемы с серверной/аппаратной: зачастую стоит 1-3 tower-сервера рядом с пользовательскими рабочими местами или в небольшой нише/чулане.

Проще использовать уже готовую сборку(дистрибутив), который достаточно залить на microSD-карту и вставить в распространенный одноплатный компьютер (beaglebone, семейства raspberry pi и orange pi, asus tinker board). Кроме того, такое оборудование стоит недорого и может быть установлено в любом месте.

В данном разделе я рассматриваю часть возможностей по кастомизации, которые потребовались мне. Это не полный список того, что предлагает buildroot, но они вполне рабочие и не требуют вмешательства в файлы самого buildroot.

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

Зачем собирать свой дистрибутив? Зачастую нужен ограниченный функционал при ограниченных ресурсах. Ещё чаще в автоматизации нужно создавать прошивки. Приспосабливать дистрибутив общего назначения, вычищая лишние пакеты и превращать его в прошивку путь более трудоёмкий, чем собрать новый дистриб. Использование Gentoo тоже имеет свои ограничения.

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.