A web frontend for the mirrors in the mirrorbrain database to allow the mirror admins to manage their entries themself.

You might know MirrorBrain already: our download redirector and Torrent/Metalink generator used u.a. on download.opensuse.org. It's really a great tool that plays a hidden key role inside the openSUSE infrastructure.

But while the amount of openSUSE mirrors is increasing over the time (currently we have >180 mirrors in our database!), the amount of main administrators for the database itself is not increasing as well.

It happens, that mirrors want to limit the traffic for a specific time (means for us: decreasing the score of this specific mirror) or changing their setup (means for us: adapting the URLs for FTP, HTTP, rsync or the operator Name and Url - or even the Name and Email of the mirror admin). Not thinking about the work for adding new mirrors or removing old ones. Sometimes it might also be enough to disable a mirror for a short time - and re-enable it after the maintenance work is done. All this is currently done manually on request via mail to admin@opensuse.org or mirror@opensuse.org

But as most of the stuff above only affects single mirrors that are already maintained by people who should know what they are doing, why not allowing them to do the requested steps on their own?

Maybe they can even trigger a "rescan" of their mirror once it is added - or something has changed/fixed?

Wouldn't this be cool?

We guess: yes!

Looking for hackers with the skills:

postgresql ruby rails mirrorbrain python perl css html5

This project is part of:

Hack Week 10 Hack Week 11

Activity

  • about 10 years ago: abodry joined this project.
  • about 11 years ago: lrupp added keyword "css" to this project.
  • about 11 years ago: lrupp added keyword "html5" to this project.
  • about 11 years ago: lrupp added keyword "perl" to this project.
  • about 11 years ago: lrupp added keyword "python" to this project.
  • about 11 years ago: lrupp added keyword "mirrorbrain" to this project.
  • about 11 years ago: lrupp added keyword "rails" to this project.
  • about 11 years ago: lrupp added keyword "postgresql" to this project.
  • about 11 years ago: lrupp added keyword "ruby" to this project.
  • about 11 years ago: lrupp liked this project.
  • about 11 years ago: lrupp joined this project.
  • about 11 years ago: tampakrap liked this project.
  • about 11 years ago: jnweiger left this project.
  • about 11 years ago: jnweiger joined this project.
  • about 11 years ago: jnweiger left this project.
  • about 11 years ago: jnweiger joined this project.
  • about 11 years ago: jnweiger liked this project.
  • about 11 years ago: darix started this project.
  • about 11 years ago: hennevogel left this project.
  • about 11 years ago: hennevogel started this project.
  • about 11 years ago: hennevogel left this project.
  • about 11 years ago: hennevogel started this project.
  • about 11 years ago: darix originated this project.

  • Comments

    • lrupp
      about 11 years ago by lrupp | Reply

      • Initial code is now at https://github.com/openSUSE/mirrorpinky - thanks to Darix for the new project!
      • Communication with upstream via mailing list looks currently broken (no mail delivery, no error messages) - working on this topic in parallel

    • darix
      about 11 years ago by darix | Reply

      Ported to rails 4!

    • lrupp
      about 11 years ago by lrupp | Reply

      Big progress today: Big progress today: * mirrors are listed like on mirrors.opensuse.org but with additional filters (distribution, region and markers), which makes it easier for customers to find "their" mirror * each mirror belongs at least to one admin-group * users in such a group can edit the mirror data * the entered data is validated * the page to register a new mirror is prepared

      TO DO: * finish the backend parts to create a new mirror (getting Geo-based UP information, incl. ASN data and prefixes from entered data and more validation) * log all changes * do we need a "go back" button? * add delete button for mirrors * add additional tools like a search engine, "scan now" button, ... * clean-up css and html templates * write a script to create groups and users from current data and assign them to the right servers

      So there is still a lot to do, but important basics are there now and we might be able to have something to present real soon!

    • lrupp
      about 11 years ago by lrupp | Reply

      adding additional fields for public comments and IP addresses for the scanner is also an interesting point...

    • lrupp
      about 11 years ago by lrupp | Reply

      Done:

      • creating and deleting a mirror works now (thanks to darix!)
      • enhanced the web page layout, to have more space for the important data
      • merged rails4 branch with master => we will not "ship" a rails3 version any more
      • providing a small Google map for the Geo Location of a server

      ToDo:

      • write a script to create groups and users from current data and assign them to the right servers
      • add additional tools like a search engine, "scan now" button, ...
      • log all changes * do we need a "go back" button?
      • allow users to search for a specific server
      • add additional field for "rsync from" addresses, so admins can add the origin IP addresses their servers use to sync from stage.opensuse.org

    Similar Projects

    Recipes catalog and calculator in Rails 8 by gfilippetti

    My wife needs a website to catalog and sell the products of her upcoming bakery, and I need to learn and practice modern Rails. So I'm using this Hack Week to build a modern store using the latest Ruby on Rails best practices, ideally up to the deployment.

    TO DO

    • Index page
    • Product page
    • Admin area -- Supplies calculator based on orders -- Orders notification
    • Authentication
    • Payment
    • Deployment

    Day 1

    As my Rails knowledge was pretty outdated and I had 0 experience with Turbo (wich I want to use in the app), I started following a turbo-rails course. I completed 5 of 11 chapters.

    Day 2

    Continued the course until chapter 8 and added live updates & an empty state to the app. I should finish the course on day 3 and start my own project with the knowledge from it.

    Hackweek 24

    For this Hackweek I'll continue this project, focusing on a Catalog/Calculator for my wife's recipes so she can use for her Café.

    Day 1


    Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

    Description

    "LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

    However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

    The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

    Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

    Goals

    Goals of this project:

    • Modify the RSpec tests and run them against a real LDAP server
    • Replace the net-ldap rubygem with the ruby-ldap rubygem

    Achieving the above mentioned goals will:

    • Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
    • Make a step towards officially supporting LDAP in OBS.

    Resources


    Recipes catalog and calculator in Rails 8 by gfilippetti

    My wife needs a website to catalog and sell the products of her upcoming bakery, and I need to learn and practice modern Rails. So I'm using this Hack Week to build a modern store using the latest Ruby on Rails best practices, ideally up to the deployment.

    TO DO

    • Index page
    • Product page
    • Admin area -- Supplies calculator based on orders -- Orders notification
    • Authentication
    • Payment
    • Deployment

    Day 1

    As my Rails knowledge was pretty outdated and I had 0 experience with Turbo (wich I want to use in the app), I started following a turbo-rails course. I completed 5 of 11 chapters.

    Day 2

    Continued the course until chapter 8 and added live updates & an empty state to the app. I should finish the course on day 3 and start my own project with the knowledge from it.

    Hackweek 24

    For this Hackweek I'll continue this project, focusing on a Catalog/Calculator for my wife's recipes so she can use for her Café.

    Day 1


    Use local/private LLM for semantic knowledge search by digitaltomm

    Description

    Use a local LLM, based on SUSE AI (ollama, openwebui) to power geeko search (public instance: https://geeko.port0.org/).

    Goals

    Build a SUSE internal instance of https://geeko.port0.org/ that can operate on internal resources, crawling confluence.suse.com, gitlab.suse.de, etc.

    Resources

    Repo: https://github.com/digitaltom/semantic-knowledge-search

    Public instance: https://geeko.port0.org/

    Results

    Internal instance:

    I have an internal test instance running which has indexed a couple of internal wiki pages from the SCC team. It's using the ollama (llama3.1:8b) backend of suse-ai.openplatform.suse.com to create embedding vectors for indexed resources and to create a chat response. The semantic search for documents is done with a vector search inside of sqlite, using sqlite-vec.

    image


    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):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. 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)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. 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


    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/


    Team Hedgehogs' Data Observability Dashboard by gsamardzhiev

    Description

    This project aims to develop a comprehensive Data Observability Dashboard that provides r insights into key aspects of data quality and reliability. The dashboard will track:

    Data Freshness: Monitor when data was last updated and flag potential delays.

    Data Volume: Track table row counts to detect unexpected surges or drops in data.

    Data Distribution: Analyze data for null values, outliers, and anomalies to ensure accuracy.

    Data Schema: Track schema changes over time to prevent breaking changes.

    The dashboard's aim is to support historical tracking to support proactive data management and enhance data trust across the data function.

    Goals

    Although the final goal is to create a power bi dashboard that we are able to monitor, our goals is to 1. Create the necessary tables that track the relevant metadata about our current data 2. Automate the process so it runs in a timely manner

    Resources

    AWS Redshift; AWS Glue, Airflow, Python, SQL

    Why Hedgehogs?

    Because we like them.


    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"


    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

    Results

    Created WIP project Ansible-add-on-openSUSE


    Create object oriented API for perl's YAML::XS module, with YAML 1.2 Support by tinita

    Description

    YAML::XS is a binding to libyaml and already quite old, but the most popular YAML module for perl. There are two main issues:

    • It uses global package variables to influence behaviour.
    • It didn't implement the loading of types like numbers and booleans according to the YAML spec (neither 1.1 nor 1.2).

    Goals

    Create a new interface which works object oriented. Currently YAML::XS exports a list of functions.

    • The new API will allow to create a YAML::XS object containing configuration influencing the behaviour of loading and dumping.
      • It keeps the libyaml parser and emitter structs in memory, so repeated calls can save the creation of those structs
    • It will by default implement the YAML 1.2 Core Schema, so it is compatible to other YAML processors in perl and in other languages
    • If I have time, I would like to add the merge << key feature as an option. We could then use it in openQA as a replacement for YAML::PP to be faster.

    I already created a proof of concept with a minimal functionality some weeks before this HackWeek.

    Resources