September 2019 - Uyuni Users - openSUSE Mailing Lists

[uyuni-users] spacecmd: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1: ordinal not in range(128)
by Haupt, Torsten 27 Sep '19

27 Sep '19

Hello, the spacecmd command doesn't work anymore on my uyuni server. I get the following error: Welcome to spacecmd, a command-line interface to Spacewalk. Type: 'help' for a list of commands 'help <cmd>' for command-specific help 'quit' to quit Traceback (most recent call last): File "/usr/bin/spacecmd", line 193, in <module> if not shell.do_login(''): File "/usr/lib/python3.6/site-packages/spacecmd/misc.py", line 384, in do_login self.load_caches(server, username) File "/usr/lib/python3.6/site-packages/spacecmd/misc.py", line 722, in load_caches load_cache(self.system_cache_file) File "/usr/lib/python3.6/site-packages/spacecmd/utils.py", line 119, in load_cache data = pickle.load(inputfile) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1: ordinal not in range(128) Greets Torsten Haupt -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 4

[uyuni-users] http download is not possible from uyuni server
by Kaercher, Alexander 26 Sep '19

26 Sep '19

Hello @all, Since the update I'm not able to down via http request the bootstrap script from the uyuni server. If I try to download it over wget , I see only that the HTTP request get an OK back, but no download is running. The resolve of the DNS is successfully. On the uyuni is no firewall running. HTTPS requests are successfully. No error message in /var/log/apache2/* No error message in /var/log/tomcat/* No error message in /var/log/rhn/* Uyuni version: 4.0.2 Wget from client: --2019-09-25 16:01:44-- (try:20) http://uyuni/pub/bootstrap/bootstrap.sh Connecting to uyuni (xxxxxxxxx)|xxx.xxx.xxx.xxx|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 27178 (27K) [application/x-shellscript] Saving to: 'bootstrap.sh.1' 0% [ ] 0 --.-K/s in 0s 2019-09-25 16:01:44 (0.00 B/s) - Connection closed at byte 0. Giving up. Did someone has an idea where I can found an error message to solve the issue ? Mit freundlichen Grüßen / With kind regards Alexander Kärcher Delivery Manager Linux/unix and Datamanagement DXC Technology Germany Faktorhaus, Berliner Platz 1, 67056 Ludwigshafen T +49 621 48187569 M +49 1525 47 54976 alexander.kaercher(a)dxc.com Planed absence: xx.xx.2019 - xx.xx.2019 EntServ Deutschland GmbH Schickardstr. 32 71034 Böblingen dxc.technology / Twitter / Facebook / LinkedIn Geschäftsführer: Dirk Schürmann, Joachim Löffler, Karl Anzboeck, Claus Schünemann Sitz der Gesellschaft: Böblingen, Amtsgericht Stuttgart HRB 757510 VAT ID: DE307881136 EntServ Deutschland GmbH: Schickardstraße 32, 71034 Böblingen, Germany - Board of Directors: Dirk Schürmann, Joachim Löffler, Karl Anzboeck - Registered in Stuttgart: HRB 757510. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 4

[uyuni-users] Uyuni 4.0.2 - minor version control on RHEL/CentOS 8
by Strahil Nikolov 25 Sep '19

25 Sep '19

Hello Community, I know that RHEL 8 (and all its derivatives) are far away from production ready, but I would like to ask if anyone has managed to sync the CentOS (or even better - RHEL) 8 repositories ? I'm asking , as I want to sync CentOS (& RHEL) repos in dedicated channels like 8.0, 8.1, etc - which will allow me at later stage to remove only older releases ( which leads to more efficient space usage).At work we have a SUSE provided channel for Red Hat systems (SUMA v3.2) - but it's just a large repo without control about minor versioning.I have noticed that point-in-time repos do work untill you split a Minor version :) Once I manage to do it on the dev (Uyuni 4.0.2) , I will be able to propose that at work.The other approach I was thinking is using a VM with 'subscription-manager' (valid only for RHEL) locked to a specific version and pulling all rpms which will be a Uyuni repo for a channel. For CentOS , I was thinking to sync mirrors' directories (for example 7.7.1908 as one repo) as channel repos. Thanks for reading this long e-mail. Thanks for your reply. 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

1 0

[uyuni-users] remove old channels added via SCC
by Haupt, Torsten 25 Sep '19

25 Sep '19

Hi, how can I delete old channels and repositories, which I added via SCC (Admin | Setup Wizard)? I don't need SLES12SP3 anymore and accidently added a HPC repo. I can't see any option to remove these channels. Greets Torsten -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 2

[uyuni-users] Update CentOS (python-zmq)
by Haupt, Torsten 24 Sep '19

24 Sep '19

Hey, I have several CentOS machines in my uyuni server (4.0.2). The updates of CentOS makes some problems: <snip> --> Abhängigkeit libzmq.so.5()(64bit) wird für Paket python2-zmq-14.7.0-8.el7.x86_64 verarbeitet --> Abhängigkeitsauflösung beendet --> Transaktionsprüfung wird ausgeführt ---> Paket kernel.x86_64 0:3.10.0-957.12.1.el7 markiert, um gelöscht zu werden ---> Paket python-zmq.x86_64 0:14.5.0-400.3.1.develHead markiert, um veraltet zu werden --> Abhängigkeit python-pyzmq >= 2.2.0 wird für Paket python2-salt-2019.2.0-16.2.x86_64 verarbeitet ---> Paket python2-zmq.x86_64 0:14.7.0-8.el7 markiert, um Aufräumen zu werden --> Abhängigkeit libzmq.so.5()(64bit) wird für Paket python2-zmq-14.7.0-8.el7.x86_64 verarbeitet --> Abhängigkeitsauflösung beendet Fehler: Paket: python2-salt-2019.2.0-16.2.x86_64 (@susemanager:centos7-uyuni-client-x86_64) Benötigt: python-pyzmq >= 2.2.0 Entfernen: python-zmq-14.5.0-400.3.1.develHead.x86_64 (@susemanager:bootstrap) python-pyzmq = 14.5.0-400.3.1.develHead Überholt durch: python2-zmq-14.7.0-8.el7.x86_64 (susemanager:epel7-centos7-x86_64) Nicht gefunden Verfügbar: python-zmq-14.5.0-3.4.x86_64 (susemanager:centos7-uyuni-client-x86_64) python-pyzmq = 14.5.0-3.4 Fehler: Paket: python2-zmq-14.7.0-8.el7.x86_64 (susemanager:epel7-centos7-x86_64) Benötigt: libzmq.so.5()(64bit) Sie können versuchen, mit --skip-broken das Problem zu umgehen. Sie könnten Folgendes versuchen: rpm -Va --nofiles --nodigest The EPEL repository is activated and integrated in uyuni. I excluded python-zmq* and zeromq* from the epel channel und resynced (https://github.com/uyuni-project/uyuni/issues/1077). I also built the bootstrap repo again. But the error still occurs. What I have to change to update CentOS machines? Greets Torsten Haupt -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 2

[uyuni-users] spacewalk error message by running zypper command
by Kaercher, Alexander 23 Sep '19

23 Sep '19

Hello @All, Server is successfully register to the uyuni. I can manage the configure files and update channels from the uyuni server. Updates can be deploy from the repositories which are provided from the uyuni server. But I receive this error message at the beginning, when I run zipper command: Refreshing service 'spacewalk'. Problem retrieving the repository index file for service 'spacewalk': [spacewalk|file:/usr/lib/zypp/plugins/services/spacewalk] Error Message: This system is already registered as a Salt Minion. If you want to register it as a traditional client please delete it first via the web UI or API and then register it using the traditional tools. Error Class Code: 48 Error Class Info: This system is already registered as a Salt Minion. If you want to register it as a traditional client please delete it first via the web UI or API and then register it using the traditional tools. Explanation: An error has occurred while processing your request. If this problem persists please enter a bug report at scc.suse.com. If you choose to submit the bug report, please be sure to include details of what you were trying to do when this error occurred and details on how to reproduce this problem. Warning: Skipping service 'spacewalk' because of the above error. Mit freundlichen Grüßen / With kind regards Alexander Kärcher EntServ Deutschland GmbH: Schickardstraße 32, 71034 Böblingen, Germany - Board of Directors: Dirk Schürmann, Joachim Löffler, Karl Anzboeck - Registered in Stuttgart: HRB 757510. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 7

[uyuni-users] Error by sync of opensuse 15.1 update channel
by Kaercher, Alexander 19 Sep '19

19 Sep '19

Hello @All, I have added the Opensuse 15.1 Update over the spacewalk-common-channel to my uyuni. If I start the sync the following issue comes up in the logfile: 2019/09/02 11:26:30 +02:00 97.15 % 2019/09/02 11:26:31 +02:00 'NoneType' object has no attribute 'strip' 2019/09/02 11:26:37 +02:00 'NoneType' object has no attribute 'strip' 2019/09/02 11:26:44 +02:00 'NoneType' object has no attribute 'strip' 2019/09/02 11:26:45 +02:00 'NoneType' object has no attribute 'strip' 2019/09/02 11:26:45 +02:00 Importing packages finished. 2019/09/02 11:26:45 +02:00 2019/09/02 11:26:45 +02:00 Linking packages to the channel. 2019/09/02 11:28:29 +02:00 Unexpected error: <class 'spacewalk.server.importlib.importLib.InvalidPackageError'> 2019/09/02 11:28:29 +02:00 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 1142, 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 126, in submit self.backend.lookupPackages(self.batch, self.checksums) File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 697, in lookupPackages raise_with_tb(not_found[0], not_found[1]) File "/usr/lib/python3.6/site-packages/spacewalk/common/usix.py", line 77, in raise_with_tb raise value File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 689, in lookupPackages self.__lookupObjectCollection([package], 'rhnPackage') File "/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", line 2342, in __lookupObjectCollection raise InvalidPackageError(object, "Could not find object %s in table %s" % (object, tableName)) spacewalk.server.importlib.importLib.InvalidPackageError: Could not find object [<<class 'spacewalk.server.importlib.importLib.IncompletePackage'> instance; attributes={'package_id': None, 'name': 'fuse3', 'epoch': None, 'version': '3.6.1', 'release': 'lp151.2.1', 'arch': 'x86_64', 'org_id': 1, 'package_size': None, 'last_modified': None, 'md5sum': None, 'channels': {172: 'opensuse_leap15_1-x86_64-updates'}, 'checksum_list': None, 'checksum': '1a32045cc68d2fcade9b945d8137ac0f9c521d936005faf6d9200b25b7f45983', 'checksum_type': 'sha256', 'checksums': {'sha256': '1a32045cc68d2fcade9b945d8137ac0f9c521d936005faf6d9200b25b7f45983'}, 'name_id': 52144, 'evr_id': 1922, 'package_arch_id': 120, 'nevra_id': 211225, 'checksum_id': 11451621}] in table rhnPackage If I add the repo manual I'm also not able to sync. Mit freundlichen Grüßen / With kind regards Alexander Kärcher Delivery Manager Linux/unix and Datamanagement DXC Technology Germany Faktorhaus, Berliner Platz 1, 67056 Ludwigshafen T +49 621 48187569 M +49 1525 47 54976 alexander.kaercher(a)dxc.com Planed absence: xx.xx.2019 - xx.xx.2019 EntServ Deutschland GmbH Schickardstr. 32 71034 Böblingen dxc.technology / Twitter / Facebook / LinkedIn Geschäftsführer: Dirk Schürmann, Joachim Löffler, Karl Anzboeck, Claus Schünemann Sitz der Gesellschaft: Böblingen, Amtsgericht Stuttgart HRB 757510 VAT ID: DE307881136 DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 3

Re: [uyuni-users] Repository confirmation question
by Strahil 19 Sep '19

19 Sep '19

Hi Steve, I guess so... Do you suspect a package is missing from Uyuni that is in the repos ? Best Regards, Strahil NikolovOn Sep 6, 2019 15:44, Steve Moring <smoring(a)dgsllc.biz> wrote: > > Strahil, > > On Thu, 2019-09-05 at 19:53 +0000, Strahil Nikolov wrote: > > With rpm-based repos, you got repodata having the necessary data. > > As this is the update repo , you can do the following: > > > > uyuni:/tmp # curl -s > > 'http://mirrors.xgroup.si/opensuse/update/leap/15.1/oss/repodata/17a > > 7ddeb6d5c2e697c1f4fb18d29ff91d9e290d61a65933f5955abaa9e9f15f7- > > updateinfo.xml.gz' | gunzip -d - | grep 'package name' | grep > > 'arch="x86_64"' | wc -l > > Thank you. > > > > > In my case it shows 3337 packages of arch x86_64 > > I can understand some differences between repo's, your repo may not be > as current as another (the download.opensuse.org shows 3338 according > to uyuni). > > What I'm baffled by is why there would be such a disparity between the > repodata and the actual html listing the rpms. Guessing that this is > due to package dependencies? > > > > > Maybe I'm using the wrong xml ... if so , do not hesitate to correct > > me. > > > > Best Regards, > > Strahil Nikolov > N��r��y隊[��x��칻�&ޢ��'��-��w�zf��쮞+�z�>� ޮ�^�ˬz��

3 2

[uyuni-users] Repository confirmation question
by Steve Moring 06 Sep '19

06 Sep '19

Hi, I am nearly certain that my openSUSE 15.1 repository is synchronized with it's associated repository on download.opensuse.org. http://download.opensuse.org/update/leap/15.1/oss/x86_64/ How do I tell if my count on uyuni for the repo of 3338 (today), matches what's on the repository? I have tried wget for the index.html and counting the "mirrorlist" with wc -l after an egrep of the index.html - but the count of links found here versus what's in uyuni don't match. I only see 2887 total lines in the index.html, of which 2832 actually include url's to the actual rpms. Is there a way to do this to confirm? Am I not understanding how the repo's are concatenated and counted? Thanks, -Steve -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 2

[uyuni-users] Bootstrap disables other repo's but doesn't add uyuni repos
by Steve Moring 03 Sep '19

03 Sep '19

Hi, Tools repo's are synch'd. Creating the bootstrap script doesn't show any errors. The bootstrap script doesn't show any errors when run on the client. There are no uyuni provided repo's listed after accepting the salt key. Where do I look next? I thought that the zypper.log on the client being bootstrapped would show me what I needed to see but it's not showing any errors. -Steve -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

1 1

2022

2021

2020

2019

2018

Uyuni Users September 2019