The openSUSE Project will begin monthly web development sprints to address feedback provided by attendees of the Jan. 23 meetup regarding the results of the End of the Year Survey.

The sprints will be every first Thursday of the month at 18:30 UTC and will take place online at https://meet.opensuse.org/websprints; the first sprint starts on Feb. 4.

The web sprints are open for people to provide feedback to the community about the various websites openSUSE has for on-boarding people who install openSUSE and people who want to learn more about the distributions, tools and technologies. The sprints will focus on several aspects of web development and enhance the structure of the websites to better direct users toward helpful links, resources and communication tools. The web sprints seek participation from new, current and former users to provide feedback to developers with the desire to better understand how people navigate the openSUSE websites.

Gaining feedback on the best communication channels to help people solve technical issues and better ways to show people how to get involved in the project are desired outcomes from the web development sprints.

The sprints will provide a useful way for people to voice their feedback and gain knowledge about web development and technologies.

Organizers of the sprint are collecting topics and ideas on https://etherpad.opensuse.org/p/websprints, so even people who are interested but unable to attend can help improve the navigation and content of the project’s websites.

Next Meetup for End of Year Survey Results

The next sessions will start at 13:00 UTC on openSUSE’s Jitsi instance on Jan. 30. Topics to be discussed are:

• Tools driving switchers to openSUSE (Where are users coming from)
• Discuss flagship project/s
• Expanding global users
• Increasing diversity
• Increase usage with people under 34

The meetup will take place at https://meet.opensuse.org/EOY2020.

Ever since Red Hat announced that they are changing the development model of CentOS and making it an upstream project rather than downstream, it left many CentOS users frowning. No matter what argument brought forward, CentOS users, especially running production machines, relied on the stability of an enterprise-grade Linux distribution. Compiled from RHEL sources, CentOS offered such stability that it powered many web servers and enjoyed a massive 20% share of the top 500 supercomputers of the world.

Some time back, Red Hat made another annoucement, about new Red Hat Enterprise Linux programs. Under the new program RHEL can be used in production for up to 16 systems (which Red Hat considers a small workload) at zero license costs. Also, Red Hat is making it easier for a customer's development team to join the program and reap the benefits.

What risks lie ahead for an enterprise if Red Hat changes or cancels the program in the future? 🤔

On the other hand, since 2018, SUSE has worked closely with the openSUSE community to bring the Leap distribution closer to SUSE Enterprise Linux (SLE), such that now Leap and SLE are binary compatible.

openSUSE currently offers two distinct distributions, Leap & Tumbleweed.

Tumbleweed is a rolling distribution constantly getting updated software whereas Leap has planned releases that sync with SUSE Linux Enterprise and its Service Packs.

The above image depicts how openSUSE & SUSE Linux Enterprise are developed together. Factory is the rolling development codebase for both openSUSE & SLE. In the pipeline we can see that Leap & SLE are synced and both receive software packages from the same source; that is why they are both binary compatible.

In a series of blog posts explaining how SUSE builds its Enterprise Linux distribution, author Vincent Moutoussamy details the relationship between openSUSE & SLE.

Conclusion

Red Hat allows its clients to use RHEL for free on up to 16 machines. On the other hand, openSUSE Leap boasts binary compatibility with SUSE Linux Enterprise and comes without any restriction on usage.

Cover image source:
Photo by Gratisography from Pexels

Bastille is a container management system for FreeBSD, similar to Docker or Podman on Linux. The historical name of containers on FreeBSD is jail, and they appeared a lot earlier than containers on Linux. Managing jails was not always easy. When I started to use this technology in production in 2001, nothing was automated. Using Bastille, you can easily create, configure, or update jails at scale. It has a template system to install applications in containers and there is a template also for syslog-ng.

From this blog, you can learn how to get started with Bastille and how to create and run a syslog-ng jail using the freshly released 0.8 version of Bastille.

Before you begin

First of all, to use Bastille, you need FreeBSD installed. I used FreeBSD 12.2 on AMD64, but it also works on CURRENT and on any platform supported by FreeBSD, including the Raspberry Pi. Bastille 0.8, the release I’m describing in my blog, was released after the latest quarterly package release. It means, that by the time of writing this blog article, you can install it only using an up-to-date ports snapshot or following the latest PKG builds, instead of the quarterly PKG release.

Installing Bastille

The easiest way to install Bastille is to use the pkg command:

pkg install bastille

And depending on your Internet connection, it will be installed within a few seconds. You can also install it from ports:

cd /usr/ports/sysutils/bastille/
make install clean

There are no extra dependencies when you install Bastille. There is one exception, even if it is not hardcoded into the Makefile in ports: you need to install Git to be able to use the template system.

pkg install git

Configuring Bastille

Bastille supports many different FreeBSD features, like ZFS or VNET. However, these need extra planning, stronger hardware, and more control over the network. So, in this blog, I go with the easiest configuration possible, which works anywhere: on your local network or somewhere in a public cloud as well. For more choices and advanced functionality, check the Bastille documentation at https://bastille.readthedocs.io/en/latest/

The commands below enable Bastille, create and start an internal network interface for jails and also enable the PF firewall. Run each of these commands from a terminal.

sysrc bastille_enable="YES"
sysrc cloned_interfaces+=lo1
sysrc ifconfig_lo1_name="bastille0"
service netif cloneup
sysrc pf_enable="YES"

The next step is to set up the PF firewall. The configuration below should go into /etc/pf.conf and you should replace “em0” on the first line with your actual network interface name. This configuration makes sure that jails can reach the Internet through NAT and Bastille can create rules to access services in jails without editing the firewall configuration manually.

ext_if="em0"

set block-policy return
scrub in on $ext_if all fragment reassemble
set skip on lo

table <jails> persist
nat on $ext_if from <jails> to any -> ($ext_if)

rdr-anchor "rdr/*"

block in all
pass out quick modulate state
antispoof for $ext_if inet
pass in inet proto tcp from any to any port ssh flags S/SA modulate state

You can now restart the pf service for these rules to take effect. Note, that if you work over an SSH connection, you might be kicked off from the system when you hit Enter. In this case, reconnect and continue your work:

service pf restart

Finally, bootstrap the release of your choice (not more recent than what the host is running):

bastille bootstrap 12.2-RELEASE

It downloads and extracts the given release. You are now ready to create your first jail!

Creating your first jail

The first step is to create a jail. “bastille create” expects a few parameters from you. One is a name for the jail. In the example below, we use “alcatraz”, but in real life, you will most likely use names that remind you of the function of the jail, for example: centralsyslog. You also need a FreeBSD release name and finally an IP address. Use a different IP address if your host is on a 10.0.0.0/8 network.

bastille create alcatraz 12.2-RELEASE 10.17.89.50

Unlike previous releases, version 0.8 of Bastille starts the freshly created jail automatically. I prefer this way, but not everyone is happy with this change, so it might change in future releases.

Now, bootstrap the syslog-ng template. It uses Git to download the template from a repository on GitLab.

bastille bootstrap https://gitlab.com/BastilleBSD-Templates/syslog-ng

Apply the template to the jail. As you can see, we refer to the jail by its name, so choose jail names wisely!

bastille template alcatraz BastilleBSD-Templates/syslog-ng

Finally configure the PF firewall with a bastille command, and redirect the external 514 port to the 514 port of the freshly created jail on the internal network:

bastille rdr alcatraz tcp 514 514

And your second jail

The commands below create a second jail with a slightly different name and IP address. You do not have to bootstrap the syslog-ng template again, just apply it to the jail. And as port 514 on the host is already redirected to the first jail, here we redirect the external 515 port to the 514 port of the jail.

bastille create alcatray 12.2-RELEASE 10.17.89.51
bastille template alcatray BastilleBSD-Templates/syslog-ng
bastille rdr alcatray tcp 515 514

Testing

You can check the logs from both jails with the following command:

tail -f /usr/local/bastille/jails/alcatraz/root/var/log/messages /usr/local/bastille/jails/alcatray/root/var/log/messages

You should see two sets of log messages from the two jails. The -f option means that you do not get back the command prompt, but tail follows the files.

Now open another terminal and from another system use telnet to connect to port 514 and 515 of your FreeBSD host. In both cases, enter some test messages.

czanik@czplaptop:~> telnet 172.16.167.138 515
Trying 172.16.167.138...
Connected to 172.16.167.138.
Escape character is '^]'.
this is a test
^]
telnet> quit
Connection closed.
czanik@czplaptop:~> telnet 172.16.167.138 514
Trying 172.16.167.138...
Connected to 172.16.167.138.
Escape character is '^]'.
this is another test
^]  
telnet> quit
Connection closed.

On the other terminal, you should see log messages about the connection and the test messages as well:

Jan 22 10:03:13 alcatraz syslog-ng[1120]: syslog-ng starting up; version='3.30.1'
Jan 22 11:52:52 alcatraz syslog-ng[1120]: Syslog connection accepted; fd='23', client='AF_INET(172.16.167.1:50212)', local='AF_INET(0.0.0.0:514)'
Jan 22 11:52:56 172.16.167.1 this is another test
Jan 22 11:53:01 alcatraz syslog-ng[1120]: Syslog connection closed; fd='23', client='AF_INET(172.16.167.1:50212)', local='AF_INET(0.0.0.0:514)'

If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @Pczanik.

Just in case, if you’ve ever wondered how to stop cron from sending empty emails, a quick look at man mail will give you the answer you’re looking for (if you know what you’re searching for):

    -E

    If an outgoing message does not contain any text in its first or only message part, do not send it but discard it silently,
    effectively setting the skipemptybody variable at program startup. This is useful for sending messages from scripts started 
    by cron(8).

I got this after visiting couple of forums, and some threads at stack exchange, however this one nailed it

So all you need to do is, fire up that crontab -e and make your script run every five minutes, without fear of the noise

*/5 * * * * /usr/local/bin/only-talk-if-there-are-errors-script |& mail -E -r $(hostname)@opensuse.org -s "[CRON][monitoring] foo bar $(date  --iso-8601='minutes')"  do-not-spam-me@example.com

Et voilà, ma chérie!

A few tweets ago, openSUSE Mauritius mentioned using YaST to configure the timezone on a machine with just a few clicks.

YaST is a system setup & configuration tool. It was developed by SuSE in the mid-90s. YaST is an acronym for Yet another Setup Tool. It is a handy tool for administrators to install software, configure hardware, connect to a network, etc.

It is written in Ruby. It has both a GUI and is available as a command-line utility through a text-based user interface using ncurses.

To run the ncurses-based YaST version, run sudo yast2 using the terminal. Then, use the tab & arrow keys to navigate and press the enter button to select an item. Menu items and buttons can be triggered by using the Alt + Hightlighted Letter. For example, to quit the screen as in the above screenshot, one would press Alt  + Q.

Software Management

YaST can be used to install software packages. Both the GUI & yast2 command can be used to search for packages and install them. YaST uses the Zypp package management engine which is also used by the zypper command-line tool, to manage software.

YaST Modules

Additional modules can be installed to extend YaST's capabilities. For example, installaling the yast2-docker package provides a module that allows YaST to manage Docker containers. The YaST website provides a list of available modules.

Documentation

SUSE has excellent documentation on YaST. The administration section of the Leap documentation refers to using YaST for various configuration tasks.

Contributing

YaST is developed in the open. Its source code is available on GitHub. The YaST Team has made it easy for volunteers to to find their way to contribute code.

2021 is here and it doesn’t look like it’s going to be a boring year… at least in the YaST side! The YaST team just restarted the work a couple of weeks ago and we already have some development news to share with you, including some improvements our users requested through the openSUSE’s End of the Year Community Survey.

• Writing NetworkManager configuration during system installation
• Refining the mechanism to reuse existing EFI partitions
• Using more stable and consistent names to reference devices in the bootloader
• Improving AutoYaST behavior when no product has been specified
• Updating the roles offered by yast2-vm
• Many more small improvements here and there

Let’s start with an installer improvement quite some people was waiting for. Both openSUSE and SUSE Linux Enterprise can use either wicked or NetworkManager to handle the system’s network configuration. Only the former can be fully configured with YaST (which is generally not a problem because there are plenty of tools to configure NetworkManager). Moreover, during the standard installation process, wicked is always used to setup the network of the installer itself. If the user decides to rely on wicked also in the final system, then the configuration of the installer is carried over to it. But, so far, if the user opted to use NetworkManager then the installer configuration was lost and the network of the final system had to be be configured again using NetworkManager this time. Not anymore!

That’s not the only installer behavior we have refined based on feedback from our users. In some scenarios, the logic used to decide whether an existing EFI System Partition (ESP) could be reused was getting in the way of those aiming for a fine-grained control of their partitions. That should now be fixed by the changes described in this pull request, that have been already submitted to Tumbleweed and will be part of the upcoming releases (15.3) of both openSUSE Leap and SLE.

We also fine-tuned how hibernation is configured during installation. To be precise, we improved the corresponding resume= parameter passed to the kernel by the bootloader. From now on, that parameter will use a device name that will be fully consistent with the names used in other parts of the installer and that will be often based on the swap UUID.

As usual, AutoYaST also got its quota of love during this sprint. This time on form of an usability improvement. As you may know, SUSE Linux Enterprise offers a whole set of products for different needs. When using AutoYaST to upgrade a system using a multiproduct repository, it’s necessary to specify the concrete product in the AutoYaST profile. When that was not correctly done, the system failed in a not-exactly-elegant way. In upcoming versions of products of the SLE family, that will be handled in a much nicer way.

And apart from the installation and auto-installation process, we also introduced several small fixes and improvements in other parts of YaST. Like bringing up-to-date the options offered by yast2-vm, speeding up the process of reading the network devices in s390 mainframes, improving the usability when the hostname needs to be adapted… and many other things you can check in Github or the Open Build Service if you want to know more.

As you can see, the new year has not diluted our enthusiasm to keep improving YaST bit by bit. So now it’s time to go back to work, hoping to meet you again in a couple of weeks with more news. Have a lot of fun!

The first session of the openSUSE Project’s meetup regarding the End of the Year Survey Results on Jan. 23 is already starting produce some actionable items from contributors.

View Meeting Minutes

The session on openSUSE’s Jitsi instance had engagement from about 20 people from around the globe.

Topics discussed in the two-hour session focused on addressing pain points, transferring knowledge and promoting openSUSE projects.

Members of the “let’s improve the openSUSE learning experience” shared statics and analysis from the survey and attendees engaged in generating ideas and actions to enhance and improve the above mentioned items.

Actions to take voiced during the session were enhancing the project’s websites to better direct visitors to appropriate communication mediums, documenting easier “getting started” guides and coming up with monthly or quarterly workshops.

The discussions during the meetup lead to other topics like having more surveys to extract greater information about hardware difficulties and other pain points. Discussions also talked about enhancing the wording and live images on software.opensuse.org.

Most of the ideas were captured on https://etherpad.opensuse.org/p/EOY2020Meetup.

The next sessions will start at 13:00 UTC on openSUSE’s Jitsi instance on Jan. 30.

Topics to be discussed in the Jan. 30 session include:

• Tools driving switchers to openSUSE (Where are users coming from)
• Discuss flagship project/s
• Expanding global users
• Increasing diversity
• Increase usage with people under 34

The meetup will take place at https://meet.opensuse.org/EOY2020.

More details about the End of the Year Community Survey results can be found on the openSUSE Wiki.

Dear Tumbleweed users and hackers,

Shame on me for giving you the information about the changes in Tumbleweed during this week only now, but at least technically this is still the review of Week 03. Since the last weekly review, there have been 6 snapshots published (0114, 0115, 0118, 0119, 0120, and 0121).

The main changes this week include:

• Linux kernel 5.10.7
• GNOME 3.38.3
• Mozilla Tunderbird 78.6.1
• Mesa 20.3.3
• openSSH 8.4p1
• Tcl/Tk 8.6.11
• Bash 5.1.4
• PHP 8 was added
• Wine 6.0
• Multiple versions of python 3 parallel installable. Besides all python-FOO packages being built for python 3.8, they are now also built for python 3.6 (where they make sense and are buildable). The packages are named python36-FOO and python38-FOO. As Python 3.8 is currently the default python 3 interpreter in Tumbleweed, all python38-FOO packages provide/obsolete the python3-FOO symbol, in order to facilitate the migration to the new naming scheme.

The future changes that are currently being planned, worked on and being tested include:

• Postfix: change the default database format to lmdb, migrating away from BerkleyDB.
• icu 68.1: breaks a few things like PostgreSQL. Staging:I
• Rust 1.49: breaks librsvg
• Automake 1.16.3
• Autoconf 2.70: breaks quite a few packages. The list of failures has been noted on the current SR; no active staging left for it (no progress in the last days/weeks on it)
• Migrate to LUA 5.4 as main lua interpreter, mainly relevant in context of RPM and thus the distro bootstrap

We design systems around the size of delays that are expected. You may have seen the popular table “latency numbers every programmer should know” which lists some delays that are significant in technology systems we build.

Teams are systems too. Delays in operations that teams need to perform regularly are significant to their effectiveness. We should know what they are.

Ssh to a server on the other side of the world and you will feel frustration; delay in the feedback loop from keypress to that character displayed on the screen. 

Here’s some important feedback loops for a team, with feasible delays. I’d consider these delays tolerable by a team doing their best work (in contexts I’ve worked in). Some teams can do better, lots do worse.

What are the equivalent feedback mechanisms for your team? How long do they take? How do they influence your work?

Feedback Delays Matter

They represent how quickly we can learn. Keeping the delays as low as the table above means we can get feedback as fast as we have made any meaningful progress. Our tools/system do not hold us back. 

Feedback can be synchronous if you keep them this fast. You can wait for feedback and immediately use it to inform your next steps. This helps avoid the costs of context switching. 

With fast feedback loops we run tests, and fix broken behaviour. We integrate our changes and update our design to incoporate a colleague’s refactoring.

Fast is deploying to production and immediately addressing the performance degradation we observe. It’s rolling out a feature to 1% of users and immediately addressing errors some of them see.

With slow feedback loops we run tests and respond to some emails while they run, investigate another bug, come back and view the test results later. At this point we struggle to build a mental model to understand the errors. Eventually we’ll fix them and then spend the rest of the afternoon trying to resolve conflicts with a branch containing a week’s changes that a teammate just merged.

With slow deploys you might have to schedule a change to production. Risking being surprised by errors reported later that week, when it has finally gone live, asynchronously. Meanwhile users have been experiencing problems for hours.

Losing Twice

As feedback delays increase, we lose twice:

a) We waste more time waiting for these operations (or worse—incur context switching costs as we fill the time waiting)

b) We are incentivised to seek feedback less often, since it is costly to do so. Thereby wasting more time & effort going in the wrong direction.

I picture this as a meandering path towards the most value. Value often isn’t where we thought it was at the start. Nor is the route to it often what we envisioned at the start.

We waste time waiting for feedback. We waste time by following our circuitous route. Feedback opportunities can bring us closer to the ideal line.

When feedback is slow it’s like setting piles of money on fire. Investment in reducing feedback delays often pays off surprisingly quickly—even if it means pausing forward progress while you attend to it.

This pattern of going in slightly the wrong direction then correcting repeats at various granularities of change. From TDD, to doing (not having) continuous integration. From continuous deployment to testing in production. From customers in the team, to team visibility of financial results.

Variable delays are even worse

In recent times you may have experienced the challenge of having conversations over video links with significant delays. This is even harder when the delay is variable. It’s hard to avoid talking over each other. 

Similarly, it’s pretty bad if we know it’s going to take all day to deploy a change to production. But it’s so worse if we think we can do it in 10 minutes, when it actually ends up taking all day. Flaky deployment checks, environment problems, change conflicts create unpredictable delays.

It’s hard to get anything done when we don’t know what to expect. Like trying to hold a video conversation with someone on a train that’s passing through the occasional tunnel. 

Measure what Matters 

The time it takes for key types of feedback can be a useful lead indicator on the impact a team can have over the longer term. If delays in your team are important to you why not measure them and see if they’re getting better or worse over time? This doesn’t have to be heavyweight.

How about adding a timer to your deploy process and graphing the time it takes from start to production over time? If you don’t have enough datapoints to plot deploy delay over time that probably tells you something ;)

Or what about a physical/virtual wall for waste. Add to a tally or add a card every time you have wasted 5 mins waiting. Make it visible. How big did the tally get each week?

What do the measurements tell you? If you stopped all feature work for a week and instead halved your lead time to production, how soon would it pay off?

Would you hit your quarterly goals more easily if you stopped sprinting and first removed the concrete blocks strapped to your feet?

What’s your experience?

Every team has a different context. Different sorts of feedback loops will be more or less important to different teams. What’s important enough for your team to measure? What’s more important than I’ve listed here?

What is difficult to keep fast? What gets in the way? What is so slow in your process that synchronous feedback seems like an unattainable dream? 

The post Latency Numbers Every Team Should Know appeared first on Benji's Blog.