Run local LLMs with Ollama and explore possible integrations with Uyuni by PSuarezHernandez

Description

Using Ollama you can easily run different LLM models in your local computer. This project is about exploring Ollama, testing different LLMs and try to fine tune them. Also, explore potential ways of integration with Uyuni.

Goals

• Explore Ollama
• Test different models
• Fine tuning
• Explore possible integration in Uyuni

Resources

• https://ollama.com/
• https://huggingface.co/
• https://apeatling.com/articles/part-2-building-your-training-data-for-fine-tuning/

---

Make more sense of openQA test results using AI by livdywan

Description

AI has the potential to help with something many of us spend a lot of time doing which is making sense of openQA logs when a job fails.

User Story

Allison Average has a puzzled look on their face while staring at log files that seem to make little sense. Is this a known issue, something completely new or maybe related to infrastructure changes?

Goals

• Leverage a chat interface to help Allison
• Create a model from scratch based on data from openQA
• Proof of concept for automated analysis of openQA test results

Bonus

• Use AI to suggest solutions to merge conflicts
  • This would need a merge conflict editor that can suggest solving the conflict
• Use image recognition for needles

Resources

• TensorFlow
• open-webui
• openQA instance of openSUSE
• openQA documentation

Timeline

Day 1

• Conversing with open-webui to teach me how to create a model based on openQA test results
  • Asking for example code using TensorFlow in Python
  • Discussing log files to explore what to analyze
  • Drafting a new project called Testimony (based on Implementing a containerized Python action) - the project name was also suggested by the assistant

Day 2

• Using NotebookLLM (Gemini) to produce conversational versions of blog posts
  • Writing openQA tests in Python
  • Developing in distrobox containers
• Researching the possibility of creating a project logo with AI
  • Asking open-webui, persons with prior experience and conducting a web search for advice

Highlights

• I briefly tested compared models to see if they would make me more productive. Between llama, gemma and mistral there was no amazing difference in the results for my case.
• Convincing the chat interface to produce code specific to my use case required very explicit instructions.
• Asking for advice on how to use open-webui itself better was frustratingly unfruitful both in trivial and more advanced regards.
• Documentation on source materials used by LLM's and tools for this purpose seems virtually non-existent - specifically if a logo can be generated based on particular licenses

Outcomes

• Chat interface-supported development is providing good starting points and open-webui being open source is more flexible than Gemini. Although currently some fancy features such as grounding and generated podcasts are missing.
• Allison still has to be very experienced with openQA to use a chat interface for test review. Publicly available system prompts would make that easier, though.

---

Ansible for add-on management by lmanfredi

Description

Machines can contains various combinations of add-ons and are often modified during the time.

The list of repos can change so I would like to create an automation able to reset the status to a given state, based on metadata available for these machines

Goals

Create an Ansible automation able to take care of add-on (repo list) configuration using metadata as reference

Resources

• Machines
• Repositories
• Developing modules
• Basic VM Guest management
• Module zypper_repository_list
• ansible-collections community.general
  • plugins/modules/zypper.py
  • plugins/modules/zypper_repository.py
  • plugins/modules/zypperrepositoryinfo.py

Results

Created WIP project Ansible-add-on-openSUSE

---

Symbol Relations by hli

Description

There are tools to build function call graphs based on parsing source code, for example, cscope.

This project aims to achieve a similar goal by directly parsing the disasembly (i.e. objdump) of a compiled binary. The assembly code is what the CPU sees, therefore more "direct". This may be useful in certain scenarios, such as gdb/crash debugging.

Detailed description and Demos can be found in the README file:

Supports x86 for now (because my customers only use x86 machines), but support for other architectures can be added easily.

Tested with python3.6

Goals

Any comments are welcome.

Resources

https://github.com/lhb-cafe/SymbolRelations

symrellib.py: mplements the symbol relation graph and the disassembly parser

symrel_tracer*.py: implements tracing (-t option)

symrel.py: "cli parser"

---

SUSE AI Meets the Game Board by moio

Use tabletopgames.ai’s open source TAG and PyTAG frameworks to apply Statistical Forward Planning and Deep Reinforcement Learning to two board games of our own design. On an all-green, all-open source, all-AWS stack!

---

Results: Infrastructure Achievements

We successfully built and automated a containerized stack to support our AI experiments. This included:

• a Fully-Automated, One-Command, GPU-accelerated Kubernetes setup: we created an OpenTofu based script, tofu-tag, to deploy SUSE's RKE2 Kubernetes running on CUDA-enabled nodes in AWS, powered by openSUSE with GPU drivers and gpu-operator
• Containerization of the TAG and PyTAG frameworks: TAG (Tabletop AI Games) and PyTAG were patched for seamless deployment in containerized environments. We automated the container image creation process with GitHub Actions. Our forks (PRs upstream upcoming):
  • https://github.com/moio/TabletopGames/tree/hackweek24
  • https://github.com/moio/PyTAG/tree/hackweek24

./deploy.sh and voilà - Kubernetes running PyTAG (k9s, above) with GPU acceleration (nvtop, below)

Results: Game Design Insights

Our project focused on modeling and analyzing two card games of our own design within the TAG framework:

• Game Modeling: We implemented models for Dario's "Bamboo" and Silvio's "Totoro" and "R3" games, enabling AI agents to play thousands of games ...in minutes!
• AI-driven optimization: By analyzing statistical data on moves, strategies, and outcomes, we iteratively tweaked the game mechanics and rules to achieve better balance and player engagement.
• Advanced analytics: Leveraging AI agents with Monte Carlo Tree Search (MCTS) and random action selection, we compared performance metrics to identify optimal strategies and uncover opportunities for game refinement .
  • more about Bamboo on Dario's site
  • more about R3 on Silvio's site (italian, translation coming)
  • more about Totoro on Silvio's site

A family picture of our card games in progress. From the top: Bamboo, Totoro, R3

Results: Learning, Collaboration, and Innovation

Beyond technical accomplishments, the project showcased innovative approaches to coding, learning, and teamwork:

• "Trio programming" with AI assistance: Our "trio programming" approach—two developers and GitHub Copilot—was a standout success, especially in handling slightly-repetitive but not-quite-exactly-copypaste tasks. Java as a language tends to be verbose and we found it to be fitting particularly well.
• AI tools for reporting and documentation: We extensively used AI chatbots to streamline writing and reporting. (Including writing this report! ...but this note was added manually during edit!)
• GPU compute expertise: Overcoming challenges with CUDA drivers and cloud infrastructure deepened our understanding of GPU-accelerated workloads in the open-source ecosystem.
• Game design as a learning platform: By blending AI techniques with creative game design, we learned not only about AI strategies but also about making games fun, engaging, and balanced.

Last but not least we had a lot of fun! ...and this was definitely not a chatbot generated line!

The Context: AI + Board Games

---

Kanidm: A safe and modern IDM system by firstyear

Kanidm is an IDM system written in Rust for modern systems authentication. The github repo has a detailed "getting started" on the readme.

Kanidm Github

In addition Kanidm has spawn a number of adjacent projects in the Rust ecosystem such as LDAP, Kerberos, Webauthn, and cryptography libraries.

In this hack week, we'll be working on Quokca, a certificate authority that supports PKCS11/TPM storage of keys, issuance of PIV certificates, and ACME without the feature gatekeeping implemented by other CA's like smallstep.

For anyone who wants to participate in Kanidm, we have documentation and developer guides which can help.

I'm happy to help and share more, so please get in touch!

---

Migrate from Docker to Podman by tjyrinki_suse

Description

I'd like to continue my former work on containerization of several domains on a single server by changing from Docker containers to Podman containers. That will need an OS upgrade as well as Podman is not available in that old server version.

Goals

• Update OS.
• Migrate from Docker to Podman.
• Keep everything functional, including the existing "meanwhile done" additional Docker container that is actually being used already.
• Keep everything at least as secure as currently. One of the reasons of having the containers is to isolate risks related to services open to public Internet.
• Try to enable the Podman use in production.
• At minimum, learn about all of these topics.
• Optionally, improve Ansible side of things as well...

Resources

A search engine is one's friend. Migrating from Docker to Podman, and from docker-compose to podman-compose.

---

Bot to identify reserved data leak in local files or when publishing on remote repository by mdati

Description

Scope here is to prevent reserved data or generally "unwanted", to be pushed and saved on a public repository, i.e. on Github, causing disclosure or leaking of reserved informations.

The above definition of reserved or "unwanted" may vary, depending on the context: sometime secret keys or password are stored in data or configuration files or hardcoded in source code and depending on the scope of the archive or the level of security, it can be either wanted, permitted or not at all.

As main target here, secrets will be registration keys or passwords, to be detected and managed locally or in a C.I. pipeline.

Goals

• Detection:

  • Local detection: detect secret words present in local files;
  • Remote detection: detect secrets in files, in pipelines, going to be transferred on a remote repository, i.e. via git push;

• Reporting:

  • report the result of detection on stderr and/or log files, noticed excluding the secret values.

• Acton:

  • Manage the detection, by either deleting or masking the impacted code or deleting/moving the file itself or simply notify it.

Resources

• Project repository, published on Github (link): m-dati/hkwk24;
• Reference folder: hkwk24/chksecret;
• First pull request (link): PR#1;
• Second PR, for improvements: PR#2;
• README.md and TESTS.md documentation files available in the repo root;
• Test subproject repository, for testing CI on push [TBD].

Notes

We use here some examples of secret words, that still can be improved.
The various patterns to match desired reserved words are written in a separated module, to be on demand updated or customized.

[Legend: TBD = to be done]

---

Model checking the BPF verifier by shunghsiyu

Project Description

BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

Goal for this Hackweek

Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

Resources

• Formal Methods for the Informal Engineer: Tutorial #1 - The Z3 Theorem Prover and its accompanying notebook is a great introduction into Z3
  • Has a section specifically on model checking
• Software Verification and Analysis Using Z3 a great example of using Z3 for model checking
• Sound, Precise, and Fast Abstract Interpretation with Tristate Numbers - existing work that use formal verification to prove that the multiplication helper used for value tracking work as intended
• [PATCH v5 net-next 00/12] bpf: rewrite value tracking in verifier - initial patch set that adds tristate number to the verifier

---

OIDC Loginproxy by toe

Description

Reverse proxies can be a useful option to separate authentication logic from application logic. SUSE and openSUSE use "loginproxies" as an authentication layer in front of several services.

Currently, loginproxies exist which support LDAP authentication or SAML authentication.

Goals

The goal of this Hack Week project is, to create another loginproxy which supports OpenID Connect authentication which can then act as a drop-in replacement for the existing LDAP or SAML loginproxies.

Testing is intended to focus on the integration with OIDC IDPs from Okta, KanIDM and Authentik.

Resources

• #122254: Migrate away from login proxies to SSO

---

Drag Race - comparative performance testing for pull requests by balanza

Description

«Sophia, a backend developer, submitted a pull request with optimizations for a critical database query. Once she pushed her code, an automated load test ran, comparing her query against the main branch. Moments later, she saw a new comment automatically added to her PR: the comparison results showed reduced execution time and improved efficiency. Smiling, Sophia messaged her team, “Performance gains confirmed!”»

Goals

• To have a convenient and ergonomic framework to describe test scenarios, including environment and seed;
• to compare results from different tests
• to have a GitHub action that executes such tests on a CI environment

Resources

The MVP will be built on top of Preevy and K6.

---