- ARCHIVED: Uyuni Development

[uyuni-devel] Re: [uyuni-users] Fwd: openSUSE 15.1 tools repo sync errors?
by Strahil Nikolov 23 Aug '19

23 Aug '19

On August 23, 2019 5:06:33 PM GMT+03:00, Boris Manojlovic <boris(a)steki.net> wrote: >kernel-default but it is multiple packages that will trigger this >(same update as in SLE SP1 in which i first noticed this issue with >this specific changelog entry ) > >sw:~ # cat /etc/*rele* >NAME="openSUSE Leap" >VERSION="15.1 " >ID="opensuse-leap" >ID_LIKE="suse opensuse" >VERSION_ID="15.1" >PRETTY_NAME="openSUSE Leap 15.1" >ANSI_COLOR="0;32" >CPE_NAME="cpe:/o:opensuse:leap:15.1" >BUG_REPORT_URL="https://bugs.opensuse.org" >HOME_URL="https://www.opensuse.org/" >Spacewalk release 4.0 (Smile) >sw:~ # rpm -q --changelog kernel-default |grep -A 5 -B1 >'reclaimed_journal_buckets' >* Mon Jul 15 2019 colyli(a)suse.de >- bcache: add reclaimed_journal_buckets to struct cache_set > (bsc#1140652). >- bcache: performance improvement for btree_flush_write() > (bsc#1140652). >- bcache: fix race in btree_flush_write() (bsc#1140652). >- bcache: remove retry_flush_write from struct cache_set >-- >* Mon Jul 15 2019 colyli(a)suse.de >- bcache: add reclaimed_journal_buckets to struct cache_set > (bsc#1140652). >- bcache: performance improvement for btree_flush_write() > (bsc#1140652). >- bcache: fix race in btree_flush_write() (bsc#1140652). >- bcache: remove retry_flush_write from struct cache_set >sw:~ # > >On Fri, Aug 23, 2019 at 12:46 AM Strahil Nikolov ><hunter86_bg(a)yahoo.com> wrote: >> >> >> On August 21, 2019 12:21:29 PM GMT+03:00, Boris Manojlovic ><boris(a)steki.net> wrote: >> >> >Hi list, >> > >> >reason why all of you had issues with updates from opensuse 15.1 is >> >kernel update that originated from suse sources (or someone made >> >exactly SAME kind of mistake) >> > >> >in source code (database code) you will find your mentioned unique >> >index creation code >> > >> >``` >> >CREATE UNIQUE INDEX rhn_pkg_clr_pid_cld_uq >> > ON rhnPackageChangeLogRec (package_id, changelog_data_id) >> > NOLOGGING >> > TABLESPACE [[32m_tbs]]; >> >``` >> > >> >so what happens in other part of code is next >> >get changelog data from rpm, insert it into db line by line (all >text >> >as one row per changelog entry ) >> >some other stuff in between >> >try adding rpm package changelog info into table as bellow >(arbitrary >> >values 10 and 3 just to show point) >> >``` >> >info into packagechangelogrec ( pkg_id=10 , chg_id=3 ,...); >> >info into packagechangelogrec ( pkg_id=10 , chg_id=3 ,...); <- >second >> >one fails with unique index problerm >> >` >> >insert will of course fail with given error (from log file pasted) >as >> >package has exactly same changelog entries. >> > >> >hope this helps someone in future to debug this kind of error >> > >> >P.S. >> >sorry for not responding to thread as is, simply was not subscribed >> >before :) >> > >> >P.P.S. >> > >> >Not sure list got it as i still did not confirm my subscription >before >> >sending... >> > >> > >> >Is it fixed, as I thought my Uyuni DB 'ended' and redeployed again >:) ? >> > >> >I will need to create all repos again. >> > >> >Best Regards, >> >Strahil Nikolov >> >> >> It's definitely not fixed: >> >> 01:39:50 01:39:50 Importing packages to DB: >Importing packages: >|--------------------------------------------------| 0.21% 01:41:24 >0.21 % Importing packages: >|--------------------------------------------------| 0.38% 01:42:40 >duplicate key value violates unique constraint "rhn_pkg_clr_pid_cld_uq" >DETAIL: Key (package_id, changelog_data_id)=(36047, 35803) already >exists. 01:42:40 Unexpected error: 01:42:40 Traceback (most recent call >last): File >"/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", >line 568, in sync ret = self.import_packages(plugin, data['id'], >url, is_non_local_repo) File >"/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", >line 1086, in import_packages importer.run() File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/importLib.py", >line 764, in run self.submit() File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/packageImport.py", >line 343, in submit transactional=self.transactional) File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 853, in processPackages transactional=transactional) File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 2158, in __processObjectCollection__ return self.__doDML(dml) >File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 2263, in __doDML self.__doInsert(dml.insert, dml.tables) >File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 2270, in __doInsert self.__doInsertTable(tname, dict) File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 2285, in __doInsertTable insertObj.query(hash) File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backendLib.py", >line 459, in query executeStatement(statement, values, chunksize) >File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backendLib.py", >line 484, in executeStatement count += >statement.executemany(**tempdict) File >"/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", >line 159, in executemany return >self._execute_wrapper(self._executemany, *p, **kw) File >"/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", >line 298, in _execute_wrapper retval = function(*p, **kw) File >"/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", >line 348, in _executemany self._real_cursor.executemany(self.sql, >all_kwargs) psycopg2.IntegrityError: duplicate key value violates >unique constraint "rhn_pkg_clr_pid_cld_uq" DETAIL: Key (package_id, >changelog_data_id)=(36047, 35803) already exists. >> >> Does anyone know the names of the offending packages ? >> >> Best Regards, >> Strahil Nikolov >-- >To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org >To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org Adding uyuni-devel list. I hope someone in the dev can assist us. 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

1 0

[uyuni-devel] Documentation Bug in Uyuni 4.0.2 Reference guide (PDF)
by Strahil Nikolov 05 Aug '19

05 Aug '19

Hello All, Can someone rebuild the reference guide for Uyuni 4.0.2 ,as there is a difference between the PDF and the HTML ? I have described the issue in : https://github.com/uyuni-project/uyuni-docs/issues/6 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

1 0

[uyuni-devel] New website and branding
by Julio Gonzalez 02 Aug '19

02 Aug '19

Together with the announcement of Uyuni 4.0.2 we are happy to present our new website and branding: https://www.uyuni-project.org/ You can also check the updated documentation as HTML, and with a search engine working at: https://www.uyuni-project.org/uyuni-docs/uyuni/index-uyuni.html What's more, you can even contribute to the documentation from there! We hope you will enjoy it, and we will be happy to receive your feedback and contributions. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Uyuni 4.0.2 is released!
by Julio Gonzalez 02 Aug '19

02 Aug '19

Hello everyone, We are happy to announce the immediate availability of Uyuni 4.0.2, our third Uyuni release! At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 4.0.2, including the release notes, documentation, requirements and setup instructions. ===================================== IMPORTANT: If you are migrating from 4.0.1 check the release notes [1], as a special procedure is needed for the server! ===================================== This is the list of highlights for this release: - Base system upgrade to openSUSE Leap 15.1 - Salt 2019.2.0 - Prometheus Monitoring - Content lifecycle management - Virtualization management for Salt minions - Updated Documentation Structure - Improved logging for Salt Remote Command Page - Support for more Distributions as Clients - EoL for openSUSE Leap 42.3 clients - Salt Rate Limiting (Batching) - Product Information Loaded from SCC - Image build host with SLES 12 SP4 - Updated backend for communicating with SCC - XMLRPC API changes - Support for Ubuntu Clients - Change behavior on token refresh - New option to force regeneration of channel metadata - New products supported - Package download endpoint override - Technical preview: Single Sign-On (SSO) Please check the release notes for full details. Remember that Uyuni follows a rolling release planning, so there will be no maintenance of 4.0.2, but a new version with bugfixes and most probably new features. We hope you will enjoy Uyuni 4.0.2 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/doc/4.0.2/release-notes-uyuni-server.html [2] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Re: [uyuni-users] need assistance with debugging bootstrap issues
by Strahil Nikolov 16 Jul '19

16 Jul '19

Hi Chris, thanks for your hint. I have tested adding a fresh openSUSE 15.1 and everything is fine until I have noticed that every minute the Uyuni is doing package refresh (8 refresh per minute) and never stops. Running it manually passes in 3.22s . Now I have to find the reason behind this constant running of package refresh. Adding uyuni-devel list. Best Regards, Strahil Nikolov В вторник, 9 юли 2019 г., 17:47:16 ч. Гринуич+3, Cristian Gherman <cristian.gherman(a)reea.net> написа: I had to change the id of minions in something: fe-1.blabla.com => fe-1-prod.blabla,com If I use previous names , they are not added to Uyuni any more. Cristian Gherman -------- Forwarded Message -------- Subject: Re: [uyuni-users] need assistance with debugging bootstrap issues Date: Tue, 9 Jul 2019 13:55:59 +0000 (UTC) From: Strahil Nikolov <hunter86_bg(a)yahoo.com> To: Cristian Gherman <cristian.gherman(a)reea.net> Hi Christian, thanks for the fast reply. Already done all of these. The new key is accepted , but the machines are not added. I even used "snapper" to rollback one of the VMs to openSUSE 15.0 in order to check bootstraping. The results are the same. Rebooting Uyuni doesn't solve the issue :) Any ideas appreciated. Best Regards, Strahil Nikolov В вторник, 9 юли 2019 г., 9:52:05 ч. Гринуич-4, Cristian Gherman <cristian.gherman(a)reea.net> написа: Hello, Can you try this: - remove minion key from master - stop the salt-minion on VM's - remove minion key from /etc/salt/pki/ - change the minion id in /etc/minion_id - change the machine id in /etc/machine-id with command systemd-machine-id-setup - start the salt-minion on VM's - accept new keys, check if minons is added on Uyuni This steps helped me with some stoborn minions some time ago. Cristian Gherman On 7/9/19 4:39 PM, Strahil Nikolov wrote: > Hello All, > can you assist me by guiding me in the correct direction? > Yesterday I found out that all my clients (4 openSUSE 15.1) are not reporting for the past 3 days.I tried to refresh , but it didn't do anything . > > Then I removed the VMs and tried to add them, but after accepting the salt key - the VM is not added as a system. > I have checked the logs and I see a lot of errors , one of them is : > 2019-07-09 16:26:24,719 [salt-event-thread-1] ERROR com.suse.manager.reactor.PGEventListener - Unexpected exception while executing a MessageAction com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $ > at com.google.gson.Gson.fromJson(Gson.java:900) > at com.google.gson.Gson.fromJson(Gson.java:953) > at com.suse.manager.reactor.messaging.JobReturnEventMessageAction.lambda$execute$7(JobReturnEventMessageAction.java:128) > at java.util.Optional.ifPresent(Optional.java:159) > at com.suse.manager.reactor.messaging.JobReturnEventMessageAction.execute(JobReturnEventMessageAction.java:114) > at com.suse.manager.reactor.PGEventListener.lambda$null$1(PGEventListener.java:74) > at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) > at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) > at com.suse.manager.reactor.PGEventListener.lambda$notify$2(PGEventListener.java:72) > at java.util.stream.Streams$StreamBuilderImpl.forEachRemaining(Streams.java:419) > at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) > at com.suse.manager.reactor.PGEventListener.notify(PGEventListener.java:69) > at com.suse.salt.netapi.event.AbstractEventStream.notifyListeners(AbstractEventStream.java:64) > at com.suse.manager.reactor.PGEventStream.lambda$processEvents$3(PGEventStream.java:147) > at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:352) > at java.util.stream.Sink$ChainedReference.end(Sink.java:258) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483) > at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) > at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) > at com.suse.manager.reactor.PGEventStream.processEvents(PGEventStream.java:141) > at com.suse.manager.reactor.PGEventStream.lambda$null$0(PGEventStream.java:127) > at com.redhat.rhn.frontend.events.TransactionHelper.run(TransactionHelper.java:62) > at com.redhat.rhn.frontend.events.TransactionHelper.handlingTransaction(TransactionHelper.java:46) > at com.suse.manager.reactor.PGEventStream.lambda$notification$2(PGEventStream.java:126) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $ > at com.google.gson.internal.bind.JsonTreeReader.expect(JsonTreeReader.java:161) > at com.google.gson.internal.bind.JsonTreeReader.beginObject(JsonTreeReader.java:87) > at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:183) > at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145) > at com.google.gson.Gson.fromJson(Gson.java:888) > ... 30 more > 2019-07-09 16:26:24,719 [salt-event-thread-4] ERROR com.redhat.rhn.frontend.events.TransactionHelper - java.lang.ClassCastException 2019-07-09 16:26:24,719 [salt-event-thread-4] ERROR com.redhat.rhn.frontend.events.TransactionHelper - Additional Exception during Exception handling java.lang.ClassCastException > 2019-07-09 16:26:24,720 [salt-event-thread-3] ERROR com.redhat.rhn.frontend.events.TransactionHelper - java.lang.ClassCastException 2019-07-09 16:26:24,719 [salt-event-thread-1] ERROR com.redhat.rhn.frontend.events.TransactionHelper - com.suse.manager.reactor.PGEventListenerException > 2019-07-09 16:26:24,720 [salt-event-thread-5] ERROR com.redhat.rhn.frontend.events.TransactionHelper - com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected NUMBER but was BEGIN_OBJECT at path $.retcode > > Any ideas how to debug this one? Which logs should I check ? > Maybe someone has already had a similar situation... > > Best Regards, > Strahil Nikolov -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 3

[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

[uyuni-devel] Looking for a way to automate the first organization creation
by Stankowic, Christian 14 Nov '18

14 Nov '18

Hello Uyuni team! I'm currently writing a Chef cookbook for automating Uyuni test deployments. After installing Uyuni, the first organization still needs to be created using the web page. I understand that there is an automation tool spacecmd, but this seems not to work if no organization or admin user exist: # spacecmd org_create Spacewalk Username: Spacewalk Password: ERROR: Invalid credentials I figured out that entering no username/password does not work (also not via the .spacecmd/config file) - so therefore the error message seems legit. My question is now: how can I automate this? I cannot used the web page in an automated manner. Is there an option for the /root/setup_env.sh file? Thanks a lot in advance - also keep up the good work! Best wishes, Christian Stankowic

5 7

[uyuni-devel] Re: [uyuni-announce] Upgrade Question from Beta to Stable
by Julio González Gil 01 Nov '18

01 Nov '18

Hi Bernd, First of all, thanks for trying out Uyuni! I am moving this thread to uyuni-devel since list is supposed to be only for announces. Best regards. On jueves, 1 de noviembre de 2018 10:55:38 (CET) Bernd Helber wrote: > Hi Uyuni Team, > > impressed by the Stability of the Beta Product, > > i tried to give the Upgrade from Beta to Stable a Shot. > > > What i did so far... > > 1st removed the Beta Repos > > 2nd added the Uyuni Stable Reps > > 3rd Database Hot Backup from the Existing Installation. > > smdba backup-hot --backup-dir=/var/spacewalk/db-backup > > zypper dup (Vendor got changed succesfully) > > spacewalk-service stop > > Postgres was running as it should be. > > THe issue i had to face covers the Topic Schema Upgrade. > > > > # spacewalk-schema-upgrade > Schema upgrade: [susemanager-schema-3.2.10-320.1.2.develHead] -> > [susemanager-schema-4.0.2-1.1] > Searching for upgrade path to: [susemanager-schema-4.0.2-1.1] > Searching for upgrade path to: [susemanager-schema-4.0.2] > Searching for start path: [susemanager-schema-3.2.10-320.1.2] > Searching for start path: [susemanager-schema-3.2.10] > Was not able to find upgrade path in directory > [/etc/sysconfig/rhn/schema-upgrade]. > > Do you guys have an Advice for me, to get this fixed? > > With kind regards. > > Bernd Helber -- 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)

2 2

[uyuni-devel] Uyuni 4.0.0 is released!
by Julio González Gil 26 Oct '18

26 Oct '18

Hello everyone, We are happy to announce the immediate availability of Uyuni 4.0.0, our first 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:/Master… - openSUSE Leap 15.0 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - SLE12 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - SLE15 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - CentOS6 (i686, x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - CentOS7 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… At https://www.uyuni-project.org/stable-version.html you will find all the resources you need to start working with Uyuni 4.0.0, including the release notes, documentation, requirements and setup instructions. For this first release, all the functionality of Uyuni Server and Uyuni proxy is ready, and only certain clients distributions have some functionality restricted, or untested (but most probably should work). We hope to test and fix everything during the following releases. Remember that Uyuni will follow a rolling release planning, so next version will be 4.0.1 with bugfixes and features, and there will be no maintenance of 4.0.0. If you are wondering why 4.0.0 if it is the first release, please the FAQ, as it explains everything: https://www.uyuni-project.org/faq.html#first-version We hope you will enjoy Uyuni 4.0.0 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

[uyuni-devel] Welcome to the uyuni-devel mailing list!
by Julio González Gil 14 Sep '18

14 Sep '18

This message serves to test that the list is working fine, and to give you a warm welcome! This is the list where we will be discussing Uyuni development stuff with all developers. Anyone can post to this list as long as it is registered. Enjoy! -- 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