The affordable ARM hardware that was donated last year were distributed to Italy, India, Cameroon, Germany, Spain and Argentina to improve healthcare management and patient care. Some were also used to improve development on the platform.

The intention of the fork is to give new inspiration to a project that has been perceived as idling in recent years. Uyuni, however is already looking at increasing the implementation of a React web User Interface, translations, clients, container and Kubernetes integration. Uyuni is using Salt for configuration management, thereby inheriting its name: Uyuni refers to the world’s largest Salt flat, Salar de Uyuni in Southwest Bolivia.

Compatible and Innovative

“Uyuni has a vision for this open-source code and plans on growing its community and innovating the code beyond its current state in Spacewalk,” said Klaus Kämpf, SUSE’s Project Owner of SUSE Manager, who announced the fork. “Contributions for Spacewalk have decreased and focused more on maintenance and stabilization than on innovation.”

Uyuni will stay compatible, Kämpf adds as much as possible: “The Uyuni project will not break up compatibility on purpose, but that shall not prevent improvements for that reason.”

The current development plans are releasing a first version this summer, and then deciding on a release model together with the community.

Development will have automated testing using both the Open Build Service and Cluster Infrastructure.

A fact listed from the previous Spacewalk FAQ website, which has since been removed, stated, “As Red Hat’s participation ramps down, there will be an opportunity for the participation from other community members to ramp up. Someone (or several someones!) will need to take over some of the management role that currently rests on Red Hat.”

Uyuni community members decided to fork the project after extensive discussions with Red Hat about taking over the management role as stated above.

Spacewalk is an open source Linux systems management solution, currently available in version 2.8 as upstream community project for Red Hat Satellite 5. SUSE Manager is also based on Spacewalk and now plans on shifting to Uyuni as an upstream community.

“SUSE Manager’s development will be openly available to open-source community members for whatever contributions they would like to make to the Uyuni project,” Kämpf said.

Today’s major release of openSUSE Leap 15 is offering professional users, entrepreneurs and ISVs (Independent Software Vendors) a new, fresh and hardened code base for their workloads that supports modern hardware, based on a stable, community- and enterprise-based open-source GNU/Linux distribution – but developed with a modern, more secure, better tested and much more open open-source build system unique to SUSE and openSUSE.

New Features

openSUSE Leap 15 now allows migration to SLE, brings a new partitioner, integrates the Groupware Kopano, moves to Firewalld – and also comes distributed by Linode (for Cloud and infrastructure setups) and on high-end hardware like Tuxedo Laptops (other Cloud and hardware vendors will follow). On top of that, Leap 15 introduces a system role selection with classic “server” or “transactional server” role with transactional updates and a read-only root file system. This brings in all the benefits of atomic updates to the full scope of deployments, from the Internet of Things (IoT) and embedded devices to classical server and desktop roles. Apart from that, Leap 15 has been continually optimized for cloud usage scenarios as virtualization guest and at the same time offers a great variety of desktops, including KDE and GNOME and features the return of Live images for simple test-driving.

New Look, closely aligned with SLE

With a brand new look developed by the community, openSUSE Leap 15 brings plenty of community packages built on top of a core from SUSE Linux Enterprise (SLE) 15 sources, with the two major releases being built in parallel from the beginning for the first time. Leap 15 shares a common core with SLE 15, which is due for release in the coming months. The first release of Leap was version 42.1, and it was based on the first Service Pack (SP1) of SLE 12. Three years later SUSE’s enterprise version and openSUSE’s community version are now aligned at 15 with a fresh rebase.

“Having a community distribution that shares a common DNA with enterprise is the smart way to interact with the open-source ecosystem,” said Kai Dupke, long-time openSUSE user and senior product manager for SUSE Linux Enterprise 15. “Leap provides great flexibility and freedom of choice for developers and users.”

Migration to Enterprise made easy

Consequently, for the first time, SUSE will support migration from openSUSE Leap server installations to SUSE Linux Enterprise, which makes it easy for system integrators to develop on Leap code and later move to an enterprise version for SLAs, certification, mass deployment, or extended Long Term Support.

“Upgrading to a commercial product can be complex for developers wanting to migrate a solution from a community Linux distribution to an enterprise distribution”, Dupke explains. “With Leap 15 SUSE Linux Enterprise Server 15, that journey is made easy. We know that the community is where the innovations happen, and Leap community developers now can easily broaden that scope into enterprise Linux, if needed. Leap 15 is offering the quickest and most flexible transition to enterprise service, support and maintenance.”

OBS, OpenQA: Better Tested, More Secure and More Open than Others

openSUSE.Asia Committee calls for proposals of talks for openSUSE.Asia Summit 2018 held at National Taiwan University of Science and Technology on August 11 and 12. We might have community day on 10th August before the summit.

openSUSE.Asia Summit is one of the great events for openSUSE community (i.e., both contributors, and users) in Asia. Those who usually communicate online can get together from all over the world, talk face to face, and have fun. Members of the community will share their most recent knowledge, experiences, and learn FLOSS technologies surrounding openSUSE.

This event at Taipei is the fifth in openSUSE.Asia Summit. Following the first Asia Summit in Beijing 2014. The past Asia Summits have had participants from China, Taiwan, India, Indonesia, Japan, South Korea, and etc.

This time we co-host with COSCUP and GNOME.Asia, COSCUP is an annual conference held by Taiwanese open source community since 2006. It is a major force of free software movement advocacy in Taiwan. The event is often held with talks, sponsor and communities booths, and Birds of a feather. In addition to international speakers, many Taiwanese local open source contributors often give their talks here. The chief organizer, staffs, and speakers are all volunteers.

COSCUP’s aim is providing a platform to connect open source coders, users, and promoters, and promote FLOSS with the annual conference. The conference is free to attend because of the enthusiastic sponsors and donator. In 2017, there are around 1,800 attendees, and we plan to invite more than 2,000 people join COSCUP × openSUSE.Asia Summit × GNOME.Asia Summit this year.

Call for proposals

The speakers are eligible to receive sponsorship from openSUSE Travel Support Program (TSP). Even if you live away from Taipei. please consider applying for the event.

Selecting a good date and having some goodies to pass out to the party requires a bit of planning. The checklist below can help with planning the release party. If you plan on having a party, email ddemaio (at) opensuse.org well before the party to get some goodies to hand out to the party people. Please include “Leap 15 Party” in the subject line and include a mailing address and phone number.

checklist:

Find a date

The date of a party is best during a weekend (because it’s easier for people to join, since most people work during the week), but we all function differently. Find two alternative dates for the party if you want and use http://www.doodle.com/ to find a common date that works for most people.

Find a place

A cafe, bar or Linux group meetup location are all great places to have an event. A coffee and cake release party is just as fun as a beer and pizza release party.

Cake

It is not necessary to have a cake, but it sure is a lot of fun. You can also have openSUSE Cookies. On the Launch Party wiki page, there are two Release Parties list so far. One release party is in Nuremberg, Germany, on August 3 starting at 4 p.m. The other party is listed for FrOSCon and both will have a cake.

This blog is part of a series of technical blogs leading up to the release of openSUSE Leap 15. All of the blogs provide a use case regarding openSUSE Leap and the packages available in the distribution. Happy reading.

Transactional Updates is one of the exciting new features available in the upcoming release of openSUSE Leap 15, which is scheduled to be officially released May 25.

Contributed by the Kubic Project, Transactional Updates provides openSUSE systems with a method of updating the operating system and its packages in an entirely ‘atomic’ way. Updates are either applied to the system all together in a single transaction, or not at all. This happens without influencing the running system. If an update fails, or if the successful update is deemed to be incompatible or otherwise incorrect, it can be discarded to immediately return the system to its previous functioning state.

This differs from existing alternatives that already exist in the open source world. Some users use a rather exorbitant approach of maintaining multiple versions of their system in multiple partitions on disk to switch between the partitions to address a fear of tampering with a perfectly running system.

This juggling approach works, but takes an exorbitant amount of disk storage and maintenance efforts. More modern approaches like using ostree and snap attempt to address these problems and bring atomic/transactional updates to their users. However, these solutions have unintended consequence as users, developers, and partnering software vendors all learn new ways of managing their systems and existing packages cannot be re-used, which require either repackging or conversion. All of this develops to a situation where adopters need to redesign their mindsets, systems, tools and company policies to work with these clever tools. These workarounds have some key flaws that Kubic’s Transactional Updates feature strives to avoid.

Under the hood, Transactional Updates are made simple. Utilising the same btrfs, snapper, and zypper technologies that are trusted defaults in openSUSE Leap, Transactional Updates do something very similar to the traditional snapshots and rollbacks in Leap. However, Transactional Updates it never touches the running system. Instead of patching the current system, the transactional-update tool creates a new snapshot. All of the operations required by the update are carried out into a snapshot that ensures the current system is untouched with no changes impacting the running system.

The openSUSE Conference is right around the corner and attendees list keeps growing for oSC18, which will take place May 25 – 27 at the Faculty of Information Technologies of Czech Technical University in Prague.

There are about 250 people signed up to attend the conference and most of the talks have been scheduled for this year’s conference. In addition to the conference, there will be a cryptofest on May 26, which will incorporate comes oSC18. The schedule for the cryptofest list three oSC18 security-focused talks and will be room 107.

There are several track that will be taking place at the conference like an openSUSE track, a cloud and containers track, an open source track, a desktop and application track and an embedded track. On Saturday, May 26, will be a lightingbeers talk where people will get a free beer and give a short 5 minutes talks; people can sign up for this at http://bit.ly/2wtjczw.

There will be a wide range of speakers from many different open-source projects, and on Sunday, May 27, there will be an unconference in room 107; people can submitted their ideas for talks at the unconference on the Friday and Saturday. A schedule for the unconference will be made available for the last day.

This blog is part of a series of technical blogs leading up to the release of openSUSE Leap 15. All of the blogs provide a use case regarding openSUSE Leap and the packages available in the distribution. Happy reading.

Authored by Max Huang

Docker is a software technology providing containers, promoted by the company Docker, Inc. Docker provides an additional layer of abstraction and automation of operating-system-level virtualization on Windows and Linux.

Docker implements a high-level Application Programming Interface to provide lightweight containers that run processes in isolation.

Because Docker containers are so lightweight, a single server or virtual machine can run several containers simultaneously.

The results of the elections ended in the success of 237 out of 400 people voting in this year’s election, which is a record both in participation percentage (59.25 percent) and in actual voters (237).

This year was the first year the projected attempted to vote through Helios Voting System.

The election committee was able to solved all problems that came to their attention, said Kostas Koudaras, who was on the election committee with Chuck Payne.

“I must say that although the work of the election committee ends somewhere around here the new elected members have a long way ahead of them and we, the election committee, wish them all the best,” Koudaras said.

The candidates had several weeks of campaigning and their efforts and voluntary commitment is apprecated.

This blog is part of a series of technical blogs leading up to the release of openSUSE Leap 15. All of the blogs provide a use case regarding openSUSE Leap and the packages available in the distribution. Happy reading.

Authored by Peter Czanik

People often ask me what to use: systemd’s journald or syslog-ng? The quick answer is that most likely both, but it depends on how you use your computer(s). If you have a single standalone machine, journald is probably enough. There is even a nice desktop application to view the logs in the journal. But once you have multiple machines to manage, using syslog-ng has many advantages.

Even if you use syslog-ng, local system logs are collected by journald. It is an integral part of systemd and cannot be uninstalled. Luckily, syslog-ng can read log messages from the journal. If journald stores additional name-value pairs about an event, syslog-ng can read those as well.

So, why install syslog-ng? The short answer is: central logging.

Why is the central collection of logs such a big deal? One reason is ease of use, as central logging creates a single place to check logs instead of tens or thousands of devices. Another reason is availability – you can check a device’s log messages even if the device itself is unavailable for any reason. A third reason is security; when your device is hacked, checking the logs can uncover traces of the hack.

journald also has some central logging capabilities, but syslog-ng provides a lot more features and better performance:

journald was originally designed for local logs on desktops – where there are not that many logs. On the other hand, syslog-ng was designed for high-performance central log collection from the ground up.

syslog-ng can collect logs from many more sources, including pipes, sockets, and files. File sources are especially important, as many applications – like web servers – log to files and do that at a rate that journald cannot handle.

syslog-ng does more than simple log storage. It can process log messages in many ways: parse them to create name-value pairs for easier alerting and reporting, enrich them with geographical information (GeoIP), rewrite them for anonymization (see PCI-DSS or GDPR), or reformat them according to the requirements of the destination.

Filtering in syslog-ng makes very precise log routing possible, ensuring that all logs reach the right destination.

Speaking of destinations: there are many possibilities for storing log messages, not just flat files or other syslog servers as it was the case many years ago. For example, you can store logs in SQL databases, send logs to Splunk for further analysis using HTTP, store name-value pairs parsed from logs in MongoDB, or send an email alert using the SMTP destination.