- ARCHIVED: Uyuni Development

[uyuni-devel] Uyuni 4.0.1 Configuration files - schedule a check
by Strahil Nikolov 10 Jun '19

10 Jun '19

Hello Community, I have setup a system with a centrally managed configuration file (/etc/motd) and when applying high state - it gets deployed. I checked the taskomatic and there is a job for checking (compare-configs-default) which properly detects a difference from centrally managed file and local one . Can someone hint me , how can I schedule a task so the files that diff to be replaced with the centrally managed one (from uyuni) - so if I edit /etc/motd locally -> the file to be restored on a schedule ? If there is no such option , is it currently under development ? Thanks in advance. Best Regards, Strahil Nikolov -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

3 4

[uyuni-devel] Uyuni Master (development) is now based on openSUSE Leap 15.1
by Julio González Gil 05 Jun '19

05 Jun '19

Hello, In preparation for the next release of Uyuni, we switched the base OS for Master (the development version) Server and Proxy to openSUSE Leap 15.1 https://www.uyuni-project.org/devel-version.html is now updated showing this. For new installations, please use the new repositories. For older installations remember that updating is not supported, but if you still want to try, replace the repositories at /etc/zypper/repos.d and adjust your synced repositories the server. Please remember that Uyuni Master is intended for development and testing, and not for production. We cannot still give you an exact date for release of the next version, but we expect to have it ready in the next two to four weeks, and it will have big new features such as support for Ubuntu clients, monitoring with prometheus and grafana and much more. Stay tuned! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Feature request: Add missing Debian headers to repository metadata before signing
by Robert Paschedag 27 May '19

27 May '19

Hello Uyuni devel, this is a feature request for sysadmins, managing Debian / Ubuntu systems with Uyuni. Although there has been a lot of work to support Ubuntu / Debian, there is still some major thing missing. Several metadata headers are missing for Debian packages, that causes major issues on Debian / Ubuntu systems. One header is the "Multi-Arch" header, that is missing. This missing header causes packages to be installable over and over again. "apt" does not correctly "get it", that this package is already the newest installed and suggests these packages when searching for updates all the time. Also some dependencies cannot be successfully solved, because of this missing header. So the workaround most Debian / Ubuntu admins are doing right now, is to - sync the data into Uyuni - wait for spacewalk to generate the "Packages.gz" file - start - possibly below - script to add the missing "Multi-Arch" header to the "Packages.gz" file - sign the file Currently, I don't think that there are any efforts to tune the Uyuni database to also support the missing headers of Debian packages. So a further workaround could be to include such a script to add the missing headers "while or after" the "Packages.gz" gets created (or has been created), but before the file gets "signed". This could be added somewhere within the "DebRepositoryWriter.java" file, where the "signing" of the channel starts. First, I only had written a script to only add the "Multi-Arch" header. But this script below adds all headers missing for a packages. For this to work, you - of course - need the original "Packages.gz" file from Debian / Ubuntu with *all* headers present. Think about it. Would be cool, if this part could also be integrated into Uyuni. Just an idea and still used as workaround.... Best regards, Robert #!/usr/bin/env python -tt # Basically, this should only add one major header # 'Multi-Arch' to the Debian Packages file, but now # we add all missing headers. # # This only works correctly, if you are syncing the Debian repos # directly to one channel within Spacewalk or Uyuni # # You also need python-debian (which is installed on # Spacewalk server) to run this script # # Author: Robert Paschedag <robert.paschedag(a)netlution.de> # Version: 20181107 import sys import os from debian.deb822 import * if len(sys.argv) < 3: print "Usage: %s <path_to_unzipped_Packages_from_Spacewalk_Uyuni> <path_to_original_Debian_repo>" % sys.argv[0] sys.exit(1) spacewalk_file = sys.argv[1] original_file = sys.argv[2] if not os.path.isfile(spacewalk_file): print "Error: Inputfile '%s' not available." % spacewalk_file sys.exit(1) if not os.path.isfile(original_file): print "Error: Inputfile '%s' not available." % original_file sys.exit(1) spacewalk_packages = {} original_packages = {} with open(spacewalk_file, 'r') as pkgs: for pkg in Packages.iter_paragraphs(pkgs): spacewalk_packages[pkg['Package'] + pkg['Version'] + pkg['Architecture']] = pkg with open(original_file, 'r') as orig_file: for pkg in Packages.iter_paragraphs(orig_file): p = pkg['Package'] v = pkg['Version'] a = pkg['Architecture'] if spacewalk_packages.has_key(p + v + a): # found package. Check for missing headers for header in pkg.keys(): if not header in spacewalk_packages[p + v + a].keys(): spacewalk_packages[p + v + a][header] = pkg[header] # open new file new_package = open(spacewalk_file + '.new', 'w') for pkg in spacewalk_packages.values(): pkg.dump(new_package) new_package.write("\n") new_package.close() sys.exit(0) uyuni-test:/usr/local/sbin # -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

3 4

[uyuni-devel] Feature: Please add opensuse 15.1 to bootstrap
by Strahil Nikolov 25 May '19

25 May '19

Hello Users,Dev, I have modified my '/usr/share/susemanager/mgr_bootstrap_data.py' in order to bootstrap openSUSE Leap 15.1 , but it will be nice if in the next versions we have that out of the box.I haven't tested my modifications, but I will keep you updated. Do you see any issues with my modification? Here is what I got for openSUSE 15.X: openSUSE-Leap-15.0-x86_64' : { 'BASECHANNEL' : 'opensuse_leap15_0-x86_64', 'PKGLIST' : PKGLIST15 + PKGLIST15_NO_Z, 'DEST' : '/srv/www/htdocs/pub/repositories/opensuse/15/0/bootstrap/' }, 'openSUSE-Leap-15.1-x86_64' : { 'BASECHANNEL' : 'opensuse_leap15_1-x86_64', 'PKGLIST' : PKGLIST15 + PKGLIST15_NO_Z, 'DEST' : '/srv/www/htdocs/pub/repositories/opensuse/15/1/bootstrap/' }, Best Regards, Strahil Nikolov -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

2 2

[uyuni-devel] New RFC proposed: Migrating to DNF for managing RPM content
by Neal Gompa 04 Apr '19

04 Apr '19

Hey all, As I mentioned in my previous mail[0], I have been working on making Uyuni work on CentOS and Fedora servers. I was frustrated by the migration to Zypper, but now it became more serious than that. My recent experiments with integrating Fedora releases and RHEL 8 beta has become tremendously more difficult due to incomplete and improper handling of RH/Fedora modules. I've filed issues related to these two problems[1][2], but I've also decided to try to take advantage of the new RFC process introduced last month[3]. In order to fix these problems and to open the door to future features that would benefit people wanting to manage Linux distributions that use RH/Fedora modularity technology, I have proposed an RFC to migrate the underlying repository sync and dependency resolver code for RPM content to DNF[4]. The details about the proposal are in the pull request referenced. The highlights: * YUM is dead and removed in Fedora and DNF is officially part of RHEL/CentOS 7 now * Zypper and YUM both do the wrong things for handling new RH/Fedora releases. * DNF is available for SUSE distributions, with support for handling RH/Fedora modules * This should be a fairly painless migration, though there are a couple of open questions related to handling legacy metadata and some extra metadata. Please take a look! I'd greatly appreciate your feedback in the pull request. Thanks in advance and best regards, Neal [0]: https://lists.opensuse.org/uyuni-devel/2019-01/msg00000.html [1]: https://github.com/uyuni-project/uyuni/issues/804 [2]: https://github.com/uyuni-project/uyuni/issues/805 [3]: https://lists.opensuse.org/uyuni-devel/2019-03/msg00000.html [4]: https://github.com/uyuni-project/uyuni-rfc/pull/4 -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 0

[uyuni-devel] Build repositories for openSUSE 42.3
by Robert Paschedag 28 Mar '19

28 Mar '19

Hi all, I already asked several times several weeks ago within the chat but I still have problems. I have a test uyuni server (4.0.1) running on openSUSE 42.3. Now I want to build new packages based on the "ubuntu-support" branch since there has been a lot of work in the last weeks and I want to test these improvements, since we are currently running Spacewalk 2.7 with a lot of Debian clients and are planning (or at least thinking about) migrating to Uyuni (to also get Salt). Now I also have a "build system" also based on openSUSE 42.3. But it seems that at least one "build repository" seems to be missing. Trying to build "spacewalk-backend" returns uyuni-build:~/git/uyuni/backend # rpmbuild -bb spacewalk-backend.spec error: Failed build dependencies: python2-spacewalk-usix is needed by spacewalk-backend-4.0.7-1.noarch python2-gzipstream is needed by spacewalk-backend-4.0.7-1.noarch python2-rhn-client-tools is needed by spacewalk-backend-4.0.7-1.noarch python2-rhnlib >= 2.5.74 is needed by spacewalk-backend-4.0.7-1.noarch My current list of repos. I know, there is missing but I did not find the above mentioned packages around the build.opensuse.org system (or I really overlooked something). uyuni-build:~/git/uyuni/backend # zypper lr Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh ---+----------------------------------+-----------------------------------------+---------+-----------+-------- 1 | openSUSE-Leap-42.3-0 | openSUSE-Leap-42.3-0 | Yes | (r ) Yes | Yes 2 | repo-debug | openSUSE-Leap-42.3-Debug | No | ---- | ---- 3 | repo-debug-non-oss | openSUSE-Leap-42.3-Debug-Non-Oss | No | ---- | ---- 4 | repo-debug-update | openSUSE-Leap-42.3-Update-Debug | No | ---- | ---- 5 | repo-debug-update-non-oss | openSUSE-Leap-42.3-Update-Debug-Non-Oss | No | ---- | ---- 6 | repo-non-oss | openSUSE-Leap-42.3-Non-Oss | Yes | (r ) Yes | Yes 7 | repo-oss | openSUSE-Leap-42.3-Oss | Yes | (r ) Yes | Yes 8 | repo-source | openSUSE-Leap-42.3-Source | No | ---- | ---- 9 | repo-source-non-oss | openSUSE-Leap-42.3-Source-Non-Oss | No | ---- | ---- 10 | repo-update | openSUSE-Leap-42.3-Update | Yes | (r ) Yes | Yes 11 | repo-update-non-oss | openSUSE-Leap-42.3-Update-Non-Oss | Yes | (r ) Yes | Yes 12 | uyuni-master_leap42_client-tools | uyuni-master_leap42_client-tools | Yes | (r ) Yes | No uyuni-build:~/git/uyuni/backend # Where do I find the needed repositories for openSUSE 42.3 to be able to successfully build all "changed" packages? Thanks Robert -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

2 5

[uyuni-devel] Uyuni RFCs are now available for the community
by Julio González Gil 21 Mar '19

21 Mar '19

Hello, We are happy to announce that all the RFCs (Requests For Comments) for Uyuni are now available at https://github.com/uyuni-project/uyuni-rfc As described at the repository: > The "RFC" (request for comments) process is intended to provide a consistent > and controlled path for such substantial changes to enter the project. This > process will be adjusted over time as more features are implemented and the > community settles on specific approaches to feature development. And as discussed at uyuni-devel mailing list [1], we are publishing not only so you can check those that already exist and are archived, but so the community can also participate in future RFCs. If you want to start a RFC, we strongly suggest starting an initial discussion at the uyuni-devel mailing list [2]. Remember that the procedure is described at the README.md file at https://github.com/uyuni-project/uyuni-rfc Next step will be managing all of our issues directly at the Uyuni repository (I will provide a schedule as soon as I have one). Happy hacking! [1] https://lists.opensuse.org/uyuni-devel/2019-02/msg00000.html [2] https://lists.opensuse.org/uyuni-devel -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] About Uyuni development decisionmaking
by Neal Gompa 08 Feb '19

08 Feb '19

Hey all, So I've been following the development of Uyuni in parallel to the Spacewalk development for the past few months. I've been glad to see that both projects are showing a steady state of development, and Uyuni development is evenly paced. However, there have been some (IMO) major disappointments in how the development process for Uyuni is going, which all seem to stem from a foundational issue: It is fundamentally impossible for me to figure out what is going on as you guys are developing and merging in code. The main "symptoms" of this opaque development process: * Pull requests are referencing issues that exist in a private repository (SUSE/spacewalk), which presumably is the SUSE Manager codebase. This means that many pull requests have no context for external (i.e. non-SUSE) contributors to review. * Changes are being made with no obvious indicator of why they are happening, and the way the developers are committing to the codebase makes it impossible to divine any useful understanding. The style of just slamming out change after change with inscrutable commit messages really makes it hard to figure out what the meaningful change even is! * To my surprise, there is apparently an RFC process for figuring out major decisions. Unfortunately, external contributors have no opportunity to weigh in and help with those decisions. This is because that process is completely private and not open for public discussion. This means that by the time external contributors can react, it's already been implemented and there's no time anymore, which means we're stuck with a potentially bad decision due to incomplete information. Each of these things have happened during my time observing the Uyuni project. That said, it's not like Spacewalk is too much better, but we should aim for better no matter what! This most recently was a problem for me because I had been slowly examining the effort required to run Uyuni on Fedora and CentOS and I kept getting broken by changes done before I had any time to react. The most recent one completely broke everything for me[1], and had I known they were trying to decide on an approach to solve that, I would have given them a better strategy that would have worked on CentOS/RHEL 7, Fedora, openSUSE Leap 15.0, and SUSE Linux Enterprise 15. However, I didn't know until it was literally about to be merged, which is a terrible way to find these things out. This change exhibits the characteristics of all the problems I described earlier, because the way changes were done means that reverting this and doing it right will be extraordinarily painful _for me_, and it shows some callousness for the community, because we have no opportunity to be part of the project. Julio and Pablo (cc'd to this email) have already affirmed to me that they'll reconsider their approach so that this is unbroken. But this development process needs to change. It's too daunting for me to track and work with (and I'm pretty experienced at this stuff!). I worry that it's even scarier for people less versed in these kinds of projects. I know that in a lot of projects, I wind up being the token "community guy". And I'm okay playing that role for a while, if I can help make a project become good enough that it can start attracting a community to sustain itself. I've done this for a number of projects over the years, and I'm okay with doing this. But I don't want to be only community person forever, and the only way that will improve is if the development process improves. All the best, Neal [1]: https://github.com/uyuni-project/uyuni/pull/527 -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

3 3

[uyuni-devel] Client tools question
by Thomas Sundell 20 Dec '18

20 Dec '18

Hi, we are in the process of setting up a SES cluster and planning on using Uyuni to deploy SLES12 and provide SLES12+SES5 packages/patches using traditional client mode to our SES nodes. I'm trying to create a bootstrap repo but it complains about missing packages: mgr-create-bootstrap-repo -l 1. SLE-12-SP3-x86_64 mgr-create-bootstrap-repo -c SLE-12-SP3-x86_64 ERROR: package 'hwdata' not found ERROR: package 'libnewt0_52' not found ERROR: package 'newt' not found ... ERROR: package 'salt' not found ERROR: package 'salt-minion' not found ERROR: package 'python2-salt' not found My guess is that I need to setup "Client Tools" for SLE12 but I can't find anything about that in the documentation. Do I simply create a new channel with SLES12SP3-Pool as parent and add https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… as a repository to that channel or? Have a nice day! Thomas -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

4 7

[uyuni-devel] Uyuni 4.0.1 is released!
by Julio González Gil 20 Dec '18

20 Dec '18

Hello everyone, We are happy to announce the immediate availability of Uyuni 4.0.1, our second Uyuni release! Repositories: - Server: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - Proxy: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - openSUSE Leap 42.3 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - openSUSE Leap 15.0 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - SLE12 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - SLE15 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - CentOS6 (i686, x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - CentOS7 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… At https://www.uyuni-project.org/stable-version.html you will find all the resources you need to start working with Uyuni 4.0.1, including the release notes, documentation, requirements and setup instructions. Remember you can find the update instructions at the Best Practices guide. This is the list of highlights for this release: - Support for PostgreSQL 10 - spacecmd: Support state channels (aka Salt Minion config channels) - spacecmd: New API calls and spacecmd commands to merge packages and errata. - spacewalk-common-channels: Support for Uyuni, Fedora 29 and cleanup - openSUSE Leap 42.3/15.0, SLE12/15 and CentOS6 have now full support as salt, salt-ssh and traditional clients (Client Tools are still Beta) - New products added to SCC syncing Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so next version will be 4.0.2 with bugfixes and features, and there will be no maintenance of 4.0.1. We hope you will enjoy Uyuni 4.0.1 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/contact.html -- Julio González Gil <jgonzalez(a)suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

1 0