Libyui REST API
In the previous hack week project I was focused on implementing a REST API for testing the YaST modules.
The major functionality of the REST API has been already implemented, the RPM packages are also available in openSUSE (see the libyui*-rest-api packages). What's missing? The REST API is not available in the openSUSE/SUSE installer. If you would like to test the installation workflow then you would need to build a Driver Update Disk with the REST API packages and all dependencies. That's not trivial and it might be even more complicated for some architectures like s390 or aarch64.
So the goal of this project is to include the packages in the default installer.
Details
OK, we should just add some more packages into the installer? It's not that simple. The libyui REST API is special and a vast majority of users do not need it. Actually it could be a problem because it would take the precious memory which we have during installation. The YaST installer must run even with 512MB memory (keep in mind that the installer itself is running from RAM disk) and with additional packages we might not fit into that limit anymore...
Proposed Solution
The installer allows using extensions, we already do that for the gdb tool. It's not included in the installer by default, if you run the gdb command it will fail.
But you can extend the installation system by calling extend gdb which will download the GDB image and mount it. Then you can use the GDB tool as usually.
We want to have this implemented also for the libyui REST API - by default it won't be included in the installer (saving space) but if needed it could be easily included with the extend libyui-rest-api call.
Looking for hackers with the skills:
This project is part of:
Hack Week 19
Activity
Comments
Be the first to comment!
Similar Projects
HTTP API for nftables by crameleon
Background
The idea originated in https://progress.opensuse.org/issues/164060 and is about building RESTful API which translates authorized HTTP requests to operations in nftables, possibly utilizing libnftables-json(5).
Originally, I started developing such an interface in Go, utilizing https://github.com/google/nftables. The conversion of string networks to nftables set elements was problematic (unfortunately no record of details), and I started a second attempt in Python, which made interaction much simpler thanks to native nftables Python bindings.
Goals
- Find and track the issue with google/nftables
- Revisit and polish the Go or Python code (prefer Go, but possibly depends on implementing missing functionality), primarily the server component
- Finish functionality to interact with nftables sets (retrieving and updating elements), which are of interest for the originating issue
- Align test suite
- Packaging
Resources
- https://git.netfilter.org/nftables/tree/py/src/nftables.py
- https://git.com.de/Georg/nftables-http-api (to be moved to GitHub)
- https://build.opensuse.org/package/show/home:crameleon:containers/pytest-nftables-container
Results
- Started new https://github.com/tacerus/nftables-http-api.
- First Go nftables issue was related to set elements needing to be added with different start and end addresses - coincidentally, this was recently discovered by someone else, who added a useful helper function for this: https://github.com/google/nftables/pull/342.
- Further improvements submitted: https://github.com/google/nftables/pull/347.
Side results
Upon starting to unify the structure and implementing more functionality, missing JSON output support was noticed for some subcommands in libnftables. Submitted patches here as well:
- https://lore.kernel.org/netfilter-devel/20251203131736.4036382-2-georg@syscid.com/T/#u