Project Description
SUSE IT needs help from fellow geekos with release engineering skills to define the requirements, process, infrastructure, and tools for building an openSUSE-based distribution bundled with SUSE IT-supported application stack. The resulting OS build will be offered as a standard distribution for new SUSE employees in addition to the existing Operating System library.
Goal for this Hackweek
- Define requirements (and name) for the build.
- Selected features implemented for the MVP.
- Define a process for updating the image with the future releases of openSUSE.
- Identify and deploy required infrastructure and repositories.
- Produce an installable OS image that can be used by volunteers across the company.
- Document everything.
- Have a lot of fun in the process.
MVP requirements
- the deployment do the end-user machine is unattended
- machine has disk encrypted
- once the machine is provisioned, it is added to asset DB (serial number + asset owner)
- productivity tools are installed
Details are tracked here: https://en.opensuse.org/Portal:Leap:CSBRequirements
Looking for hackers with the skills:
releaseengineering osbuildprocess infrastructure rpmbuild rpm yast packaging distribution
This project is part of:
Hack Week 21
Activity
Comments
-
over 2 years ago by lkocman | Reply
I think we're talking about a spin of openSUSE Leap 15.X with probably some autoyast config to meet requirements from the SUSE IT Policy (encrypted home etc) and some tool initialized on the first boot (Or perhaps SUMA could do that ?) that can pull additional "new" software and deploys configuration changes to clients as needed.
The first-boot experience should probably connect to suse-guest (or other corporate wifi), pull VPN client and up2date configs, enable local printer discovery, certificates, enable multimedia and preferred browser that works with our web tools, preinstall tools used by SUSE Engineering (and other departments) teams, slack, Evolution with EWS config, etc.
I know both RH with (CentOS 7.X based CSB) and IBM (with their open client) used to have 3rd party tools that were monitoring installed software, deploy new config changes etc. Perhaps that's something we could consider as well.
Non-technical users had an option "not to have root password' any sort of management was done from the IT side. Knowing root password meant that you manage the host by yourself.
The question is also if IT will want to have control about what updates go in as that would probably require some sort of RMT in between.
-
over 2 years ago by lrupp | Reply
Looks like you want to explore kiwi's feature set and OBS ability to constantly rebuild the image to me.
Beside the encryption, you might want to have a look at existing images (like the one of the openSUSE heroes) to get a starting point.
...I'm just wondering what you plan to do with the rest of the week
-
over 2 years ago by lkocman | Reply
I personally wanted to play with container images for a quick home mirror enablement :-)
-
over 2 years ago by lrupp | Reply
JFYI: as we are testing our Salt Setup via Gitlab Runners, there are already some specialized Container images available, that you might want to check for some ideas.
-
-
-
over 2 years ago by vgrinco | Reply
For encryption I'd make use of the device TPM chip for storing the encryption key, to not rely on people remembering passwords.
We might also explore options to allow users to select the profile for their machine. E.G. sales, engineering, marketing, etc. and have ansible profiles packaged for each that would apply only specific set of rules, deploy the apps they use, create shortcuts relevant for that particular role, and so on. It would result in a cleaner experience.
For the bootstrap process, we can prepare a PXE server in given VLANs, which will also guarantee some sort of connectivity for the machine that's being bootstrapped. During the bootstrap process, we might want to consider updating the asset management system with the machine serial number and owner login.
Agree with the root/no root option, and a mechanism to reset the password to gain full system access for the ones who want to self-manage. We must assume that there will be part of the population who will rely on IT entirely to manage their OS (HR, for example, we want to have as diverse community as possible). Not sure if we'll be able to create a secure, user-initiated mechanism for remote support - we can add that to the backlog to be implemented at a latter stage.
-
over 2 years ago by lrupp | Reply
For PXE, please get in touch with our "Core Components" Team. They provide PXE + AutoYaST + some kind of Post-Boostrap process now since >15 years. It's called 'Orthos' and allows also to inventorize a machine automatically.
For E&I, there are standard PXE services up and running in Nuremberg and Prague as well, including the latest development versions of our distribution. IMHO this should exist in Provo and Prague as well, but I'm not 100% sure there. EngInfra is providing this service.
-
-
over 2 years ago by bmwiedemann | Reply
> enable multimedia
depends on the openh264 work with Cisco, if we want something that can pass legal review.
Or we need to convince Microsoft & friends to re-design their tools to use open codecs such as VP9/webm or AV1 in Teams.
We certainly do not want to include those 3rd party Packman repos.
-
-
over 2 years ago by lkocman | Reply
We already build a Corporate Standard build for Datto in OBS (it's Ubuntu based but the requirements would be similar), we might want to add that to our starting points next to image for Heroes.
https://mysuse.sharepoint.com/sites/OpenSourceCommunityCitizens/SitePages/Past-Events-and-meetings.aspx
-
over 2 years ago by anthidote | Reply
I was helping a new joiner who made the masochistic choice of a Thinkpad with an i9 and Intel Onboard GFX + Dedicated NVIDIA GFX. It does not well work on Tumbleweed. It works ok with Ubuntu, so I told him to stick with it and maybe keep on openSUSE as dual boot if he's interested in hacking it.
Perhaps the most important part of this would be to have IT "certify" or "reccomend" certain laptops for openSUSE. Once a new joiner has made a hw choice like that, there's very little we can realisitically do.
The same Thinkpad model with a Ryzen + Vega GFX is much, much more stable with TW. In fact it works flawlessly.
I can share a pdf guide, that I am building for new joiners. Perhaps there are some things that could be used for the image. One thing that could be useful is preloading it with SUSE CA certificates. That would make accessing the LDAP directory and setting up a thunderbird addressbook a bit easier.
-
over 2 years ago by vgrinco | Reply
We could also consider leapmicro[1]. Might be cool to offer a system unbreakable by updates. Heard there was a desktop spin for it.
[1] https://get.opensuse.org/leapmicro/5.2/
-
over 2 years ago by vgrinco | Reply
Leapmicro doesn't have a desktop manager - so no go. MicroOS is beta, and worked with moderate success - plus it's tumbleweed based. Sounds like a cool tiny os, but is not stable enough to be used in prod. Am working on leape 15.4 RC now -so far the best experience.
-
over 2 years ago by lkocman | Reply
Quick update
I do currently experiment here https://build.opensuse.org/project/show/home:lkocman:suse-it-infra
It's based on GNOME Live image package set, however I'm aiming for selfinstall media with gnome-initial-setup for firstboot
I'd like to submit Proof Of Concept to https://build.opensuse.org/project/show/home:mpiala:suse-it-infra quite soon
Official space where we'll build images long term is here (SUSE IT has admin permissions) https://build.opensuse.org/project/show/isv:SUSE:suse-it-infra
-
over 2 years ago by lnussel | Reply
We are the actual OS vendor, what's wrong with the official images we already produce? :-) We can basically change all aspects of them to suite our needs. Forking and maintaining a specific image in OBS over time is a lot of effort. Maybe SUSE specifics aren't so specific and could be integrated in a way that makes it possible to be reused by other companies? Upstream first is always a good idea :-)
For example, IIRC the fedora installer asks whether the installation at hand is a corporate one and offers AD integration then. That's probably not exactly what we need here. Instead the installer could offer something similar to the community repos dialog, allowing to specify a custom domain name. Ie one would enter suse.com, the installer downloads a config file from there that tells the installer eg what VPN technology is used, what extra repos or packages are needed or whether eg full disk encryption should be enabled by default.
-
over 2 years ago by wstephenson | Reply
Is there a way for an extension (once activated early in the installation) to hook in to the installer and add the features we require to the base openSUSE images, as Ludwig suggests? Or can this be done with the venerable AutoYast?
-
over 2 years ago by gkurel_suse | Reply
Here's the short description of the corporate openSUSE image seen by SUSE IT. Please note that this is still a draft, based on comments posted in this project along with the security and business requirements. We believe it is a good starting point. The content is kept and updated on Confluence. File below is the latest snapshot in PDF format.
Link: openSUSE Corporate Image
-
over 2 years ago by rkissiov | Reply
The below link is for the openSUSE image project schedule, starting from the 27th at 1PM till Friday the 1st of July.
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NGM2OGNjNjQtYjcxMi00MjJiLWI2ZDMtMjAxMzI1MGY5YzBl%40thread.v2/0?context=%7b%22Tid%22%3a%22f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba%22%2c%22Oid%22%3a%2272f6f3b7-35f8-48b2-bfd9-fd379d4e4b51%22%7d
-
over 2 years ago by mpiala | Reply
Day 1 kick-off meeting
Attendees: lkocman, vgrinco, mpiala, rkissiov, wfrisch, toepkes, gkurel
Initially defined streams: A. deployment B. packaging C. MDM enrollment (former configuration management + asset management integration)
Actions for today: A1: gnome-initial-setup is enabled, disk encrypted by default password (later can be changed) - lkocman A2: create dummy rpm from IBS B1: deploy package for VPN configuration (for corp + Eng VPN; openconnect + OpenVPN are dependency for this package, should be already in Leap) - wfrisch B2: deploy package for MDM enrollment (
/opt/vmware/ws1-hub/bin/ws1HubUtil enroll -s ds1678.awmdm.com -g m3115296 -u openSUSE -p openSUSE
; workspaceone-intelligent-hub is dependency for this package) - gkurel C1: enroll device into our Workspace One tenant (currently default credentials, goal is to use Okta)-
over 2 years ago by mpiala | Reply
better readable format:
Initially defined streams: A. deployment B. packaging C. MDM enrollment (former configuration management + asset management integration)
Actions for today: A1: gnome-initial-setup is enabled, disk encrypted by default password (later can be changed) - lkocman A2: create dummy rpm from IBS - mpiala B1: deploy package for VPN configuration (for corp + Eng VPN; openconnect + OpenVPN are dependency for this package, should be already in Leap) - wfrisch B2: deploy package for MDM enrollment (/opt/vmware/ws1-hub/bin/ws1HubUtil enroll -s ds1678.awmdm.com -g m3115296 -u openSUSE -p openSUSE ; workspaceone-intelligent-hub is dependency for this package) - gkurel C1: enroll device into our Workspace One tenant (currently default credentials, goal is to use Okta) - rkissiov
-
-
over 2 years ago by mpiala | Reply
Day 1 summary:
Deployment
- A1: build has enabled gnome-initial-setup + disk encryption. Still failing, lkocman will continue on it
Packaging
- B1: Deploy package for openconnect - done by wfrisch. Deploy package for OpenVPN - item for tomorrow for gkurel/wfrisch
- B2: Deploy package for MDM enrollment - done by vgrinco, using only default credentials. Once C1 is completed, we will change enrollment to use Okta.
MDM enrollment
- C1: Enrollment working with default credentials works. Call with Workspace One happened (Okta authentication), we are expecting some answers tomorrow.
Thank you guys for a nice work today! Let's have a sync tomorrow at 9:30 CEST
-
over 2 years ago by lkocman | Reply
I have encrypted image by using "suseit" password https://download.opensuse.org/repositories/home:/lkocman:/suse-it-infra/images/
Together with gnome-branding which should install basic flatpaks after gnome-initial-setup (thank to Richard's work in MicroOS).
However, I'm now debugging why my image end up with gdm, instead of gnome-intial-setup (I suppose systems service conflicts).
-
over 2 years ago by mpiala | Reply
Day 2
Deployment
- The encryption works. We might consider to disable the encryption for few days, to lower the build time
- Some issue with GDM, lkocman working on it
Packaging
- OpenVPN package in progress by wfrisch
- Teams, Slack to be installed using flatpack - gkurel is working it
MDM enrollment
- Currently, we can enroll (all) linux machines under one user and to move them to different user is not working. Waiting for replies from Workspace One, how to properly integrate it with Okta.
-
over 2 years ago by lkocman | Reply
So we do have an btrfs encrypted Leap 15.4 self-install image that triggers gnome-initial-setup. Once the first-boot is done gnome-branding-Leap's mod-firstboot (Big thanks to Richard) will pull remaining software as flatpaks. Deployment on real HW was under 3 minutes. VM in file/gnome-boxes more likely 5-7.
https://ibb.co/yPHvV2g (see pic from my tuxedo laptop)
Issue1: I had to disable ignition as it was failing the boot (seems like caused by some update in SLE Micro 5.3)
Issue2: We've had to fork gdm, as the gnome-initial-setup feature is disabled in SLE/Leap.
Issue3: I see that the gnome-initial-setup is either buggy (e.g. nothing happens if you click on connect to wifi) or there is something wrong with the modified GNOME livecd base that was used for the self-install image and seems like no user is created after finishing the first-boot wizard. This currently blocks the gnome-branding mod-firstboot and any other progress.
I could use somebody who could debug it and fix the remaining issues. Unfortunately the latest version from the factory will not build on top of 15.4
The image is built by these two files (livecd-openSUSE as I started with GNOME livecd as a base) https://build.opensuse.org/package/viewfile/home:lkocman:suse-it-infra/livecd-openSUSE/selfinstall-leap-gnome-csb.kiwi?expand=1 https://build.opensuse.org/package/viewfile/home:lkocman:suse-it-infra/livecd-openSUSE/config.sh?expand=1
I did create https://build.opensuse.org/package/show/isv:SUSE:suse-it-infra/suse-csb-release, that will enable the isv:SUSE:suse-it-infra repo and adds recommends for suse-it software (OpenVPN configs etc). This one could use some love as well.
-
over 2 years ago by lkocman | Reply
OK, so I've fixed the gnome-initial-setup it was really stupid issue, as we were building the image with readonly root (copied from livecd). I did notice this before, but simply remounting it as r/w before reastarting display-manager did not fix the issue. Full boot with /r/w / simply worked. I got to the point where I had Leap 15.4 self-installed image with GNOME, that triggered gnome-branding-Leap which installed remaining software as flatpaks. Fixed in https://build.opensuse.org/package/rdiff/home:lkocman:suse-it-infra/livecd-openSUSE?linkrev=base&rev=36
The current image has ignition-dracut enabled, so we can set a root password, otherwise, it's a pain. Seems like self-install built itself erases root password, even when it was originally set in kiwi.
-
over 2 years ago by lkocman | Reply
Oky so we did syncup with mpiala, put our changes together and all was submitted and accepted into https://build.opensuse.org/project/show/isv:SUSE:suse-it-infra
My remaining next steps for this hackweek is to ensure that ignition/combustion can change root password (otherwise you have to use rescue media or similar), as the initial build on Monday was failing on ignition related things.
-
over 2 years ago by lkocman | Reply
The ideal next steps, in general, would be to make self-install Leap media with updated gnome-initial-setup (and gdm without SLEs patches to disable gnome-initial-setup) part of official Leap 15.4 or 15.5 :Images.
We'd still have to figure out a way for suse-it to manage the gnome-initial-setup and gnome-branding (mod-firstboot), without rebuilding the image, in any case at least we'd have a fork of the official image to overwrite defaults).
-
over 2 years ago by lkocman | Reply
I've played a bit with combustion (tested in gnome-boxes) and depends if you first-boot with "ignition usb device" or not, the it either has control over root or not https://github.com/SUSE/suse-csb-release/pull/2
The changeLuksKey for btrfs doesn't seem to work, so that will require further investigation.
Otherwise, the custom sudoers, where the user has to enter the root password works ... keep in mind that as long as the person knows the luks password, they can boot with init=/bin/sh and get a root shell...
-
over 2 years ago by lkocman | Reply
Just additional info, the user is datto-ansible, we could be using suse-ansible (or -salt, I've heard that we want to prefer Ansible over salt in Alp, not sure what SUSE IT uses ...). Also, the user has to be a system user (have uid < 1000), so it's not displayed in GDM, and gnome-initial-setup starts.
Similar Projects
Add productcompose support to skippkg-finder by mlin7442
Description
Leap 16 started to use product-composer to build product repository, skippkg-finder as a script to generate a list of package to be filter-out while building repository, it should be able to support productcompose as well.
Goals
skippkg-finder be able to generate a filter list according to the pre-defined data in the OSRT:Config project attribute, and add it to unneeded
subset block into productcompose definition file, for Leap 16.0 it's default.productcompose file.
Resources
A CLI for Harvester by mohamed.belgaied
[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.
Project Description
Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as:
harvester vm create my-vm --count 5
to create 5 VMs named my-vm-01
to my-vm-05
.
Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.
Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli
Done in previous Hackweeks
- Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
- Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE
Goal for this Hackweek
The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.
Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it
Issue list is here: https://github.com/belgaied2/harvester-cli/issues
Resources
The project is written in Go, and using client-go
the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact).
Welcome contributions are:
- Testing it and creating issues
- Documentation
- Go code improvement
What you might learn
Harvester CLI might be interesting to you if you want to learn more about:
- GitHub Actions
- Harvester as a SUSE Product
- Go programming language
- Kubernetes API
Switch software-o-o to parse repomd data by hennevogel
Currently software.opensuse.org search is using the OBS binary search for everything, even for packages inside the openSUSE distributions. Let's switch this to use repomd data from download.opensuse.org
A CLI for Harvester by mohamed.belgaied
[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.
Project Description
Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as:
harvester vm create my-vm --count 5
to create 5 VMs named my-vm-01
to my-vm-05
.
Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.
Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli
Done in previous Hackweeks
- Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
- Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE
Goal for this Hackweek
The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.
Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it
Issue list is here: https://github.com/belgaied2/harvester-cli/issues
Resources
The project is written in Go, and using client-go
the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact).
Welcome contributions are:
- Testing it and creating issues
- Documentation
- Go code improvement
What you might learn
Harvester CLI might be interesting to you if you want to learn more about:
- GitHub Actions
- Harvester as a SUSE Product
- Go programming language
- Kubernetes API
Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons
Description
We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.
Goals
Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:
git-annex
pandoc
xmonad
cabal-install
Resources
- https://build.opensuse.org/project/show/devel:languages:haskell/
- https://github.com/opensuse-haskell/configuration/
- #discuss-haskell
- https://www.twitch.tv/peti343
Framework laptop integration by nkrapp
Project Description
Although openSUSE does run on the Framework laptops out-of-the-box, there is still room to improve the experience. The ultimate goal is to get openSUSE on the list of community supported distros
Goal for this Hackweek
The goal this year is to at least package all of the soft- and firmware for accessories like the embedded controller, Framework 16 inputmodule and other tools. I already made some progress by packaging the inputmodule control software, but the firmware is still missing
Resources
As I only have a Framework laptop 16 and not a 13 I'm looking for people with hardware that can help me test
Progress:
Update 1:
The project lives under my home for now until I can get an independent project on OBS: Framework Laptop project
Also, the first package is already done, it's the cli for the led-matrix spacer module on the Framework Laptop 16. I am also testing this myself, but any feedback or questions are welcome.
You can test the package on the Framework 16 by adding this repo and installing the package inputmodule-control
Update 2:
I finished packaging the python cli/gui for the inputmodule. It is using a bit of a hack because one of the dependencies (PySimpleGUI) recently switched to a noncommercial license so I cannot ship it. But now you can actually play the games on the led-matrix (the rust package doesn't include controls for the games). I'm also working on the Framework system tools now, which should be more interesting for Framework 13 users.
You can test the package on the Framework 16 by installing python311-framework16_inputmodule and then running "ledmatrixctl" from the command line.
Update 3:
I packaged the framework_tool, a general application for interacting with the system. You can find it some detailed information what it can do here. On my system everything related to the embedded controller functionality doesn't work though, so some help testing and debugging would be appreciated.
Update 4:
Today I finished the qmk interface, which gives you a cli (and gui) to configure your Framework 16 keyboard. Sadly the Python gui is broken upstream, but I added the qmk_hid package with the cli and from my testing it works well.
Final Update:
All the interesting programs are now done, I decided to exclude the firmware for now since upstream also recommends using fwupd to update it. I will hack on more things related to the Framework Laptops in the future so if there are any ideas to improve the experience (or any bugs to report) feel free to message me about it.
As a final summary/help for everyone using a Framework Laptop who wants to use this software:
The source code for all packages can be found in repositories in the Framework organization on Github
All software can be installed from this repo (Tumbleweed)
The available packages are:
framework-inputmodule-control (FW16) - play with the inputmodules on your Framework 16 (b1-display, led-matrix, c1-minimal)
python-framework16_inputmodule (FW16) - same as inputmodule-control but is needed if you want to play and crontrol the built-in games in the led-matrix (call with ledmatrixctl or ledmatrixgui)
framework_tool (FW13 and FW 16) - use to see and configure general things on your framework system. Commands using the embedded controller might not work, it looks like there are some problems with the kernel module used by the EC. Fixing this is out of scope for this hackweek but I am working on it
qmk_hid (FW16) - a cli to configure the FW16 qmk keyboard. Sadly the gui for this is broken upstream so only the cli is usable for now
Packaging Mu on OBS by joeyli
Description
Packaging Microsoft Mu project
Goals
Packaging Mu RPM on OBS.
Resources
https://microsoft.github.io/mu/
https://github.com/microsoft/mu
https://github.com/microsoft/mu_basecore
https://github.com/microsoft/mutianoplatforms
https://github.com/microsoft/mutianoplus
https://github.com/microsoft/mu_plus
Hackweek 22: Look at Microsoft Mu project
https://hackweek.opensuse.org/22/projects/look-at-microsoft-mu-project
https://drive.google.com/file/d/1BT31i7z3qh13adj9pdRz3lTUkqIsXvjY/view?usp=drive_link
Switch software-o-o to parse repomd data by hennevogel
Currently software.opensuse.org search is using the OBS binary search for everything, even for packages inside the openSUSE distributions. Let's switch this to use repomd data from download.opensuse.org
Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil
Join the Gitter channel! https://gitter.im/uyuni-project/hackweek
Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!
Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.
For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.
No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)
The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.
To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):
- Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
- Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
- Package management (install, remove, update...)
- Patching
- Applying any basic salt state (including a formula)
- Salt remote commands
- Bonus point: Java part for product identification, and monitoring enablement
- Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
- Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
- Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)
If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)
- If you don't have knowledge about some of the steps: ask the team
- If you still don't know what to do: switch to another distribution and keep testing.
This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)
Pending
FUSS
FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.
https://fuss.bz.it/
Seems to be a Debian 12 derivative, so adding it could be quite easy.
[W]
Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)[W]
Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).[W]
Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.[I]
Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?[W]
Applying any basic salt state (including a formula)[W]
Salt remote commands[ ]
Bonus point: Java part for product identification, and monitoring enablement
Explore simple and distro indipendent declarative Linux starting on Tumbleweed or Arch Linux by janvhs
Description
Inspired by mkosi the idea is to experiment with a declarative approach of defining Linux systems. A lot of tools already make it possible to manage the systems infrastructure by using description files, rather than manual invocation. An example for this are systemd presets for managing enabled services or the /etc/fstab
file for describing how partitions should be mounted.
If we would take inspiration from openSUSE MicroOS and their handling of the /etc/
directory, we could theoretically use systemd-sysupdate
to swap out the /usr/
partition and create an A/B boot scheme, where the /usr/
partition is always freshly built according to a central system description. In the best case it would be possible to still utilise snapshots, but an A/B root scheme would be sufficient for the beginning. This way you could get the benefit of NixOS's declarative system definition, but still use the distros package repositories and don't have to deal with the overhead of Flakes or the Nix language.
Goals
- A simple and understandable system
- Check fitness of
mkosi
or write a simple extensible image builder tool for it - Create a declarative system specification
- Create a system with swappable
/usr/
partition - Create an A/B root scheme
- Swap to the new system without reboot (kexec?)
Resources
- Ideas that have been floating around in my head for a while
- https://0pointer.net/blog/fitting-everything-together.html
- GNOME OS
- MicroOS
- systemd mkosi
- Vanilla OS