Chaos Computer Club - archive feed

Everybody of us have got a laptop. Then there are some Embedded enthusiasts with arm hardware. Did you hear already about the architecture s390x for mainframes, which includes IBM zSystems and LinuxONE? You will learn, where such hardware is used and that you can also still use it with openSUSE. Hints will be given, how to receive mainframe access for free for open source development. Finally, there is a short introduction, how you can be included for better s390x support (with feedback) within the Linux Distributions Working Group at the Open Mainframe Project.

Everybody of us have got a laptop. Then there are some Embedded enthusiasts with arm hardware. Did you hear already about the architecture s390x for mainframes, which includes IBM zSystems and LinuxONE? You will learn, where such hardware is used and that you can also still use it with openSUSE. Hints will be given, how to receive mainframe access for free for open source development. Finally, there is a short introduction, how you can be included for better s390x support (with feedback) within the Linux Distributions Working Group at the Open Mainframe Project.

about this event: https://c3voc.de

BCI (Base Container Images) is a set of open-source container images that developers and operators can use as a foundation for containerizing applications.

BCIs cover a wide range of use cases and scenarios compared to traditional enterprise distribution images. We had to take a different approach to testing and delivery to cover all these new use cases.

In this session we briefly cover the history of the Base Container Images and the tooling that we created in the process. This includes our [Dockerfile generator](https://github.com/SUSE/BCI-dockerfile-generator), the [BCI test suite](https://github.com/SUSE/BCI-tests/), and the [`pytest_container`](https://github.com/dcermak/pytest_container) plugin. We also take a look how we moved the development from our internal build service to the [public Open Build Service](https://build.opensuse.org/project/subprojects/devel:BCI) and then to [Github](https://github.com/SUSE/BCI-dockerfile-generator).

BCI (Base Container Images) is a set of open-source container images that developers and operators can use as a foundation for containerizing applications.

BCIs cover a wide range of use cases and scenarios compared to traditional enterprise distribution images. We had to take a different approach to testing and delivery to cover all these new use cases.

In this session we briefly cover the history of the Base Container Images and the tooling that we created in the process. This includes our [Dockerfile generator](https://github.com/SUSE/BCI-dockerfile-generator), the [BCI test suite](https://github.com/SUSE/BCI-tests/), and the [`pytest_container`](https://github.com/dcermak/pytest_container) plugin. We also take a look how we moved the development from our internal build service to the [public Open Build Service](https://build.opensuse.org/project/subprojects/devel:BCI) and then to [Github](https://github.com/SUSE/BCI-dockerfile-generator).

about this event: https://c3voc.de

Rancher can deploy and manage your Kubernetes clusters on AWS EKS and EC2. But what about things like Authentication, Logging, Monitoring or Backup? I will give an overview of AWS services for these four pillars and talk about what’s already possible, which challenges some integrations might have and an outlook what’s planned. Learn more about how the integrations are working under the hood and which technologies and open-sources solutions are involved.

Rancher can deploy and manage your Kubernetes clusters on AWS EKS and EC2. But what about things like Authentication, Logging, Monitoring or Backup? I will give an overview of AWS services for these four pillars and talk about what’s already possible, which challenges some integrations might have and an outlook what’s planned. Learn more about how the integrations are working under the hood and which technologies and open-sources solutions are involved.

about this event: https://c3voc.de

We are using SALT to deploy SUSE Systems for production. The included modules work well for usual problems.

But what needs to be done if you want to integrate a software system (or part thereof) where there are no modules available? Calling out to shell commands won't work to well for complex tasks.

You'll find the slides at https://www.jochen.org/vortraege/implementing-salt-modules.pdf

We've implemented - as part of a bigger automation effort - some SALT modules to configure our SAP HANA applications for better integration into the automation machinery.

I'll present our motivation for implementing execution and state modules, how you can start implementing and testing them.

In my experience the function signatures of the modules are the key to useful state modules, so I'll take a look at our modules and discuss the experiences gained in using them. Is the effort worth the gain? My answer is "yes".

Some basic programming skills and Python will be helpful for understanding, but not required.

We are using SALT to deploy SUSE Systems for production. The included modules work well for usual problems.

But what needs to be done if you want to integrate a software system (or part thereof) where there are no modules available? Calling out to shell commands won't work to well for complex tasks.

You'll find the slides at https://www.jochen.org/vortraege/implementing-salt-modules.pdf

We've implemented - as part of a bigger automation effort - some SALT modules to configure our SAP HANA applications for better integration into the automation machinery.

I'll present our motivation for implementing execution and state modules, how you can start implementing and testing them.

In my experience the function signatures of the modules are the key to useful state modules, so I'll take a look at our modules and discuss the experiences gained in using them. Is the effort worth the gain? My answer is "yes".

Some basic programming skills and Python will be helpful for understanding, but not required.

about this event: https://c3voc.de

This talk will cover the development of an openSUSE based external-dns solution that can be used within a k3s environment. The current upstream solution for external-dns is based on Alpine Linux. In order to create containers based on openSUSE, powerdns and external-dns containers were developed and published to registry.opensuse.org. During this session, the different design decisions and hurdles that were overcome will be covered. In addition, the presentation will provide tools, tips, and troubleshooting techniques that were used during the development cycle.

This talk will cover the development of an openSUSE based external-dns solution that can be used within a k3s environment. The current upstream solution for external-dns is based on Alpine Linux. In order to create containers based on openSUSE, powerdns and external-dns containers were developed and published to registry.opensuse.org. During this session, the different design decisions and hurdles that were overcome will be covered. In addition, the presentation will provide tools, tips, and troubleshooting techniques that were used during the development cycle.

about this event: https://c3voc.de

With SUSE's ALP stirring up discussions how Linux distribution may look like, we decided to try different approach how installer may work.

Part of these installer try-outs is **Iguana** - installation initramfs where all heavy lifting is done in containers.

Moving installers to the containers and by leveraging container infrastructure, we are trying to solve ever changing requirements or need to have security and other fixes in installer, which was always a bit of challenge for relatively static things like OS installers.

With SUSE's ALP stirring up discussions how Linux distribution may look like, we decided to try different approach how installer may work.

Part of these installer try-outs is **Iguana** - installation initramfs where all heavy lifting is done in containers.

Moving installers to the containers and by leveraging container infrastructure, we are trying to solve ever changing requirements or need to have security and other fixes in installer, which was always a bit of challenge for relatively static things like OS installers.

about this event: https://c3voc.de

WASM affords portability when coupled with Content Addressable Tar Files, we can utilize Peer.2 Peer distribution to enhance and reduce the size and vitality of images.

This talk explores how the next evolution of containers might take place, and what key technologies are driving solutions in place today.

WASM affords portability when coupled with Content Addressable Tar Files, we can utilize Peer.2 Peer distribution to enhance and reduce the size and vitality of images.

This talk explores how the next evolution of containers might take place, and what key technologies are driving solutions in place today.

about this event: https://c3voc.de

Packaging for a distribution means taking sources from upstream

projects, applying fixes and modifications, adding some

configuration and then build the result by calling some commands.

RPM formalized the process following a "pristine sources" model. The

approach is basically to take the unmodified sources as released by

upstream and store required changes in the form of patches as well

as a build description next to them.

Times have changed. The distributed version control system git

dominates the free software world. Juggling tarballs and manually

applying patches is no longer a natural workflow. Packager life

could be much easier if downstream changes could be applied by means

of git too, skipping tarballs.

This talks presents a way how to apply the pristine source idea to a

git based world, without history rewriting in the distro repo.

Packaging for a distribution means taking sources from upstream

projects, applying fixes and modifications, adding some

configuration and then build the result by calling some commands.

RPM formalized the process following a "pristine sources" model. The

approach is basically to take the unmodified sources as released by

upstream and store required changes in the form of patches as well

as a build description next to them.

Times have changed. The distributed version control system git

dominates the free software world. Juggling tarballs and manually

applying patches is no longer a natural workflow. Packager life

could be much easier if downstream changes could be applied by means

of git too, skipping tarballs.

This talks presents a way how to apply the pristine source idea to a

git based world, without history rewriting in the distro repo.

about this event: https://c3voc.de

Both the ISO 27001 and ISO 27002 standards have been updated in 2022. What does this mean for open source communities and companies leveraging open source?

What are the most significant changes to the standards?

The new ISO27001 standard requires companies to identify and meet the needs of interested parties, such as customers and suppliers. That way, organizations can ensure that their information security management system is designed to meet their stakeholders needs.

It also requires that organizations include processes for managing information security objectives in their ISMS, so that those objectives can be monitored and evaluated over time. It is essential for organizations to be able to demonstrate that their data-protection and security risk mitigation measures will be maintained and continuously improved.

The new ISO27001 standard also makes it clear that changes to an organization's ISMS must be planned, with a specific process for communicating those changes to interested parties. This process should establish how communication should occur (rather than just who should communicate).

Organizations now have to control processes, products, or services that are outside of the ISMS (as well as those that are inside of it), which means that they have to take a more holistic approach to managing both internal and outsourced operations.

ISO 27002 has been updated, firstly the phrase 'code of practice' has been dropped from the title of the updated ISO 27002 standard. This approach better reflects the set's intended purpose as a reference of information security controls.

The 27002 Standard itself is considerably longer than the previous version, and the controls have been reordered and updated.

The new controls are identifiable by attribute, which makes it easier to focus on relevant categorical selections, which could reduce the compliance burden or help better integrate information security processes, making the ISMS easier to implement and manage.

What is a reasonable for IT vendors and open source communities to update their cybersecurity approach to reflect the new requirements from the new norms?

Both the ISO 27001 and ISO 27002 standards have been updated in 2022. What does this mean for open source communities and companies leveraging open source?

What are the most significant changes to the standards?

The new ISO27001 standard requires companies to identify and meet the needs of interested parties, such as customers and suppliers. That way, organizations can ensure that their information security management system is designed to meet their stakeholders needs.

It also requires that organizations include processes for managing information security objectives in their ISMS, so that those objectives can be monitored and evaluated over time. It is essential for organizations to be able to demonstrate that their data-protection and security risk mitigation measures will be maintained and continuously improved.

The new ISO27001 standard also makes it clear that changes to an organization's ISMS must be planned, with a specific process for communicating those changes to interested parties. This process should establish how communication should occur (rather than just who should communicate).

Organizations now have to control processes, products, or services that are outside of the ISMS (as well as those that are inside of it), which means that they have to take a more holistic approach to managing both internal and outsourced operations.

ISO 27002 has been updated, firstly the phrase 'code of practice' has been dropped from the title of the updated ISO 27002 standard. This approach better reflects the set's intended purpose as a reference of information security controls.

The 27002 Standard itself is considerably longer than the previous version, and the controls have been reordered and updated.

The new controls are identifiable by attribute, which makes it easier to focus on relevant categorical selections, which could reduce the compliance burden or help better integrate information security processes, making the ISMS easier to implement and manage.

What is a reasonable for IT vendors and open source communities to update their cybersecurity approach to reflect the new requirements from the new norms?

about this event: https://c3voc.de

After some years from first openSUSE image for a mobile phone, i think it is time to let people know about status of project for this topic. In other hand the talk will check features already working and some not fixed, of course at the end there will be a resume about future of the project.

This talk will show to everyone wich devices can be considered to be used in a daily drive devices and wich ones are having improvements and will be usable in future.

After some years from first openSUSE image for a mobile phone, i think it is time to let people know about status of project for this topic. In other hand the talk will check features already working and some not fixed, of course at the end there will be a resume about future of the project.

This talk will show to everyone wich devices can be considered to be used in a daily drive devices and wich ones are having improvements and will be usable in future.

about this event: https://c3voc.de