DebConf23 https://debconf23.debconf.org/ took place from 2023-09-10 to –17 in Kochi, India.
Four employees (three Debian developers) from NetApp had the opportunity to participate in the annual event, which is the most important conference in the Debian world: Christoph Senkel, Andrew Lee, Michael Banck and Noël Köthe.
What is DebCamp? DebCamp usually takes place a week before DebConf begins. For participants, DebCamp is a hacking session that takes place just before DebConf. It’s a week dedicated to Debian contributors focusing on their Debian-related projects, tasks, or problems without interruptions.
DebCamps are largely self-organized since it’s a time for people to work. Some prefer to work individually, while others participate in or organize sprints. Both approaches are encouraged, although it’s recommended to plan your DebCamp week in advance.
During this DebCamp, there are the following public sprints:
- Debian Boot Camp: An introduction for newcomers on how to contribute to Debian more deeply.
- GPG keys 101: Get your keys ready for DebConf’s key signing party: An introduction to PGP/GPG keys and the web of trust, primarily targeting those new to Debian who don’t have a GPG key yet.
In addition to the organizational part, our colleague Andrew also attended and arranged private sprints during DebCamp:
- Debian Installer hacking: Debian installer is a complex project with multiple components. We had an on-site d-i hacker, Alper Nebi Yasak, who guided us in addressing issues specific to zh_TW locale users in the Debian installer.
- LXQt/LXDE hacking session: LXQt and LXDE are lightweight desktop environments for Linux users. Our colleague Andrew Lee leads the LXQt team in Debian and also provided assistance to the LXDE team in the absence of their original team leader from Ukraine.
It also allows the DebConf committee to work together with the local team to prepare additional details for the conference. During DebCamp, the organization team typically handles the following tasks:
- Setting up the Frontdesk: This involves providing conference badges (with maps and additional information) and distributing SWAG such as food vouchers, conference t-shirts, and sponsor gifts.
- Setting up the network: This includes configuring the network in conference rooms, hack labs, and video team equipment for live streaming during the event.
- Accommodation arrangements: Assigning rooms for participants to check in to on-site accommodations.
- Food arrangements: Catering to various dietary requirements, including regular, vegetarian, vegan, halal, gluten-free (regular, vegetarian, vegan), and accommodating special religious and allergy-related needs.
- Setting up a conference bar: Providing a relaxed environment for participants to socialize and get to know each other.
- Writing daily announcements: Keeping participants informed about ongoing activities.
- Organizing day trip options.
- Arranging parties.
The conference itself started on Sunday 10. September with an opening, some organizational stuff, GPG keysigning information (the fingerprint was printed on the badge) and a big welcome to everyone onsite and in the world.
Most talks of DebConf were live streamed and are available in the video archive. The topics were broad from very technical (e.g., “What’s new in the Linux kernel”) over organizational (e.g., “DebConf committee”) to social (e.g., “Adulting”).
Thanks a lot, to the voluntarily organized video team for this video transmission coverage.
On the last day of DebConf, the traditional lightning talks were held. One talk in particular was noticed, the presentation of extrepo by Wouter Verhelst. At NetApp, we use bookworm-based Debian ThinkPad’s. However, in a corporate environment, non-packaged software needs to be used from time to time, and extrepo is a very elegant way to solve this problem by providing, maintaining and keeping UpToDate a list of 3rd-party APT repositories like Slack or Docker Desktop.
On Tuesday, an incredibly special lunch was offered at DebConf: a traditional Kerala vegetarian banquet (Sadya in Maralayam), which is served on a banana leaf and eaten by hand. It was quite unusual for the European part of the attendees at first, but a wonderful experience once one got into it.
On Wednesday, the Daytrip happened and everybody could choose out of five different trips: https://wiki.debian.org/DebConf/23/DayTrip
The houseboat trip was a bus tour to Alappuzha about 60 km away from the conference venue. It was interesting to see (and hear) the typical bus, car, motorbike and Tuktuk road traffic in action. During the boat trip the participants socialized and visited the local landscape outside the city.
Unfortunately, we had an accident at one of the daytrip options. Abraham a local Indian participant drowned while swimming.
It was a big shock for everybody and all events including the traditional formal dinner were cancelled for Thursday. The funeral with the family was on Friday morning and DebConf people had the opportunity with organized buses to participate and say goodbye.
NetApp internal dinner on Friday
The NetApp team at DebConf wanted to take the chance to go to a local restaurant (“were the locals go eating”) and enjoyed very tasty food.
Sunday was the last day of DebConf23. As usual, the upcoming DebConf24 was very briefly presented and there was a call for bids for DebConf25.
Maybe see you in Haifa, Israel next year.
Authors: Andrew Lee, Michael Banck and Noël Köthe
Congratulations to the Debian Community
The Debian Project just released version 11 (aka “bullseye”) of their free operating system. In total, over 6,208 contributors worked on this release and were indispensable in making this launch happen. We would like to thank everyone involved for their combined efforts, hard work, and many hours pent in recent years building this new release that will benefit the entire open source community.
We would also like to acknowledge our in-house Debian developers who contributed to this effort. We really appreciate the work you do on behalf of the community and stand firmly behind your contributions.
What’s New in Debian 11 Bullseye
Debian 11 comes with a number of meaningful changes and enhancements. The new release includes over 13,370 new software packages, for a total of over 57,703 packages on release. Out of these, 35,532 packages have been updated to newer versions, including an update in the kernel from 4.19 in “buster” to 5.10 in bullseye.
Bullseye expands on the capabilities of driverless printing with Common Unix Printing System (CUPS) and driverless scanning with Scanner Access Now Easy (SANE). While it was possible to use CUPS for driverless printing with buster, bullseye comes with the package ipp-usb, which allows a USB device to be treated as a network device and thus extend driverless printing capabilities. SANE connects to this when set up correctly and connected to a USB port.
As in previous releases, Debian 11 comes with a Debian Edu / Skolelinux version. Debian Edu has been a complete solution for schools for many years. Debian Edu can provide the entire network for a school and then only users and machines need to be added after installation. This can also be easily managed via the web interface GOsa².
Debian 11 bullseye can be downloaded here.
For more information and greater technical detail on the new Debian 11 release, please refer to the official release notes on Debian.org
Contributions by Instaclustr Employees
Our Debian roots run deep here. credativ, which was acquired by Instaclustr in March 2021, has always been an active part of the Debian community and visited every DebConf since 2004. Debian also serves as the operating system at the heart of the Instaclustr Managed Platform.
For the release of Debian 11, our team has taken over various responsibilities in the community. Our contributions include:
- 90% of the PostgreSQL packaging of the new release Maintenance work on various packages
- Support as Debian-Sys-Admin
- Contributions to Debian Edu/Skolelinux
- Development work on kernel images
- Development work on cloud images
- Development work for various Debian backports
- Work on salsa.debian.org
Many of our colleagues have made significant contributions to the current release, including:
- Adrian Vondendriesch
- Alexander Wirt (Formorer)
- Bastian Blank (waldi)
- Christoph Berg (Myon)
- Dominik George (natureshadow)
- Felix Geyer (fgeyer)
- Martin Zobel-Helas (zobel)
- Michael Banck (azeem)
- Michael Meskes (feivel)
- Noël Köthe (Noel)
- Sven Bartscher (kritzefitz)
How to Upgrade
Given that Debian 11 bullseye is a major release, we suggest that everyone running on Debian 10 buster upgrade. The main steps for an upgrade include:
- Make sure to backup any data that should not get lost and prepare for recovery
- Remove non-Debian packages and clean up leftover files and old versions
- Upgrade to latest point release
- Check and prepare your APT source-list files by adding the relevant Internet sources or local mirrors
- Upgrade your packages and then upgrade your system
You can find a more detailed walkthrough of the upgrade process in the Debian documentation.
All existing credativ customers who are running a Debian-based installation are naturally covered by our service and support and are encouraged to reach out.
If you are interested in upgrading from your old Debian version, or if you have questions with regards to your Debian infrastructure, do not hesitate to drop us an email or contact us at firstname.lastname@example.org.
Or, you can get started in minutes with any one of these open source technologies like Apache Cassandra, Apache Kafka, Redis, and OpenSearch on the Instaclustr Managed Platform. Sign up for a free trial today.
Patroni is a clustering solution for PostgreSQL® that is getting more and more popular in the cloud and Kubernetes sector due to its operator pattern and integration with Etcd or Consul. Some time ago we wrote a blog post about the integration of Patroni into Debian. Recently, the vip-manager project which is closely related to Patroni has been uploaded to Debian by us. We will present vip-manager and how we integrated it into Debian in the following.
To recap, Patroni uses a distributed consensus store (DCS) for leader-election and failover. The current cluster leader periodically updates its leader-key in the DCS. As soon the key cannot be updated by Patroni for whatever reason it becomes stale. A new leader election is then initiated among the remaining cluster nodes.
PostgreSQL Client-Solutions for High-Availability
From the user’s point of view it needs to be ensured that the application is always connected to the leader, as no write transactions are possible on the read-only standbys. Conventional high-availability solutions like Pacemaker utilize virtual IPs (VIPs) that are moved to the primary node in the case of a failover.
For Patroni, such a mechanism did not exist so far. Usually, HAProxy (or a similar solution) is used which does periodic health-checks on each node’s Patroni REST-API and routes the client requests to the current leader.
An alternative is client-based failover (which is available since PostgreSQL 10), where all cluster members are configured in the client connection string. After a connection failure the client tries each remaining cluster member in turn until it reaches a new primary.
A new and comfortable approach to client failover is vip-manager. It is a service written in Go that gets started on all cluster nodes and connects to the DCS. If the local node owns the leader-key, vip-manager starts the configured VIP. In case of a failover, vip-manager removes the VIP on the old leader and the corresponding service on the new leader starts it there. The clients are configured for the VIP and will always connect to the cluster leader.
Debian-Integration of vip-manager
For Debian, the
pg_createconfig_patroni program from the Patroni package has been adapted so that it can now create a vip-manager configuration:
pg_createconfig_patroni 11 test --vip=10.0.3.2
Similar to Patroni, we start the service for each instance:
systemctl start vip-manager@11-test
The output of
patronictl shows that
pg1 is the leader:
+---------+--------+------------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+------------+--------+---------+----+-----------+ | 11-test | pg1 | 10.0.3.247 | Leader | running | 1 | | | 11-test | pg2 | 10.0.3.94 | | running | 1 | 0 | | 11-test | pg3 | 10.0.3.214 | | running | 1 | 0 | +---------+--------+------------+--------+---------+----+-----------+
In journal of ‘pg1’ it can be seen that the VIP has been configured:
Jan 19 14:53:38 pg1 vip-manager: 2020/01/19 14:53:38 IP address 10.0.3.2/24 state is false, desired true Jan 19 14:53:38 pg1 vip-manager: 2020/01/19 14:53:38 Configuring address 10.0.3.2/24 on eth0 Jan 19 14:53:38 pg1 vip-manager: 2020/01/19 14:53:38 IP address 10.0.3.2/24 state is true, desired true
If LXC containers are used, one can also see the VIP in the output of
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED pg1 RUNNING 0 - 10.0.3.2, 10.0.3.247 - false pg2 RUNNING 0 - 10.0.3.94 - false pg3 RUNNING 0 - 10.0.3.214 - false
The vip-manager packages are available for Debian testing (
bullseye) and unstable, as well as for the upcoming 20.04 LTS Ubuntu release (
focal) in the official repositories. For Debian stable (
buster), as well as for Ubuntu 19.04 and 19.10, packages are available at
apt.postgresql.org maintained by credativ, along with the updated Patroni packages with vip-manager integration.
In case of a planned switchover, e.g.
pg2 becomes the new leader:
# patronictl -c /etc/patroni/11-test.yml switchover --master pg1 --candidate pg2 --force Current cluster topology +---------+--------+------------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+------------+--------+---------+----+-----------+ | 11-test | pg1 | 10.0.3.247 | Leader | running | 1 | | | 11-test | pg2 | 10.0.3.94 | | running | 1 | 0 | | 11-test | pg3 | 10.0.3.214 | | running | 1 | 0 | +---------+--------+------------+--------+---------+----+-----------+ 2020-01-19 15:35:32.52642 Successfully switched over to "pg2" +---------+--------+------------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+------------+--------+---------+----+-----------+ | 11-test | pg1 | 10.0.3.247 | | stopped | | unknown | | 11-test | pg2 | 10.0.3.94 | Leader | running | 1 | | | 11-test | pg3 | 10.0.3.214 | | running | 1 | 0 | +---------+--------+------------+--------+---------+----+-----------+
The VIP has now been moved to the new leader:
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED pg1 RUNNING 0 - 10.0.3.247 - false pg2 RUNNING 0 - 10.0.3.2, 10.0.3.94 - false pg3 RUNNING 0 - 10.0.3.214 - false
This can also be seen in the journals, both from the old leader:
Jan 19 15:35:31 pg1 patroni: 2020-01-19 15:35:31,634 INFO: manual failover: demoting myself Jan 19 15:35:31 pg1 patroni: 2020-01-19 15:35:31,854 INFO: Leader key released Jan 19 15:35:32 pg1 vip-manager: 2020/01/19 15:35:32 IP address 10.0.3.2/24 state is true, desired false Jan 19 15:35:32 pg1 vip-manager: 2020/01/19 15:35:32 Removing address 10.0.3.2/24 on eth0 Jan 19 15:35:32 pg1 vip-manager: 2020/01/19 15:35:32 IP address 10.0.3.2/24 state is false, desired false
As well as from the new leader
Jan 19 15:35:31 pg2 patroni: 2020-01-19 15:35:31,881 INFO: promoted self to leader by acquiring session lock Jan 19 15:35:31 pg2 vip-manager: 2020/01/19 15:35:31 IP address 10.0.3.2/24 state is false, desired true Jan 19 15:35:31 pg2 vip-manager: 2020/01/19 15:35:31 Configuring address 10.0.3.2/24 on eth0 Jan 19 15:35:31 pg2 vip-manager: 2020/01/19 15:35:31 IP address 10.0.3.2/24 state is true, desired true Jan 19 15:35:32 pg2 patroni: 2020-01-19 15:35:32,923 INFO: Lock owner: pg2; I am pg2
As one can see, the VIP is moved within one second.
Updated Ansible Playbook
Our Ansible-Playbook for the automated setup of a three-node cluster on Debian has also been updated and can now configure a VIP if so desired:
# ansible-playbook -i inventory -e vip=10.0.3.2 patroni.yml
Questions and Help
Do you have any questions or need help? Feel free to write to email@example.com.
Yesterday, the fourth beta of the upcoming PostgreSQL®-major version 12 was released.
Compared to its predecessor PostgreSQL® 11, there are many new features:
- Performance improvements for indexes: btree indexes now manage space more efficiently. The REINDEX command now also supports CONCURRENTLY, which was previously only possible with new indexes.
- WITH queries are now embedded in the main query and thus optimized much better by the planner. Previously, WITH queries were always executed independently.
- The native partitioning was further improved. Foreign keys can now also reference partitioned tables. Maintenance commands such as ATTACH PARTITION no longer require an exclusive table lock.
- The support of page checksums and the tool pg_checksums was further improved, also with substantial cooperation by credativ.
- It is now possible to integrate additional storage engines. The “zheap”, which is still under development, will be based on this, which promises more compact data storage with less bloat.
Of course, PostgreSQL® 12 will be tested using sqlsmith, the SQL “fuzzer” from our colleague Andreas Seltenreich. Numerous bugs in different PostgreSQL® versions were found with sqlsmith by using randomly generated SQL queries.
Debian and Ubuntu packages for PostgreSQL® 12 are going to be published on apt.postgresql.org with credativ’s help. This work will be handled by our colleague Christoph Berg.
The release of PostgreSQL® 12 is expected in the next weeks.
Patroni is a PostgreSQL high availability solution with a focus on containers and Kubernetes. Until recently, the available Debian packages had to be configured manually and did not integrate well with the rest of the distribution. For the upcoming Debian 10 “Buster” release, the Patroni packages have been integrated into Debian’s standard PostgreSQL framework by credativ. They now allow for an easy setup of Patroni clusters on Debian or Ubuntu.
Patroni employs a “Distributed Consensus Store” (DCS) like Etcd, Consul or Zookeeper in order to reliably run a leader election and orchestrate automatic failover. It further allows for scheduled switchovers and easy cluster-wide changes to the configuration. Finally, it provides a REST interface that can be used together with HAProxy in order to build a load balancing solution. Due to these advantages Patroni has gradually replaced Pacemaker as the go-to open-source project for PostgreSQL high availability.
However, many of our customers run PostgreSQL on Debian or Ubuntu systems and so far Patroni did not integrate well into those. For example, it does not use the
postgresql-common framework and its instances were not displayed in
pg_lsclusters output as usual.
Integration into Debian
In a collaboration with Patroni lead developer Alexander Kukushkin from Zalando the Debian Patroni package has been integrated into the
postgresql-common framework to a large extent over the last months. This was due to changes both in Patroni itself as well as additional programs in the Debian package. The current Version 1.5.5 of Patroni contains all these changes and is now available in Debian “Buster” (testing) in order to setup Patroni clusters.
The packages are also available on apt.postgresql.org and thus installable on Debian 9 “Stretch” and Ubuntu 18.04 “Bionic Beaver” LTS for any PostgreSQL version from 9.4 to 11.
The most important part of the integration is the automatic generation of a suitable Patroni configuration with the
pg_createconfig_patroni command. It is run similar to
pg_createcluster with the desired PostgreSQL major version and the instance name as parameters:
pg_createconfig_patroni 11 test
This invocation creates a file
/etc/patroni/11-test.yml, using the DCS configuration from
/etc/patroni/dcs.yml which has to be adjusted according to the local setup. The rest of the configuration is taken from the template
/etc/patroni/config.yml.in which is usable in itself but can be customized by the user according to their needs. Afterwards the Patroni instance is started via systemd similar to regular PostgreSQL instances:
systemctl start patroni@11-test
A simple 3-node Patroni cluster can be created and started with the following few commands, where the nodes
pg3 are considered to be hostnames and the local file
dcs.yml contains the DCS configuration:
for i in pg1 pg2 pg3; do ssh $i 'apt -y install postgresql-common'; done for i in pg1 pg2 pg3; do ssh $i 'sed -i "s/^#create_main_cluster = true/create_main_cluster = false/" /etc/postgresql-common/createcluster.conf'; done for i in pg1 pg2 pg3; do ssh $i 'apt -y install patroni postgresql'; done for i in pg1 pg2 pg3; do scp ./dcs.yml $i:/etc/patroni; done for i in pg1 pg2 pg3; do ssh @$i 'pg_createconfig_patroni 11 test' && systemctl start patroni@11-test'; done
Afterwards, you can get the state of the Patroni cluster via
ssh pg1 'patronictl -c /etc/patroni/11-patroni.yml list' +---------+--------+------------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+------------+--------+---------+----+-----------+ | 11-test | pg1 | 10.0.3.111 | Leader | running | 1 | | | 11-test | pg2 | 10.0.3.41 | | stopped | | unknown | | 11-test | pg3 | 10.0.3.46 | | stopped | | unknown | +---------+--------+------------+--------+---------+----+-----------+
Leader election has happened and
pg1 has become the primary. It created its instance with the Debian-specific
pg_createcluster_patroni program that runs
pg_createcluster in the background. Then the two other nodes clone from the leader using the
pg_clonecluster_patroni program which sets up an instance using
pg_createcluster and then runs
pg_basebackup from the primary. After that, all nodes are up and
+---------+--------+------------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+------------+--------+---------+----+-----------+ | 11-test | pg1 | 10.0.3.111 | Leader | running | 1 | 0 | | 11-test | pg2 | 10.0.3.41 | | running | 1 | 0 | | 11-test | pg3 | 10.0.3.46 | | running | 1 | 0 | +---------+--------+------------+--------+---------+----+-----------+
The well-known Debian
postgresql-common commands work as well:
ssh pg1 'pg_lsclusters' Ver Cluster Port Status Owner Data directory Log file 11 test 5432 online postgres /var/lib/postgresql/11/test /var/log/postgresql/postgresql-11-test.log
If the primary is abruptly shutdown, its leader token will expire after a while and Patroni will eventually initiate failover and a new leader election:
+---------+--------+-----------+------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+-----------+------+---------+----+-----------+ | 11-test | pg2 | 10.0.3.41 | | running | 1 | 0 | | 11-test | pg3 | 10.0.3.46 | | running | 1 | 0 | +---------+--------+-----------+------+---------+----+-----------+ [...] +---------+--------+-----------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+-----------+--------+---------+----+-----------+ | 11-test | pg2 | 10.0.3.41 | Leader | running | 2 | 0 | | 11-test | pg3 | 10.0.3.46 | | running | 1 | 0 | +---------+--------+-----------+--------+---------+----+-----------+ [...] +---------+--------+-----------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+-----------+--------+---------+----+-----------+ | 11-test | pg2 | 10.0.3.41 | Leader | running | 2 | 0 | | 11-test | pg3 | 10.0.3.46 | | running | 2 | 0 | +---------+--------+-----------+--------+---------+----+-----------+
The old primary will rejoin the cluster as standby once it is restarted:
+---------+--------+------------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+------------+--------+---------+----+-----------+ | 11-test | pg1 | 10.0.3.111 | | running | | unknown | | 11-test | pg2 | 10.0.3.41 | Leader | running | 2 | 0 | | 11-test | pg3 | 10.0.3.46 | | running | 2 | 0 | +---------+--------+------------+--------+---------+----+-----------+ [...] +---------+--------+------------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +---------+--------+------------+--------+---------+----+-----------+ | 11-test | pg1 | 10.0.3.111 | | running | 2 | 0 | | 11-test | pg2 | 10.0.3.41 | Leader | running | 2 | 0 | | 11-test | pg3 | 10.0.3.46 | | running | 2 | 0 | +---------+--------+------------+--------+---------+----+-----------+
If a clean rejoin is not possible due to additional transactions on the old timeline the old primary gets re-cloned from the current leader. In case the data is too large for a quick re-clone,
pg_rewind can be used. In this case a password needs to be set for the
postgres user and regular database connections (as opposed to replication connections) need to be allowed between the cluster nodes.
Creation of additional Instances
It is also possible to create further clusters with
pg_createconfig_patroni, one can either assign a PostgreSQL port explicitly via the
--port option, or let
pg_createconfig_patroni assign the next free port as is known from
for i in pg1 pg2 pg3; do ssh $i 'pg_createconfig_patroni 11 test2 && systemctl start patroni@11-test2'; done ssh pg1 'patronictl -c /etc/patroni/11-test2.yml list' +----------+--------+-----------------+--------+---------+----+-----------+ | Cluster | Member | Host | Role | State | TL | Lag in MB | +----------+--------+-----------------+--------+---------+----+-----------+ | 11-test2 | pg1 | 10.0.3.111:5433 | Leader | running | 1 | 0 | | 11-test2 | pg2 | 10.0.3.41:5433 | | running | 1 | 0 | | 11-test2 | pg3 | 10.0.3.46:5433 | | running | 1 | 0 | +----------+--------+-----------------+--------+---------+----+-----------+
In order to easily deploy a 3-node Patroni cluster we have created an Ansible playbook on Github. It automates the installation and configuration of PostgreSQL and Patroni on the three nodes, as well as the DCS server on a fourth node.
Questions and Help
Do you have any questions or need help? Feel free to write to firstname.lastname@example.org.
This years DebConf will take place in Taiwan from July 29th to August 05th.
Even if the flights last 16 hours on average, the anticipation of the colleagues is already great and we are very curious what the event has in store for its visitors.
Lectures, Talks and BoFs
Meanwhile the packed lecture program has been published. There will be around 90 presentations in 3 tracks on the following 8 topics:
- Debian blends
- Cloud and containers
- Debian in science
- Packaging, policy, and Debian infrastructure
- Social context
- Systems administration, automation and orchestration
Many of the presentations can even be streamed. The links are as follows:
We are especially looking forward to the SPI BoF (Software in the Public Interest – Birds of a Feather) and the DSA BoF (Debian System Administrators – Birds of a Feather), in which our colleague and Debian sysadmin Martin Zobel-Helas participates.
For us at credativ, the Job Fair is of particular importance. Here we meet potential new colleagues and hopefully many visitors interested in our company. If you want to have a chat with our colleagues: Noël, Sven and Martin will be available for you at the Job Fair and on all other days of the event.
In addition to exciting discussions, we of course hope for one or two interesting applications that we will receive afterwards.
The Job Fair takes place one day before DebConf18, on 28 July.
Daytrip and other events
Of course there will also be the “Daytrip” this year, which will show the conference visitors the surroundings and the country. Participants have a whole range of options to choose from. Whether you want to explore the city, go hiking, or hold a Taiwanese tea ceremony, there should be something for everyone.
In addition to the daily breakfast, lunch, coffee break and dinner, there will be a cheese-and-wine party on Monday 30 August and a conference dinner on Thursday 2 August. Our colleagues will attend both events and hopefully have some interesting conversations.
Debian and credativ
The free operating system Debian is one of the most popular Linux distributions and has thousands of users worldwide.
Besides Martin Zobel-Helas, the credativ employs many members of the Debian project. Also our managing director, Dr. Michael Meskes, was actively involved in Debian even before credativ GmbH (1999) was founded. This also resulted in a close and long-standing bond with the Debian project and the community for credativ.
This article was originally written by Philip Haas.
Debian 9 “Stretch”, the latest version of Debian, is about to be released and after a full-freeze on February 5th everyone is trying its best to fix the last bugs that are left.
Upon entering the final phase of development in February the test version was “frozen” so that no more packages could be added or removed without the approval of the release team.
However, Stretch has some bugs left, which need to be resolved until the release date, especially the so called release critical bugs (RC). For this purpose, numerous Debian developers host worldwide meet ups.
These meet ups are a long standing tradition and are lovingly called “Bug Squashing Party”. Despite the cute name, these events usually turn out to be one the most focused, intense and hard working days in the life cycle of a new Debian version. Pressured by the upcoming release date, everyone gets together to get rid of the nasty release critical bugs and focus on unfinished packages.
The Open Source Support Center employs the likely biggest number of European Debian developers in one place. Therefore credativ GmbH is providing the location and technical infrastructure for everyone who decided to join the Bug Squashing Party.
We hope that this year’s meeting is going to be as successful as in the previous years. Developers from all neighbouring countries took part in past events and some even found their future employer.
If you would like to participate, feel free to sign up!
We are looking forward to your visit.
Here is the announcement on the mailing-list:
Here is the entry in the Debian wiki:
This article was originally written by Philip Haas.
In this post we describe how to integrate Icinga2 with Graphite and Grafana on Debian stable (jessie).
What is Graphite?
Graphite stores performance data on a configurable period. Via a defined interface, services can send metrics to Graphite, which are then stored for the designated period. Possible examples of the type of metrics that it might be useful for are CPU utilization or traffic of a web server. Graphs can be generated from the various metrics via the integrated web interface in Graphite. This allows changes in values to be observed across different time periods. A good example of where this type of trend analysis could be useful is monitoring levels on a hard drive. By using a Trend Graph, it’s clear to see the growth rate of the footprint and anticipate when an exchange of storage will become necessary.
What is Grafana?
Graphite does have a private web interface but it is neither attractive nor flexible. This is where Grafana comes in.
Grafana is a frontend for various storage metrics, supporting Graphite, InfluxDB and OpenTSDB, among others. Grafana offers an intuitive interface through which you can create graphs to represent the metrics and a variety of functions to optimise their appearance and presentation. The graphs can then be summarized in dashboards; you can also opt to display one from a specific host only, through parameterization.
Installation of Icinga2
Here we describe the only installation which is essential for Graphite. Icinga2 packages in the current version of Debian can be obtained directly from Debmon projekt.
At the Debmon project up to date versions of the different monitoring tools software for the different Debian releases are provided by the official Debian package maintainers. To include these packages, use the following commands:
# add debmon cat <<EOF >/etc/apt/sources.list.d/debmon.list deb http://debmon.org/debmon debmon-jessie main EOF # add debmon key wget -O - http://debmon.org/debmon/repo.key 2>/dev/null | apt-key add - # update repos apt-get update
Finally we can install Icinga2:
apt-get install icinga2
Installation of Graphite and Graphite-Web
Once Icinga2 is installed, Graphite and Graphite-Web can also be installed.
# install packages for icinga2 and graphite-web and carbon apt-get install icinga2 graphite-web graphite-carbon libapache2-mod-wsgi apache2
Configuration of Icinga2 with Graphit
Icinga2 must be configured so that all defined metrics are exported to Graphite. The Graphite component receives this data called “Carbon”. In our sample installation Carbon runs on the same host as Icinga2 and uses the default port, meaning no further configuration of Icinga2 is necessary – it is enough to export on.
To do this, simply enter the command:
icinga2 feature enable graphite
Subsequently Icinga2 must be restarted:
service icinga2 restart
If the Carbon Server is running on a different host or a different port, the configuration of the file /etc/icinga2/features-enabled/graphite.conf Icinga2 should be adjusted. Details can be found in the Icinga2 documentation.
If the configuration was successful, then after a short time a number of files should appear in “/var/lib/graphite/whisper/icinga“. If they don’t, then you should take a look in the log file of Icinga2 (located in “/var/log/icinga2/icinga2.log“)
Configuration of Graphite – Web
Grafana uses the frontend of Graphite as an interface for the stored metrics of Graphite so correct configuration of Graphite-web is very important. For performance reasons, we operate Graphite-web as a WSGI module. A number of configuration steps are necessary:
- First, we create a user database for Graphite-web. Since we will not have many users, at this point we use SQLite as the backend for our user data. We do this using the following commands which initialize the user database and transfer ownership to the user under which the Web front-end runs:
graphite-manage syncdb chown _graphite:_graphite /var/lib/graphite/graphite.db
- Then we activate the WSGI module in Apache:
- For simplicity the web interface should run in a separate virtual host and on its own port. So that Apache listens to this port, we add the line “Listen 8000” to the file “/etc/apache2/ports.conf“
- The Graphite Debian package already provides a configuration file for Apache, which is fine to use with slight adaptations.
cp /usr/share/graphite-web/apache2- graphite.conf /etc/apache2/sites-available/graphite.conf. In order for the virtual host to also use port 8000, we replace the line:
- We can now activate the new virtual host via
a2ensite graphiteand restart Apache:
systemctl restart apache2
- You should now be able to reach Graphite-web at http://YOURIP:8000/. If you cannot, the Apache log files in “/var/log/apache2/” can provide valuable information.
Configuration of Grafana
Grafana is not currently included in Debian. However, the author offers an Apt repository from which you can install Grafana. Even if the repository points to Wheezy, the packages should still function under Debian Jessie.
The repository is only accessible via https – so first, you need to install https support for apt:
apt-get install apt-transport-https
Next, the repository can be integrated.
# add repo (package for wheezy works on jessie) cat <
/etc/apt/sources.list.d/grafana.list deb https://packagecloud.io/grafana/stable/debian/ wheezy main EOF # add key curl -s https://packagecloud.io/gpg.key | sudo apt-key add - # update repos apt-get update
After this, the package can be installed:
apt-get install grafana For Grafana to run we still need to activate the service
systemctl enable grafana-server.service and start
systemctl start grafana-server.
Grafana is now accessible at http://YOURIP:3000/. The default user name and password in our example is ‘admin’. This password should, of course, be replaced by a secure password at the earliest opportunity.
Grafana must then be configured so that it uses Graphite as a data source. For simplicity, the configuration is explained in the following screencast:
After setting up Graphite as the data source, we can create our first graph. Here is another short screencast to illustrate this:
Congratulations! You have successfully installed and configured Icinga2, Graphite and Grafana. For subsequent steps, please refer to the documentation for the specific projects:
To read more about credativ’s work with Debian, please read our Debian blogs.
The vast majority of Debian installations are simplified with the use of Preseeding and Netboot. Friedrich Weber, a school student on a work experience placement with us at our German office has observed the process and captured it in a Howto here:
Imagine the following situation: you find yourself with ten to twenty brand new Notebooks and the opportunity to install them with Debian and customise to your own taste. In any case it would be great fun to manually perform the Debian installation and configuration on each Notebook.
This is where Debian Preseed comes into play. The concept is simple and self-explanatory; usually, whoever is doing the installation will be faced with a number of issues during the process (e.g. language, partitioning, packages, Bootloader, etc.) In terms of Preseed, all of these issues can now be resolved. Only those which are not already accounted for in Preseed remain for the Debian installer. In the ideal situation these would become apparent at the outset of the installation, where the solution would differ depending on the target system and which the administrator must deal with manually – only when these have been dealt with can the installation be left to run unattended.
Preseed functions on some simple inbuilt configuration data:
preseed.cfg. It includes, as detailed above, the questions which must be answered during installation, and in debconf-format. Data such as this consists of several rows, each row of which defines a debconf configuration option – a response to a question – for example:
d-i debian-installer/locale string de_DE.UTF-8
The first element of these lines is the name of the package, which is configured (d-i is here an abbreviation of debian installer), the second element is the name of the option, which is set, as the third element of the type of option (a string) and the rest is the value of the option.
In this example, we set the language to German using UTF-8-coding. You can put lines like this together yourself, even simpler with the tool
debconf-get-selections: these commands provide straight forward and simple options, which can be set locally.
From the selection you can choose your desired settings, adjusted if necessary and copied into
preseed.cfg. Here is an example of
d-i debian-installer/locale string de_DE.UTF-8 d-i debian-installer/keymap select de-latin1 d-i console-keymaps-at/keymap select de d-i languagechooser/language-name-fb select German d-i countrychooser/country-name select Germany d-i console-setup/layoutcode string de_DE d-i clock-setup/utc boolean true d-i time/zone string Europe/Berlin d-i clock-setup/ntp boolean true d-i clock-setup/ntp-server string ntp1 tasksel tasksel/first multiselect standard, desktop, gnome-desktop, laptop d-i pkgsel/include string openssh-client vim less rsync
In addition to language and timezone settings, selected tasks and packages are also set with these options. If left competely unattended, the installation will not complete, but will make a good start.
Now onto the question of where Preseed pulls its data from. It is in fact possible to use Preseed with CD and DVD images or USB sticks, but generally more comfortable to use a Debian Netboot Image, essentially an installer, which is started across the network and which can cover its Preseed configuration.
This boot across the network is implemented with PXE and requires a system that can boot from a network card. Next, the system depends on booting from the network card. It travels from a DHCO server to an IP address per broadcast.
This DHCP server transmits not only a suitable IP, but also to the IP of a so-called Bootserver. A Bootserver is a TFTP-Server, which provides a Bootloader to assist the Administrator with the desired Debian Installer. At the same time the Debian Installer can be shared with the Boot options that Preseed should use and where he can find the Preseed configuration. Here is a snippet of the PXELINUX configuration data
label i386 kernel debian-installer/i386/linux append vga=normal initrd=debian-installer/i386/initrd.gz netcfg/choose_interface=eth0 domain=example.com locale=de_DE debian-installer/country=DE debian-installer/language=de debian-installer/keymap=de-latin1-nodeadkeys console-keymaps-at/keymap=de-latin1-nodeadkeys auto-install/enable=false preseed/url=http://$server/preseed.cfg DEBCONF_DEBUG=5 -- quiet
When the user types
debian-installer/i386/linux kernel (found on the TFTP server) is downloaded and run. This is in addition to a whole load of bootoptions given along the way. The debian installer allows the provision of debconf options as boot parameters. It is good practice for the installer to somehow communicate where to find the Preseed communication on the network (
In order to download this Preseed configuration, it must also be somehow built into the network. The options for that will be handed over (the options for the hostnames would be deliberately omitted here, as every target system has its own Hostname).
auto-install/enable would delay the language set up so that it is only enabled after the network configuration, in order that these installations are read through
It is not necessary as the language set up will also be handed over to the kernel options to ensure that the network configuration is German. The examples and configuration excerpts mentioned here are obviously summarised and shortened. Even so, this blog post should have given you a glimpse into the concept of Preseed in connection with netboot. Finally, here is a complete version of
d-i debian-installer/locale string de_DE.UTF-8 d-i debian-installer/keymap select de-latin1 d-i console-keymaps-at/keymap select de d-i languagechooser/language-name-fb select German d-i countrychooser/country-name select Germany d-i console-setup/layoutcode string de_DE # Network d-i netcfg/choose_interface select auto d-i netcfg/get_hostname string debian d-i netcfg/get_domain string example.com # Package mirror d-i mirror/protocol string http d-i mirror/country string manual d-i mirror/http/hostname string debian.example.com d-i mirror/http/directory string /debian d-i mirror/http/proxy string d-i mirror/suite string lenny # Timezone d-i clock-setup/utc boolean true d-i time/zone string Europe/Berlin d-i clock-setup/ntp boolean true d-i clock-setup/ntp-server string ntp.example.com # Root-Account d-i passwd/make-user boolean false d-i passwd/root-password password secretpassword d-i passwd/root-password-again password secretpassword # Further APT-Options d-i apt-setup/non-free boolean false d-i apt-setup/contrib boolean false d-i apt-setup/security-updates boolean true d-i apt-setup/local0/source boolean false d-i apt-setup/local1/source boolean false d-i apt-setup/local2/source boolean false # Tasks tasksel tasksel/first multiselect standard, desktop d-i pkgsel/include string openssh-client vim less rsync d-i pkgsel/upgrade select safe-upgrade # Popularity-Contest popularity-contest popularity-contest/participate boolean true # Command to be followed after the installation. `in-target` means that the following # Command is followed in the installed environment, rather than in the installation environment. # Here http://$server/skript.sh nach /tmp is downloaded, enabled and implemented. d-i preseed/late_command string in-target wget -P /tmp/ http://$server/skript.sh; in-target chmod +x /tmp/skript.sh; in-target /tmp/skript.sh>
This post was originally written by Irenie White.