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
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
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
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
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
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
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
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��
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
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