Re: [Spacewalk-list] Why there are two activation keys in my kickstart file ?

[Robert Paschedag]

Sorry...I'm not the kickstart expertbut within other project to install some redhat servers

via spacewalk (or uyuni) ~ 1 year ago, I always had trouble with the "magic" kickstart snippets that were

included (maybe I always did something wrongdon't know).

 

We always uploaded our own kickstart files and this worked for us.

 

This is for now all I can say. Maybe you want to try this. But hopefully some other spacewalker can

give you a better advise here.

 

Robert

 


 

Gesendet: Freitag, 05. Februar 2021 um 08:57 Uhr
Von: "tommy" 
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Why there are two activation keys in my kickstart file ?




Anyone can help me ??

 

 

 



From: spacewalk-list-boun...@redhat.com  On Behalf Of tommy
Sent: Friday, February 5, 2021 12:02 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Why there are two activation keys in my kickstart file ?



 

Hi ,everyone:

 

This is part of the kickstart which is auto produced by spacewalk.

 


try:  # python 2

    import xmlrpclib

except ImportError:  # python 3

    import xmlrpc.client as xmlrpclib

import shutil

import sys

import os.path

 

try:

    old_system_id = "/tmp/rhn/systemid"

    new_system_id = "/mnt/sysimage/root/systemid.old"

    tmp_key = "/mnt/sysimage/tmp/key"

 

    new_keys = "1-fd833f6fb24dbd1f8807f36d434049a4,1-296a3f05d95aec9f804024a596acc810"

    for key in new_keys.split(','):

    if key.startswith('re-'):

    sys.exit(0)


 

You can see that there are tow keys, but when I create the kickstart, I only choose one key(1-296a3f05d95aec9f804024a596acc810) just like below pic, and the other one(1-fd833f6fb24dbd1f8807f36d434049a4) does not exists in my spacewalk system.

 

But why the spacewalk produce such a kickstart file ? Why ?

 

Could you give me some explain ? 

 

Thanks.

 

 



___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list



___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] rhn_check failed to pick up updates from Spacewalk 2.10 for debian buster client

[Robert Paschedag]

 


you need the errata.py file on each client within the rhn "actions" folder to be able to install "errata"

 

See https://github.com/spacewalkproject/spacewalk/tree/master/client/rhel/yum-rhn-plugin/actions and https://github.com/philicious/spacewalk-scripts (read the README.md)

 

Robert

 

 

Gesendet: Dienstag, 02. Februar 2021 um 10:21 Uhr
Von: "BARRIERE Benoit" 
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] rhn_check failed to pick up updates from Spacewalk 2.10 for debian buster client




Hello,

 

I try to retrieve from my debian buster client any updates availables and scheduled from our spacewalk server (in 2.10)

When i force to retrieve from my debian client i have this following error :

 

D: do_call errata.update([28197],){'cache_only': None}

D: Attempt to call an unsupported action errata.update([28197],)

D: Sending back response(6, 'Invalid function call attempted', {})

 

Below the debug rhn_check command :

 

root@vla-remedybackup-p01:/var/log# rhn_check -

D: check_action{'action': "\n\nerrata.update\n\n\n\n28197\n\n\n\n\n", 'version': 2, 'id': 8502}

updateLoginInfo() login info

D: login(forceUpdate=True) invoked

logging into up2date server

D: rpcServer: Calling XMLRPC up2date.login

D: writeCachedLogin() invoked

D: Wrote pickled loginInfo at 1612256497.86 with expiration of 1612260097.86 seconds.

successfully retrieved authentication token from up2date server

D: logininfo:{'X-RHN-Server-Id': 110867, 'X-RHN-Auth-Server-Time': '1612256467.81', 'X-RHN-Auth': 'DFE12JbukLSDCXQlSDCSv+ywc1ZznKolOhWMlropQPk=', 'X-RHN-Auth-Channels': [['debian_buster', '20200514102455', '1', '1'], ['buster_main_main', '20210202000626', '0', '1'], ['buster_main_contrib', '20210202000622', '0', '1'], ['buster_main_non-free', '20210202001450', '0', '1'], ['buster_updates_contrib', '20210202000625', '0', '1'], ['buster_updates_main', '20210202000619', '0', '1'], ['buster_updates_non-free', '20210202001449', '0', '1'], ['buster_security_main', '20210202000602', '0', '1'], ['buster_security_contrib', '20210202000620', '0', '1'], ['buster_security_non-free', '20210202000621', '0', '1']], 'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}

D: handle_action{'action': "\n\nerrata.update\n\n\n\n28197\n\n\n\n\n", 'version': 2, 'id': 8502}

D: handle_action actionid = 8502, version = 2

D: do_call errata.update([28197],){'cache_only': None}

D: Attempt to call an unsupported action errata.update([28197],)

D: Sending back response(6, 'Invalid function call attempted', {})

D: do_call packages.checkNeedUpdate('rhnsd=1',){}

D: Called refresh_list

Updating package profile

D: rpcServer: Calling XMLRPC registration.welcome_message

D: rpcServer: Calling XMLRPC registration.update_packages

D: local action status: (0, 'package list refreshed', {})

D: rpcServer: Calling XMLRPC registration.welcome_message

 

To install the client i am using : the opensuse repo :  http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/Debian_10/all/

root@vla-remedybackup-p01:/var/log# dpkg -l | grep -E '(rhn|spacewalk)'

ii  apt-transport-spacewalk   1.0.15-2.debian10.3  all  APT transport for communicating with Spacewalk servers

ii  python2-rhn-check 2.9.36-3.debian10.3  all  Check for RHN actions

ii  python2-rhn-client-tools  2.9.36-3.debian10.3  all  Support programs and libraries for Red Hat Satellite or Spacewalk

ii  python2-rhn-setup 2.9.36-3.debian10.3  all  Configure and register an RHN/Spacewalk client

ii  python2-rhncfg    5.10.129-4.debian10.3    all  Spacewalk Configuration Client Libraries

ii  python2-rhncfg-actions    5.10.129-4.debian10.3    all  Spacewalk Configuration Client Actions

ii  python2-rhncfg-client     5.10.129-4.debian10.3    all  Spacewalk Configuration Client

ii  python2-rhnlib    2.9.5-2.debian10.3   all  Python libraries for the Spacewalk project

ii  python2-spacewalk-usix    2.9.1-3.debian10.3   all  Spacewalk client micro six library

ii  rhn-check 2.9.36-3.debian10.3  all  Check for RHN actions

ii  rhn-client-tools  2.9.36-3.debian10.3  all  Support programs and libraries for Red Hat Satellite or Spacewalk

ii  rhn-setup 2.9.36-3.debian10.3  all  Configure and register an RHN/Spacewalk client

ii  rhncfg    5.10.129-4.debian10.3    all      Spacewalk Configuration Client Libraries

ii  rhncfg-actions    5.10.129-4.debian10.3    all  Spacewalk Configuration Client Actions

ii  rhncfg-client 5.10.129-4.debian10.3    all  Spacewalk Configuration Client

ii  rhnsd 

Re: [Spacewalk-list] rhel7 to rhel8 in place upgrade

[Robert Paschedag]

It all only depends on the repos that you have attached and that all packages 
are there what are needed for the upgrade.

But if there is a package to be installed for the upgrade (that itself might 
change your repos for the upgrade)... This might break the upgrade.

Robert



⁣sent from my mobile device​


 Originale Nachricht 
Von: "oogiej...@yahoo.com" 
Gesendet: Tue Sep 29 16:46:17 GMT+02:00 2020
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] rhel7 to rhel8 in place upgrade

Have any of you tried doing a rhel7 to rhel8 upgrade using spacewalk?  
According to the redhat upgrade instructions you can do the upgrade without 
being connected to redhat, but it looks like they want you to use repos.d repo 
files.  Wondering if you would need to do that if you have spacewalk repos set 
up or if you can just use spacewalk the same way you would use the main redhat 
repos.





___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] too many osad clients timeout

[Robert Paschedag]

So your jabber server does not start. I would just try to install the latest 
updates for your OS.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: gian sisal 
Gesendet: Wed Sep 16 12:48:15 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] too many osad clients timeout

Hi Robert,
In my osa-dispatcher.log I can see the following (many times...):
2019/07/09 19:32:55 +02:00 5970 0.0.0.0: osad/jabber_lib.main('ERROR',
'Error caught:')
2019/07/09 19:32:55 +02:00 5970 0.0.0.0: osad/jabber_lib.main('ERROR',
'Traceback (most recent call last):\n  File
"/usr/lib/python2.7/site-packages/osad/jabber_lib.py", line 120, in main\n
   self.setup_config(config, 1)\nTypeError: setup_config() takes exactly 2
arguments (3 given)\n')
2019/07/09 19:33:05 +02:00 5970 0.0.0.0: osad/jabber_lib.main('ERROR',
'Error caught:')

I haven't found any other error on taskomatic and messages (I'll try to
search better)...

Maybe I need to simply update my python version or what?

Thanks for your help.

Best Regards.
Gianfrancesco

Il giorno mer 16 set 2020 alle ore 10:53 Robert Paschedag <
robert.pasche...@web.de> ha scritto:

> Search/var/log/messages, /var/log/rhn/osa_dispatcher and
> /var/log/rhn/rhn_taskomatic for errors.
>
> Robert
>
> ⁣sent from my mobile device​
>
>
>  Originale Nachricht 
> Von: gian sisal 
> Gesendet: Wed Sep 16 10:11:39 GMT+02:00 2020
> An: spacewalk-list@redhat.com
> Betreff: [Spacewalk-list] too many osad clients timeout
>
> Hi everyone,
> I'm facing a problem with many of my remote systems: on many of these
> systems I see osad daemon in dead status (inactive), when I try to restart
> it I see "activating" but after 90 seconds I see again "dead (inactive)"
> for timeout.
>
> I even tried to invoke /usr/sbin/osad -vvv to monitor the daemon starting
> phase and I just saw:
> "trying to connect to spacewalk server" but it waits too long (it exceeds
> the 90 seconds threshold)..
>
> I thought It could be related to "server busy" but even after a service's
> restart, I have the same abnormal behaviour.
>
> Any suggestion about how to prevent this situation?
>
> my software versions:
> spacewalk server: 2.9
>
> osad: osad-5.11.107
>
> Thanks for your cooperation.
>
> Best Regards.
>
>
> 
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] too many osad clients timeout

[Robert Paschedag]

Search/var/log/messages, /var/log/rhn/osa_dispatcher and 
/var/log/rhn/rhn_taskomatic for errors.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: gian sisal 
Gesendet: Wed Sep 16 10:11:39 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] too many osad clients timeout

Hi everyone,
I'm facing a problem with many of my remote systems: on many of these
systems I see osad daemon in dead status (inactive), when I try to restart
it I see "activating" but after 90 seconds I see again "dead (inactive)"
for timeout.

I even tried to invoke /usr/sbin/osad -vvv to monitor the daemon starting
phase and I just saw:
"trying to connect to spacewalk server" but it waits too long (it exceeds
the 90 seconds threshold)..

I thought It could be related to "server busy" but even after a service's
restart, I have the same abnormal behaviour.

Any suggestion about how to prevent this situation?

my software versions:
spacewalk server: 2.9

osad: osad-5.11.107

Thanks for your cooperation.

Best Regards.




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk project discontinued

[Robert Paschedag]

It is a true replacement. Also Debian support did improve a lot.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Brian Long 
Gesendet: Sat Jul 25 17:19:37 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk project discontinued

Pau,
Without reading the detailed documentation, is Uyuni a true replacement or
upgrade for Spacewalk 2.10, managing CentOS 6, 7 and 8 as well as RHEL 6, 7
and 8, or is it more tied to Suse distributions now?

Thanks.

/Brian/

On Fri, Jul 24, 2020 at 8:17 PM Pau Garcia  wrote:

> Hello
>
> Thank you for your kind words about Uyuni, Michael.
>
> For those of you interested in pursuing the Uyuni path, we have just
> released Uyuni 2020.07 and we will be holding our next monthly Uyuni
> Community Hours next Friday. More details here:
> https://lists.opensuse.org/uyuni-users/2020-07/msg00074.html
>
>
> Pau Garcia Quiles
> SUSE Manager Product Owner & Technical Project Manager
> SUSE Software Solutions Spain
>
> --
> *From:* spacewalk-list-boun...@redhat.com <
> spacewalk-list-boun...@redhat.com> on behalf of Michael Mraka <
> michael.mr...@redhat.com>
> *Sent:* Thursday, July 23, 2020 5:39 PM
> *To:* spacewalk-announce-l...@redhat.com <
> spacewalk-announce-l...@redhat.com>; spacewalk-list@redhat.com <
> spacewalk-list@redhat.com>
> *Subject:* [Spacewalk-list] Spacewalk project discontinued
>
> Dear Spacewalkers,
>
> You may have noticed that the number of Red Hat contributions decreased in
> the
> last couple of months. This is aligned with our plan and communication.
> Now we
> reached a state when no further contributions are planned from the Red Hat
> side.
>
>
> Let me clarify what it means for the community:
> - Spacewalk 2.10 is the very last release
> - Spacewalk github repositories have been archived (are read-only now)
> - Red Hat won't commit any new code, provide any bug fixes (not even
> critical
>   security ones), enhancement or accept any pull requests (it isn't
> possible to
>   submit a PR to an archived repository)
> - The spacewalk-announce-l...@redhat.com and spacewalk-de...@redhat.com
> mailing
>   lists will be archived
> - Spacewalk contributors from Red Hat left #spacewalk-devel IRC channel on
> freenode
> - All remaining Spacewalk bugreports have been closed and it is not
> possible to
>   create new ones
> - There's no one to track future security exposures, CVEs
> - Due to the lack of further updates we strongly recommend not to expose
>   running servers on a public network and keeping them within your private
>   network
>
> What will still be available:
> - spacewalkproject.org pages (as they are, with no further changes)
> - COPR repositories with Spacewalk packages, so it's possible:
>   - to install new and upgrade existing Spacewalk servers (but with no
> further updates)
>   - to fork them to make your own customizations
> - #spacewalk IRC channel on freenode and
> - spacewalk-list@redhat.com mailing list for the community to discuss
> Spacewalk
>   related questions or issues
> - read-only github repositories - anyone can clone and use them according
> to
>   the General Public License (GPLv2) license
>
>
> If you choose to, you may still run your existing or install new servers,
> use
> already synced content, create or sync new one, manage existing or
> register new
> clients. We know there will still be plenty of users that will keep
> operating
> Spacewalk for some time.
>
> Up to the current date, we're aware of only one public Spacewalk fork -
> Uyuni
> project. We're encouraging everyone who'd like to stay with the codebase
> and
> active community to check out this project.
>
>
> We'd also like to take this opportunity and thank all developers and
> contributors who helped us to create this project, to our long time users,
> to
> people opening bug reports, debugging and fixing issues and to Red Hat to
> sponsoring the project for all these years. It's been a pleasure and fun
> working on Spacewalk, we've enjoyed it. Thank you!
>
> See you in communities of other management projects!
>
> Spacewalk team
>
>
>
> --
> Michael Mráka
> Smart Management Engineering, Red Hat
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Client execution returned "Invalid function call attempted" (code 6)

[Robert Paschedag]

On my Debian, the CheckNeedUpdate is provided in 
/usr/share/rhn/actions/packages.py which is provided by 
"apt-transport-spacewalk"



⁣sent from my mobile device​


 Originale Nachricht 
Von: Wenkai Chen 
Gesendet: Thu Jul 16 09:52:50 GMT+02:00 2020
An: "spacewalk-list@redhat.com" 
Betreff: Re: [Spacewalk-list] Client execution returned "Invalid
functioncall attempted" (code 6)

HI ,

The rhncfg packages are already installed.

[root@x302 yum.repos.d]# rpm -qa | grep rhncfg*
rhncfg-5.10.129-1.el7.noarch
rhncfg-actions-5.10.129-1.el7.noarch
python2-rhncfg-5.10.129-1.el7.noarch
python2-rhncfg-client-5.10.129-1.el7.noarch
python2-rhncfg-actions-5.10.129-1.el7.noarch
rhncfg-management-5.10.129-1.el7.noarch
rhncfg-client-5.10.129-1.el7.noarch
python2-rhncfg-management-5.10.129-1.el7.noarch

I just checked under /usr/share/rhn/actions. It is empty.



Chen Wenkai
Infrastructure Security Engineer



  E:  wenkai_c...@ensigninfosecurity.com
  A:  30A Kallang Place, Level 9 Right Wing, Singapore 339213




-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Robert Paschedag
Sent: Saturday, 11 July 2020 3:10 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Client execution returned "Invalid function call 
attempted" (code 6)

EXTERNAL: Caution this email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.


You seem to be missing some packages that provide the function

packages.checkNeedUpdate('rhnsd=1',)

If I remember right, these should live in /usr/share/rhn/actions

Maybe your missing the rhn-actions package.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Wenkai Chen 
Gesendet: Wed Jul 01 04:44:32 GMT+02:00 2020
An: "spacewalk-list@redhat.com" 
Betreff: Re: [Spacewalk-list] Client execution returned "Invalid function call 
attempted" (code 6)

HI,

Anyone can help on this?
Furthermore, when I do a 'yum repolist' command on the client machine, the 
number of packages listed for the Spacewalk channel is 0.
[cid:image009.jpg@01D64F94.E21B4380]

When in fact, it has 1 over packages.
[cid:image010.jpg@01D64F94.E21B4380]


[A close up of a sign  Description generated with very high confidence]

Chen Wenkai
Infrastructure Security Engineer

   [A picture containing building  Description generated with high 
confidence] 
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fensign-infosecurity%2Fdata=02%7C01%7Cwenkai_chen%40ensigninfosecurity.com%7C0a01d1750eda48676e2108d8256a38bc%7Cd5cb08f4d38848b2bc028ecce3c63fce%7C1%7C0%7C637300485442922641sdata=jxU%2F7WOv5mIa4PEeNf%2Fh8feu8aAPzoxGsVtb4bNV6ck%3Dreserved=0>
  [A picture containing tableware  Description generated with high 
confidence] 
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2F9J7FkhXpb-4data=02%7C01%7Cwenkai_chen%40ensigninfosecurity.com%7C0a01d1750eda48676e2108d8256a38bc%7Cd5cb08f4d38848b2bc028ecce3c63fce%7C1%7C0%7C637300485442922641sdata=iAEkzqAp3fBHGhZ3N%2FTj8KRlkYxO7mFnNaUUXYf6y9U%3Dreserved=0>
  [A close up of a sign  Description generated with high confidence] 
<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FEnsignGlobaldata=02%7C01%7Cwenkai_chen%40ensigninfosecurity.com%7C0a01d1750eda48676e2108d8256a38bc%7Cd5cb08f4d38848b2bc028ecce3c63fce%7C1%7C0%7C637300485442922641sdata=droPSezkKi9Bzx9xgW43wIrYrBe%2BtJ%2FW2t13j%2BzjBRk%3Dreserved=0>

  E:  wenkai_c...@ensigninfosecurity.com
  A:  30A Kallang Place, Level 9 Right Wing, Singapore 339213


From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Wenkai Chen
Sent: Wednesday, 24 June 2020 6:40 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Client execution returned "Invalid function call 
attempted" (code 6)

EXTERNAL: Caution this email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.
HI Spacewalk users,

I encountered an error while trying to run a package verification job on one of 
the CentOS 7 clients.

Client execution returned "Invalid function call attempted" (code 6)

Here is the output of the command "rhn_check -vvv".

==
rhn_check -vvv
D: opening  db environment /var/lib/rpm cdb:0x401
D: opening  db index   /var/lib/rpm/Packages 0x400 mode=0x0
D: locked   db index   /var/lib/rpm/Packages
D: opening  db index   /var/lib/rpm/Providename 0x400 mode=0x0
D: do_call packages.checkNeedUpdate('rhnsd=1',){}
D: opening  db environment /var/lib/rpm cdb:0x401
D: opening  db index   /var/lib/rpm/Packages 0x400 mode=0x0
D: loading keyring from pubkeys i

Re: [Spacewalk-list] Client execution returned "Invalid function call attempted" (code 6)

[Robert Paschedag]

You seem to be missing some packages that provide the function

packages.checkNeedUpdate('rhnsd=1',)

If I remember right, these should live in /usr/share/rhn/actions

Maybe your missing the rhn-actions package.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Wenkai Chen 
Gesendet: Wed Jul 01 04:44:32 GMT+02:00 2020
An: "spacewalk-list@redhat.com" 
Betreff: Re: [Spacewalk-list] Client execution returned "Invalid function call 
attempted" (code 6)

HI,

Anyone can help on this?
Furthermore, when I do a 'yum repolist' command on the client machine, the 
number of packages listed for the Spacewalk channel is 0.
[cid:image009.jpg@01D64F94.E21B4380]

When in fact, it has 1 over packages.
[cid:image010.jpg@01D64F94.E21B4380]


[A close up of a sign  Description generated with very high confidence]

Chen Wenkai
Infrastructure Security Engineer

   [A picture containing building  Description generated with high 
confidence]   [A 
picture containing tableware  Description generated with high confidence] 
  [A close up of a sign  Description 
generated with high confidence] 

  E:  wenkai_c...@ensigninfosecurity.com
  A:  30A Kallang Place, Level 9 Right Wing, Singapore 339213


From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Wenkai Chen
Sent: Wednesday, 24 June 2020 6:40 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Client execution returned "Invalid function call 
attempted" (code 6)

EXTERNAL: Caution this email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.
HI Spacewalk users,

I encountered an error while trying to run a package verification job on one of 
the CentOS 7 clients.

Client execution returned "Invalid function call attempted" (code 6)

Here is the output of the command "rhn_check -vvv".

==
rhn_check -vvv
D: opening  db environment /var/lib/rpm cdb:0x401
D: opening  db index   /var/lib/rpm/Packages 0x400 mode=0x0
D: locked   db index   /var/lib/rpm/Packages
D: opening  db index   /var/lib/rpm/Providename 0x400 mode=0x0
D: do_call packages.checkNeedUpdate('rhnsd=1',){}
D: opening  db environment /var/lib/rpm cdb:0x401
D: opening  db index   /var/lib/rpm/Packages 0x400 mode=0x0
D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
D: loading keyring from rpmdb
D: opening  db index   /var/lib/rpm/Name 0x400 mode=0x0
D: added key gpg-pubkey-f4a80eb5-53a7ff4b to keyring
D: added key gpg-pubkey-442df0f8-4783f24a to keyring
D: added key gpg-pubkey-352c64e5-52ae6884 to keyring
D: added key gpg-pubkey-7fac5991-4615767f to keyring
D: added key gpg-pubkey-d38b4796-570c8cd3 to keyring
D: added key gpg-pubkey-2582e0c5-56099b04 to keyring
D: added key gpg-pubkey-9bd837ba-5bfbc74c to keyring
D: added key gpg-pubkey-6963f07f-57fad2ec to keyring
D: Using legacy gpg-pubkey(s) from rpmdb
D: opening  db index   /var/lib/rpm/Providename 0x400 mode=0x0
D: closed   db index   /var/lib/rpm/Providename
D: closed   db index   /var/lib/rpm/Name
D: closed   db index   /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm
Loaded plugins: fastestmirror, langpacks, rhnplugin
Adding en_SG.UTF-8 to language list
Config time: 0.024
D: login(forceUpdate=False) invoked
D: readCachedLogin invoked
D: Checking pickled loginInfo, currentTime=1592995113.38, 
createTime=1592994906.84, expire-offset=3600.0
D: readCachedLogin(): using pickled loginInfo set to expire at 1592998506.84
D: rpcServer: Calling XMLRPC up2date.listChannels
This system is receiving updates from RHN Classic or Red Hat Satellite.
rpmdb time: 0.000
Loading mirror speeds from cached hostfile
* base: mirror.upsi.edu.my
* epel: mirrors.bfsu.edu.cn
D: Attempt to call an unsupported action packages.checkNeedUpdate('rhnsd=1',)
D: local action status: (6, 'Invalid function call attempted', {})
D: rpcServer: Calling XMLRPC registration.welcome_message
D: closed   db index   /var/lib/rpm/Providename
D: closed   db index   /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm
==

May I know how to resolve this issue?
Thank you.

[A close up of a sign  Description generated with very high confidence]

Chen Wenkai
Infrastructure Security Engineer

   [A picture containing building  Description generated with high 
confidence] 

Re: [Spacewalk-list] SLES 12 SP5 package import

[Robert Paschedag]

Do you see any error when running the rhnpush or do the packages just don't 
make it into the channel?

You should take a look into the PostgreSQL logs in /var/lib/pgsql/data/log and 
look for errors.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: William Hongach 
Gesendet: Wed Jun 10 16:36:18 GMT+02:00 2020
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] SLES 12 SP5 package import

Good Morning,

Is anyone experiencing issues with pushing SLES 12 SP5 packages to Spacewalk 
via rhnpush?  We stage our updates in a Spacewalk 2.8 server and this is our 
first attempt to push SP5 updates but it does not appear to work.  We are 
successfully pushing SLES 12 SP3, SP4, SLES 15 SP1 updates without issue.  The 
scripted process is the same for SP5 yet they cause a timeout during the POST 
process which then fails after three attempts.

Unfortunately, there are no error messages logged to 
/var/log/httpd/ssl_error_log or error_log.  Has anyone seen this problem?  Is 
there an alternate logging location that I should check to try to view more 
detailed information about what is occurring?  Any insight would be greatly 
appreciated.





___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] End of life for Spacewalk project?

[Robert Paschedag]

Uyuni is a fork of spacewalk and the upstream protect of SuSE Manager

⁣sent from my mobile device​


 Originale Nachricht 
Von: Robert Paschedag 
Gesendet: Thu May 21 18:47:09 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] End of life for Spacewalk project?

The alternative is to migrate to Uyuni.
https://www.uyuni-project.org

I'm also in the process in migration. If you like to stick with the 
"traditional client" (like spacewalk is doing) this should work.

My error was, that I directly wanted to migrate also from the "traditional 
client" to the "saltstack" client (with Debian clients) around 1 year ago. That 
was quite a pain.

It was a lot of work till now but the latest version of uyuni works pretty good 
right now with Debian.

No need to do all the workarounds to patch the Packages.gz file with missing 
headers anymore.
Release and InRelease files get generated (of configured).

I've tried to run the foreman/katello But I failed quite miserably (maybe I 
didn't try it long enough or was just to stupid... Don't know)

You should give it a try.

Regards
Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Jody McIvor 
Gesendet: Thu May 21 18:16:51 GMT+02:00 2020
An: "spacewalk-list@redhat.com" 
Betreff: Re: [Spacewalk-list] End of life for Spacewalk project?

@Howard

It was actually announced by Michael M. a while ago thru this very email list. 
(Late April/Early may if I recall), so yes, Spacewalk discontinued.

Jody McIvor
Sr. Systems Administrator, Integration
Les Services D'intégration
[TEL] (250) 852-5202


jmci...@bclc.com
BCLC.com





-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of spacewalk-list-requ...@redhat.com
Sent: May 21, 2020 9:12 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk-list Digest, Vol 144, Issue 15

Send Spacewalk-list mailing list submissions to
spacewalk-list@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to
spacewalk-list-requ...@redhat.com

You can reach the person managing the list at
spacewalk-list-ow...@redhat.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Spacewalk-list digest..."


Today's Topics:

   1. Re: End of life for Spacewalk project? (Howard Coles)
   2. Re: End of life for Spacewalk project? (Paul Greene)


--

Message: 1
Date: Thu, 21 May 2020 16:07:38 +
From: Howard Coles 
To: "spacewalk-list@redhat.com" 
Subject: Re: [Spacewalk-list] End of life for Spacewalk project?
Message-ID:


Content-Type: text/plain; charset="iso-8859-1"

>From what I'm seeing it just says that Satellite will end on May 31, not 
>spacewalk.  Where did we read that Spacewalk will be done?
Also, is there a consolidated upstream project similar to Satellite 6?  Because 
from what I can see SuSE and Oracle (for their unbearable Linux) use Spacewalk 
or a similar structure, or am I mistaken?
We used to use spacewalk much more than we do now, but it does need to be 
caught up in patching.


See Ya'
Howard Coles Jr.

John 3:16!


From: spacewalk-list-boun...@redhat.com  on 
behalf of Paul Greene 
Sent: Thursday, May 21, 2020 10:23 AM
To: spacewalk-list@redhat.com 
Subject: Re: [Spacewalk-list] End of life for Spacewalk project?


EXTERNAL MESSAGE: Exercise Caution

What would be the implications of moving to the newer stack? Would it lose 
compatibility with previous versions?

On Thu, May 21, 2020 at 11:16 AM Joe Belliveau 
mailto:joe.belliv...@gmail.com>> wrote:

Means we have to either fork it or move on to the newer stack that redhat uses.

My plan so far is to start migrating to the newer stack. Sadly the value of 
spacewalk is dropping due to cloud usage. And a lack of understanding what 
Spacewalk can do.


On 5/21/20 11:04 AM, Paul Greene wrote:
I have 2 spacewalk servers - one running 2.7 and one running 2.9. I was looking 
at the Spacewalk homepage yesterday, thinking about updating to 2.10, and saw 
that Spacewalk is being discontinued as of May 31, 2020??

What does that mean? It won't be available anymore? No new updates after that 
date? What does the future hold for Spacewalk after May 31, 2020?





___
Spacewalk-list mailing list
Spacewalk-list@redhat.com<mailto:Spacewalk-list@redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_spacewalk-2Dlist=DwMFaQ=fEu2bgw3pNXAPCclXAucaUr2IoGZ7yiSSHPvd02mOBQ=snqX7lBGRnBrdAOZ3eplSnu-aBlPXKFvdkM2GFYwyMc=D1vHJKRwCMAdPzkq53bB-3q5TKY6NcK38fRpdhiPpRU=pWonVgHp7JQVN3y8KlacHHJMAG7hdtSry8aNU09xdCs=>

___

Re: [Spacewalk-list] End of life for Spacewalk project?

[Robert Paschedag]

The alternative is to migrate to Uyuni.
https://www.uyuni-project.org

I'm also in the process in migration. If you like to stick with the 
"traditional client" (like spacewalk is doing) this should work.

My error was, that I directly wanted to migrate also from the "traditional 
client" to the "saltstack" client (with Debian clients) around 1 year ago. That 
was quite a pain.

It was a lot of work till now but the latest version of uyuni works pretty good 
right now with Debian.

No need to do all the workarounds to patch the Packages.gz file with missing 
headers anymore.
Release and InRelease files get generated (of configured).

I've tried to run the foreman/katello But I failed quite miserably (maybe I 
didn't try it long enough or was just to stupid... Don't know)

You should give it a try.

Regards
Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Jody McIvor 
Gesendet: Thu May 21 18:16:51 GMT+02:00 2020
An: "spacewalk-list@redhat.com" 
Betreff: Re: [Spacewalk-list] End of life for Spacewalk project?

@Howard

It was actually announced by Michael M. a while ago thru this very email list. 
(Late April/Early may if I recall), so yes, Spacewalk discontinued.

Jody McIvor
Sr. Systems Administrator, Integration
Les Services D'intégration
[TEL] (250) 852-5202


jmci...@bclc.com
BCLC.com





-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of spacewalk-list-requ...@redhat.com
Sent: May 21, 2020 9:12 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk-list Digest, Vol 144, Issue 15

Send Spacewalk-list mailing list submissions to
spacewalk-list@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to
spacewalk-list-requ...@redhat.com

You can reach the person managing the list at
spacewalk-list-ow...@redhat.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Spacewalk-list digest..."


Today's Topics:

   1. Re: End of life for Spacewalk project? (Howard Coles)
   2. Re: End of life for Spacewalk project? (Paul Greene)


--

Message: 1
Date: Thu, 21 May 2020 16:07:38 +
From: Howard Coles 
To: "spacewalk-list@redhat.com" 
Subject: Re: [Spacewalk-list] End of life for Spacewalk project?
Message-ID:


Content-Type: text/plain; charset="iso-8859-1"

>From what I'm seeing it just says that Satellite will end on May 31, not 
>spacewalk.  Where did we read that Spacewalk will be done?
Also, is there a consolidated upstream project similar to Satellite 6?  Because 
from what I can see SuSE and Oracle (for their unbearable Linux) use Spacewalk 
or a similar structure, or am I mistaken?
We used to use spacewalk much more than we do now, but it does need to be 
caught up in patching.


See Ya'
Howard Coles Jr.

John 3:16!


From: spacewalk-list-boun...@redhat.com  on 
behalf of Paul Greene 
Sent: Thursday, May 21, 2020 10:23 AM
To: spacewalk-list@redhat.com 
Subject: Re: [Spacewalk-list] End of life for Spacewalk project?


EXTERNAL MESSAGE: Exercise Caution

What would be the implications of moving to the newer stack? Would it lose 
compatibility with previous versions?

On Thu, May 21, 2020 at 11:16 AM Joe Belliveau 
mailto:joe.belliv...@gmail.com>> wrote:

Means we have to either fork it or move on to the newer stack that redhat uses.

My plan so far is to start migrating to the newer stack. Sadly the value of 
spacewalk is dropping due to cloud usage. And a lack of understanding what 
Spacewalk can do.


On 5/21/20 11:04 AM, Paul Greene wrote:
I have 2 spacewalk servers - one running 2.7 and one running 2.9. I was looking 
at the Spacewalk homepage yesterday, thinking about updating to 2.10, and saw 
that Spacewalk is being discontinued as of May 31, 2020??

What does that mean? It won't be available anymore? No new updates after that 
date? What does the future hold for Spacewalk after May 31, 2020?





___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com

Re: [Spacewalk-list] package not available for installation

[Robert Paschedag]

I bet your channel packages files are not updated anymore... So the packages 
are synced to the channels but this information is not updated... So the client 
knows nothing about it.

Check the channelrepo task. Might be stuck (running forever) since last trigger 
in "Admin" -> Task schedules.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: "Peirce, Dean" 
Gesendet: Fri May 01 17:43:04 GMT+02:00 2020
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] package not available for installation

Hi All,
I’m trying to resolve an issue with spacewalk 2.7 where all of my channels are 
unable to update packages.
I select a server in spacewalk, and select the packages to upgrade, and 
confirm… Then I run rhn_check -vv from the target machine and get an error for 
every package that was to be upgraded like:
E:Package binutils-0:2.27-41.base.el7_7.3.x86_64 is not available for 
installation.

I have verified that the packages really exist in the channel(s).

Any ideas?


Thanks in advance.

Dean

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Permanently remove package from subscribed channel

[Robert Paschedag]

See the filters option on the repository

https://www.itzgeek.com/how-tos/linux/centos-how-tos/managing-channels-and-repositories-spacewalk-on-centos-7-rhel-7.html

⁣sent from my mobile device​


 Originale Nachricht 
Von: Sulove Khanal 
Gesendet: Wed Apr 08 15:36:43 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Permanently remove package from subscribed channel

Where on the WebUI am I able to block these packages? The only thing I see is 
to delete a package within a channel, which will reappear the next time it 
syncs. (Manage software channels ---> click on # of packages in channel, search 
for package in question, click remove.)

Regards,
Sulove

On 4/7/20, 4:21 PM, "Robert Paschedag"  wrote:

I would go via the WebUI and edit the channel

⁣sent from my mobile device​


 Originale Nachricht 
Von: Sulove Khanal 
Gesendet: Tue Apr 07 21:12:57 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Permanently remove package from subscribed 
channel

Is the channel definition within the command line? How would I get to where 
I want to go?

For example, if I want to block Firefox package updates from a channel 
called "centos7-x86-64," what commands would I run exactly? I am a beginner 
Spacewalk user.

Regards,
Sulove

    On 4/7/20, 2:54 PM, "Robert Paschedag"  wrote:

Within the channel definition, you can specify to block certain 
packages. Something like

"-perl*" would not sync perl packages.

Note that this might break dependencies.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Sulove Khanal 
Gesendet: Tue Apr 07 15:54:21 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] Permanently remove package from subscribed 
channel

Hi,



Is there a way to permanently remove packages from a Spacewalk channel? 
I am receiving Firefox package updates in a Centos7 channel that I don’t 
believe should be occurring; I’ve figured out a way to temporarily delete the 
Firefox package updates, but once the channel syncs (which is often), the 
Firefox updates pull again and I am left with the same issue.



Thank you,

Sulove







___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list



___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list



___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Permanently remove package from subscribed channel

[Robert Paschedag]

I would go via the WebUI and edit the channel

⁣sent from my mobile device​


 Originale Nachricht 
Von: Sulove Khanal 
Gesendet: Tue Apr 07 21:12:57 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Permanently remove package from subscribed channel

Is the channel definition within the command line? How would I get to where I 
want to go?

For example, if I want to block Firefox package updates from a channel called 
"centos7-x86-64," what commands would I run exactly? I am a beginner Spacewalk 
user.

Regards,
Sulove

On 4/7/20, 2:54 PM, "Robert Paschedag"  wrote:

Within the channel definition, you can specify to block certain packages. 
Something like

"-perl*" would not sync perl packages.

Note that this might break dependencies.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Sulove Khanal 
Gesendet: Tue Apr 07 15:54:21 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] Permanently remove package from subscribed channel

Hi,



Is there a way to permanently remove packages from a Spacewalk channel? I 
am receiving Firefox package updates in a Centos7 channel that I don’t believe 
should be occurring; I’ve figured out a way to temporarily delete the Firefox 
package updates, but once the channel syncs (which is often), the Firefox 
updates pull again and I am left with the same issue.



Thank you,

Sulove







___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list



___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Permanently remove package from subscribed channel

[Robert Paschedag]

Within the channel definition, you can specify to block certain packages. 
Something like

"-perl*" would not sync perl packages.

Note that this might break dependencies.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Sulove Khanal 
Gesendet: Tue Apr 07 15:54:21 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] Permanently remove package from subscribed channel

Hi,

 

Is there a way to permanently remove packages from a Spacewalk channel? I am 
receiving Firefox package updates in a Centos7 channel that I don’t believe 
should be occurring; I’ve figured out a way to temporarily delete the Firefox 
package updates, but once the channel syncs (which is often), the Firefox 
updates pull again and I am left with the same issue.

 

Thank you,

Sulove

 





___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] login errors and Internal Server Error - Back Again!!

[Robert Paschedag]

>From my experience...I had also the cannot login (taskomatic_user) problem.

My error was a change in ssl certs. So even if you did not change it, it might 
be expired.

So please... From the spacewalk server itself, run a "curl -v " . The 
name that is used is also within /etc/cobbler/settings (the 
"redhatmanagement_server" if I remember right).

If you get a ssl error, you need to fix this first.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Laurence Rosen 
Gesendet: Mon Mar 30 18:39:17 GMT+02:00 2020
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] login errors and Internal Server Error - Back Again!!

I recently had the problem I could not delete a system profile.  Well, I
ended up removing and re-installing spacewalk packages, running
spacewalk-setup and that did not fix my issue.
I had to remove all spacewalk packages and delete all conf directories I
could find in /etc; /etc/cobbler, /etc/tomcat, /etc/jabber, etc. and
reinstalling the server.

It worked perfectly after installation for a week.

Today I tried to schedule a remote-command on a group of systems, they all
failed with "invalid function call".  Running rhn-actions-control
--enable-all, didn't help.
So then I attempted to run a remote-command on one system and it too
failed, but when I tried to go to the Provisioning tab of the system I now
get this error:

Internal Server Error
The server experienced a problem which prevented your request from being
filled out. It may not be possible to execute this action at this time.

And this is error back again in my rhn_taskomatic_daemon.log:
###
INFO   | jvm 1| 2020/03/27 17:57:00 | 2020-03-27 17:57:00,024
[DefaultQuartzScheduler_Worker-5] ERROR
com.redhat.rhn.taskomatic.task.CobblerSyncTask - Cause:
redstone.xmlrpc.XmlRpcFault: :'login failed
(taskomatic_user)'
INFO   | jvm 1| 2020/03/27 17:57:00 | 2020-03-27 17:57:00,024
[DefaultQuartzScheduler_Worker-5] ERROR
com.redhat.rhn.taskomatic.task.CobblerSyncTask - Stack
trace:com.redhat.rhn.manager.kickstart.cobbler.NoCobblerTokenException: We
had an error trying to login.


And in tomcats localhost log ( I can login to spacewalk as sysadmin fine):

SEVERE: Servlet.service() for servlet [action] in context with path [/rhn]
threw exception [java.lang.reflect.InvocationTargetException] with root
cause
redstone.xmlrpc.XmlRpcFault: :'login failed
(sysadmin)'
at
redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:444)
at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
...


I am really stumped by this now as my server configuration has not changed
at all, it simply stopped working all of a sudden.

Something else is wrong and I need help tracking it down.
Has nobody else experienced this error not due to configuration of the
server?
What could suddenly cause the taskomatic user login to fail after working
fine for some time?

I will be glad to post any other  logs that might help.

-- 





***




This e-mail and any of its attachments may contain
Interactions LLC 
proprietary information, which is privileged,
confidential, or subject to 
copyright belonging to the Interactions
LLC. This e-mail is intended solely 
for the use of the individual or
entity to which it is addressed. If you 
are not the intended recipient of this
e-mail, you are hereby notified that 
any dissemination, distribution, copying,
or action taken in relation to 
the contents of and attachments to this e-mail
is strictly prohibited and 
may be unlawful. If you have received this e-mail in
error, please notify 
the sender immediately and permanently delete the original
and any copy of 
this e-mail and any printout. Thank You.  




*** 




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] cannot delete profile

[Robert Paschedag]

But it should not match your issuer It should be signed by the issuer.

There is another script you can modify to test. That's the authentication 
module for cobbler to spacewalk.

It is located within the cobbler directory somewhere below /usr/lib/python.. . 
Search for the filename that is written here
https://github.com/spacewalkproject/spacewalk/blob/9be948a4a01d0dd41baed0c6d0032a2078d336d3/spacewalk/setup/share/cobbler/modules.conf

You can then modify it. Overwrite the server name with your fqdn and replace 
username and password with "taskomatic_user" and use the token from 
"...secret_1" from rhn.conf.


⁣sent from my mobile device​


 Originale Nachricht 
Von: Laurence Rosen 
Gesendet: Wed Mar 18 20:55:29 GMT+01:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] cannot delete profile

My cert matches the Issuer fqdn:
CN=ip-172-28-6-214.eu-west-1.compute.internal

The curl fails, but I don't think due to the CERT:

[root@spacewalk-prod-dub ~]# curl
https://spacewalk101.prod.dublin.aws.interactions.net/cobbler_api

Error response


Error response
Error code 501.
Message: Unsupported method ('GET').
Error code explanation: 501 = Server does not support this operation.


And the test script does not seem to work for me:

[root@spacewalk-prod-dub ~]# ./test_cobbler.py
Couldn't load needed libs, Are you sure you are running this on a satellite?

Am I missing some python deps?

Thanks for the pointers.

--





***




This e-mail and any of its attachments may contain
Interactions LLC
proprietary information, which is privileged,
confidential, or subject to
copyright belonging to the Interactions
LLC. This e-mail is intended solely
for the use of the individual or
entity to which it is addressed. If you
are not the intended recipient of this
e-mail, you are hereby notified that
any dissemination, distribution, copying,
or action taken in relation to
the contents of and attachments to this e-mail
is strictly prohibited and
may be unlawful. If you have received this e-mail in
error, please notify
the sender immediately and permanently delete the original
and any copy of
this e-mail and any printout. Thank You. 




*** 




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] cannot delete profile

[Robert Paschedag]

But your cert should not match your issuer... It should match your fqdn. Might 
be within the SAN.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Laurence Rosen 
Gesendet: Wed Mar 18 20:55:29 GMT+01:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] cannot delete profile

My cert matches the Issuer fqdn:
CN=ip-172-28-6-214.eu-west-1.compute.internal

The curl fails, but I don't think due to the CERT:

[root@spacewalk-prod-dub ~]# curl
https://spacewalk101.prod.dublin.aws.interactions.net/cobbler_api

Error response


Error response
Error code 501.
Message: Unsupported method ('GET').
Error code explanation: 501 = Server does not support this operation.


And the test script does not seem to work for me:

[root@spacewalk-prod-dub ~]# ./test_cobbler.py
Couldn't load needed libs, Are you sure you are running this on a satellite?

Am I missing some python deps?

Thanks for the pointers.

-- 





***




This e-mail and any of its attachments may contain
Interactions LLC 
proprietary information, which is privileged,
confidential, or subject to 
copyright belonging to the Interactions
LLC. This e-mail is intended solely 
for the use of the individual or
entity to which it is addressed. If you 
are not the intended recipient of this
e-mail, you are hereby notified that 
any dissemination, distribution, copying,
or action taken in relation to 
the contents of and attachments to this e-mail
is strictly prohibited and 
may be unlawful. If you have received this e-mail in
error, please notify 
the sender immediately and permanently delete the original
and any copy of 
this e-mail and any printout. Thank You.  




*** 




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] cannot delete profile

[Robert Paschedag]

Because I nearly had the same issue while I changed the ssl certificates on a 
server, the problem might be, that your cobbler cannot connect back to your 
spacewalk server.

What I would test...

>From your spacewalk server!!!

- run a "curl" against your spacewalk server itself. So if the fqdn is 
"foo.bar.com" , run "curl https://foo.bar.com/cobbler_api;

Only thing you need to clarify is that you don't get an SSL verification error.

In case you have an SSL verification error, you need to add the 
RHN-ORG-TRUSTED-SSL-CERT file from the .../htdocs/pub directory to the local 
ssl can store (look at manage of "update-ca-certificates") and run that tool, 
after you have added the file.

- you can additionally check with this script 
https://github.com/spacewalkproject/spacewalk/blob/9be948a4a01d0dd41baed0c6d0032a2078d336d3/java/scripts/test_cobbler_sw_login.py

But do not use "localhost". Use the fqdn.

Robert




⁣sent from my mobile device​


 Originale Nachricht 
Von: Laurence Rosen 
Gesendet: Wed Mar 18 18:20:03 GMT+01:00 2020
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] cannot delete profile

Please help!
How do I troubleshoot this?
I just removed all spacewalk packages from this system, and started from
scratch (with 2.10) and still does not fix it!

However I am still at a loss, I STILL cannot delete ANY systems/profiles.
What info do I need to provide here?  A spacewalk-debug file?

rhn_taskomatic_daemon.log:

INFO   | jvm 1| 2020/03/18 13:11:00 | 2020-03-18 13:11:00,081
[DefaultQuartzScheduler_Worker-9] ERROR com.redhat.rhn.manager.kickst
art.cobbler.CobblerLoginCommand - XmlRpcFault while logging in.  most
likely user doesn't have permissions.
INFO   | jvm 1| 2020/03/18 13:11:00 | redstone.xmlrpc.XmlRpcFault:
:'login failed (taskomatic_user)
'
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:444)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXML
RPCHelper.java:69)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginComma
nd.java:52)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.frontend.integration.IntegrationService.authorize(IntegrationService.java:114)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(IntegrationService.java:67)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerCommand.(CobblerCommand.java:68)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerDistroSyncCommand.(CobblerDistroSyncCommand.java:51)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:78)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:88)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:186)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
org.quartz.core.JobRunShell.run(JobRunShell.java:216)
INFO   | jvm 1| 2020/03/18 13:11:00 |   at
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
INFO   | jvm 1| 2020/03/18 13:11:00 | 2020-03-18 13:11:00,082
[DefaultQuartzScheduler_Worker-9] ERROR
com.redhat.rhn.taskomatic.task.CobblerSyncTask - RuntimeExceptionError
trying to sync to cobbler: We had an error trying to login.

-- 





***




This e-mail and any of its attachments may contain
Interactions LLC 
proprietary information, which is privileged,
confidential, or subject to 
copyright belonging to the Interactions
LLC. This e-mail is intended solely 
for the use of the individual or
entity to which it is addressed. If you 
are not the intended recipient of this
e-mail, you are hereby notified that 
any dissemination, distribution, copying,
or action taken in relation to 
the contents of and attachments to this e-mail
is strictly prohibited and 
may be unlawful. If you have received this e-mail in
error, please notify 
the sender immediately and permanently delete the original
and any copy of 
this e-mail and any printout. Thank You.  




*** 




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com

Re: [Spacewalk-list] Spacewalk Filters

[Robert Paschedag]

Shouldn't it be "-grafana..."?

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Raymond Setchfield 
Gesendet: Tue Feb 18 12:11:22 GMT+01:00 2020
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] Spacewalk Filters

Hi All,

I am receiving an error message when I am trying to pull down the grafana
packages, and I thought I'd use the filters to remove the appropriate
packages.

10:58:48 197/200 : grafana-6.2.3-1.x86_64.rpm
10:58:48 198/200 : grafana-5.2.2-1.armhfp.rpm
10:58:48 199/200 : grafana-6.2.2-1.armhfp.rpm
10:58:48 200/200 : grafana-6.3.6-1.armhfp.rpm
10:58:49
10:58:49   Importing packages to DB:
   Importing packages:
|##| 100.0%
10:59:42
10:59:42   Linking packages to the channel.
10:59:42 ERROR: Unknown arch armhfp
10:59:43 Sync of channel completed in 0:03:32.
10:59:43 Total time: 0:03:32

So using the filters I am tried;
+grafana-*.x86_64.rpm

and I am receiving this from the repo  sync
11:06:44   Processing repository with URL:
https://packages.grafana.com/oss/rpm
11:06:45 Packages in repo:   201
11:06:45 Packages passed filter rules: 0
11:06:45 No new packages to sync.
11:06:45
11:06:45   Errata in repo: 0.
11:06:45 Sync of channel completed in 0:01:24.
11:06:45 Total time: 0:01:24

Can anyone suggest what I am doing wrong on the filters?

Thanks

Ray




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Invalid function call attempted (code 6)

[Robert Paschedag]

At least one "Action" is missing in /usr/share/rhn/actions that has the 
checkNeedUpdate

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Muhammad Mosleh Uddin 
Gesendet: Tue Jan 21 17:18:21 GMT+01:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Invalid function call attempted (code 6)

Hi.
Thanks for your respond.
No, it wasnt the issue.


On Mon, Jan 20, 2020 at 4:52 AM Michael Mraka 
wrote:

> Muhammad Mosleh Uddin:
> > i paul,
> > my rhel client is not pulling package from spacewalk server.
> > my spacewalk client is test01. spacewalk can sync redhat channel and I
> see
> > some packages.
> >
> > [root@test01 yum.repos.d]# rhn_check -vv
> > D: do_call packages.checkNeedUpdate('rhnsd=1',){}
> > D: Attempt to call an unsupported action
> > packages.checkNeedUpdate('rhnsd=1',)
> > D: local action status: (6, 'Invalid function call attempted', {})
> > D: rpcServer: Calling XMLRPC registration.welcome_message
>
> It looks like yum-rhn-plugin is missing on the client.
>
> Regards,
>
> --
> Michael Mráka
> System Management Engineering, Red Hat
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list



-- 




Muhammad Mosleh Uddin




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk client not checking in on CentOS 7

[Robert Paschedag]

The daemon should be running. It should then check every interval minutes if 
something has to be done. See also within /etc/sysconfig/rhn/ for the interval. 
(Just right now know the name of the config file). The minimum interval is 60 
minutes.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Len Ewen 
Gesendet: Wed Jan 08 15:11:06 GMT+01:00 2020
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk client not checking in on CentOS 7

The rhnsd daemon isn't running, should it be constantly running or does it
pause and then run again?  It is enabled, just not running.

---

Len Ewen

Systems Administrator 1

Information Technology

University of Indianapolis

(317) 788-3362

[image: UIndyIT.jpg]

Confidentiality Notice: This communication and/or its content are for the
sole use of the intended recipient, and may be privileged, confidential, or
otherwise protected from disclosure by law. If you are not the intended
recipient, please notify the sender and then delete all copies of it.
Unless you are the intended recipient, your use or dissemination of the
information contained in this communication may be illegal.


On Wed, Jan 8, 2020 at 8:58 AM Michael Mraka 
wrote:

> Len Ewen:
> > I know this a stupid noob question but I have a problem.  I've got a
> clean
> > built, fresh out of the box spacewalk 2.9 server and a 2.9 client.  The
> > client checked in once, but hasn't checked again for the last 16 hours.
> 16
> > hours seems like a long time for a check in to happen, but I am not sure
> > what is going on.  What am I missing?  Do I need to set up a cron job to
> > update or something?
>
> Hello,
>
> Check that rhnsd service is enabled and daemon is running.
> You can also check manually if the client is able to connect to the
> spacewalk server:
>   rhn_check -vv
>
>
> Regards,
>
> --
> Michael Mráka
> System Management Engineering, Red Hat
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] osa-dispatcher.service failed

[Robert Paschedag]

Look into /var/log/messages for errors.

Also changing a hostname (of course!) breaks the SSL verification, unless the 
new hostname is mentioned as SAN (subject alternative name) within the 
certificate or the certificate is a wildcard certificate that Assisi matches 
the new hostname.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Raymond Setchfield 
Gesendet: Tue Nov 19 17:04:20 GMT+01:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] osa-dispatcher.service failed

Hi All,

Can anyone assist on this issue?

Ray

On Wed, Nov 6, 2019 at 11:44 AM Raymond Setchfield <
raymond.setchfi...@gmail.com> wrote:

> Hi All,
>
> Been testing this to see if I could potentially recreate the fault.
>
> I have taken a copy of the instance which was working (vanilla install
> with spacewalk applied). When the copy starts up. It appears to be loaded
> and running fine. When I made a change to the server. For example, the
> hostname. The OSAD failed after reboot.
> I then made another machine from known working copy and changed the
> sshd_config file. Rebooted the machine and osad then failed.again.
>
> The failure seems to be the same, and there is nothing within the logs
> which suggest why its failed. It appears to be a time out. anything else I
> could potentially look into?
>
> Thanks
>
> Ray
>
> -- Forwarded message -
> From: Raymond Setchfield 
> Date: Tue, Nov 5, 2019 at 10:00 AM
> Subject: osa-dispatcher.service failed
> To: 
>
>
> Hi All,
>
> I have been following this guide to install the SSL certificate, and it
> appears to have worked fine. As I can see the certificate when logging into
> spacewalk etc.
>
> However, when restarting the services it appears that the osa-dispatcher
> has failed. There is little or no information to go with to figure out why
> it has failed.
>
> ● postgresql.service - PostgreSQL database server
>Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled;
> vendor preset: disabled)
>Active: active (running) since Tue 2019-11-05 09:50:15 UTC; 4min 41s ago
>   Process: 12341 ExecStop=/usr/bin/pg_ctl stop -D ${PGDATA} -s -m fast
> (code=exited, status=0/SUCCESS)
>   Process: 12504 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p
> ${PGPORT} -w -t 300 (code=exited, status=0/SUCCESS)
>   Process: 12487 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA}
> (code=exited, status=0/SUCCESS)
>  Main PID: 12518 (postgres)
>CGroup: /system.slice/postgresql.service
>├─12518 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432
>├─12529 postgres: logger process
>├─12531 postgres: checkpointer process
>├─12532 postgres: writer process
>├─12533 postgres: wal writer process
>├─12534 postgres: autovacuum launcher process
>├─12535 postgres: stats collector process
>├─12590 postgres: rhnuser rhnschema 127.0.0.1(44062) idle
>├─12591 postgres: rhnuser rhnschema 127.0.0.1(44065) idle
>├─12592 postgres: rhnuser rhnschema 127.0.0.1(44064) idle
>├─12593 postgres: rhnuser rhnschema 127.0.0.1(44068) idle
>├─12594 postgres: rhnuser rhnschema 127.0.0.1(44070) idle
>├─12762 postgres: rhnuser rhnschema 127.0.0.1(44074) idle
>├─12867 postgres: rhnuser rhnschema 127.0.0.1(44076) idle
>├─12868 postgres: rhnuser rhnschema 127.0.0.1(44078) idle
>├─12869 postgres: rhnuser rhnschema 127.0.0.1(44080) idle
>├─12870 postgres: rhnuser rhnschema 127.0.0.1(44082) idle
>├─12871 postgres: rhnuser rhnschema 127.0.0.1(44084) idle
>├─12872 postgres: rhnuser rhnschema 127.0.0.1(44086) idle
>├─12873 postgres: rhnuser rhnschema 127.0.0.1(44088) idle
>├─12874 postgres: rhnuser rhnschema 127.0.0.1(44090) idle
>├─12875 postgres: rhnuser rhnschema 127.0.0.1(44092) idle
>├─12876 postgres: rhnuser rhnschema 127.0.0.1(44094) idle
>├─12877 postgres: rhnuser rhnschema 127.0.0.1(44096) idle
>├─12878 postgres: rhnuser rhnschema 127.0.0.1(44098) idle
>├─12879 postgres: rhnuser rhnschema 127.0.0.1(44100) idle
>├─12880 postgres: rhnuser rhnschema 127.0.0.1(44102) idle
>├─12881 postgres: rhnuser rhnschema 127.0.0.1(44104) idle
>├─12887 postgres: rhnuser rhnschema 127.0.0.1(44106) idle
>├─12888 postgres: rhnuser rhnschema 127.0.0.1(44108) idle
>├─12889 postgres: rhnuser rhnschema 127.0.0.1(44110) idle
>├─12890 postgres: rhnuser rhnschema 127.0.0.1(44112) idle
>├─12891 postgres: rhnuser rhnschema 127.0.0.1(44114) idle
>├─12930 postgres: rhnuser rhnschema 127.0.0.1(44118) idle
>├─12931 postgres: rhnuser rhnschema 127.0.0.1(44120) idle
>├─12941 postgres: rhnuser rhnschema 127.0.0.1(44126) idle
>├─12942 postgres: rhnuser 

Re: [Spacewalk-list] Ongoing Jabberd issues on SW 2.9/Centos7 servers

[Robert Paschedag]

So also nothing within /var/log/messages?

⁣sent from my mobile device​


 Originale Nachricht 
Von: Larry Clegg 
Gesendet: Fri Oct 04 18:30:44 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] Ongoing Jabberd issues on SW 2.9/Centos7 servers

Hello Spacewalkers,

I am continuing to have issues on all my Centos7/Spacewalk 2.9 servers
with Jabberd failing.  It is failing consistently on every server.  I have
verified that all the /etc/jabberd/*.xml files have the same FQDN and same
passwords.  The /etc/pki/spacewalk/jabberd/server.pem includes the same
FQDN.

I just don’t know where else to look and trouble-shoot.

I cannot find any logs for jabberd either:

[root@us3-inf-lu-s01 jabberd]# pwd
/var/lib/jabberd
[root@us3-inf-lu-s01 jabberd]# ls -lR
.:
total 0
drwx-- 2 jabber jabber  65 Oct  4 11:53 db
drwx-- 2 jabber jabber   6 Jul  4  2017 log
drwx-- 2 jabber jabber 105 Sep 17 19:06 pid

./db:
total 8096
-rw-r--r-- 1 jabber jabber  131072 Oct  4 11:53 sqlite.db
-rw-r--r-- 1 jabber jabber   32768 Oct  4 12:26 sqlite.db-shm
-rw-r--r-- 1 jabber jabber 4103552 Oct  4 12:26 sqlite.db-wal

./log:
total 0

./pid:
total 16
-rw-r--r-- 1 jabber jabber 4 Oct  4 11:53 c2s.pid
-rw-r--r-- 1 jabber jabber 4 Oct  4 11:53 router.pid
-rw-r--r-- 1 jabber jabber 4 Oct  4 11:53 s2s.pid
-rw-r--r-- 1 jabber jabber 4 Oct  4 11:53
us3-inf-lu-s01.inf.us3.cloud.kyriba.com.pid
[root@us3-inf-lu-s01 jabberd]#

Environment:
Centos7 with kernel 3.10.0-1062.1.2.el7.x86_64

Spacewalk 2.9
[root@us3-inf-lu-s01 jabberd]# rpm -qa | grep jab
spacewalk-setup-jabberd-2.9.2-1.el7.noarch
jabberpy-0.5-0.27.el7.noarch
jabberd-2.6.1-1.el7.x86_64

[root@us3-inf-lu-s01 jabberd]# rpm -qa | grep java
spacewalk-java-config-2.9.31-1.el7.noarch
java-1.8.0-openjdk-1.8.0.222.b10-1.el7_7.x86_64
javamail-1.4.6-8.el7.noarch
spacewalk-java-lib-2.9.31-1.el7.noarch
java-1.8.0-openjdk-devel-1.8.0.222.b10-1.el7_7.x86_64
java-1.8.0-openjdk-headless-1.8.0.222.b10-1.el7_7.x86_64
javapackages-tools-3.4.1-11.el7.noarch
xz-java-1.3-3.el7.noarch
python-javapackages-3.4.1-11.el7.noarch
javassist-3.16.1-10.el7.noarch
maven-javadoc-plugin-2.10.4-1.sw.noarch
spacewalk-java-postgresql-2.9.31-1.el7.noarch
spacewalk-java-2.9.31-1.el7.noarch
tzdata-java-2019c-1.el7.noarch

[root@us3-inf-lu-s01 ~]# rpm -qa | grep space
spacewalk-base-minimal-config-2.9.4-1.el7.noarch
spacewalk-search-2.9.1-1.el7.noarch
spacewalk-setup-jabberd-2.9.2-1.el7.noarch
spacewalk-schema-2.9.11-1.el7.noarch
spacewalk-remote-utils-2.9.6-1.el7.noarch
spacewalk-backend-app-2.9.35-1.el7.noarch
spacewalk-java-config-2.9.31-1.el7.noarch
spacecmd-2.9.9-1.el7.noarch
spacewalk-dobby-2.9.4-1.el7.noarch
spacewalk-backend-server-2.9.35-1.el7.noarch
spacewalk-backend-iss-2.9.35-1.el7.noarch
perl-XML-NamespaceSupport-1.11-10.el7.noarch
spacewalk-java-lib-2.9.31-1.el7.noarch
python2-spacewalk-usix-2.9.1-1.el7.noarch
spacewalk-backend-config-files-common-2.9.35-1.el7.noarch
spacewalk-backend-libs-2.9.35-1.el7.noarch
spacewalk-backend-iss-export-2.9.35-1.el7.noarch
spacewalk-backend-package-push-server-2.9.35-1.el7.noarch
spacewalk-backend-sql-postgresql-2.9.35-1.el7.noarch
spacewalk-branding-2.9.2-1.el7.noarch
spacewalk-html-2.9.4-1.el7.noarch
spacewalk-certs-tools-2.9.2-1.el7.noarch
spacewalk-selinux-2.9.6-1.el7.noarch
spacewalk-utils-2.9.9-1.el7.noarch
spacewalk-base-minimal-2.9.4-1.el7.noarch
spacewalk-base-2.9.4-1.el7.noarch
spacewalk-repo-2.9-4.el7.noarch
spacewalk-backend-2.9.35-1.el7.noarch
spacewalk-backend-xml-export-libs-2.9.35-1.el7.noarch
spacewalk-backend-config-files-2.9.35-1.el7.noarch
spacewalk-backend-applet-2.9.35-1.el7.noarch
spacewalk-config-2.8.5-1.el7.noarch
spacewalk-reports-2.9.1-1.el7.noarch
python2-spacewalk-certs-tools-2.9.2-1.el7.noarch
spacewalk-setup-2.9.3-1.el7.noarch
spacewalk-postgresql-2.9.1-1.el7.noarch
spacewalk-taskomatic-2.9.31-1.el7.noarch
spacewalk-common-2.9.1-1.el7.noarch
spacewalk-admin-2.9.1-1.el7.noarch
spacewalk-backend-sql-2.9.35-1.el7.noarch
spacewalk-backend-config-files-tool-2.9.35-1.el7.noarch
spacewalk-doc-indexes-2.9.2-1.el7.noarch
spacewalk-java-postgresql-2.9.31-1.el7.noarch
spacewalk-java-2.9.31-1.el7.noarch
spacewalk-backend-tools-2.9.35-1.el7.noarch
spacewalk-setup-postgresql-2.8.4-1.el7.noarch
spacewalk-backend-xmlrpc-2.9.35-1.el7.noarch
spacewalk-usix-2.9.1-1.el7.noarch


[root@us3-inf-lu-s01 ~]# spacewalk-service status
● postgresql.service - PostgreSQL database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled;
vendor preset: disabled)
   Active: active (running) since Fri 2019-10-04 11:53:53 EDT; 4min 42s
ago
  Process: 1348 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p
${PGPORT} -w -t 300 (code=exited, status=0/SUCCESS)
  Process: 1320 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA}
(code=exited, status=0/SUCCESS)
 Main PID: 1400 (postgres)
   CGroup: /system.slice/postgresql.service
   ├─ 1400 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432
   ├─ 1441 

Re: [Spacewalk-list] Problems with OSAD not picking up remote commands

[Robert Paschedag]

Looks like simply you're jabber certificate is broken.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Larry Clegg 
Gesendet: Mon Sep 30 22:33:08 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Problems with OSAD not picking up remote  commands

More research on this issue….I’m finding that on all of my SW 2.9 nodes
running on Centos7 are failing with Jabberd.



● jabberd.service - Jabber Server

   Loaded: loaded (/usr/lib/systemd/system/jabberd.service; enabled; vendor
preset: disabled)

   Active: active (exited) since Thu 2019-09-12 20:16:19 UTC; 2 weeks 4
days ago

  Process: 19180 ExecStart=/bin/true (code=exited, status=0/SUCCESS)

Main PID: 19180 (code=exited, status=0/SUCCESS)

   CGroup: /system.slice/jabberd.service



Checking the /var/log/rhn/osa-dispatcher.log I see this:



2019/09/30 20:32:22 -00:00 14849 0.0.0.0: osad/jabber_lib.main('ERROR',
'Error caught:')

2019/09/30 20:32:22 -00:00 14849 0.0.0.0: osad/jabber_lib.main('ERROR',
'Traceback (most recent call last):¥n  File
"/usr/lib/python2.7/site-packages/osad/jabber_lib.py", line 126, in
main¥nself.process_forever(c)¥n  File
"/usr/lib/python2.7/site-packages/osad/jabber_lib.py", line 187, in
process_forever¥nself.process_once(client)¥n  File
"/usr/lib/python2.7/site-packages/osad/osa_dispatcher.py", line 182, in
process_once¥nclient.retrieve_roster()¥n  File
"/usr/lib/python2.7/site-packages/osad/jabber_lib.py", line 757, in
retrieve_roster¥nstanza = self.get_one_stanza()¥n  File
"/usr/lib/python2.7/site-packages/osad/jabber_lib.py", line 829, in
get_one_stanza¥nself.process(timeout=tm)¥n  File
"/usr/lib/python2.7/site-packages/osad/jabber_lib.py", line 1100, in
process¥nraise_with_tb(SSLError("OpenSSL error; will retry", str(e)),
sys.exc_info()[2])¥n  File
"/usr/lib/python2.7/site-packages/osad/jabber_lib.py", line 1095, in
process¥ndata = self._read(self.BLOCK_SIZE)¥nSSLError: (¥'OpenSSL
error; will retry¥', "(-1, ¥'Unexpected EOF¥')")¥n')



*Larry E. Clegg*

Systems Engineer (SaaS Platform Operations) | *Kyriba*

[Cell Phone] +1 858-357-5579

[Address] 9620 Towne Centre Drive | Suite 250 | San Diego, California |
92121

www.kyriba.com | Facebook  | Twitter
 | LinkedIn
 | Blog




*From:* Larry Clegg [mailto:lcl...@kyriba.com]
*Sent:* Monday, September 30, 2019 11:42 AM
*To:* 'spacewalk-list@redhat.com' 
*Subject:* Problems with OSAD not picking up remote commands



Greetings Spacers,



My environment:



SW Server: Centos 7 fully patched and Spacewalk 2.9

SW Client: Centos 6 fully patched and Spacewalk Client 2.9 including OSAD
osad-5.11.107-1.el6.noarch



Issue:  From the SW server I select several systems and issue a remote
command.  Normally OSAD will pick up the remote command within seconds.
Now it is not picking it up for many minutes….even after a normal system
check-in the remote command is still not picked up.  I can login to the
client system and issue a rhn_check – and see it pick up the remote
command and return the output.Service osad is running; restarting makes
no difference.



On the SW server:

jabberpy-0.5-0.27.el7.noarch

spacewalk-setup-jabberd-2.9.2-1.el7.noarch

jabberd-2.6.1-1.el7.x86_64

osa-dispatcher-selinux-5.11.107-1.el7.noarch

python2-osa-common-5.11.107-1.el7.noarch

osa-dispatcher-5.11.107-1.el7.noarch

python2-osa-dispatcher-5.11.107-1.el7.noarch



Port 5222 is open with established connections.  I find no errors in any
logs.

I’m at a loss as to where to look now….any guidance would be appreciated.



Regards,



*Larry E. Clegg*

Systems Engineer (SaaS Platform Operations) | *Kyriba*

[Cell Phone] +1 858-357-5579

[Address] 9620 Towne Centre Drive | Suite 250 | San Diego, California |
92121

www.kyriba.com | Facebook  | Twitter
 | LinkedIn
 | Blog





___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] [BULK][EXT] Re: Regenerating Trusted Cert

[Robert Paschedag]

If I understand it right, the name of your server within your certificate was 
wrong and all the clients are running with the wrong fqdn name. Right?

So you know want to fix this and created a new certificate with the Fqdn fixed. 
Right?

Has this certificate been generated (and signed) by the same CA? Then you don't 
have to redistribute the CA file and don't need to change the 
RHN-TRUSTED-SSL-CERT file.

The best thing would be, if you created the new certificate with both FQDN 
names... The wrong old (current) and the new fixed one (as SAN certificate.)

All that should be needed then is to put the new certificate in place on the 
server (within Apache and jabber (xml files) configuration) and set the old 
FQDN name as ServerAlias within Apache.

With this configuration in place, it should work that all clients (old and new) 
can connect to Spacewalk without getting certificate errors.

The new clients should use the new name and you can later fix the name on all 
old clients within /etc/sysconfig/rhn/up2date and restart "rhnsd" and/or "osad" 
(maybe also within osad configuration file).

EDIT:

Hmm... Even if that all works, I think you would have problems with "osad". I 
think a temporary configuration of jabber (for 2 server names) would be too 
complicated.

So if you don't mind to lose osad connectivity on the old clients, I would try 
that.

Backup all your configuration files or - when running virtually - create a 
snapshot before you start.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: "Weiner, Michael" 
Gesendet: Fri Sep 27 19:20:49 GMT+02:00 2019
An: "spacewalk-list@redhat.com" 
Betreff: Re: [Spacewalk-list] [BULK][EXT] Re:  Regenerating Trusted Cert

Thank you for your response, Dean. I didnt do the let's encrypt cert, will that 
be a problem?


From: spacewalk-list-boun...@redhat.com  on 
behalf of Peirce, Dean 
Sent: Friday, September 27, 2019 12:02 PM
To: spacewalk-list@redhat.com
Subject: [BULK][EXT] Re: [Spacewalk-list] Regenerating Trusted Cert

Hi Michael,
I followed the instructions in the link below, when I had to change my cert. I 
had to work around a couple of the steps, since we use a static ssl 
certificate, and not a Let's Encrypt cert.

Hope this helps.

https://omg.dje.li/2017/04/using-lets-encrypt-ssl-certificates-with-spacewalk/


-Dean

On Sep 27, 2019, at 11:38 AM, Weiner, Michael 
mailto:wein...@ccf.org>> wrote:

I have a need to regenerate and redistribute the SSL certificate for my 
instance of spacewalk. When i set it up originally, the FQDN was not correct so 
the cert is now wrong that got distributed to workstations/servers, and i need 
to correct it now that the FQDN is correct. I have been googling but i cant 
seem to find anything specific to my query. I would have assumed there was a 
script (like the initial install script) that can recreate the cert and RPM.

Any assistance would be greatly appreciated.
Michael

Please consider the environment before printing this e-mail
Cleveland Clinic is currently ranked as one of the nation's top hospitals by 
U.S. News & World Report (2019-2020). Visit us online at 
http://www.clevelandclinic.org for a complete 
listing of our services, staff and locations. Confidentiality Note: This 
message is intended for use only by the individual or entity to which it is 
addressed and may contain information that is privileged, confidential, and 
exempt from disclosure under applicable law. If the reader of this message is 
not the intended recipient or the employee or agent responsible for delivering 
the message to the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please contact 
the sender immediately and destroy the material in its entirety, whether 
electronic or hard copy. Thank you. 
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


Please consider the environment before printing this e-mail

Cleveland Clinic is currently ranked as the No. 2 hospital in the country by 
U.S. News & World Report (2017-2018). Visit us online at 
http://www.clevelandclinic.org for a complete listing of our services, staff 
and locations. Confidentiality Note: This message is intended for use only by 
the individual or entity to which it is addressed and may contain information 
that is privileged, confidential, and exempt from disclosure under applicable 
law. If the reader of this message is not the intended recipient or the 
employee or agent responsible for delivering the message to the intended 
recipient, you are hereby 

Re: [Spacewalk-list] "Security: GPG" section of Channel? What's it for?

[Robert Paschedag]

The package manager (apt, zypper or yum or dnf) uses the signature to verify, 
that the metadata you're downloading (i.e. the Packages.gz on Debian) is not 
modified and is from a trusted source.

Only if the verification succeeds, the package manager will allow to install 
packages from that "source".

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Guy Matz 
Gesendet: Fri Sep 13 18:57:59 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] "Security: GPG" section of Channel? What's it for?

Hi!  Does anyone know what the "Security : GPG" section of the channel is
for?  I.e., what component uses that information and how?

Thanks!




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Ubuntu 16.04 / 18.04 Errata

[Robert Paschedag]

I still use it on sw2.7

⁣sent from my mobile device​


 Originale Nachricht 
Von: Raymond Setchfield 
Gesendet: Fri Sep 13 09:52:39 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Ubuntu 16.04 / 18.04 Errata

Hi Robert

Thank you for that. I see that this appears to be a forked version of one I
have mentioned. So is this still relevant? As I see it mentioned spacewalk
2.3 and older versions of ubuntu

Ray

On Thu, Sep 12, 2019 at 8:50 PM Robert Paschedag 
wrote:

> You could try my repo or the upstream fork from @philicious
>
> https://github.com/rpasche/spacewalk-scripts
>
> Robert
>
> ⁣sent from my mobile device​
>
>
>  Originale Nachricht 
> Von: Raymond Setchfield 
> Gesendet: Thu Sep 12 17:17:38 GMT+02:00 2019
> An: spacewalk-list@redhat.com
> Betreff: [Spacewalk-list] Ubuntu 16.04 / 18.04 Errata
>
> Hi All,
>
> Just wondering if any of you have documentation on how to pull down the
> errata for ubuntu?
> I found a link on git but it looks a bit dated. Can this still be used? (
> https://github.com/pandujar/spacewalk-scripts)  Or has anyone got
> something
> else which might be useful?
>
> Thanks
>
> Ray
>
>
> 
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] SSL errors after upgrading 2.8 to 2.9

[Robert Paschedag]

I do not run sw2.9 but maybe some ssl ciphers have changed within the Apache 
configuration

Robert

In case you get ssl verification errors after upgrading your clients, this 
could be caused by ssl updates and changes within /etc/ssl/openssl.cnf (maybe 
the "Cipher" has some "SECLEVEL2" set.

I got this error on Debian upgrades from stretch to buster.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Guy Matz 
Gesendet: Thu Sep 12 21:38:09 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] SSL errors after upgrading 2.8 to 2.9

Hi!  Anyone know if anything changed in 2.9 regarding SSL?  I had a
self-signed cert that no longer seems to work

Thanks
Guy




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Ubuntu 16.04 / 18.04 Errata

[Robert Paschedag]

You could try my repo or the upstream fork from @philicious

https://github.com/rpasche/spacewalk-scripts

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Raymond Setchfield 
Gesendet: Thu Sep 12 17:17:38 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] Ubuntu 16.04 / 18.04 Errata

Hi All,

Just wondering if any of you have documentation on how to pull down the
errata for ubuntu?
I found a link on git but it looks a bit dated. Can this still be used? (
https://github.com/pandujar/spacewalk-scripts)  Or has anyone got something
else which might be useful?

Thanks

Ray




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] Debian / Ubuntu: Multi-Arch Code merged

[Robert Paschedag]

Hi Spacewalkers,

Good news. Code to also import the important "Multi-Arch" header from .deb 
packages has been merged today (see 
https://github.com/spacewalkproject/spacewalk/pull/697).

So in future (nightlies or maybe spacewalk 2.10(??)), you're able to 
synchronize the .deb repositories directly within Spacewalk and don't need to 
run a script to inject the missing "Multi-Arch" header afterwards.

But you still need to sign the "Release" file with "gpg".

Yet there is still a drawback. All already imported Debian packages will still 
miss this information within the database.

Hence there are two possibilities.

1. Reimport all Debian packages. That cous take a long time.

2. Someone could write a cool script that adds the missing "Multi-Arch" value 
for each .deb package already imported into the database.

The new column "multi_arch" will be stored within the "rhnPackage" table.

Maybe when I have more time, I'll think about option 2.

Thanks to the Spacewalk team that merged the code.

Regards
Robert




⁣sent from my mobile device​

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Problem while registering ( CentOS 7 )

[Robert Paschedag]

You're missing the python xml2 module. You need to manually download it from 
your spacewalk server and install it.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Amir Kalhori 
Gesendet: Tue Sep 03 06:22:15 GMT+02:00 2019
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] Problem while registering ( CentOS 7 )


Dear All,

I got below error while registering a a CentOS 7 server.


[root@TAAM-DB /]# sudo rhnreg_ks --serverUrl=https://repo.yaas.bm/XMLRPC 
--sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-centos7

Traceback (most recent call last):
  File "/sbin/rhnreg_ks", line 35, in 
from up2date_client import rhnreg
  File "/usr/lib/python2.7/site-packages/up2date_client/rhnreg.py", line 20, in 

from up2date_client import hardware
  File "/usr/lib/python2.7/site-packages/up2date_client/hardware.py", line 57, 
in 
import dmidecode
  File "/usr/lib64/python2.7/site-packages/dmidecode.py", line 28, in 
import libxml2
ImportError: No module named libxml2
[root@TAAM-DB /]#





___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] SLES15-SP1 client with spacewalk?

[Robert Paschedag]

Hi Javier,

thanks. As our servers are not allowed to access internet directly, I'll have 
to download them
and create a temporary myself.

Thanks for your help.

Robert


> Gesendet: Freitag, 30. August 2019 um 13:29 Uhr
> Von: javier.flo...@gmz.migros.ch
> An: spacewalk-list@redhat.com
> Betreff: Re: [Spacewalk-list] SLES15-SP1 client with spacewalk?
>
> Hi Robert
> 
> I am using the packages from 
> https://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9/SLE_15/
> 
> Here is the list:
>  
> noarch/hwdata-0.323-46.1.noarch.rpm
> noarch/koan-2.9.0-1.1.noarch.rpm
> noarch/osad-5.11.107-8.1.noarch.rpm
> noarch/osa-dispatcher-5.11.107-8.1.noarch.rpm
> noarch/python2-gzipstream-2.9.3-5.1.noarch.rpm
> noarch/python2-hwdata-2.3.5-1.1.noarch.rpm
> noarch/python2-osa-common-5.11.107-8.1.noarch.rpm
> noarch/python2-osa-dispatcher-5.11.107-8.1.noarch.rpm
> noarch/python2-rhn-check-2.9.36-2.1.noarch.rpm
> noarch/python2-rhn-client-tools-2.9.36-2.1.noarch.rpm
> noarch/python2-rhnlib-2.9.5-6.1.noarch.rpm
> noarch/python2-rhnpush-5.5.117.3-2.1.noarch.rpm
> noarch/python2-rhn-setup-2.9.36-2.1.noarch.rpm
> noarch/python2-rhn-setup-gnome-2.9.36-2.1.noarch.rpm
> noarch/python2-spacewalk-usix-2.9.1-5.1.noarch.rpm
> noarch/python2-zypp-plugin-spacewalk-1.0.5-2.1.noarch.rpm
> noarch/python3-gzipstream-2.9.3-5.1.noarch.rpm
> noarch/python3-hwdata-2.3.5-1.1.noarch.rpm
> noarch/python3-osa-common-5.11.107-8.1.noarch.rpm
> noarch/python3-osad-5.11.107-8.1.noarch.rpm
> noarch/python3-osa-dispatcher-5.11.107-8.1.noarch.rpm
> noarch/python3-rhncfg-5.10.129-6.1.noarch.rpm
> noarch/python3-rhncfg-actions-5.10.129-6.1.noarch.rpm
> noarch/python3-rhncfg-client-5.10.129-6.1.noarch.rpm
> noarch/python3-rhncfg-management-5.10.129-6.1.noarch.rpm
> noarch/python3-rhn-check-2.9.36-2.1.noarch.rpm
> noarch/python3-rhn-client-tools-2.9.36-2.1.noarch.rpm
> noarch/python3-rhnlib-2.9.5-6.1.noarch.rpm
> noarch/python3-rhn-setup-2.9.36-2.1.noarch.rpm
> noarch/python3-rhn-setup-gnome-2.9.36-2.1.noarch.rpm
> noarch/python3-rhn-virtualization-common-5.4.76-6.1.noarch.rpm
> noarch/python3-rhn-virtualization-host-5.4.76-6.1.noarch.rpm
> noarch/python3-spacewalk-backend-libs-2.9.34-1.1.noarch.rpm
> noarch/python3-spacewalk-koan-2.9.1-6.1.noarch.rpm
> noarch/python3-spacewalk-oscap-2.9.5-6.1.noarch.rpm
> noarch/python3-zypp-plugin-spacewalk-1.0.5-2.1.noarch.rpm
> noarch/python-debian-0.1.16-0.5.1.noarch.rpm
> noarch/rhncfg-5.10.129-6.1.noarch.rpm
> noarch/rhncfg-actions-5.10.129-6.1.noarch.rpm
> noarch/rhncfg-client-5.10.129-6.1.noarch.rpm
> noarch/rhncfg-management-5.10.129-6.1.noarch.rpm
> noarch/rhn-check-2.9.36-2.1.noarch.rpm
> noarch/rhn-client-tools-2.9.36-2.1.noarch.rpm
> noarch/rhn-custom-info-5.4.43.1-2.1.noarch.rpm
> noarch/rhnpush-5.5.117.3-2.1.noarch.rpm
> noarch/rhnsd-5.0.44-6.1.noarch.rpm
> noarch/rhn-setup-2.9.36-2.1.noarch.rpm
> noarch/rhn-setup-gnome-2.9.36-2.1.noarch.rpm
> noarch/rhn-virtualization-host-5.4.76-6.1.noarch.rpm
> noarch/spacewalk-backend-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-app-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-applet-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-cdn-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-config-files-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-config-files-common-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-config-files-tool-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-iss-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-iss-export-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-libs-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-package-push-server-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-server-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-sql-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-sql-oracle-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-sql-postgresql-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-tools-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-xml-export-libs-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-backend-xmlrpc-2.9.34-1.1.noarch.rpm
> noarch/spacewalk-koan-2.9.1-6.1.noarch.rpm
> noarch/spacewalk-oscap-2.9.5-6.1.noarch.rpm
> noarch/spacewalk-pylint-2.9.0-5.1.noarch.rpm
> noarch/spacewalk-remote-utils-2.9.6-6.1.noarch.rpm
> noarch/spacewalk-usix-2.9.1-5.1.noarch.rpm
> noarch/zypp-plugin-spacewalk-1.0.5-2.1.noarch.rpm
> x86_64/python2-dmidecode-3.12.2-1.1.x86_64.rpm
> x86_64/python2-simplejson-3.13.2-1.1.x86_64.rpm
> x86_64/python2-simplejson-test-3.13.2-1.1.x86_64.rpm
> x86_64/python3-dmidecode-3.12.2-1.1.x86_64.rpm
> x86_64/python3-simplejson-3.13.2-1.1.x86_64.rpm
> x86_64/python3-simplejson-test-3.13.2-1.1.x86_64.rpm
> x86_64/python-dmidecode-3.12.2-1.1.x86_64.rpm
> x86_64/python-jabberpy-0.5-0.9.1.x86_64.rpm
> 

Re: [Spacewalk-list] SLES15-SP1 client with spacewalk?

[Robert Paschedag]

I might just have solved it myselfbut still...if you could send me the list 
or your packages
within your temporary repository, I'll really appreciate it.

I was missing the rhn-setup package (which includes the 'rhnreg_ks' tool).

But still testing

Robert


> Gesendet: Freitag, 30. August 2019 um 13:22 Uhr
> Von: "Robert Paschedag" 
> An: spacewalk-list@redhat.com
> Cc: spacewalk-list@redhat.com
> Betreff: Re: [Spacewalk-list] SLES15-SP1 client with spacewalk?
>
> May I ask for your temporary repo package list?
> 
> That is the part I'm currently missing.
> 
> thanks,
> Robert
> 
> 
> > Gesendet: Freitag, 30. August 2019 um 12:50 Uhr
> > Von: javier.flo...@gmz.migros.ch
> > An: spacewalk-list@redhat.com
> > Betreff: Re: [Spacewalk-list] SLES15-SP1 client with spacewalk?
> >
> > Hi Robert
> > 
> > I have some SLES 15 SP1 clients registered to Spacewalk. Although, all 
> > clients were setup with SLES 15 GA before I dist-upgrade to SP1.
> > 
> > No problems so far. 
> > 
> > I use autoyast for installation and once the system is up and running I 
> > have an ansible role to attach a temporary repo with the spacewalk client, 
> > install the spacewalk client, register the client to spacewalk and remove 
> > the temporary repo.
> > 
> > Where are you having problems?
> > 
> > Regards,
> > Javier
> > 
> > -Ursprüngliche Nachricht-
> > Von: spacewalk-list-boun...@redhat.com  
> > Im Auftrag von Robert Paschedag
> > Gesendet: Friday, August 30, 2019 12:41 PM
> > An: spacewalk-listredhat.com 
> > Betreff: [Spacewalk-list] SLES15-SP1 client with spacewalk?
> > 
> > Hi,
> > 
> > anybody yet tried to register an SLES15-SP1 client to Spacewalk?
> > 
> > Of course I have some problems with the bootstrap repository. And I'm also 
> > afraid, that SUSE is totally trimmed to use the "salt" way to connecto to 
> > Uyuni or SuSE Manager.
> > 
> > So if anybody got it working with the "tranditional client" (on Spacewalk), 
> > drop a line with your bootstrap repository.
> > 
> > Thanks.
> > 
> > Robert
> > 
> > ___
> > Spacewalk-list mailing list
> > Spacewalk-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> > 
> > ___
> > Spacewalk-list mailing list
> > Spacewalk-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> >
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] SLES15-SP1 client with spacewalk?

[Robert Paschedag]

May I ask for your temporary repo package list?

That is the part I'm currently missing.

thanks,
Robert


> Gesendet: Freitag, 30. August 2019 um 12:50 Uhr
> Von: javier.flo...@gmz.migros.ch
> An: spacewalk-list@redhat.com
> Betreff: Re: [Spacewalk-list] SLES15-SP1 client with spacewalk?
>
> Hi Robert
> 
> I have some SLES 15 SP1 clients registered to Spacewalk. Although, all 
> clients were setup with SLES 15 GA before I dist-upgrade to SP1.
> 
> No problems so far. 
> 
> I use autoyast for installation and once the system is up and running I have 
> an ansible role to attach a temporary repo with the spacewalk client, install 
> the spacewalk client, register the client to spacewalk and remove the 
> temporary repo.
> 
> Where are you having problems?
> 
> Regards,
> Javier
> 
> -Ursprüngliche Nachricht-----
> Von: spacewalk-list-boun...@redhat.com  Im 
> Auftrag von Robert Paschedag
> Gesendet: Friday, August 30, 2019 12:41 PM
> An: spacewalk-listredhat.com 
> Betreff: [Spacewalk-list] SLES15-SP1 client with spacewalk?
> 
> Hi,
> 
> anybody yet tried to register an SLES15-SP1 client to Spacewalk?
> 
> Of course I have some problems with the bootstrap repository. And I'm also 
> afraid, that SUSE is totally trimmed to use the "salt" way to connecto to 
> Uyuni or SuSE Manager.
> 
> So if anybody got it working with the "tranditional client" (on Spacewalk), 
> drop a line with your bootstrap repository.
> 
> Thanks.
> 
> Robert
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] SLES15-SP1 client with spacewalk?

[Robert Paschedag]

Hi,

anybody yet tried to register an SLES15-SP1 client to Spacewalk?

Of course I have some problems with the bootstrap repository. And I'm also 
afraid, that SUSE is totally trimmed
to use the "salt" way to connecto to Uyuni or SuSE Manager.

So if anybody got it working with the "tranditional client" (on Spacewalk), 
drop a line with your bootstrap
repository.

Thanks.

Robert

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] help with ubuntu16 client and spacewalk2.9 server

[Robert Paschedag]

Can you check from the client with "apt-get", if the package "python-wadllib" 
is really an upgrade candidate?

Might be an error, that spacewalk "thinks" it is an update for the server but 
it isn't.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Nicole Beck 
Gesendet: Tue Aug 27 19:13:51 GMT+02:00 2019
An: "'spacewalk-list@redhat.com'" 
Betreff: [Spacewalk-list] help with ubuntu16 client and spacewalk2.9 server

Hello,
I'm trying to get an Ubuntu 16 xenial client setup to do updates from a 
spacewalk 2.9 server installed on CentOS7.  I am able to register the client, 
install and remove, or update a single package thru the spacewalk web 
interface. But when I try to update all of the packages on (choose system - 
Software - Packages tab - Upgrade tab - choose Select All - Upgrade packages - 
confirm), then run "rhn_check -vvv" on the client, it fails with:

...
Apt-Spacewalk: Updating sources.list
D: Failed to update package['python-wadllib', '1.3.2', '3ubuntu0.16.04.1', '', 
'all-deb']
D: Sending back response(1, 'update failed', {})
D: do_call packages.checkNeedUpdate('rhnsd=1',){}
D: Called refresh_list
Updating package profile
D: rpcServer: Calling XMLRPC registration.welcome_message
D: rpcServer: Calling XMLRPC registration.update_packages
D: local action status: (0, 'package list refreshed', {})
D: rpcServer: Calling XMLRPC registration.welcome_message

I could use the web interface to update the single package that it says it is 
failing on.

I used the steps listed in 
https://www.redhat.com/archives/spacewalk-list/2019-January/msg6.html to 
get this setup. I installed the 2.8 spacewalk client referenced in the thread, 
and I signed the repos per the documentation at 
http://www.devops-blog.net/spacewalk/gpg-signing-apt-repository-in-spacewalk. I 
checked, and I think the necessary patches referenced in that document are 
already the client and server. I used spacewalks spacewalk-repo-sync command to 
sync the Ubuntu repositories. However, I did not run the script to setup 
multiarch headers that is referenced in 
https://www.redhat.com/archives/spacewalk-list/2018-September/msg00072.html. Is 
that still needed? The documentation for Ubuntu and spacewalk isn't that great, 
some is for older versions of spacewalk, so I'm piecing things together and I'm 
not sure what is still needed and what is not, of if I installed things 
correctly.

Any suggestions are appreciated.

Thanks!
Nicole




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Debian package comparison failing.

[Robert Paschedag]

Hi Paul,

Problem has been solved. All good. Your code works. It was an outdated 
Packages.gz file.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Paul-Andre Panon 
Gesendet: Wed Jul 31 20:08:45 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Debian package comparison failing.

Well, looks like the Ubuntu apt-get is the one that's getting it wrong
here and that Spacewalk is correct (for these packages). That's what it
looked like to me on your first e-mail but I wasn't certain, however this
seems to confirm it. Now, have you tried to update with rhn_check after
approving the package updates in Spacewalk?

It's been annoying me that Ubuntu seems to take great liberties with the
Debian package versioning standards but it appears to be a new low for
them to manage to come up with versions that seem to break their own
hacked up versioning algorithms. You could try to crank up the logging on
the rhn_check, to verify that those package versions are being recommended
by Spacewalk (or look at the event history?) but if Spacewalk is
suggesting python-ethtool-0.14-1.amd64-deb and the apt-get client is
rejecting it, then the client is wrong. If that only happens with apt-get
however, then maybe there's a bug in the apt-get=>spacewalk glue/shim in
separating and parsing the package version and breaking it down into
epoch/upstream-version/Debian-version (which would be my guess with
python-gobject-2 but unfortunately doesn't make sense with the others)

Cheers,

Paul-Andre

On Tue, 30 Jul 2019 17:36:34 +0200, philippe bidault
 wrote:
>Nope, no lock or nothing similar:
>
>root@debian10:~# dpkg -l | grep python-eth
>ii  python-ethtool  0.12-1.1   amd64
>   Python bindings for the ethtool kernel interface
>
>Regards,
>Philippe.
>
>On Tue, 30 Jul 2019 at 15:02, Michael Mraka 
>wrote:
>
>> philippe bidault:
>> > Hi Michael,
>> >
>> > Here are the installed versions:
>> >
>> > root@debian10:~# dpkg -l | grep python-go
>> > ii  python-gobject  3.22.0-2   all
>> >  Python 2.x bindings for GObject - transitional package
>> > ii  python-gobject-22.28.6-13  amd64
>> >deprecated static Python bindings for the GObject library
>> > root@debian10:~# dpkg -l | grep python-eth
>> > ii  python-ethtool  0.12-1.1   amd64
>> >Python bindings for the ethtool kernel interface
>> >
>> > So this is in fact matching what appears in the "Installed Package"
column
>> > in the Spacewalk web console. The Debian 10 client just does not see
>> > the 3 updates.
>>
>> Can't they be somehow excluded / version-locked / ... etc?
>> If you use dpkg to list all available python-ethtool packages can you
>> see
>> python-ethtool-0.14-1 among them?
>>
>> > Regards,
>> > Philippe.
>> ...
>> > > > Latest Package   Installed Package
>> > > > python-ethtool-0.14-1.amd64-deb
python-ethtool-0.12-1.1.amd64-deb
>> > > > python-gobject-3.30.4-1.all-deb
python-gobject-3.22.0-2.all-deb
>> > > > python-gobject-2-2.28.6-13+b1.amd64-deb
python-gobject-2-2.28.6-13.amd64-deb
>> > > >
>> > > > But on the registered debian 10 server, "apt update" is telling
me that all
>> > > > the packages are already up-to-date.
>> > >
>> > > What version of python-ethtool, python-gobject and
>> > > python-gobject-2 do you have installed on the debian server?
>>
>> Regards,
>>
>> --
>> Michael Mr?ka
>> System Management Engineering, Red Hat
>>
>

--
At Motorola Solutions and our subsidiaries, your privacy is important to
us. That is why we have taken appropriate measures to ensure the data you
provide to us is kept secure. To learn more about how we process your
personal information, how we comply with applicable data protection laws,
and care for the security and privacy of your personal data, please review
our Privacy Policy
.
If you have any questions related to data protection and compliance with
applicable laws, please contact us at priva...@motorolasolutions.com


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Debian package comparison failing.

[Robert Paschedag]

Please check, that you repo metadata has been correctly regenerated. Might be, 
that within the channel, the new package is there, but the metadata has not 
been refreshed (the Packages.gz) is still old.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: philippe bidault 
Gesendet: Wed Jul 31 08:30:07 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Debian package comparison failing.

Hi Robert,

No, this is so strange, absolutely no trace through apt of the new packages
proposed by Spacewalk on the Debian server. I need to troubleshoot this
deeper.

root@debian10:~# apt-cache show python-gobject
Package: python-gobject
Status: install ok installed
Priority: extra
Section: oldlibs
Installed-Size: 323
Maintainer: Debian GNOME Maintainers <
pkg-gnome-maintain...@lists.alioth.debian.org>
Architecture: all
Source: pygobject
Version: 3.22.0-2
Depends: python-gi (>= 3.22.0-2), python-gobject-2
Description: Python 2.x bindings for GObject - transitional package
This package will bring the two versions of GObject Python modules: the
deprecated gobject module, and the new gobject-introspection system. It
is here for upgrade purposes only. You can remove it safely when
nothing else depends on it.
Description-md5: 0972cedec40e0869495e1025aa320af1
Homepage: https://wiki.gnome.org/Projects/PyGObject

Regards,
Philippe.

On Tue, 30 Jul 2019 at 21:53, Robert Paschedag 
wrote:

> You can also try to install one of the packages with "apt-get -o
> Debug::pkgProblemResolver install ..."
>
> Robert
>
> ⁣sent from my mobile device​
>
>
>  Originale Nachricht 
> Von: philippe bidault 
> Gesendet: Tue Jul 30 17:36:34 GMT+02:00 2019
> An: spacewalk-list@redhat.com
> Betreff: Re: [Spacewalk-list] Debian package comparison failing.
>
> Nop, no lock or nothing similar:
>
> root@debian10:~# dpkg -l | grep python-eth
> ii  python-ethtool  0.12-1.1   amd64
>Python bindings for the ethtool kernel interface
>
> Regards,
> Philippe.
>
> On Tue, 30 Jul 2019 at 15:02, Michael Mraka 
> wrote:
>
> > philippe bidault:
> > > Hi Michael,
> > >
> > > Here are the installed versions:
> > >
> > > root@debian10:~# dpkg -l | grep python-go
> > > ii  python-gobject  3.22.0-2   all
> > >  Python 2.x bindings for GObject - transitional package
> > > ii  python-gobject-22.28.6-13  amd64
> > >deprecated static Python bindings for the GObject library
> > > root@debian10:~# dpkg -l | grep python-eth
> > > ii  python-ethtool  0.12-1.1   amd64
> > >Python bindings for the ethtool kernel interface
> > >
> > > So this is in fact matching what appears in the "Installed Package"
> > column
> > > in the Spacewalk web console. The Debian 10 client just does not see
> the
> > 3
> > > updates.
> >
> > Can't they be somehow excluded / version-locked / ... etc?
> > If you use dpkg to list all available python-ethtool packages can you see
> > python-ethtool-0.14-1 among them?
> >
> > > Regards,
> > > Philippe.
> > ...
> > > > > Latest Package
> > > > Installed
> > > > > Package
> > > > > python-ethtool-0.14-1.amd64-deb
> > > > > python-ethtool-0.12-1.1.amd64-deb
> > > > > python-gobject-3.30.4-1.all-deb
> > > > > python-gobject-3.22.0-2.all-deb
> > > > > python-gobject-2-2.28.6-13+b1.amd64-deb
> > > > >  python-gobject-2-2.28.6-13.amd64-deb
> > > > >
> > > > > But on the registered debian 10 server, "apt update" is telling me
> > that
> > > > all
> > > > > the packages are already up-to-date.
> > > >
> > > > What version of python-ethtool, python-gobject and  python-gobject-2
> > > > do you have installed on the debian server?
> >
> > Regards,
> >
> > --
> > Michael Mráka
> > System Management Engineering, Red Hat
> >
> > ___
> > Spacewalk-list mailing list
> > Spacewalk-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
> 
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Debian package comparison failing.

[Robert Paschedag]

You can also try to install one of the packages with "apt-get -o 
Debug::pkgProblemResolver install ..."

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: philippe bidault 
Gesendet: Tue Jul 30 17:36:34 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Debian package comparison failing.

Nop, no lock or nothing similar:

root@debian10:~# dpkg -l | grep python-eth
ii  python-ethtool  0.12-1.1   amd64
   Python bindings for the ethtool kernel interface

Regards,
Philippe.

On Tue, 30 Jul 2019 at 15:02, Michael Mraka 
wrote:

> philippe bidault:
> > Hi Michael,
> >
> > Here are the installed versions:
> >
> > root@debian10:~# dpkg -l | grep python-go
> > ii  python-gobject  3.22.0-2   all
> >  Python 2.x bindings for GObject - transitional package
> > ii  python-gobject-22.28.6-13  amd64
> >deprecated static Python bindings for the GObject library
> > root@debian10:~# dpkg -l | grep python-eth
> > ii  python-ethtool  0.12-1.1   amd64
> >Python bindings for the ethtool kernel interface
> >
> > So this is in fact matching what appears in the "Installed Package"
> column
> > in the Spacewalk web console. The Debian 10 client just does not see the
> 3
> > updates.
>
> Can't they be somehow excluded / version-locked / ... etc?
> If you use dpkg to list all available python-ethtool packages can you see
> python-ethtool-0.14-1 among them?
>
> > Regards,
> > Philippe.
> ...
> > > > Latest Package
> > > Installed
> > > > Package
> > > > python-ethtool-0.14-1.amd64-deb
> > > > python-ethtool-0.12-1.1.amd64-deb
> > > > python-gobject-3.30.4-1.all-deb
> > > > python-gobject-3.22.0-2.all-deb
> > > > python-gobject-2-2.28.6-13+b1.amd64-deb
> > > >  python-gobject-2-2.28.6-13.amd64-deb
> > > >
> > > > But on the registered debian 10 server, "apt update" is telling me
> that
> > > all
> > > > the packages are already up-to-date.
> > >
> > > What version of python-ethtool, python-gobject and  python-gobject-2
> > > do you have installed on the debian server?
>
> Regards,
>
> --
> Michael Mráka
> System Management Engineering, Red Hat
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Debian package comparison failing.

[Robert Paschedag]

What does "apt-cache show" for each package tell? So you see the newest package 
from SW server?

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: philippe bidault 
Gesendet: Tue Jul 30 17:36:34 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Debian package comparison failing.

Nop, no lock or nothing similar:

root@debian10:~# dpkg -l | grep python-eth
ii  python-ethtool  0.12-1.1   amd64
   Python bindings for the ethtool kernel interface

Regards,
Philippe.

On Tue, 30 Jul 2019 at 15:02, Michael Mraka 
wrote:

> philippe bidault:
> > Hi Michael,
> >
> > Here are the installed versions:
> >
> > root@debian10:~# dpkg -l | grep python-go
> > ii  python-gobject  3.22.0-2   all
> >  Python 2.x bindings for GObject - transitional package
> > ii  python-gobject-22.28.6-13  amd64
> >deprecated static Python bindings for the GObject library
> > root@debian10:~# dpkg -l | grep python-eth
> > ii  python-ethtool  0.12-1.1   amd64
> >Python bindings for the ethtool kernel interface
> >
> > So this is in fact matching what appears in the "Installed Package"
> column
> > in the Spacewalk web console. The Debian 10 client just does not see the
> 3
> > updates.
>
> Can't they be somehow excluded / version-locked / ... etc?
> If you use dpkg to list all available python-ethtool packages can you see
> python-ethtool-0.14-1 among them?
>
> > Regards,
> > Philippe.
> ...
> > > > Latest Package
> > > Installed
> > > > Package
> > > > python-ethtool-0.14-1.amd64-deb
> > > > python-ethtool-0.12-1.1.amd64-deb
> > > > python-gobject-3.30.4-1.all-deb
> > > > python-gobject-3.22.0-2.all-deb
> > > > python-gobject-2-2.28.6-13+b1.amd64-deb
> > > >  python-gobject-2-2.28.6-13.amd64-deb
> > > >
> > > > But on the registered debian 10 server, "apt update" is telling me
> that
> > > all
> > > > the packages are already up-to-date.
> > >
> > > What version of python-ethtool, python-gobject and  python-gobject-2
> > > do you have installed on the debian server?
>
> Regards,
>
> --
> Michael Mráka
> System Management Engineering, Red Hat
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk 2.9 - Enabling GPG check for channels

[Robert Paschedag]

You have to check within the channel options in spacewalk, if GPG signing is 
activated.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Wenkai Chen 
Gesendet: Wed Jul 17 05:29:31 GMT+02:00 2019
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list]  Spacewalk 2.9 - Enabling GPG check for channels

HI Spacewalk users,

I just configured Spacewalk to sync from Red hat and Centos repositories. 
However, I am unsure of whether GPG check is really enabled for each channel.
I would like to enable GPG check for security reasons.
I could not find any useful resources online, apart from this article 
https://serverfault.com/questions/593281/how-to-disable-gpg-checks-per-channel-in-spacewalk
 which tells us how to disable gpg check in a channel. I did the reverse so 
that I can enable it.

However, I am not exactly sure if it works. I am also not sure for Centos 
channels, is gpg check enabled by default? Where exactly are the settings in 
spacewalk to configure this?
I understand that for standalone servers, these settings can be configured 
under the /etc/yum.repos.d/ folder files corresponding to the repository. But I 
am not exactly sure if it is similar to Spacewalk servers? Or channels in that 
manner.

Thanks.

Regards,
Wenkai








CONFIDENTIALITY NOTICE: "This email is confidential and may also be privileged. 
If this email has been sent to you in error, please delete it immediately and 
notify us. Please do not copy, distribute or disseminate part or whole of this 
email if you are not the intended recipient or if you have not been authorized 
to do so. We reserve the right, to the extent and under circumstances permitted 
by applicable laws, to monitor, retain, intercept and block email messages to 
and from our systems. Thank you."





___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] sync

[Robert Paschedag]

Just download...

⁣sent from my mobile device​


 Originale Nachricht 
Von: Ananta Chakravartula 
Gesendet: Thu Jun 27 16:16:35 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] sync

does repo sync delete any packages that are deleted in upstream? or just
downloads the updates?

Thanks,
Ananta




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] R/O user

[Robert Paschedag]

I think you can only create a read-only API user.

Robert

⁣sent from my mobile device​


 Originale Nachricht 
Von: Paul Deveau 
Gesendet: Fri Jun 21 19:25:13 GMT+02:00 2019
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] R/O user

Hi,

Has anybody ever created a read-only user for Spacewalk. I want an account that 
can look but not touch.

Thanks,

--
Paul Deveau
Université d’Ottawa|University of Ottawa






___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Reposync and proxy servers

[Robert Paschedag]

Not true...

https://github.com/spacewalkproject/spacewalk/blob/master/backend/satellite_tools/repo_plugins/yum_src.py#L137

⁣sent from my mobile device​


 Originale Nachricht 
Von: Luca Menegus 
Gesendet: Thu Jun 20 18:34:48 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Reposync and proxy servers

Hi, 
spacewalk-repo-sync uses / etc/rhn/spacewalk-repo-sync/yum.conf for 
configuration. 

Luca 

- Original Message -

> From: "Larry Clegg" 
> To: spacewalk-list@redhat.com
> Sent: Thursday, June 20, 2019 6:16:27 PM
> Subject: [Spacewalk-list] Reposync and proxy servers

> Greetings Spacewalkers,

> My environment: Spacewalk 2.9 on Centos 6.10

> Everything is working well but a question from our networking/firewall team
> has come up.

> On the Spacewalk server the /etc/yum.conf has a proxy setting that is
> supposed to force all yum http traffic thru an internal proxy server. This
> works except in the case of /usr/bin/spacewalk-repo-sync operations. It
> appears to ignore that and go directly from the SW server to the various
> external repos for sync’ing.

> Has anyone noticed this before? Is there a setting to adjust to force the
> repo-sync to go thru the proxy server?

> Thank you,

> Larry E. Clegg

> Systems Engineer (SaaS Platform Operations) | Kyriba

> [Cell Phone] +1 858-357-5579

> [Address] 9620 Towne Centre Drive | Suite 250 | San Diego, California | 92121

> www.kyriba.com | Facebook | Twitter | LinkedIn | Blog

> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list



___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update

[Robert Paschedag]

Hi Paul,

the clients you pointed to the other repo... These were also systems with X? 
Add there were no errors?

I could only think of possible mismatch of packages within the wrong repos on 
spacewalk (for example CentOS 6 packages within a CentOS 7 Channel... what 
could happen if you accidently made an error when mapping repos to channels.)

Another error could be a broken package within the channel that causes that 
issue. I only had that once, that I had 2 times the same package (with 
identical name and version but different content and size Until now, I 
don't know, how this could happen). The update always downloaded the wrong 
package that broke the update. I had to manually remove that broken package 
from spacewalk.

You're only chance is to run the update manually in verbose mode to see, what 
packages (and versions) get downloaded. Also save the Apache logfile to see, if 
there have been issues.

Then compare this to the list of packages when updating from the non-spacewalk 
repo.

Good luck.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Paul Greene 
Gesendet: Wed Jun 19 17:59:47 GMT+02:00 2019
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] Oddball question about Spacewalk possibly 
corrupting yum update

I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6
workstations, and synced it to a local yum repository.

After a few months I started adding some CentOS 7 systems to the mix, and
also synced to the same local yum repository (same server, different path
to the repositories, of course).

The Spacewalk server always seemed to have an issue getting a successful
full sync with the CentOS 7 local repository after the 7.6 series came out.
I wasn't concerned at first because the systems were configured to go to
the local yum repository anyway (configured in /etc/yum.repos.d).

After the CentOS 7.6 series came out, I started having an issue with any
machine that got the 7.6 updates where the system would freeze and lock up,
requiring a hard reboot to get it usable again. That happened on at least a
daily basis and sometimes multiple times a day. I rolled those users back
to CentOS 7.5 to get them a functioning stable machine again, and didn't
update anybody that was running 7.5. It seemed definitely related to X
windows - I could still go to a command prompt with ctrl-alt-f2 and work
from a command prompt, but X windows wouldn't come back without a hard
reboot. On a couple of servers that didn't need X windows and had the run
level set to multi-user.target, they didn't have an issue - it was only the
workstations that needed X windows.

I have access to another yum repository independent of the Spacewalk
server, and noticed if I updated a workstation to that repository and did
NOT join the machine to the Spacewalk server, they all ran fine with CentOS
7.6. As long as I didn't join them to the Spacewalk server there were no
issues. I tried deleting the CentOS 7 yum repository from the Spacewalk
server, thinking maybe the yum repository on the Spacewalk server had
gotten corrupted and was pushing out some bad files, but that didn't work.

The systems still seem to be looking to the Spacewalk server for updates,
regardless of what is in /etc/yum.repos.d.

Hopefully someone else has seen something like this before. I would either
like to remove any and all yum configurations from the Spacewalk server, if
possible, and just point to the local yum repository for any kind of
updates.

Barring that, I'm interested in updating to Spacewalk 2.9 anyway, and would
build a new 2.9 server, migrate everything over to that, and leave out any
yum repository configuration at all on that new server.

The CentOS 6 systems are fine - no issues at all with updates and/or yum
repositories.

Thanks,

PG




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Still having a problem with Python 9 error

[Robert Paschedag]

 

I think you messed something up with your "indentation".

 

Check that your changes are "aligned" correctly..

 

Robert

 


Gesendet: Dienstag, 18. Juni 2019 um 16:23 Uhr
Von: "Ellis, Merphis" 
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] Still having a problem with Python 9 error




I have tracked down a little more; think it is closer to the problem. I have found where in the rhn_check software, I have added some test to the message in the log file.

 

[Tue Jun 18 09:55:09 2019] up2date D: do_call packages.checkNeedUpdate('rhnsd=1',){}

[Tue Jun 18 09:55:09 2019] up2date 

Traceback (most recent call last):

  File "/usr/sbin/rhn_check", line 347, in __run_action

    (status, message, data) = CheckCli.__do_call(method, params, kwargs)

  File "/usr/sbin/rhn_check", line 339, in __do_call

    method = getMethod.getMethod(method, "/usr/share/rhn/", "actions")

  File "/usr/share/rhn/up2date_client/getMethod.py", line 78, in getMethod

    actions = __import__(modulename)

: unexpected indent (packages.py, line 363)

 

[Tue Jun 18 09:55:09 2019] up2date D: local action status: ((6,), 'Fatal error in Python code occured Add my name Merph', {})

[Tue Jun 18 09:55:09 2019] up2date D: rpcServer: Calling XMLRPC registration.welcome_message

 

 

The client is getting the list of files to update, but is breaking in the same place

 

[Tue Jun 18 09:55:09 2019] up2date D: local action status: ((6,), 'Fatal error in Python code occured Add my name Merph', {})

[Tue Jun 18 09:55:09 2019] up2date D: rpcServer: Calling XMLRPC registration.welcome_message

[Tue Jun 18 10:15:33 2019] up2date D: check_action{'action': "\n\npackages.update\n\n\n\n\npython\n2.6.6\n68.el6_10\n\nx86_64\n\n\npython-libs\n2.6.6\n68.el6_10\n\nx86_64\n\n\n\n\n\n", 'version': 2, 'id': 286}

[Tue Jun 18 10:15:33 2019] up2date updateLoginInfo() login info

[Tue Jun 18 10:15:33 2019] up2date D: login(forceUpdate=True) invoked

[Tue Jun 18 10:15:33 2019] up2date logging into up2date server

[Tue Jun 18 10:15:33 2019] up2date D: rpcServer: Calling XMLRPC up2date.login

[Tue Jun 18 10:15:53 2019] up2date D: writeCachedLogin() invoked

[Tue Jun 18 10:15:53 2019] up2date D: Wrote pickled loginInfo at 1560867353.31 with expiration of 1560870953.31 seconds.

[Tue Jun 18 10:15:53 2019] up2date successfully retrieved authentication token from up2date server

[Tue Jun 18 10:15:53 2019] up2date D: logininfo:{'X-RHN-Server-Id': 110052, 'X-RHN-Auth-Server-Time': '1560867351.54', 'X-RHN-Auth': 'GkU+adjGulORupddpyt6fHzMk5DxIeLUTV5J/1WP9hY=', 'X-RHN-Auth-Channels': [['nc_redhat_abis', '20190617112908', '1', '1']], 'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}

[Tue Jun 18 10:15:53 2019] up2date D: handle_action{'action': "\n\npackages.update\n\n\n\n\npython\n2.6.6\n68.el6_10\n\nx86_64\n\n\npython-libs\n2.6.6\n68.el6_10\n\nx86_64\n\n\n\n\n\n", 'version': 2, 'id': 286}

[Tue Jun 18 10:15:53 2019] up2date D: handle_action actionid = 286, version = 2

[Tue Jun 18 10:15:53 2019] up2date D: do_call packages.update([['python', '2.6.6', '68.el6_10', '', 'x86_64'], ['python-libs', '2.6.6', '68.el6_10', '', 'x86_64']],){'cache_only': None}

[Tue Jun 18 10:15:53 2019] up2date 

Traceback (most recent call last):

  File "/usr/sbin/rhn_check", line 347, in __run_action

    (status, message, data) = CheckCli.__do_call(method, params, kwargs)

  File "/usr/sbin/rhn_check", line 339, in __do_call

    method = getMethod.getMethod(method, "/usr/share/rhn/", "actions")

  File "/usr/share/rhn/up2date_client/getMethod.py", line 78, in getMethod

    actions = __import__(modulename)

: unexpected indent (packages.py, line 363)

 

[Tue Jun 18 10:15:53 2019] up2date D: Sending back response((6,), 'Fatal error in Python code occured Add my name Merph', {})

[Tue Jun 18 10:16:33 2019] up2date D: do_call packages.checkNeedUpdate('rhnsd=1',){}

[Tue Jun 18 10:16:33 2019] up2date 

Traceback (most recent call last):

  File "/usr/sbin/rhn_check", line 347, in __run_action

    (status, message, data) = CheckCli.__do_call(method, params, kwargs)

  File "/usr/sbin/rhn_check", line 339, in __do_call

    method = getMethod.getMethod(method, "/usr/share/rhn/", "actions")

  File "/usr/share/rhn/up2date_client/getMethod.py", line 78, in getMethod

    actions = __import__(modulename)

: unexpected indent (packages.py, line 363)

 

[Tue Jun 18 10:16:33 2019] up2date D: local action status: ((6,), 'Fatal error in Python code occured Add my name Merph', {})

[Tue Jun 18 10:16:33 2019] up2date D: rpcServer: Calling XMLRPC registration.welcome_message

 

 

 

 

 

 

Making plans actionable!

 

 

Regards,

 


	
		
			
			

	
		
		  
		
	
	
		 
		
		Merphis Ellis 
		
	
	
		 
		 
	
	
		 
		
		M. +1 850 556-6313 
		E. merphis.el...@us.idemia.com
		125 McAlpin Dr

		Winterville, GA 30683
		
	

			
			
			
			

	
		
		  
		
		

Re: [Spacewalk-list] Spacewalk-list Digest, Vol 133, Issue 15

[Robert Paschedag]

Well...then I think you have to go the hard way and debug script.

- deactivate osad on the client (if present)
- stop "rhnsd"
- schedule a package for installation via SW Web
- run the "rhn_check" manually by python with the debugger included
  python -i -m pdb $(which rhn_check)
- try to hit "c" to just run it and when finished, try to hit "bt" (for 
backtrace)

If you don't get a backtrace that might help you, run the script again

- search the "checkNeedUpdate" function definition (you should find in with 
"grep -r 'def checkNeedUpdate' /usr/share/rhn/*").
- Write down the full path to file and the line number of the first instruction 
within that function (needed to set a breakpoint)

- schedule software installation wia SW again
- run the rhn_check via debugger again
- instead of hitting "c", enter
  "break :"
- hit c
- That should bring you to the breakpoint.
- from there you can use "n" to "step over" or "s" to "step into" a function.

Goold luck.

Robert



> Gesendet: Montag, 17. Juni 2019 um 18:06 Uhr
> Von: "Ellis, Merphis" 
> An: "spacewalk-list@redhat.com" 
> Betreff: Re: [Spacewalk-list] Spacewalk-list Digest, Vol 133, Issue 15
>
> I have this file on the client.
> 
> -Original Message-
> From: spacewalk-list-boun...@redhat.com  
> On Behalf Of spacewalk-list-requ...@redhat.com
> Sent: Monday, June 17, 2019 11:52 AM
> To: spacewalk-list@redhat.com
> Subject: Spacewalk-list Digest, Vol 133, Issue 15
> 
> Send Spacewalk-list mailing list submissions to
>   spacewalk-list@redhat.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://www.redhat.com/mailman/listinfo/spacewalk-list
> or, via email, send a message with subject or body 'help' to
>   spacewalk-list-requ...@redhat.com
> 
> You can reach the person managing the list at
>   spacewalk-list-ow...@redhat.com
> 
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of Spacewalk-list digest..."
> 
> 
> Today's Topics:
> 
>1. Re: Python 6 error at the client (Robert Paschedag)
>2. Re: Python 6 error at the client (Ellis, Merphis)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 17 Jun 2019 17:38:19 +0200
> From: Robert Paschedag 
> To: "spacewalk-listredhat.com" 
> Subject: Re: [Spacewalk-list] Python 6 error at the client
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8
> 
> Please check on the clients with this error, if you have a script 
> /usr/share/rhn/actions/errata.py..
> 
> This does the actual work on the client. If it's missing, just copy that from 
> another client that is able to update.
> 
> Robert
> 
> 
> ?sent from my mobile device?
> 
> 
>  Originale Nachricht 
> Von: "Ellis, Merphis" 
> Gesendet: Mon Jun 17 17:09:44 GMT+02:00 2019
> An: "spacewalk-list@redhat.com" 
> Betreff: [Spacewalk-list] Python 6 error at the client
> 
> Good Morning
> 
> I am struggling to solve a python error 6 at some clients I need to update.
> My setup has some clients that connect direct to the server and some that 
> connect though a proxy.
> The systems that are direct connect are updating with no errors The systems 
> that connect thought the proxy are having some issues.
> 
> They registered and did update their package list.
> 
> When I try the update process I can see them login to the spacewalk, it looks 
> like it gets the list of files to update, but it seems like when it goes to 
> start the down load I start seeing the python 6 error.
> 
> Attached is the log from this morning attempt.
> 
> D: check_action{'action': " version='1.0'?>\n\npackages.update\n\n\n\n\npython\n2.6.6\n68.el6_10\n\nx86_64\n\n\nzabbix-release\n4.2\n1.el7\n\nnoarch\n\n\nzabbix-agent\n4.2.3\n2.el7\n\nx86_64\n\n\npython-libs\n2.6.6\n  
> ng>68.el6_10\n\nx86_64\n\n\n\n\n\n",
>  'version': 2, 'id': 232}
> updateLoginInfo() login info
> D: login(forceUpdate=True) invoked
> logging into up2date server
> D: rpcServer: Calling XMLRPC up2date.login
> D: writeCachedLogin() invoked
> D: Wrote pickled loginInfo at 1560781984.92 with expiration of 1560785584.92 
> seconds.
> successfully retrieved authentication token from up2date server
> D: logininfo:{'X-RHN-Server-Id': 110052, 'X-RHN-Auth-Server-Time': 
> '1560781984.72', 'X-RHN-Auth': 
> 'JbhToF2TJZIFNh5pQ7ZPQCyaIs8hLSYeJj2QEW/+IFw=', 'X-RHN-Auth-Channels': 
> [['nc_redhat_abbis', '20190613082916', '1', '1']], 'X-RHN-Auth-User-Id': '', 
> 'X-RHN-Auth-Expire-Of

Re: [Spacewalk-list] Python 6 error at the client

[Robert Paschedag]

Please check on the clients with this error, if you have a script 
/usr/share/rhn/actions/errata.py..

This does the actual work on the client. If it's missing, just copy that from 
another client that is able to update.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: "Ellis, Merphis" 
Gesendet: Mon Jun 17 17:09:44 GMT+02:00 2019
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] Python 6 error at the client

Good Morning

I am struggling to solve a python error 6 at some clients I need to update.
My setup has some clients that connect direct to the server and some that 
connect though a proxy.
The systems that are direct connect are updating with no errors
The systems that connect thought the proxy are having some issues.

They registered and did update their package list.

When I try the update process I can see them login to the spacewalk, it looks 
like it gets the list of files to update, but it seems like when it goes to 
start the down load I start seeing the python 6 error.

Attached is the log from this morning attempt.

D: check_action{'action': "\n\npackages.update\n\n\n\n\npython\n2.6.6\n68.el6_10\n\nx86_64\n\n\nzabbix-release\n4.2\n1.el7\n\nnoarch\n\n\nzabbix-agent\n4.2.3\n2.el7\n\nx86_64\n\n\npython-libs\n2.6.6\n68.el6_10\n\nx86_64\n\n\n\n\n\n",
 'version': 2, 'id': 232}
updateLoginInfo() login info
D: login(forceUpdate=True) invoked
logging into up2date server
D: rpcServer: Calling XMLRPC up2date.login
D: writeCachedLogin() invoked
D: Wrote pickled loginInfo at 1560781984.92 with expiration of 1560785584.92 
seconds.
successfully retrieved authentication token from up2date server
D: logininfo:{'X-RHN-Server-Id': 110052, 'X-RHN-Auth-Server-Time': 
'1560781984.72', 'X-RHN-Auth': 'JbhToF2TJZIFNh5pQ7ZPQCyaIs8hLSYeJj2QEW/+IFw=', 
'X-RHN-Auth-Channels': [['nc_redhat_abbis', '20190613082916', '1', '1']], 
'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
D: handle_action{'action': "\n\npackages.update\n\n\n\n\npython\n2.6.6\n68.el6_10\n\nx86_64\n\n\nzabbix-release\n4.2\n1.el7\n\nnoarch\n\n\nzabbix-agent\n4.2.3\n2.el7\n\nx86_64\n\n\npython-libs\n2.6.6\n68.el6_10\n\nx86_64\n\n\n\n\n\n",
 'version': 2, 'id': 232}
D: handle_action actionid = 232, version = 2
D: do_call packages.update([['python', '2.6.6', '68.el6_10', '', 'x86_64'], 
['zabbix-release', '4.2', '1.el7', '', 'noarch'], ['zabbix-agent', '4.2.3', 
'2.el7', '', 'x86_64'], ['python-libs', '2.6.6', '68.el6_10', '', 
'x86_64']],){'cache_only': None}
Loading "rhnplugin" plugin
Loading "product-id" plugin
Loading "refresh-packagekit" plugin
Loading "subscription-manager" plugin
Running "postconfig" handler for "subscription-manager" plugin
Updating Subscription Management repositories.
Config time: 2.163
Running "init" handler for "rhnplugin" plugin
D: rpcServer: Calling XMLRPC up2date.listChannels
This system is receiving updates from RHN Classic or RHN Satellite.
Looking for repo options for [main]
Looking for repo options for [nc_redhat_abbis]
Repo 'nc_redhat_abbis' setting option 'enabled' = '1'
Repo 'nc_redhat_abbis' setting option 'gpgcheck' = '1'
Repo 'nc_redhat_abbis' setting option 'timeout' = '120'
Reading Local RPMDB
rpmdb time: 0.000
repo time: 0.001
Setting up Package Sacks
updateLoginInfo() login info
D: login(forceUpdate=True) invoked
logging into up2date server
D: rpcServer: Calling XMLRPC up2date.login
D: writeCachedLogin() invoked
D: Wrote pickled loginInfo at 1560782035.34 with expiration of 1560785635.34 
seconds.
successfully retrieved authentication token from up2date server
D: logininfo:{'X-RHN-Server-Id': 110052, 'X-RHN-Auth-Server-Time': 
'1560782035.13', 'X-RHN-Auth': 'YPMRQ5cttlyqb5kMiibCFq8qzAxoqGtcOFEuzqM1UtM=', 
'X-RHN-Auth-Channels': [['nc_redhat_abbis', '20190613082916', '1', '1']], 
'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
updateLoginInfo() login info
D: login(forceUpdate=True) invoked
logging into up2date server
D: rpcServer: Calling XMLRPC up2date.login
D: writeCachedLogin() invoked
D: Wrote pickled loginInfo at 1560782055.04 with expiration of 1560785655.04 
seconds.
successfully retrieved authentication token from up2date server
D: logininfo:{'X-RHN-Server-Id': 110052, 'X-RHN-Auth-Server-Time': 
'1560782054.83', 'X-RHN-Auth': 'gS8OPv4PrKLFmRAALeYVNBJZN9vcyieE4eb49WpDSME=', 
'X-RHN-Auth-Channels': [['nc_redhat_abbis', '20190613082916', '1', '1']], 
'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
updateLoginInfo() login info
D: login(forceUpdate=True) invoked
logging into up2date server
D: rpcServer: Calling XMLRPC up2date.login
D: writeCachedLogin() invoked
D: Wrote pickled loginInfo at 1560782080.36 with expiration of 1560785680.36 
seconds.
successfully retrieved authentication token from up2date server
D: logininfo:{'X-RHN-Server-Id': 110052, 'X-RHN-Auth-Server-Time': 
'1560782080.16', 'X-RHN-Auth': 'siQ2d6ni4AGEJc0KQflhUo0ROTfGag9LzHYeaa1HQD4=', 
'X-RHN-Auth-Channels': [['nc_redhat_abbis', 

Re: [Spacewalk-list] Is the rhnsd service required to be able to communicate with a spacewalk server?

[Robert Paschedag]

It would be of interest for me, why this should be shut down? It shouldn't 
listen for connections. So what security concerns are there?

⁣sent from my mobile device​


 Originale Nachricht 
Von: William Hongach 
Gesendet: Thu Jun 13 20:15:47 GMT+02:00 2019
An: "spacewalk-list@redhat.com" 
Betreff: Re: [Spacewalk-list] Is the rhnsd service required to be able to 
communicate with a spacewalk server?

Hello,

It is the service (or related timer) that runs rhn_check based on the interval 
specified in /etc/sysconfig/rhn/rhnsd.  This is how Spacewalk clients check in 
with the server for queued tasks.  There should be a man page available for 
rhnsd.

If you shut it down, the client will not check in with the server, unless 
rhn_check is run manually or via a scheduled task like cron.  However, if you 
run osad (I do not) then I do not believe you need it since that is a different 
model.  But your security team may also flag osad like they flagged rhnsd.

From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Paul Greene
Sent: Thursday, June 13, 2019 1:56 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Is the rhnsd service required to be able to 
communicate with a spacewalk server?

What is the actual function of rhnsd? What is actually being lost if its not 
running?

On Thu, Jun 13, 2019 at 1:02 PM William Hongach 
mailto:william.hong...@marist.edu>> wrote:
Hello,

I suppose you could run rhn_check out of cron if you did not want rhnsd to 
schedule it.

From: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
On Behalf Of Paul Greene
Sent: Thursday, June 13, 2019 12:31 PM
To: Spacewalk-list@redhat.com
Subject: [Spacewalk-list] Is the rhnsd service required to be able to 
communicate with a spacewalk server?

Our security group is telling me, based on a Nessus scan, that I need to 
disable the rhnsd service.

Is the rhnsd service required to be able to communicate with a spacewalk server?
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] Debian / Ubuntu admins: Possible fix for missing Multi-Arch header in Packages.gz...

[Robert Paschedag]

Hi Spacewalkers,

I think many of the Debian / Ubuntu admins are using (maybe a further modified 
version) of my spacewalk-add-debian-multiarch-header.py script to inject the 
currently missing 'Multi-Arch' header into the Packages.gz file.

I'm currently testing very much with Uyuni and yesterday, I managed to 
successfully test my patch to also import and write the 'Multi-Arch' header 
into the Packages.gz file.

It is a very simple change and currently only adds the 'Multi-Arch' header (and 
not possibly all other headers that might still be missing).

But until today, all other missing headers are not as important as the 
'Multi-Arch' one.

So with this PR (https://github.com/spacewalkproject/spacewalk/pull/697), the 
debian / ubuntu repositories could be synchronized by Spacewalk and the 
Multi-Arch header does not have to be injected later. Unfortunetaly, all Debian 
/ Ubuntu packages would have to be completly removed and resynced :-(

I'm sorryI'm currently not able to really test this on a Spacewalk 
testsystem. But as long as the 'import', 'sql' and Package.gz writing code 
hopefully did not change that much in Uyuni, it should work.

Maybe someone can try and test this on a Spacewalk testserver?

Kind regards,
Robert

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Best Practice for adding a child Channel?

[Robert Paschedag]

If you add the channel to the activation key *after* the client has been 
registered with that key, nothing will be done on the client.

That's by design. New clients *will* get the child channel when registering 
with that key.

If you need to modify many clients now, use the SSM.

Robert


⁣sent from my mobile device​


 Originale Nachricht 
Von: Guy Matz 
Gesendet: Tue Jun 11 22:21:28 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: [Spacewalk-list] Best Practice for adding a child Channel?

Hi!  Is there a best way to add child channels?  I've added a channel, and
made it a child channel in the "Activation Keys" section of the UI, but the
channel does not show up on the client unless I add the child channel to
the system.  Is there a better way?  Am I missing something?

Thanks a lot,
Guy




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Syncing with SLES for SAP repos

[Robert Paschedag]

Am 11. Mai 2019 01:30:07 MESZ schrieb Paul-Andre Panon 
:
>On Tue, 16 Apr 2019 12:27:09 +, "Sadri, Wafa (BITBW)"
> wrote;
>To: "spacewalk-list@redhat.com" 
>
>>Dear Paul-Andre,
>
>>coincidentally I'm having a very similar issue. We fixed this issue in
>2.7 and it's now back because SW has
>>fundamentally changed the way it syncs repos (either from 2.7 to 2.8
>or
>2.8 to 2.9 - not sure yet). Either way, the
>>problem - afaik - seems to be that the download.py file (in which we
>implemented the fix) doesn't get called until
>>later in the sync/download process. The error though occurs before
>this
>python script is called, resulting in the
>>problem you and I are having. So far I haven't yet figured out a way
>to
>fix this. At the moment I'm looking into the
>> reposync.py file as I'm suspecting the error to be caused here.
>
>>best regards,
>>Wafa
>
>Belated thanks.  I had some issues with licenses that appeared to have
>expired on the SUSE site (even though we had support), so I only got
>back
>to this recently when we found a solution to that issue. While I still
>need to set up SUSE 12 for some servers, I'm also needing to set up
>SUSE
>11 for SAP so I decided to look at the latter again. It looks like some
>of
>the problems I was having must have been due to mistyped URLs. I did
>manage to get working the two SLES 11 for SAP channels with which I was
>having problems, after re-creating the URLS - one with more success
>than
>another. In the case of the SLES 11 for SAP Base Pool channel, I got
>Spacewalk to talk to the repository, but it appears to be quite unhappy
>with the packages. It's choking when trying to import the packages, and
>the channel for that repo shows no packages.
>
>2019/05/08 18:16:03 -07:00 Command: ['/usr/bin/spacewalk-repo-sync',
>'--channel', 'sles11sp4-sap-base', '--type', 'yum']
>2019/05/08 18:16:03 -07:00 Sync of channel started.
>2019/05/08 18:16:03 -07:00
>2019/05/08 18:16:03 -07:00   Processing repository with URL:
>https://:@nu.novell.com/repo
>/$RCE/SLE11-SP4-SAP-Pool/sle-11-x86_64
>2019/05/08 18:16:05 -07:00 Packages in repo:  3094
>2019/05/08 18:16:14 -07:00 Packages already synced:  0
>2019/05/08 18:16:14 -07:00 Packages to sync:  3094
>2019/05/08 18:16:14 -07:00 New packages to download:49
>2019/05/08 18:16:14 -07:00   Downloading packages:
>2019/05/08 18:16:14 -07:00 1/49 :
>ClusterTools2-2.5.3-14.1.noarch.rpm
>2019/05/08 18:16:14 -07:00 2/49 : SAPHanaSR-0.149-0.11.5.noarch.rpm
>2019/05/08 18:16:14 -07:00 3/49 :
>ClusterTools2-doc-2.5.3-14.1.noarch.rpm
>2019/05/08 18:16:14 -07:00 4/49 : HANA-Firewall-1.0-2.1.noarch.rpm
>2019/05/08 18:16:14 -07:00 5/49 :
>NetworkManager-openvpn-gnome-0.7.1-3.7.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 6/49 :
>SUSE_SLES_SAP-release-DVD-11.4-1.2.x86_64.rpm
>2019/05/08 18:16:15 -07:00 7/49 :
>SUSE_SLES_SAP-release-11.4-1.2.x86_64.rpm
>2019/05/08 18:16:15 -07:00 8/49 :
>HANA-Firewall-doc-1.0-2.1.noarch.rpm
>2019/05/08 18:16:15 -07:00 9/49 :
>check-create-certificate-0.5-0.2.3.noarch.rpm
>2019/05/08 18:16:15 -07:00 10/49 :
>SAPHanaSR-doc-0.149-0.11.5.noarch.rpm
>2019/05/08 18:16:15 -07:00 11/49 : collectd-4.9.4-0.13.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 12/49 : clamsap-0.9.8.0-0.5.5.x86_64.rpm
>2019/05/08 18:16:15 -07:00 13/49 :
>compat-32bit-2009.1.19-1.8.x86_64.rpm
>2019/05/08 18:16:15 -07:00 14/49 :
>compat-openssl097g-32bit-0.9.7g-146.22.29.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 15/49 :
>compat-openssl097g-0.9.7g-146.22.29.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 16/49 :
>libarchive2-2.5.5-5.19.x86_64.rpm
>2019/05/08 18:16:15 -07:00 17/49 : libunwind-0.98.6-26.6.x86_64.rpm
>2019/05/08 18:16:15 -07:00 18/49 :
>libcollectdclient-devel-4.9.4-0.13.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 19/49 :
>libcollectdclient0-4.9.4-0.13.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 20/49 :
>libstatgrab6-0.16-0.1.30.x86_64.rpm
>2019/05/08 18:16:15 -07:00 21/49 :
>lighttpd-mod_cml-1.4.20-2.54.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 22/49 :
>lighttpd-mod_magnet-1.4.20-2.54.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 23/49 :
>lighttpd-mod_mysql_vhost-1.4.20-2.54.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 24/49 :
>lighttpd-mod_rrdtool-1.4.20-2.54.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 25/49 :
>lighttpd-mod_trigger_b4_dl-1.4.20-2.54.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 26/49 :
>lighttpd-mod_webdav-1.4.20-2.54.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 27/49 :
>patterns-webyast-5-0.5.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 28/49 :
>openhpi-clients-2.12.0-1.31.x86_64.rpm
>2019/05/08 18:16:15 -07:00 29/49 :
>rubygem-locale-2.0.5-0.3.3.x86_64.rpm
>2019/05/08 18:16:15 -07:00 30/49 :
>rubygem-gettext-2.1.0-5.5.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 31/49 :
>ruby-devel-1.8.7.p357-0.9.17.1.x86_64.rpm
>2019/05/08 18:16:15 -07:00 32/49 :
>rubygem-haml-3.1.6-0.9.3.2.x86_64.rpm

Re: [Spacewalk-list] spacewalk schedule does not run at time specified

[Robert Paschedag]

Am 7. Mai 2019 14:09:45 MESZ schrieb stephen.wea...@bluesky.co.uk:
>Hi All
>
>No idea what I have missed or got wrong here.
>Spacewalk Server 2.9 all services come up as OK,
>OSAD up and running, all clients running Spacewalk client 2.9
>OSAD up and running on all clients, updates and reboots
>all work with out a problem, but do not at the time specified,
>here is an example of a recent schedule, at first I thought it

Do I read correctly? ALL jobs are functioning but do not run at the time 
scheduled, right?

Then there is an issue with osad and rhnsd on the client is doing the job (via 
interval)

You could try to stop osad on one client, remove the "osad-auth.conf" within 
/etc/sysconfig/rhn and start it again. It should generate a new "id". Then try 
again with a remote command.

Robert

>something to do with the INTERVAL setting, but as I am using
>OSAD this should have no effect, or am I mistaken, these
>are customer servers, so we inform them when the updates
>are happening, but these timing's are making us look incompetent?
>
>Anyone got any ideas?
>
>ScheduleActual
>21:00   22:06
>21:10   22:15
>21:20   22:27
>21:30   23:42
>21:40   22:48
>21:50   22:57
>22:00   00:57
>22:10   00:42
>22:20   23:45
>22:30   23:35
>22:40   23:45
>22:50   23:55
>23:00   00:06
>23:10   00:17
>23:20   00:26
>
>Thanks.
>
>
>---
>This email has been checked for viruses by AVG.
>https://www.avg.com


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] CentOS 6 2.9 Repo Install Fail - curl: (60) Peer certificate cannot be authenticated with known CA certificates

[Robert Paschedag]

Am 6. Mai 2019 04:52:53 MESZ schrieb Francis Mondia :
>Hi All,
>
>Getting this when installing the Spacewalk client on CentOS 6 from the
>official guide:
>
>$ sudo rpm -Uvh
>https://copr-be.cloud.fedoraproject.org/results/@spacewalkproject/spacewalk-2.9/epel-6-x86_64/00830557-spacewalk-repo/spacewalk-repo-2.9-4.el6.noarch.rpm
>[sudo] password for adminuser:
>Retrieving
>https://copr-be.cloud.fedoraproject.org/results/@spacewalkproject/spacewalk-2.9/epel-6-x86_64/00830557-spacewalk-repo/spacewalk-repo-2.9-4.el6.noarch.rpm
>curl: (60) Peer certificate cannot be authenticated with known CA
>certificates
>More details here: http://curl.haxx.se/docs/sslcerts.html

This only tells you that the websites certificate has not been signed by one of 
the default "trusted" CAs that are installed by default on the client.

Robert

>
>curl performs SSL certificate verification by default, using a "bundle"
>of Certificate Authority (CA) public keys (CA certs). If the default
>bundle file isn't adequate, you can specify an alternate file
>using the --cacert option.
>If this HTTPS server uses a certificate signed by a CA represented in
>the bundle, the certificate verification probably failed due to a
>problem with the certificate (it might be expired, or the name might
>not match the domain name in the URL).
>If you'd like to turn off curl's verification of the certificate, use
>the -k (or --insecure) option.
>error: skipping
>https://copr-be.cloud.fedoraproject.org/results/@spacewalkproject/spacewalk-2.9/epel-6-x86_64/00830557-spacewalk-repo/spacewalk-repo-2.9-4.el6.noarch.rpm
>- transfer failed
>
>
>CentOS 7 works fine and wondering what's wrong with the CentOS 6 repo.
>
>Kind regards,
>--
>Francis Mondia
>Engineering Systems Administrator
>
>francis.mon...@endace.com
>www.endace.com
>[Endace-horizontal (250x74 pixels high)]
>
>This message contains Endace confidential information intended only for
>specific recipients and is not to be forwarded to anyone else.  If you
>have received this message in error, please delete it immediately. 
>Thank you.


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] avoiding the thundering herd

[Robert Paschedag]

Am 10. April 2019 17:25:12 MESZ schrieb Guy Matz :
>I think the correct answer is RTFM  :-)  Thanks, Robert, your
>suggestion is
>what I'm looking for.  yum also has a "--randomwait" option:
>
>--randomwait=[time in minutes]
>  Sets the maximum amount of time yum will wait before
>performing a command  -  it  randomizes
>  over the time.
>
>so "--downloadonly --randomwait" was what I was looking for!  Thanks!!
>

But then you can do the upgrade with one command only. No need to pre-stage.

Robert

>On Wed, Apr 10, 2019 at 3:24 AM Robert Paschedag
>
>wrote:
>
>> Am 9. April 2019 23:40:35 MESZ schrieb Guy Matz :
>> >Hello!  I am going to be upgrading a number of servers and don't
>want
>> >them
>> >all banging on my spacewalk server at the same time to download
>> >packages .
>> >. .  I was hoping to be able to "stage" the updates on the servers
>> >before-hand, then trigger the update via spacewalk.  I was hoping
>this
>> >might result in a faster upgrade process on the day of upgrades,
>making
>> >the
>> >upgrade a bit easier to deal with . . .
>> >
>> >Any thoughts on how to go about this?  Any suggestions otherwise?
>> >
>>
>> Hmm..I think I would run a remote command on all clients to do an
>> "upgrade" with "download only" option.
>>
>> That prefixed with a sleep $RANDOM for example so the packages get
>staged
>> on the clients and all not running at the same time.
>>
>> Then schedule upgrade of all hosts via spacewalk or - again - run
>remote
>> command to upgrade now.
>>
>> If no new packages have been added to the channels, the clients might
>only
>> refresh the channel metadata and the rest should run "offline"
>>
>> Robert
>>
>> >Thanks a lot,
>> >Guy
>>
>>
>> --
>> sent from my mobile device
>>


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] avoiding the thundering herd

[Robert Paschedag]

Am 9. April 2019 23:40:35 MESZ schrieb Guy Matz :
>Hello!  I am going to be upgrading a number of servers and don't want
>them
>all banging on my spacewalk server at the same time to download
>packages .
>. .  I was hoping to be able to "stage" the updates on the servers
>before-hand, then trigger the update via spacewalk.  I was hoping this
>might result in a faster upgrade process on the day of upgrades, making
>the
>upgrade a bit easier to deal with . . .
>
>Any thoughts on how to go about this?  Any suggestions otherwise?
>

Hmm..I think I would run a remote command on all clients to do an "upgrade" 
with "download only" option.

That prefixed with a sleep $RANDOM for example so the packages get staged on 
the clients and all not running at the same time.

Then schedule upgrade of all hosts via spacewalk or - again - run remote 
command to upgrade now.

If no new packages have been added to the channels, the clients might only 
refresh the channel metadata and the rest should run "offline"

Robert

>Thanks a lot,
>Guy


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk Postgres database

[Robert Paschedag]

Am 9. April 2019 17:12:32 MESZ schrieb Giles Coochey :
>
>On 09/04/2019 15:58, Elizabeth Graf wrote:
>> I was looking at instructions for upgrading our spacewalk 2.7
>instance 
>> and the instructions stressed backing up the database.  Problem is 
>> when I installed spacewalk I let it install itself and it created the
>
>> database with no input from me.  So I don’t know what user I could 
>> login as to do backups.  Does anyone know if this automated install 
>> uses a generic username/password?  I followed the how to install page
>
>> on github to let spacewalk setup Postgres.
>>
>I might be wrong, but doesn't postgres use PAM authentication by 
>default? So you can just do this as root.

No. Look into /etc/rhn/rhn.conf

All information is in there.

Robert



-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Clients not Updating / Missing Python Files

[Robert Paschedag]

Am 4. April 2019 12:40:07 MESZ schrieb "Ellis, Merphis" 
:
>When I run the rhn_check it does now pull a list of required updates
>and then I see it try to go out to the internet to get the packages. 
>Is there a way to have it pull them from the spacewalk server?  This is
>a problem with our proxy in that it does not work very well when we try
>to connect to the public repos using https (port 443).
>
>We have always worked around this by only connecting using http
>(port80).

Just disable all non spacewalk repos and try again.
Robert

>
>-Original Message-
>From: Robert Paschedag 
>Sent: Thursday, April 04, 2019 2:53 AM
>To: Ellis, Merphis ;
>spacewalk-list@redhat.com
>Cc: Patel, Nainesh 
>Subject: RE: RE: [Spacewalk-list] Clients not Updating / Missing Python
>Files
>
>Am 3. April 2019 19:05:56 MESZ schrieb "Ellis, Merphis"
>:
>>I cleaned out one of the centos systems and changed the repo I was
>>using to
>>https://copr-be.cloud.fedoraproject.org/archive/spacewalk/2.7-client/RH
>>EL/7/x86_64/ Did the yum install again and now I see the files in the
>>/usr/share/rhn that I believe I should.
>>
>>Reran the rhnreg_ks with the  --force
>>
>>I now am getting the error message "local action status: ((6,), 'Fatal
>>error in Python code occurred', {}) "
>>
>>Attached is log from the rhn_check -vv
>
>And you really have the "errata.py" within the "actions" folder?
>
>Robert
>
>>
>>
>>
>>-Original Message-
>>From: Robert Paschedag 
>>Sent: Wednesday, April 03, 2019 8:36 AM
>>To: Ellis, Merphis 
>>Subject: Aw: RE: [Spacewalk-list] Clients not Updating / Missing
>Python
>>Files
>>
>>
>>
>>> Gesendet: Mittwoch, 03. April 2019 um 13:13 Uhr
>>> Von: "Ellis, Merphis" 
>>> An: "Robert Paschedag" 
>>> Betreff: RE: [Spacewalk-list] Clients not Updating / Missing Python
>>> Files
>>>
>>> I am doing a yum install for
>>> rhn-client-tools
>>> rhn-check
>>> rhn-setup
>>> rhnsd
>>> m2crypto
>>> yum-rhn-plugin
>>> rhncfg-action
>>>
>>What distribution are you running?
>>
>>Maybe there is also a "rhncfg" package, but the /usr/share/rhn/actions
>>directory should at least be there, as you installed the
>rhncfg-actions
>>package.
>>
>>Robert
>>
>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: Robert Paschedag 
>>> Sent: Wednesday, April 03, 2019 1:38 AM
>>> To: Ellis, Merphis 
>>> Subject: Re: [Spacewalk-list] Clients not Updating / Missing Python
>>> Files
>>>
>>> Am 2. April 2019 23:50:24 MESZ schrieb "Ellis, Merphis"
>>:
>>> >I am not getting any of the folders in the /use/share/rhn after a
>>yum
>>> >install of the packages and registering of the client
>>>
>>> Which packages did you install?
>>>
>>>
>>> >
>>> >Sent from my iPhone
>>> >
>>> >> On Apr 2, 2019, at 5:48 PM, Robert Paschedag
>>> > wrote:
>>> >>
>>> >> Am 2. April 2019 19:02:45 MESZ schrieb "Ellis, Merphis"
>>> >:
>>> >>> Does this need port 5222 open to work?
>>> >>
>>> >> No. Port 5222 is used by osad from client to server (5222). If
>>> >> you're
>>> >not using osad, the clients "rhnsd" or "rhn_check" will do this via
>>> >port 443
>>> >>
>>> >> Robert
>>> >>>
>>> >>> -Original Message-
>>> >>> From: Robert Paschedag 
>>> >>> Sent: Monday, April 01, 2019 2:43 PM
>>> >>> To: spacewalk-list@redhat.com; Ellis, Merphis
>>> >>> ; spacewalk-list@redhat.com
>>> >>> Subject: Re: [Spacewalk-list] Clients not Updating / Missing
>>> >>> Python Files
>>> >>>
>>> >>> Am 1. April 2019 20:18:51 MESZ schrieb "Ellis, Merphis"
>>> >>> :
>>> >>>> I am trying to get a spacewalk server up and going.   I was
>able
>>to
>>> >>>> install Spacewalk 2.7 and getting several clients registered.
>>I
>>> >am
>>> >>>> now trying to push a couple updates from a public repo.  The
>>> >Spacewalk
>>> >>>> server 

Re: [Spacewalk-list] Clients not Updating / Missing Python Files

[Robert Paschedag]

Am 3. April 2019 19:05:56 MESZ schrieb "Ellis, Merphis" 
:
>I cleaned out one of the centos systems and changed the repo I was
>using to
>https://copr-be.cloud.fedoraproject.org/archive/spacewalk/2.7-client/RHEL/7/x86_64/
>Did the yum install again and now I see the files in the /usr/share/rhn
>that I believe I should.
>
>Reran the rhnreg_ks with the  --force 
>
>I now am getting the error message "local action status: ((6,), 'Fatal
>error in Python code occurred', {}) "
>
>Attached is log from the rhn_check -vv

And you really have the "errata.py" within the "actions" folder?

Robert

>
>  
>
>-Original Message-
>From: Robert Paschedag  
>Sent: Wednesday, April 03, 2019 8:36 AM
>To: Ellis, Merphis 
>Subject: Aw: RE: [Spacewalk-list] Clients not Updating / Missing Python
>Files
>
>
>
>> Gesendet: Mittwoch, 03. April 2019 um 13:13 Uhr
>> Von: "Ellis, Merphis" 
>> An: "Robert Paschedag" 
>> Betreff: RE: [Spacewalk-list] Clients not Updating / Missing Python 
>> Files
>>
>> I am doing a yum install for
>> rhn-client-tools
>> rhn-check
>> rhn-setup
>> rhnsd
>> m2crypto
>> yum-rhn-plugin
>> rhncfg-action
>>
>What distribution are you running?
>
>Maybe there is also a "rhncfg" package, but the /usr/share/rhn/actions
>directory should at least be there, as you installed the rhncfg-actions
>package.
>
>Robert
>
>
>>
>>
>>
>> -Original Message-
>> From: Robert Paschedag 
>> Sent: Wednesday, April 03, 2019 1:38 AM
>> To: Ellis, Merphis 
>> Subject: Re: [Spacewalk-list] Clients not Updating / Missing Python 
>> Files
>>
>> Am 2. April 2019 23:50:24 MESZ schrieb "Ellis, Merphis"
>:
>> >I am not getting any of the folders in the /use/share/rhn after a
>yum 
>> >install of the packages and registering of the client
>>
>> Which packages did you install?
>>
>>
>> >
>> >Sent from my iPhone
>> >
>> >> On Apr 2, 2019, at 5:48 PM, Robert Paschedag
>> > wrote:
>> >>
>> >> Am 2. April 2019 19:02:45 MESZ schrieb "Ellis, Merphis"
>> >:
>> >>> Does this need port 5222 open to work?
>> >>
>> >> No. Port 5222 is used by osad from client to server (5222). If 
>> >> you're
>> >not using osad, the clients "rhnsd" or "rhn_check" will do this via 
>> >port 443
>> >>
>> >> Robert
>> >>>
>> >>> -Original Message-
>> >>> From: Robert Paschedag 
>> >>> Sent: Monday, April 01, 2019 2:43 PM
>> >>> To: spacewalk-list@redhat.com; Ellis, Merphis 
>> >>> ; spacewalk-list@redhat.com
>> >>> Subject: Re: [Spacewalk-list] Clients not Updating / Missing 
>> >>> Python Files
>> >>>
>> >>> Am 1. April 2019 20:18:51 MESZ schrieb "Ellis, Merphis"
>> >>> :
>> >>>> I am trying to get a spacewalk server up and going.   I was able
>to
>> >>>> install Spacewalk 2.7 and getting several clients registered.  
>I
>> >am
>> >>>> now trying to push a couple updates from a public repo.  The
>> >Spacewalk
>> >>>> server has populated the channel with the updates.
>> >>>>
>> >>>> I scheduled the updates, this task fails with an Client
>execution 
>> >>>> returned "Invalid function call attempted " (code 6)
>> >>>
>> >>> The "errata.py" action is missing in /usr/share/rhn/actions
>> >>>
>> >>> It is responsible for package installation..
>> >>>
>> >>> You can just copy this file from another client (e.g. CentOS)
>> >>>
>> >>> Robert
>> >>>
>> >>>>
>> >>>> Me a google spend several hours looking and it runs out that on
>> >these
>> >>>> clients the /usr/share/rhn only has a couple certificates?
>> >>>>
>> >>>> I am missing the folders actions, certs classes config-defaults 
>> >>>> lib osad rhnpush satellite_exported search server up2date_client
>
>> >>>> upload_server wsgi  and servers other files?
>> >>>>
>> >>>> Anyone know which rpm I need to look at rerunning? Or how to fix
>> >this?
>> >>>>

Re: [Spacewalk-list] change package install location

[Robert Paschedag]

Am 2. April 2019 17:06:49 MESZ schrieb "Peirce, Dean" :
>Hi all,
>I’ve got a bit of a head scratcher…
>
>I have a third party rpm to install on all my centos servers. Not a big
>deal. But I’ve been directed to install it in a non-default location
>/foo/bar. The package is relocatable, so adding the –prefix solves that
>requirement.
>
>How can I add this package to spacewalk2.7 and have it install into the
>/foo/bar path automagically? The solution will need to be able to
>handle package updates too.
>
>Thanks in advance!

That is it

http://rpmrebuild.sourceforge.net

Robert

>
>Dean


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] change package install location

[Robert Paschedag]

Am 2. April 2019 17:06:49 MESZ schrieb "Peirce, Dean" :
>Hi all,
>I’ve got a bit of a head scratcher…
>
>I have a third party rpm to install on all my centos servers. Not a big
>deal. But I’ve been directed to install it in a non-default location
>/foo/bar. The package is relocatable, so adding the –prefix solves that
>requirement.
>
>How can I add this package to spacewalk2.7 and have it install into the
>/foo/bar path automagically? The solution will need to be able to
>handle package updates too.
>
>Thanks in advance!

I doubt SW can do this. You should execute a remote command on all clients and 
give the needed parameters and options to "zypper", "dnf" or "apt". But I also 
think this is a one time run. So if you want to upgrade, you would have to run 
this again.

Another solution is to rebuild the rpm and specify another --prefix.

There is a tool for this. Have to search for it again. Have it not on my mind 
right now.

Robert

>
>Dean


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

jvm 1| 2019/03/15 15:56:07 | 2019-03-15 15:56:07,759 
> [DefaultQuartzScheduler_Worker-4] ERROR 
> com.redhat.rhn.taskomatic.task.CobblerSyncTask - Stack 
> trace:java.lang.RuntimeException: XmlRpcException calling cobbler.
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:72)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:52)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.frontend.integration.IntegrationService.authorize(IntegrationService.java:114)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(IntegrationService.java:67)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.manager.kickstart.cobbler.CobblerCommand.(CobblerCommand.java:68)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.manager.kickstart.cobbler.CobblerDistroSyncCommand.(CobblerDistroSyncCommand.java:52)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:78)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:88)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:186)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> org.quartz.core.JobRunShell.run(JobRunShell.java:216)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
> INFO   | jvm 1| 2019/03/15 15:56:07 | Caused by: 
> redstone.xmlrpc.XmlRpcException: The response could not be parsed.
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:435)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   ... 10 more
> INFO   | jvm 1| 2019/03/15 15:56:07 | Caused by: java.io.IOException: 
> Server returned HTTP response code: 502 for URL: http:/FQDN:80/cobbler_api
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   at 
> redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
> INFO   | jvm 1| 2019/03/15 15:56:07 |   ... 13 more
> INFO   | jvm 1| 2019/03/15 15:56:07 | 
> 
> 
> 
> - Mail original -
> De: "Robert Paschedag" 
> À: "spacewalk-list" 
> Cc: "spacewalk-list" 
> Envoyé: Vendredi 15 Mars 2019 13:33:18
> Objet: Re: [Spacewalk-list] Really slow unresponsive GUI
> 
> Ahh.then we might hunt the "wrong error". Try to increase the timeout in 
> httpd.
> 
> Try this. Maybe it helps. Conf file should be in /etc/httpd/conf/httpd.conf
> 
> https://www.rcannings.com/cobbler-proxy-502/
> 
> Robert
> 
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Queueing a hardware refresh

[Robert Paschedag]

You could also run an "rhn-profile-sync" on the clients (maybe as daily 
cronjob).

But this script might fail, if you have old-style ifconfig "aliases" (e.g. 
eth0:0) interfaces.

Robert


> Gesendet: Freitag, 15. März 2019 um 15:01 Uhr
> Von: "William Hongach" 
> An: "spacewalk-list@redhat.com" 
> Betreff: [Spacewalk-list] Queueing a hardware refresh
>
> Good Morning All,
> 
> I noticed something interesting in the web gui of our Spacewalk 2.8 server.  
> I'm actually surprised that I did not notice it sooner.  If I change the IP 
> address of a client, this change is not reflected in Systems > Details > 
> Overview > System Info.  This same outdated information for network 
> interfaces is also reflected on the Hardware > Networking tab as well.  
> 
> Our clients check in hourly but this information is not getting updated on 
> the server.  For some reason I assumed it would, but this is not the case 
> because the check in is only looking for scheduled tasks.  I discovered that 
> I needed to visit the Hardware tab and click "Schedule Hardware Refresh" to 
> queue a push of this information from the client.
> 
> This can also be accomplished on the command line using "spacecmd 
> system_schedulehardwarerefresh" so I leave this here as a tip for our newer 
> users after stumbling upon the issue myself.  Have a good day.
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

Ahh.then we might hunt the "wrong error". Try to increase the timeout in 
httpd.

Try this. Maybe it helps. Conf file should be in /etc/httpd/conf/httpd.conf

https://www.rcannings.com/cobbler-proxy-502/

Robert



> Gesendet: Freitag, 15. März 2019 um 13:15 Uhr
> Von: "Lionel Caignec" 
> An: spacewalk-list 
> Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
>
> Ok thank you i will look ce spacewalk-setup process and taskomatic_user 
> password into cobbler.
> 
> About performance of my server, in fact all is fine but when i try to open 
> kickstart related page then server is slow for hours or until reboot.
> 
> The script get exception about 60 seconds (seems like timeout) but no error 
> in cobbler.log
> 
> 
> 
> - Mail original -
> De: "Robert Paschedag" 
> À: "spacewalk-list" 
> Envoyé: Vendredi 15 Mars 2019 12:26:05
> Objet: Re: [Spacewalk-list] Really slow unresponsive GUI
> 
> you said, your server is really slow...
> 
> Do you get the exception after some time (maybe about 60 seconds) or do you 
> get it immediately?
> 
> How long did that testscript run, before it terminated?
> 
> Robert
> 
> 
> > Gesendet: Freitag, 15. März 2019 um 10:57 Uhr
> > Von: "Robert Paschedag" 
> > An: spacewalk-list@redhat.com
> > Cc: spacewalk-list 
> > Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
> >
> > 
> > 
> > > Gesendet: Freitag, 15. März 2019 um 10:29 Uhr
> > > Von: "Robert Paschedag" 
> > > An: "Lionel Caignec" 
> > > Cc: spacewalk-list 
> > > Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
> > >
> > > Am 15. März 2019 09:51:31 MEZ schrieb Lionel Caignec :
> > > >Sorry my bad a read to quickly...
> > > >
> > > >I got error  : 
> > > >python test_cobbler_sw_login.py 
> > > >Satellite auth.checkAuthToken (should be 1): 
> > > >1
> > > >Trying cobbler login (should be a random token): 
> > > >sdfsdfsdfsdlfknnsldfn
> > > 
> > > That string was returned??
> > > 
> > > Well... If the script fails, it really looks like the "password" listed 
> > > as "..._secret_1" within /etc/rhn/rhn.conf is wrong for the 
> > > "taskomatic_user" within cobbler.
> > > 
> > > I would start to search, how this password is generated within the 
> > > "spacewall-setup" script or search, how the password could be changed 
> > > within cobbler. Maybe one of the spacewalk developers has an idea?
> > > 
> > > Robert
> > 
> > See also the wiki here
> > 
> > https://github.com/spacewalkproject/spacewalk/wiki/CobblerIntegration
> > 
> > Maybe you should try another user? Maybe you have a user-specific problem?
> > 
> > Robert
> > 
> > > 
> > > >Traceback (most recent call last):
> > > >  File "test_cobbler_sw_login.py", line 23, in 
> > > >print(c.login(user, passw))
> > > >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
> > > >return self.__send(self.__name, args)
> > > >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request
> > > >verbose=self.__verbose
> > > >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
> > > >return self.single_request(host, handler, request_body, verbose)
> > > > File "/usr/lib64/python2.7/xmlrpclib.py", line 1321, in single_request
> > > >response.msg,
> > > >xmlrpclib.ProtocolError:  > > >Proxy Error>
> > > >
> > > >
> > > >
> > > >So i encouter the "secret" problem you talk about?
> > > >
> > > >
> > > >Thank you again for your help.
> > > >
> > > >Lionel
> > > >
> > > >
> > > >- Mail original -
> > > >De: "Robert Paschedag" 
> > > >À: "Lionel Caignec" 
> > > >Cc: "spacewalk-list" 
> > > >Envoyé: Vendredi 15 Mars 2019 09:14:39
> > > >Objet: Aw: Re:  Re: [Spacewalk-list] Really slow unresponsive GUI
> > > >
> > > >Saw the other mail I just wrote? You have to modify the import path
> > > >from
> > > >
> > > >from common ... 
> > > >
> > > >to
> > > >
> > > >from spacewalk.common.rhnConfig
> > > >
> > > >Robert
> > > 
> > > 
> > > -- 
> > > sent from my mobile device
> > > 
> > > ___
> > > Spacewalk-list mailing list
> > > Spacewalk-list@redhat.com
> > > https://www.redhat.com/mailman/listinfo/spacewalk-list
> > 
> > ___
> > Spacewalk-list mailing list
> > Spacewalk-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

you said, your server is really slow...

Do you get the exception after some time (maybe about 60 seconds) or do you get 
it immediately?

How long did that testscript run, before it terminated?

Robert


> Gesendet: Freitag, 15. März 2019 um 10:57 Uhr
> Von: "Robert Paschedag" 
> An: spacewalk-list@redhat.com
> Cc: spacewalk-list 
> Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
>
> 
> 
> > Gesendet: Freitag, 15. März 2019 um 10:29 Uhr
> > Von: "Robert Paschedag" 
> > An: "Lionel Caignec" 
> > Cc: spacewalk-list 
> > Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
> >
> > Am 15. März 2019 09:51:31 MEZ schrieb Lionel Caignec :
> > >Sorry my bad a read to quickly...
> > >
> > >I got error  : 
> > >python test_cobbler_sw_login.py 
> > >Satellite auth.checkAuthToken (should be 1): 
> > >1
> > >Trying cobbler login (should be a random token): 
> > >sdfsdfsdfsdlfknnsldfn
> > 
> > That string was returned??
> > 
> > Well... If the script fails, it really looks like the "password" listed as 
> > "..._secret_1" within /etc/rhn/rhn.conf is wrong for the "taskomatic_user" 
> > within cobbler.
> > 
> > I would start to search, how this password is generated within the 
> > "spacewall-setup" script or search, how the password could be changed 
> > within cobbler. Maybe one of the spacewalk developers has an idea?
> > 
> > Robert
> 
> See also the wiki here
> 
> https://github.com/spacewalkproject/spacewalk/wiki/CobblerIntegration
> 
> Maybe you should try another user? Maybe you have a user-specific problem?
> 
> Robert
> 
> > 
> > >Traceback (most recent call last):
> > >  File "test_cobbler_sw_login.py", line 23, in 
> > >print(c.login(user, passw))
> > >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
> > >return self.__send(self.__name, args)
> > >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request
> > >verbose=self.__verbose
> > >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
> > >return self.single_request(host, handler, request_body, verbose)
> > > File "/usr/lib64/python2.7/xmlrpclib.py", line 1321, in single_request
> > >response.msg,
> > >xmlrpclib.ProtocolError:  > >Proxy Error>
> > >
> > >
> > >
> > >So i encouter the "secret" problem you talk about?
> > >
> > >
> > >Thank you again for your help.
> > >
> > >Lionel
> > >
> > >
> > >- Mail original -
> > >De: "Robert Paschedag" 
> > >À: "Lionel Caignec" 
> > >Cc: "spacewalk-list" 
> > >Envoyé: Vendredi 15 Mars 2019 09:14:39
> > >Objet: Aw: Re:  Re: [Spacewalk-list] Really slow unresponsive GUI
> > >
> > >Saw the other mail I just wrote? You have to modify the import path
> > >from
> > >
> > >from common ... 
> > >
> > >to
> > >
> > >from spacewalk.common.rhnConfig
> > >
> > >Robert
> > 
> > 
> > -- 
> > sent from my mobile device
> > 
> > ___
> > Spacewalk-list mailing list
> > Spacewalk-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

> Gesendet: Freitag, 15. März 2019 um 10:29 Uhr
> Von: "Robert Paschedag" 
> An: "Lionel Caignec" 
> Cc: spacewalk-list 
> Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
>
> Am 15. März 2019 09:51:31 MEZ schrieb Lionel Caignec :
> >Sorry my bad a read to quickly...
> >
> >I got error  : 
> >python test_cobbler_sw_login.py 
> >Satellite auth.checkAuthToken (should be 1): 
> >1
> >Trying cobbler login (should be a random token): 
> >sdfsdfsdfsdlfknnsldfn
> 
> That string was returned??
> 
> Well... If the script fails, it really looks like the "password" listed as 
> "..._secret_1" within /etc/rhn/rhn.conf is wrong for the "taskomatic_user" 
> within cobbler.
> 
> I would start to search, how this password is generated within the 
> "spacewall-setup" script or search, how the password could be changed within 
> cobbler. Maybe one of the spacewalk developers has an idea?
> 
> Robert

See also the wiki here

https://github.com/spacewalkproject/spacewalk/wiki/CobblerIntegration

Maybe you should try another user? Maybe you have a user-specific problem?

Robert

> 
> >Traceback (most recent call last):
> >  File "test_cobbler_sw_login.py", line 23, in 
> >print(c.login(user, passw))
> >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
> >return self.__send(self.__name, args)
> >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request
> >verbose=self.__verbose
> >  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
> >return self.single_request(host, handler, request_body, verbose)
> > File "/usr/lib64/python2.7/xmlrpclib.py", line 1321, in single_request
> >response.msg,
> >xmlrpclib.ProtocolError:  >Proxy Error>
> >
> >
> >
> >So i encouter the "secret" problem you talk about?
> >
> >
> >Thank you again for your help.
> >
> >Lionel
> >
> >
> >- Mail original -
> >De: "Robert Paschedag" 
> >À: "Lionel Caignec" 
> >Cc: "spacewalk-list" 
> >Envoyé: Vendredi 15 Mars 2019 09:14:39
> >Objet: Aw: Re:  Re: [Spacewalk-list] Really slow unresponsive GUI
> >
> >Saw the other mail I just wrote? You have to modify the import path
> >from
> >
> >from common ... 
> >
> >to
> >
> >from spacewalk.common.rhnConfig
> >
> >Robert
> 
> 
> -- 
> sent from my mobile device
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

Am 15. März 2019 09:51:31 MEZ schrieb Lionel Caignec :
>Sorry my bad a read to quickly...
>
>I got error  : 
>python test_cobbler_sw_login.py 
>Satellite auth.checkAuthToken (should be 1): 
>1
>Trying cobbler login (should be a random token): 
>sdfsdfsdfsdlfknnsldfn

That string was returned??

Well... If the script fails, it really looks like the "password" listed as 
"..._secret_1" within /etc/rhn/rhn.conf is wrong for the "taskomatic_user" 
within cobbler.

I would start to search, how this password is generated within the 
"spacewall-setup" script or search, how the password could be changed within 
cobbler. Maybe one of the spacewalk developers has an idea?

Robert

>Traceback (most recent call last):
>  File "test_cobbler_sw_login.py", line 23, in 
>print(c.login(user, passw))
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
>return self.__send(self.__name, args)
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request
>verbose=self.__verbose
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
>return self.single_request(host, handler, request_body, verbose)
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1321, in single_request
>response.msg,
>xmlrpclib.ProtocolError: Proxy Error>
>
>
>
>So i encouter the "secret" problem you talk about?
>
>
>Thank you again for your help.
>
>Lionel
>
>
>- Mail original -
>De: "Robert Paschedag" 
>À: "Lionel Caignec" 
>Cc: "spacewalk-list" 
>Envoyé: Vendredi 15 Mars 2019 09:14:39
>Objet: Aw: Re:  Re: [Spacewalk-list] Really slow unresponsive GUI
>
>Saw the other mail I just wrote? You have to modify the import path
>from
>
>from common ... 
>
>to
>
>from spacewalk.common.rhnConfig
>
>Robert


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

Saw the other mail I just wrote? You have to modify the import path from

from common ... 

to

from spacewalk.common.rhnConfig

Robert


> Gesendet: Freitag, 15. März 2019 um 09:11 Uhr
> Von: "Lionel Caignec" 
> An: "Robert Paschedag" 
> Cc: spacewalk-list 
> Betreff: Re: Aw: Re: [Spacewalk-list] Really slow unresponsive GUI
>
> Hi,
> 
> thank you, yes for the FQDN just replace my server name.
> 
> The script give "   print "Couldn't load needed libs, Are you sure you are 
> running this on a satellite?""
> 
> Here is the content of /usr/share/rhn : 
> 
> certs
> classes
> config-defaults
> lib
> osad
> RHN-GPG-KEY
> RHN-ORG-TRUSTED-SSL-CERT
> RHN-ORG-TRUSTED-SSL-CERT.1
> RHN-ORG-TRUSTED-SSL-CERT.2
> RHN-ORG-TRUSTED-SSL-CERT.3
> RHN-ORG-TRUSTED-SSL-CERT.4
> RHNS-CA-CERT
> satellite_exporter
> search
> server
> startup.pl
> upload_server
> wsgi
> 
> 
> 
> 
> - Mail original -
> De: "Robert Paschedag" 
> À: "spacewalk-list" 
> Cc: "Lionel Caignec" , "spacewalk-list" 
> 
> Envoyé: Vendredi 15 Mars 2019 08:55:37
> Objet: Aw: Re: [Spacewalk-list] Really slow unresponsive GUI
> 
> > Gesendet: Freitag, 15. März 2019 um 08:35 Uhr
> > Von: "Robert Paschedag" 
> > An: "Lionel Caignec" 
> > Cc: "spacewalk-listredhat.com" 
> > Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
> >
> > 
> > 
> > > Gesendet: Donnerstag, 14. März 2019 um 21:53 Uhr
> > > Von: "Lionel Caignec" 
> > > An: "Robert Paschedag" 
> > > Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
> > >
> > > no problem with cobbler is running like all other service.
> > > when i try to telnet to cobbler port i get process responding.
> > > 
> > > I'm really lost. Is it possible my kickstart profile are corrupted which 
> > > give a bug with cobbler?
> > > 
> > > - Mail original -
> > > De: "Robert Paschedag" 
> > > À: "spacewalk-list" , "Lionel Caignec" 
> > > , "spacewalk-list" 
> > > Envoyé: Jeudi 14 Mars 2019 17:24:16
> > > Objet: Re: [Spacewalk-list] Really slow unresponsive GUI
> > > 
> > > Am 14. März 2019 12:58:23 MEZ schrieb Lionel Caignec :
> > > > Hi,
> > > >
> > > >finally i managed to get the source of the bug, it's about then link
> > > >between tomcat and cobbler. The bug appears only when i try to view
> > > >kickstart profiles.
> > > >
> > > >In cobbler i get this error message : 
> > > >Wed Mar 13 12:06:01 2019 - INFO | Exception Info:
> > > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1770,
> > > >in _dispatch
> > > >return method_handle(*params)
> > > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1598,
> > > >in token_check
> > > >self.__validate_token(token)
> > > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1510,
> > > >in __validate_token
> > > >raise CX("invalid token: %s" % token)
> > > >
> > > >
> > > >In tomcat log i get this error :
> > > >mars 13, 2019 12:11:38 PM org.apache.catalina.core.StandardWrapperValve
> > > >invoke
> > > >GRAVE: Servlet.service() for servlet [action] in context with path
> > > >[/rhn] threw exception [java.lang.RuntimeException: XmlRpcException
> > > >calling cobbler.] with root cause
> > 
> > 
> > > >java.io.IOException: Server returned HTTP response code: 502 for URL:
> > > >http://FQDN:80/cobbler_api
> > 
> > Hmmdid you replace the original server hostname with "FQDN" here in the 
> > log output?
> > 
> > Robert
> 
> Please see this test script. Does this succeed?
> 
> https://github.com/spacewalkproject/spacewalk/blob/9be948a4a01d0dd41baed0c6d0032a2078d336d3/java/scripts/test_cobbler_sw_login.py
> 
> Robert
> 
> > 
> > > >at
> > > >sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894)
> > > >at
> > > >sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
> > > >  at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
> > > >at redstone.xmlrpc.XmlRpc

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

> Gesendet: Freitag, 15. März 2019 um 08:55 Uhr
> Von: "Robert Paschedag" 
> An: spacewalk-list@redhat.com
> Cc: "spacewalk-listredhat.com" 
> Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
>
> 
> 
> > Gesendet: Freitag, 15. März 2019 um 08:35 Uhr
> > Von: "Robert Paschedag" 
> > An: "Lionel Caignec" 
> > Cc: "spacewalk-listredhat.com" 
> > Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
> >
> > 
> > 
> > > Gesendet: Donnerstag, 14. März 2019 um 21:53 Uhr
> > > Von: "Lionel Caignec" 
> > > An: "Robert Paschedag" 
> > > Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
> > >
> > > no problem with cobbler is running like all other service.
> > > when i try to telnet to cobbler port i get process responding.
> > > 
> > > I'm really lost. Is it possible my kickstart profile are corrupted which 
> > > give a bug with cobbler?
> > > 
> > > - Mail original -
> > > De: "Robert Paschedag" 
> > > À: "spacewalk-list" , "Lionel Caignec" 
> > > , "spacewalk-list" 
> > > Envoyé: Jeudi 14 Mars 2019 17:24:16
> > > Objet: Re: [Spacewalk-list] Really slow unresponsive GUI
> > > 
> > > Am 14. März 2019 12:58:23 MEZ schrieb Lionel Caignec :
> > > > Hi,
> > > >
> > > >finally i managed to get the source of the bug, it's about then link
> > > >between tomcat and cobbler. The bug appears only when i try to view
> > > >kickstart profiles.
> > > >
> > > >In cobbler i get this error message : 
> > > >Wed Mar 13 12:06:01 2019 - INFO | Exception Info:
> > > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1770,
> > > >in _dispatch
> > > >return method_handle(*params)
> > > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1598,
> > > >in token_check
> > > >self.__validate_token(token)
> > > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1510,
> > > >in __validate_token
> > > >raise CX("invalid token: %s" % token)
> > > >
> > > >
> > > >In tomcat log i get this error :
> > > >mars 13, 2019 12:11:38 PM org.apache.catalina.core.StandardWrapperValve
> > > >invoke
> > > >GRAVE: Servlet.service() for servlet [action] in context with path
> > > >[/rhn] threw exception [java.lang.RuntimeException: XmlRpcException
> > > >calling cobbler.] with root cause
> > 
> > 
> > > >java.io.IOException: Server returned HTTP response code: 502 for URL:
> > > >http://FQDN:80/cobbler_api
> > 
> > Hmmdid you replace the original server hostname with "FQDN" here in the 
> > log output?
> > 
> > Robert
> 
> Please see this test script. Does this succeed?
> 
> https://github.com/spacewalkproject/spacewalk/blob/9be948a4a01d0dd41baed0c6d0032a2078d336d3/java/scripts/test_cobbler_sw_login.py

You have to modify the try / except block. The "import common" is wrong (at 
least, it didn't work for me). Had to give more path

sys.path.append('/usr/share/rhn')
try:
   from spacewalk.common.rhnConfig import initCFG, CFG
except:

If this does not succeed from your spacewalk server, of course (see the 
localhost), then it seems your "secret" got screwed up. These got created 
within the spacewalk setup and I don't know how to fix this.

Robert


> 
> Robert
> 
> > 
> > > >at
> > > >sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894)
> > > >at
> > > >sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
> > > >  at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
> > > >at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
> > > >at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
> > > >at
> > > >com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
> > > >at
> > > >com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:52)
> > > >at
> > > >com.redhat.rhn.frontend.integration.IntegrationService.authorize(IntegrationService.java:114)
> > > >at
> > > >com.redhat.rhn.frontend.integration.Integr

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

> Gesendet: Freitag, 15. März 2019 um 08:35 Uhr
> Von: "Robert Paschedag" 
> An: "Lionel Caignec" 
> Cc: "spacewalk-listredhat.com" 
> Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
>
> 
> 
> > Gesendet: Donnerstag, 14. März 2019 um 21:53 Uhr
> > Von: "Lionel Caignec" 
> > An: "Robert Paschedag" 
> > Betreff: Re: [Spacewalk-list] Really slow unresponsive GUI
> >
> > no problem with cobbler is running like all other service.
> > when i try to telnet to cobbler port i get process responding.
> > 
> > I'm really lost. Is it possible my kickstart profile are corrupted which 
> > give a bug with cobbler?
> > 
> > - Mail original -
> > De: "Robert Paschedag" 
> > À: "spacewalk-list" , "Lionel Caignec" 
> > , "spacewalk-list" 
> > Envoyé: Jeudi 14 Mars 2019 17:24:16
> > Objet: Re: [Spacewalk-list] Really slow unresponsive GUI
> > 
> > Am 14. März 2019 12:58:23 MEZ schrieb Lionel Caignec :
> > > Hi,
> > >
> > >finally i managed to get the source of the bug, it's about then link
> > >between tomcat and cobbler. The bug appears only when i try to view
> > >kickstart profiles.
> > >
> > >In cobbler i get this error message : 
> > >Wed Mar 13 12:06:01 2019 - INFO | Exception Info:
> > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1770,
> > >in _dispatch
> > >return method_handle(*params)
> > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1598,
> > >in token_check
> > >self.__validate_token(token)
> > >File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1510,
> > >in __validate_token
> > >raise CX("invalid token: %s" % token)
> > >
> > >
> > >In tomcat log i get this error :
> > >mars 13, 2019 12:11:38 PM org.apache.catalina.core.StandardWrapperValve
> > >invoke
> > >GRAVE: Servlet.service() for servlet [action] in context with path
> > >[/rhn] threw exception [java.lang.RuntimeException: XmlRpcException
> > >calling cobbler.] with root cause
> 
> 
> > >java.io.IOException: Server returned HTTP response code: 502 for URL:
> > >http://FQDN:80/cobbler_api
> 
> Hmmdid you replace the original server hostname with "FQDN" here in the 
> log output?
> 
> Robert

Please see this test script. Does this succeed?

https://github.com/spacewalkproject/spacewalk/blob/9be948a4a01d0dd41baed0c6d0032a2078d336d3/java/scripts/test_cobbler_sw_login.py

Robert

> 
> > >at
> > >sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894)
> > >at
> > >sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
> > >  at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
> > >at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
> > >at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
> > >at
> > >com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
> > >at
> > >com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:52)
> > >at
> > >com.redhat.rhn.frontend.integration.IntegrationService.authorize(IntegrationService.java:114)
> > >at
> > >com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(IntegrationService.java:74)
> > >at
> > >com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.getConnection(CobblerXMLRPCHelper.java:93)
> > >at
> > >com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.getConnection(CobblerXMLRPCHelper.java:83)
> > >at
> > >com.redhat.rhn.manager.kickstart.KickstartLister.listCobblerProfiles(KickstartLister.java:436)
> > >at
> > >com.redhat.rhn.frontend.action.kickstart.KickstartsSetupAction.execute(KickstartsSetupAction.java:64)
> > >at
> > >org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425)
> > >at
> > >org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:229)
> > >at
> > >com.redhat.rhn.frontend.struts.RhnRequestProcessor.process(RhnRequestProcessor.java:105)
> > >at
> > >org.apache.struts.action.ActionServlet.process(ActionServlet.java:1926)
> > >at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:451)
> > >at 

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

Am 14. März 2019 12:58:23 MEZ schrieb Lionel Caignec :
> Hi,
>
>finally i managed to get the source of the bug, it's about then link
>between tomcat and cobbler. The bug appears only when i try to view
>kickstart profiles.
>
>In cobbler i get this error message : 
>Wed Mar 13 12:06:01 2019 - INFO | Exception Info:
>File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1770,
>in _dispatch
>return method_handle(*params)
>File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1598,
>in token_check
>self.__validate_token(token)
>File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 1510,
>in __validate_token
>raise CX("invalid token: %s" % token)
>
>
>In tomcat log i get this error :
>mars 13, 2019 12:11:38 PM org.apache.catalina.core.StandardWrapperValve
>invoke
>GRAVE: Servlet.service() for servlet [action] in context with path
>[/rhn] threw exception [java.lang.RuntimeException: XmlRpcException
>calling cobbler.] with root cause
>java.io.IOException: Server returned HTTP response code: 502 for URL:
>http://FQDN:80/cobbler_api
>at
>sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894)
>at
>sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
>  at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
>at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
>at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
>at
>com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
>at
>com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerLoginCommand.java:52)
>at
>com.redhat.rhn.frontend.integration.IntegrationService.authorize(IntegrationService.java:114)
>at
>com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(IntegrationService.java:74)
>at
>com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.getConnection(CobblerXMLRPCHelper.java:93)
>at
>com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.getConnection(CobblerXMLRPCHelper.java:83)
>at
>com.redhat.rhn.manager.kickstart.KickstartLister.listCobblerProfiles(KickstartLister.java:436)
>at
>com.redhat.rhn.frontend.action.kickstart.KickstartsSetupAction.execute(KickstartsSetupAction.java:64)
>at
>org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425)
>at
>org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:229)
>at
>com.redhat.rhn.frontend.struts.RhnRequestProcessor.process(RhnRequestProcessor.java:105)
>at
>org.apache.struts.action.ActionServlet.process(ActionServlet.java:1926)
>at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:451)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:624)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>at
>org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>at
>com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:107)
>at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>at
>com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129)
>at
>com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77)
>at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>at
>com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter.doFilter(LocalizedEnvironmentFilter.java:67)
>at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>at
>com.redhat.rhn.frontend.servlets.EnvironmentFilter.doFilter(EnvironmentFilter.java:101)
>at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>at
>com.redhat.rhn.frontend.servlets.SessionFilter.doFilter(SessionFilter.java:58)
>at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>at
>com.redhat.rhn.frontend.servlets.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:97)
>at

Re: [Spacewalk-list] rhn_check and yum lock

[Robert Paschedag]

Am 12. März 2019 03:01:31 MEZ schrieb "Zhou, Rui A. (NSB - CN/Shanghai)" 
:
>Hi：dears
>One problem I encountered was that if the process of rhn_check did not
>start, the client would report the system not checking in with
>Spacewalk. But If I start it(/bin/systemctl restart rhnsd.service), the
>yum execution would be locked.
>I understand that the rhn_check  process starts automatically every
>four hours, but sometime it doesn't seem like that. So who knows about
>the process or what information can be shared? Thank you very much!
>
>[root@FNSHA190 blueadmin]# service rhnsd status
>Redirecting to /bin/systemctl status rhnsd.service
>* rhnsd.service - Spacewalk Server daemon
>Loaded: loaded (/usr/lib/systemd/system/rhnsd.service; static; vendor
>preset: disabled)
>   Active: active (running) since Tue 2019-03-12 09:38:35 CST; 2s ago
>Main PID: 22200 (rhn_check)
>   CGroup: /system.slice/rhnsd.service
>   `-22200 /usr/bin/python2 /usr/sbin/rhn_check
>
>Mar 12 09:38:35 FNSHA190 systemd[1]: Started Spacewalk Server daemon.
>Mar 12 09:38:37 FNSHA190 rhn_check[22200]: Repository base is listed
>more than once in the configuration
>Mar 12 09:38:37 FNSHA190 rhn_check[22200]: Repository updates is listed
>more than once in the configuration
>Mar 12 09:38:37 FNSHA190 rhn_check[22200]: Repository extras is listed
>more than once in the configuration
>[root@FNSHA190 blueadmin]# yum remove lrzsz
>Loaded plugins: fastestmirror, langpacks
>Repository base is listed more than once in the configuration
>Repository updates is listed more than once in the configuration
>Repository extras is listed more than once in the configuration
>Existing lock /var/run/yum.pid: another copy is running as pid 22200.
>Another app is currently holding the yum lock; waiting for it to
>exit...
>  The other application is: rhn_check
>Memory :  31 M RSS (1.4 GB VSZ)
>Started: Tue Mar 12 09:38:35 2019 - 00:31 ago
>State  : Sleeping, pid: 22200
>Another app is currently holding the yum lock; waiting for it to
>exit...
>  The other application is: rhn_check
>Memory :  31 M RSS (1.4 GB VSZ)
>Started: Tue Mar 12 09:38:35 2019 - 00:33 ago
>State  : Sleeping, pid: 22200

I sometimes had such errors. This might happen, if the repo tool (yum, dnf, 
apt, etc.) might have a problem and trying to ask "interactively" for 
assistance (or make a choice).

Had this a few times in Debian when some php packages should be updated and 
debconf (or whatever) tried to ask me, which config file I should use... The 
new or old (or view diff, etc.).

You can try to find the open fd of the running process with "ls -l 
/proc/PID/fd/" and see, if you find something like this in some log file.

If not, kill the process and run "rhn_check -vvv" and see, if it hangs 
again.

Robert



-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

Am 8. März 2019 16:55:47 MEZ schrieb Lionel Caignec :
>Hi Phil,
>
>thank for your help. No error about java heap space, but tried to
>configure taskomatic memory like you said without success.
>
>I setup the kickstart part long time ago, just using satellite redhat
>doc.

Errors within catalina.log?

Robert

>
>- Mail original -
>De: "P Cookson" 
>À: "spacewalk-list" 
>Envoyé: Vendredi 8 Mars 2019 16:43:23
>Objet: Re: [Spacewalk-list] Really slow unresponsive GUI
>
>Hi Lionel
>
>Have you looked in /var/log/rhn/rhn_taskomatic_daemon.log too? After
>seeing "java.lang.OutOfMemoryError: Java heap space" messages, in
>there, I changed config for Taskomatic but not sure if this is relevant
>for you?
>
>Current maxmemory (Xmx) can be seen by checking status of Taskomatic:
>
># systemctl status taskomatic.service
>
>I increased from 256 to 4096:
>
># grep taskomatic.java.maxmemory /etc/rhn/rhn.conf
>taskomatic.java.maxmemory=4096
>#
>
>Then re-started Spacewalk:
>
># spacewalk-service restart
>
>Also, I've noted you've said something about using Kickstart. After
>patching for some time I need to start looking at provisioning, too, so
>if you have any notes/links about setup that would be useful.
>
>
>Regards
>Phil
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
> On Behalf Of caig...@cines.fr
>Sent: 08 March 2019 14:59
>To: spacewalk-list 
>Subject: [Spacewalk-list] Really slow unresponsive GUI
>
>Hi,
>
>i'm writing here because i've a strange behaviour with no clue on how
>to resolve it. 
>There is no load on CPU, ram is mostly free, no IO wait, no processus
>stuck a 100%. In log file (tomcat/postresql,...) nothing about error or
>warning.
>No recent modification on the system.
>
>When i want to access spacewalk web interface (or API) this one
>sometimes answer after a very long time, and sometimes get error 500.
>Same behaviour with the spacecmd cli command.
>
>I really don't understand because i've another spacewalk on another
>server and this one work like a charm.
>
>My setup : VM with 2vpcu 8Gb RAM near 200 clients spacewalk 2.8, used
>only for patching and sometimes kickstart new server.
> JAVA_OPTS -Xms2048m -Xmx2048m, tried with 4096 but no difference.
>
>I don't know which log to put here due to the fact i found no error
>trace.
>
>For now the only solution I imagine is to backup and restore to a new
>server freshly installed my spacewalk.
>
>Thank you for help.
>
>--
>Lionel Caignec 
>
>Centre Informatique National de l' Enseignement Supérieur 
>950 rue de Saint Priest 
>34097 MONTPELLIER Cedex 5 
>Tel : (33) 04 67 14 14 14
>Fax : (33)04 67 52 37 63 
>https://www.cines.fr
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Really slow unresponsive GUI

[Robert Paschedag]

On 3/8/19 4:43 PM, p.cook...@bham.ac.uk wrote:
> Hi Lionel
>
> Have you looked in /var/log/rhn/rhn_taskomatic_daemon.log too? After seeing 
> "java.lang.OutOfMemoryError: Java heap space" messages, in there, I changed 
> config for Taskomatic but not sure if this is relevant for you?
>
> Current maxmemory (Xmx) can be seen by checking status of Taskomatic:
>
> # systemctl status taskomatic.service
>
> I increased from 256 to 4096:
>
> # grep taskomatic.java.maxmemory /etc/rhn/rhn.conf
> taskomatic.java.maxmemory=4096
> #

Yes, Lionel,

as Phil suggested, I would only increase the taskomatic memory settings.
I think increasing this generally might be too much on a 8 GB RAM
server. Just try it with 2048 for taskomatic first and increase, if you
still see OutOfMemory errors.

Robert

>
> Then re-started Spacewalk:
>
> # spacewalk-service restart
>
> Also, I've noted you've said something about using Kickstart. After patching 
> for some time I need to start looking at provisioning, too, so if you have 
> any notes/links about setup that would be useful.
>
>
> Regards
> Phil
>
> -Original Message-
> From: spacewalk-list-boun...@redhat.com  
> On Behalf Of caig...@cines.fr
> Sent: 08 March 2019 14:59
> To: spacewalk-list 
> Subject: [Spacewalk-list] Really slow unresponsive GUI
>
> Hi,
>
> i'm writing here because i've a strange behaviour with no clue on how to 
> resolve it.
> There is no load on CPU, ram is mostly free, no IO wait, no processus stuck a 
> 100%. In log file (tomcat/postresql,...) nothing about error or warning.
> No recent modification on the system.
>
> When i want to access spacewalk web interface (or API) this one sometimes 
> answer after a very long time, and sometimes get error 500. Same behaviour 
> with the spacecmd cli command.
>
> I really don't understand because i've another spacewalk on another server 
> and this one work like a charm.
>
> My setup : VM with 2vpcu 8Gb RAM near 200 clients spacewalk 2.8, used only 
> for patching and sometimes kickstart new server.
>  JAVA_OPTS -Xms2048m -Xmx2048m, tried with 4096 but no difference.
>
> I don't know which log to put here due to the fact i found no error trace.
>
> For now the only solution I imagine is to backup and restore to a new server 
> freshly installed my spacewalk.
>
> Thank you for help.
>
> --
> Lionel Caignec
>
> Centre Informatique National de l' Enseignement Supérieur
> 950 rue de Saint Priest
> 34097 MONTPELLIER Cedex 5
> Tel : (33) 04 67 14 14 14
> Fax : (33)04 67 52 37 63
> https://www.cines.fr
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] pxe install error

[Robert Paschedag]

Am 2. März 2019 03:33:20 MEZ schrieb "Zhou, Rui A. (NSB - CN/Shanghai)" 
:
>When I install the new os using pxe, it is always appears the following
>error.
>But the package is the channel, someone has the same error?

I can see the package in the picture, but this also tells me, that this package 
is within a channel, that the client needs to be subscribed to, so your client 
needs to be registered to spacewalk while it's installing.

I did not yet do installations with kickstartable trees. Instead, I use the 
normal "distribution" to install the client and register it to spacewalk in a 
%post.

Would be interesting to know, if that package in the picture is the only 
package in that channel that cannot be downloaded or if this was just the first 
that failed and - possibly - all following packages from that channel would 
fail too.

Just try to download it from your admin workstation from the web UI.

Robert
>
>[cid:image001.jpg@01D4D0E3.5A1C1350]
>[cid:image002.jpg@01D4D0E3.5A1C1350]


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Registration to the new server via rhnreg_ks returns an SSL error

[Robert Paschedag]

Am 2. März 2019 00:55:20 MEZ schrieb "Zhou, Rui A. (NSB - CN/Shanghai)" 
:
>My problem was resloved, I reset my login password and it work  now!

I dought that a login reset fixes an SSL verification error but if you're happy 
now, all is good. ;-)

Robert
>
>-Original Message-
>From: Zhou, Rui A. (NSB - CN/Shanghai) 
>Sent: 2019年3月1日 19:02
>To: spacewalk-list@redhat.com; robert.pasche...@web.de
>Cc: Zhu, Ting (NSB - CN/Shanghai) 
>Subject: RE: [Spacewalk-list] Registration to the new server via
>rhnreg_ks returns an SSL error
>
>Very sad to say, they are the same, I think if the file in hosts has
>some impacts? I find I have not write the configuration before. I will
>try and tell the result later.
>[root@spacewalk-server pxelinux.cfg]# cat /etc/hosts
>127.0.0.1   localhost localhost.localdomain localhost4
>localhost4.localdomain4
>::1 localhost localhost.localdomain localhost6
>localhost6.localdomain6
>135.251.206.139 spacewalk-server
>
>Client:
>[root@FNSHA172 yum.repos.d]# cat
>/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
>Certificate:
>Data:
>Version: 3 (0x2)
>Serial Number:
>91:88:95:56:dd:6c:6d:0d
>
>Server:
>[root@spacewalk-server ~]# cat
>/var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT
>Certificate:
>Data:
>Version: 3 (0x2)
>Serial Number:
>91:88:95:56:dd:6c:6d:0d
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of
>p.cook...@bham.ac.uk
>Sent: 2019年3月1日 17:09
>To: robert.pasche...@web.de; spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Registration to the new server via
>rhnreg_ks returns an SSL error
>
>Whether you re-installed the Spacewalk application on the same server
>or a different one, a new certificate should have been produced after
>running "spacewalk-setup."
>
>Subsequently, the certificate can be viewed on the server:
>
>cat /var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT
>
>OR
>
>WebUI -> Systems (Top Menu) -> Kickstart (Left Menu) -> GPG and SSL
>Keys -> RHN-ORG-TRUSTED-SSL-CERT -> Key contents
>
>If everything has been done correctly, to register the client, the
>certificate can be viewed on there too:
>
>cat /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
>
>If they don't match, you'll have a problem!
>
>Like Robert says, it seems to be "just" a SSL issue really but,
>obviously, the certificate is being generated by the Spacewalk
>application installation.
>
>Regards
>Phil
>
>-Original Message-
>From: robert.pasche...@web.de 
>Sent: 28 February 2019 16:47
>To: spacewalk-list@redhat.com; Philip Cookson (IT Services)
>; spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Registration to the new server via
>rhnreg_ks returns an SSL error
>
>Am 28. Februar 2019 11:10:57 MEZ schrieb "p.cook...@bham.ac.uk"
>:
>>Obviously, that will work but you won’t be using the secure layer or 
>>addressing the underlying problem!
>>
>>If you’re getting the same problem with a new client system I can see 
>>how you may think it’s a server related issue. However, the Spacewalk 
>>certificate is generated during installation so it would be un-usual,
>I 
>>would have thought?
>>
>>Did you add the certificate to the database (certutil -d 
>>sql:/etc/pki/nssdb -An RHN-ORG-TRUSTED-SSL-CERT -t C,, -ai 
>>/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT), too, as you only mention 
>>getting the rpm (rpm -Uvh 
>>http://spacewalk-server/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm)?
>>
>>Regards
>>Phil
>>
>>From: spacewalk-list-boun...@redhat.com 
>> On Behalf Of 
>>rui.a.z...@nokia-sbell.com
>>Sent: 28 February 2019 09:51
>>To: spacewalk-list@redhat.com
>>Cc: Zhu, Ting (NSB - CN/Shanghai) 
>>Subject: Re: [Spacewalk-list] Registration to the new server via 
>>rhnreg_ks returns an SSL error
>>
>>
>>I think this may not the problem of the client, when I try to add new 
>>client server it also has the error: The SSL certificate failed 
>>verification.
>>I find this help, change the
>>--serverUrl=https://spacewalk-server/XMLRPC to 
>>--serverUrl=http://spacewalk-server/XMLRPC.  The system can be 
>>registerd,  The reason maybe:
>>
>>*   System did not have the correct SSL certificate.(I check, server
>>and client have the same sslCACert)
>>  *   SSL certificate was corrupted.(how to explain this?)
>
>This is just a standard SSL issue. Nothing special with spacewalk.
>
>If you're connecting to https://spacewalk-server/, "spacewalk-server"
>has to be included within the SSL certificate. And if that is missing,
>the certificate may be valid but you still get the verification error .
>
>Robert
>
>>
>>
>>From:
>>spacewalk-list-boun...@redhat.com>com> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of
>>p.cook...@bham.ac.uk
>>Sent: 2019年2月28日 17:35
>>To: spacewalk-list@redhat.com
>>Subject: Re: [Spacewalk-list] Registration to the new server via 
>>rhnreg_ks returns an 

Re: [Spacewalk-list] Registration to the new server via rhnreg_ks returns an SSL error

[Robert Paschedag]

Am 28. Februar 2019 11:10:57 MEZ schrieb "p.cook...@bham.ac.uk" 
:
>Obviously, that will work but you won’t be using the secure layer or
>addressing the underlying problem!
>
>If you’re getting the same problem with a new client system I can see
>how you may think it’s a server related issue. However, the Spacewalk
>certificate is generated during installation so it would be un-usual, I
>would have thought?
>
>Did you add the certificate to the database (certutil -d
>sql:/etc/pki/nssdb -An RHN-ORG-TRUSTED-SSL-CERT -t C,, -ai
>/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT), too, as you only mention
>getting the rpm (rpm -Uvh
>http://spacewalk-server/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm)?
>
>Regards
>Phil
>
>From: spacewalk-list-boun...@redhat.com
> On Behalf Of
>rui.a.z...@nokia-sbell.com
>Sent: 28 February 2019 09:51
>To: spacewalk-list@redhat.com
>Cc: Zhu, Ting (NSB - CN/Shanghai) 
>Subject: Re: [Spacewalk-list] Registration to the new server via
>rhnreg_ks returns an SSL error
>
>
>I think this may not the problem of the client, when I try to add new
>client server it also has the error: The SSL certificate failed
>verification.
>I find this help, change the
>--serverUrl=https://spacewalk-server/XMLRPC to
>--serverUrl=http://spacewalk-server/XMLRPC.  The system can be
>registerd,
> The reason maybe:
>
>*   System did not have the correct SSL certificate.(I check, server
>and client have the same sslCACert)
>  *   SSL certificate was corrupted.(how to explain this?)

This is just a standard SSL issue. Nothing special with spacewalk.

If you're connecting to https://spacewalk-server/, "spacewalk-server" has to be 
included within the SSL certificate. And if that is missing, the certificate 
may be valid but you still get the verification error
.

Robert

>
>
>From:
>spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of
>p.cook...@bham.ac.uk
>Sent: 2019年2月28日 17:35
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Registration to the new server via
>rhnreg_ks returns an SSL error
>
>Hi
>
>It’s a little more involved than that! I produced these notes, for
>myself, when un-registering a system from a Dev Spacewalk Server and
>registering it with a Test Spacewalk Server. It’s effectively the same
>thing that you need to do though.
>
>
>Spacewalk does not provide an option to un-register a client system
>(similar to registering - “rhnreg_ks”) - the only option is to remove
>the client system’s profile from the Spacewalk server.
>
>To remove a client’s profile from the Spacewalk server perform these
>steps:
>
>
>  1.  Log in to the Spacewalk Console.
>2.  Click on the Systems tab in the top navigation bar and then click
>on the name of the system which you want to remove from the Systems
>List.
>  3.  Click the Delete System link in the top-right corner of the page.
>4.  Confirm system profile deletion by clicking the Delete Profile
>button.
>5.  Now go to the client system and execute below command to remove the
>associated System ID file:
>
># rm /etc/sysconfig/rhn/systemid
>
>In addition, remove Spacewalk certificate for Development and add
>certificate for Test. Then register client system with Test Spacewalk
>server:
>
># certutil -d sql:/etc/pki/nssdb -Dn RHN-ORG-TRUSTED-SSL-CERT -t C,,
>-ai /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
># rpm -ev rhn-org-trusted-ssl-cert-1.0-1.noarch
># rpm -Uvh https://https://%3cTest>
>Server>/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
># certutil -d sql:/etc/pki/nssdb -An RHN-ORG-TRUSTED-SSL-CERT -t C,,
>-ai /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
># rhnreg_ks --serverUrl=https:///XMLRPC
>--sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
>--activationkey=[ACTIVATION KEY]
>
>
>Note, if you’re using OSAD, the service may have stopped during this
>process and therefore, will need to be re-started. I’ve also found
>that, even if it’s still running, I’ve had to restart it before actions
>were automatically picked up again:
>
># systemctl start osad OR service osad start
>
>
>Hope this is of help?
>
>Regards
>Phil
>
>From:
>spacewalk-list-boun...@redhat.com
>mailto:spacewalk-list-boun...@redhat.com>>
>On Behalf Of
>rui.a.z...@nokia-sbell.com
>Sent: 28 February 2019 08:57
>To: spacewalk-list@redhat.com
>Cc: Zhu, Ting (NSB - CN/Shanghai)
>mailto:ting@nokia-sbell.com>>
>Subject: [Spacewalk-list] Registration to the new server via rhnreg_ks
>returns an SSL error
>
>I re-installed the spacewalk server, and the client can not register to
>the new installed server.
>
>[root@FNSHB109 rhn]# rpm -e rhn-org-trusted-ssl-cert-1.0-1.noarch
>
>[root@FNSHB109 rhn]# rpm -Uvh
>http://spacewalk-server/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
>Retrieving

Re: [Spacewalk-list] Someone managing Ubuntu / Debian with Spacewalk also using "unattended-upgrades"?

[Robert Paschedag]

Am 26. Februar 2019 10:28:21 MEZ schrieb Robert Paschedag 
:
>Hi all,
>
>see the subject. Does someone use "unattended-upgrades" while getting
>the repos from spacewalk?
>
>Does it work?
>
>In case it does work, what settings do you set within the config?
>
>A customer showed me, that the "unattended-upgrades" does not work with
>the "default" settings. Also it looks like it cannot determine, what
>are security updates and what not. I do not have the time right now to
>make a deep dive into that problem. That's why I'm asking.
>
>Any feedback will be appreciated.

Ok. Got some time and fixed it myself. Just have to use the keywords from my 
rudimentary "Release" files.

Robert
>
>Robert
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] Someone managing Ubuntu / Debian with Spacewalk also using "unattended-upgrades"?

[Robert Paschedag]

Hi all,

see the subject. Does someone use "unattended-upgrades" while getting the repos 
from spacewalk?

Does it work?

In case it does work, what settings do you set within the config?

A customer showed me, that the "unattended-upgrades" does not work with the 
"default" settings. Also it looks like it cannot determine, what are security 
updates and what not. I do not have the time right now to make a deep dive into 
that problem. That's why I'm asking.

Any feedback will be appreciated.

Robert

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

[Robert Paschedag]

On 2/22/19 10:30 PM, Robert Paschedag wrote:
> On 2/22/19 7:53 PM, Robert Paschedag wrote:
>> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
>> :
>>> On 2019-02-13 10:56, Florin Portase wrote:
>>>
>>>> Hello,
>>>>
>>>> I just have upgraded the spacewalk server from 2.7 => 2.9.
>>>>
>>>> I have applied also the sql patch from
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1661347
>>>>
>>>> + upgraded the clients from :
>>>>
>>>>
>>> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>>>
>>>>
>>>> Just to mention spacewalk 2.7 +  patches was working just fine for
>>> both debian & ubuntu.
>>>>
>>>> Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable(
>>> over and over)
>>>>
>>>> ___
>>>>
>>>> Spacewalk-list mailing list
>>>> Spacewalk-list@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>
>>> So, after digging through  SPW archive Dec '18 til Feb '19 finally I
>>> come to something more acceptable:
>>>
>>> 1. sync script for Ubuntu channels
>>>
>>> 2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from
>>> "https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html;
>>>
>>>
>>> wget  -q
>>> http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-main.gz && gunzip -f
>>> /tmp/Packages-xenial-main.gz
>>> wget  -q
>>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>>> /tmp/Packages-xenial-updates.gz
>>> wget  -q
>>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>>> \
>>>-O /tmp/Packages-xenial-security.gz && gunzip -f
>>> /tmp/Packages-xenial-security.gz
>>>
>>> s=180
>>> trap 'echo "Ctrl-C detected."' 2
>>> for (( i=$s ; i>0; i--));
>>>do
>>>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>>>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>>> sleep 1
>>>done
>>> echo -e "\nSync completed!"
>>> trap 2
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_MAIN/Packages/tmp/Packages-xenial-main
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_SEC/Packages  /tmp/Packages-xenial-security
>>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>>> $_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>>>
>
> Below is your error
>
> Packages.new is the "modified" Packages which you rename and
> *afterwards* use its "modified" timestamp. This is wrong.
>
> You have to use the "modified" timestamp of the "original" (the one
> generated by Spacewalk) packages file
>
> So when you have the original "Packages" file (by spacewalk), do
>
> - run the  script (which generates "Packages.new")
> - gzip -c Packages.new > Packages.gz
> - touch -r Packages Packages.new Packages.gz && mv Packages.new Packages
>
> So you have transferred the original timestamp to the new files and all
> set to "secure" your repo then.
>
> Robert
>

OopsI was wrong. The modified time of "Packages.gz" is the one you
need to preserve

See this function, which checks, if the files has to be regenerated.

...
public boolean isChannelRepodataStale(Channel channel) {
File theFile = new File(mountPoint + File.separator + pathPrefix +
File.separator + channel.getLabel() + File.separator +
"Packages.gz");
// Init Date objects without milliseconds
Calendar cal = Calendar.getInstance();
cal.setTime(new Date(theFile.lastModified()));
cal.set(Calendar.MILLISECOND, 0);
Date fileModifiedDate = cal.getTime();
cal.setTime(channel.getLastModified());
cal.set(Calendar.MILL

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

[Robert Paschedag]

On 2/22/19 7:53 PM, Robert Paschedag wrote:
> Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
> :
>> On 2019-02-13 10:56, Florin Portase wrote:
>>
>>> Hello,
>>>
>>> I just have upgraded the spacewalk server from 2.7 => 2.9.
>>>
>>> I have applied also the sql patch from
>> https://bugzilla.redhat.com/show_bug.cgi?id=1661347
>>>
>>> + upgraded the clients from :
>>>
>>>
>> http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>>
>>>
>>> Just to mention spacewalk 2.7 +  patches was working just fine for
>> both debian & ubuntu.
>>>
>>> Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable(
>> over and over)
>>>
>>> ___
>>>
>>> Spacewalk-list mailing list
>>> Spacewalk-list@redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>> So, after digging through  SPW archive Dec '18 til Feb '19 finally I
>> come to something more acceptable:
>>
>> 1. sync script for Ubuntu channels
>>
>> 2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from
>> "https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html;
>>
>>
>> wget  -q
>> http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-main.gz && gunzip -f
>> /tmp/Packages-xenial-main.gz
>> wget  -q
>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>> /tmp/Packages-xenial-updates.gz
>> wget  -q
>> http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>> \
>>-O /tmp/Packages-xenial-security.gz && gunzip -f
>> /tmp/Packages-xenial-security.gz
>>
>> s=180
>> trap 'echo "Ctrl-C detected."' 2
>> for (( i=$s ; i>0; i--));
>>do
>>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>> sleep 1
>>done
>> echo -e "\nSync completed!"
>> trap 2
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_MAIN/Packages/tmp/Packages-xenial-main
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_SEC/Packages  /tmp/Packages-xenial-security
>>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW
>> $_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>>

Below is your error

Packages.new is the "modified" Packages which you rename and
*afterwards* use its "modified" timestamp. This is wrong.

You have to use the "modified" timestamp of the "original" (the one
generated by Spacewalk) packages file

So when you have the original "Packages" file (by spacewalk), do

- run the  script (which generates "Packages.new")
- gzip -c Packages.new > Packages.gz
- touch -r Packages Packages.new Packages.gz && mv Packages.new Packages

So you have transferred the original timestamp to the new files and all
set to "secure" your repo then.

Robert

>>/bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages
>>/bin/mv $_PKG_SEC/Packages.new $_PKG_SEC/Packages
>>/bin/mv $_PKG_UPD/Packages.new $_PKG_UPD/Packages
>>/bin/mv $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages
>>
>>gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz
>>gzip < $_PKG_UPD/Packages  > $_PKG_UPD/Packages.gz
>>gzip < $_PKG_SEC/Packages  > $_PKG_SEC/Packages.gz
>>gzip < $_PKG_UNIV/Packages > $_PKG_UNIV/Packages.gz
>>
>> cd $_PKG_MAIN
>>$_BIN_PATH/secureApt.sh  xenial xenial-main
>>touch -r Packages.gz  Packages
>> cd $_PKG_UPD
>>$_BIN_PATH/secureApt.sh  xenial xenial-updates
>>touch -r Packages.gz  Packages
>> cd $_PKG_SEC
>>$_BIN_PATH/secureApt.sh  xenial xenial-security
>>touch -r Packages.gz  Packages
>>
>> So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now
>> the
>> packages that are showed as up-gradable dropped from ~120 to only 6 (
>> base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141
>> )
>>
>>
>> ~~BUT~~
>>
>> Here I run into another problem, it seems taskomatic is generating
>> Package files over and over ( touch -r Packages.gz  Packages seems to
>> have no effect)
>
> This seems to be new. You might have to check within code, at which 
> conditions a rebuild of the Packages file gets triggered
>
> I'm still on SW2.7 so I cannot test on my environment.
>
> Robert
>
>
>




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients

[Robert Paschedag]

Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase 
:
>On 2019-02-13 10:56, Florin Portase wrote:
>
>> Hello, 
>> 
>> I just have upgraded the spacewalk server from 2.7 => 2.9. 
>> 
>> I have applied also the sql patch from
>https://bugzilla.redhat.com/show_bug.cgi?id=1661347 
>> 
>> + upgraded the clients from : 
>> 
>>
>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/
>
>> 
>> Just to mention spacewalk 2.7 +  patches was working just fine for
>both debian & ubuntu. 
>> 
>> Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable(
>over and over) 
>> 
>> ___
>> 
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>So, after digging through  SPW archive Dec '18 til Feb '19 finally I
>come to something more acceptable: 
>
>1. sync script for Ubuntu channels 
>
>2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from
>"https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html;
>
>
>wget  -q
>http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-main.gz && gunzip -f
>/tmp/Packages-xenial-main.gz
>wget  -q
>http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz
> \
>-O /tmp/Packages-xenial-updates.gz  && gunzip -f
>/tmp/Packages-xenial-updates.gz
>wget  -q
>http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz
>\
>-O /tmp/Packages-xenial-security.gz && gunzip -f
>/tmp/Packages-xenial-security.gz
>
>s=180
>trap 'echo "Ctrl-C detected."' 2
>for (( i=$s ; i>0; i--));
>do
>#printf '\rFinishing sync in: %2d seconds' $i; sleep 1
>echo -ne  "\rFinishing sync in: $i seconds\033[0K";
>sleep 1
>done
>echo -e "\nSync completed!"
>trap 2
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_MAIN/Packages/tmp/Packages-xenial-main
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_UPD/Packages  /tmp/Packages-xenial-updates
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_SEC/Packages  /tmp/Packages-xenial-security
>   $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW 
>$_PKG_UNIV/Packages/tmp/Packages-xenial-universe
>
>/bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages
>/bin/mv $_PKG_SEC/Packages.new $_PKG_SEC/Packages
>/bin/mv $_PKG_UPD/Packages.new $_PKG_UPD/Packages
>/bin/mv $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages
>
>gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz
>gzip < $_PKG_UPD/Packages  > $_PKG_UPD/Packages.gz
>gzip < $_PKG_SEC/Packages  > $_PKG_SEC/Packages.gz
>gzip < $_PKG_UNIV/Packages > $_PKG_UNIV/Packages.gz
>
>cd $_PKG_MAIN
>$_BIN_PATH/secureApt.sh  xenial xenial-main
>touch -r Packages.gz  Packages
>cd $_PKG_UPD
>$_BIN_PATH/secureApt.sh  xenial xenial-updates
>touch -r Packages.gz  Packages
>cd $_PKG_SEC
>$_BIN_PATH/secureApt.sh  xenial xenial-security
>touch -r Packages.gz  Packages 
>
>So just to resume, SYNC =>OK, applying ALL missing headers =>OK, now
>the
>packages that are showed as up-gradable dropped from ~120 to only 6 (  
>base-files libbind9-140 libisc160 libisccc140 libisccfg140 liblwres141
>)
>
>
>~~BUT~~ 
>
>Here I run into another problem, it seems taskomatic is generating
>Package files over and over ( touch -r Packages.gz  Packages seems to
>have no effect)

This seems to be new. You might have to check within code, at which conditions 
a rebuild of the Packages file gets triggered 

I'm still on SW2.7 so I cannot test on my environment.

Robert



-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] xmlrpclib.ProtocolError issue with spacewalk-manage-channel-lifecycle

[Robert Paschedag]

Am 19. Februar 2019 16:44:24 MEZ schrieb "Jérôme Meyer" 
:
>Hi Everyone,
>
>I'm using the spacewalk-manage-channel-lifecycle to manage my
>spacewalk's channel.
>
>Sometimes when I run this command, I've received this following error
>on epel channel but not on any other channel.
>At the end I've runned with channel exclusion (-x
>dev-epel7-centos7-x86_64) and all was fine but it isn't the solution...
>
>
>1)  In this case I just started the command a second time. This is the
>reason why there is no package.
>
>2)  The only difference I see between the epel channel and the others
>is that there are a lot of packets to transfert.
>
>
># spacewalk-manage-channel-lifecycle -c dev-centos7-x86_64 --promote
>INFO: Merging packages from dev-centos7-x86_64 into test-centos7-x86_64
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64
>INFO: Added 0 errata
>
>INFO: Merging packages from dev-centos7-x86_64-centosplus into
>test-centos7-x86_64-centosplus
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64-centosplus
>INFO: Added 0 errata
>
>INFO: Merging packages from dev-centos7-x86_64-extras into
>test-centos7-x86_64-extras
>INFO: Added 0 packages
>INFO: Merging errata into test-centos7-x86_64-extras
>INFO: Added 0 errata
>
>[...]
>
>INFO: Merging packages from dev-epel7-centos7-x86_64 into
>test-epel7-centos7-x86_64
>Traceback (most recent call last):
>  File "/bin/spacewalk-manage-channel-lifecycle", line 575, in 
>merge_channels(child_source, child_dest)
>File "/bin/spacewalk-manage-channel-lifecycle", line 213, in
>merge_channels
>dest_label)
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
>return self.__send(self.__name, args)
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request
>verbose=self.__verbose
>  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
>return self.single_request(host, handler, request_body, verbose)
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1321, in single_request
>response.msg,
>xmlrpclib.ProtocolError: chlxintmgmtp01.weforum.local/rpc/api: 500 Internal Server Error>

What I could think of, is that there are too many transaction going onto the 
database and it just takes too long so you get that 500 error.

Had this when I was to clean (and archive) finished actions. Had to do this in 
steps
Otherwise I got an 500 error. But that was somewhere in SW 2.7 I think.

Robert

>
>
>Has anyone ever had this problem before?
>A suggestion or an idea that could help me?
>
>Thanks and best regards,
>Jérôme


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Sequences going wrong

[Robert Paschedag]

Am 15. Februar 2019 09:28:26 MEZ schrieb Thomas Schweikle 
:
>On 14.02.2019 12:09, p.cookson-mhdz94l+r7k1qrn1bg8...@public.gmane.org
>wrote:
>> Hi Thomas
>> 
>> The "Internal Server Error" appears to be a really generic and
>un-helpful message that comes out of Spacewalk in all sorts of
>scenario's! I haven't experienced your particular problem but, in the
>past, I've been advised to look at " /var/log/tomcat/catalina.out" to
>try and get a better idea of what the issue is. Don't know if this will
>help on this occasion?
>
>No, this was not helpful in this occasion. I'd need some way to make
>spacewalk deliver what error was created, by taking logs from
>/var/log/tomcat/catalina.out,
>/var/lib/pgsql/11/data/log/postgres-*.log.
>
>It would be really helpful spacewalk pushing the error logs to the web
>interface for debugging such cases!
>
>> 
>> Regards
>> Phil
>> 
>> -Original Message-
>> From: spacewalk-list-bounces-h+wxahxf7alqt0dzr+a...@public.gmane.org
> On
>Behalf Of tschweikle-re5jqeeqqe8avxtiumw...@public.gmane.org
>> Sent: 14 February 2019 10:31
>> To: spacewalk
>
>> Subject: [Spacewalk-list] Sequences going wrong
>> 
>> Hi!
>> 
>> We're having a lot of troubble with spacewalk loosing sequences, or
>> better: loosing sync within sequences. As spacewalk runs all looks ok
>for some time. then you may get "Internal server error" at a variety of
>places. Mostly it starts showing up in "Schedule -> Actions" click on
>one of the numbers behind in columns Finished, Failed, Pending.
>> Instead of showing me details on where the action hav finished,
>failed or is pending I am prompted with "Internal server error".
>> 
>> Looking into the sql-logs I can find sequences out of sync. Fixing
>these manually makes it work again -- for some time. I do not have any
>idea why these sequences starting to get out of sync. Any idea? Bug?
>> 
>> Spacewalk 2.9
>> OS: CentOS 7
>> 
>> --
>> Thomas
>> 
>> ___
>> Spacewalk-list mailing list
>> spacewalk-list-h+wxahxf7alqt0dzr+a...@public.gmane.org
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> 

Well... You can look into the stack traces at which file (and line) the error 
occurred. Clone the spacewalk git repo, checkout your version "branch" and look 
at the code.

Robert
-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

[Robert Paschedag]

Am 13. Februar 2019 21:48:07 MEZ schrieb Jonathan Horne :
>all your clients should have established traffic to the spacewalk
>server on port 5222.  it should stay in an established state.
>
>
>[jhorne@dlp-log01 ~]$ netstat -tn|grep 5222
>tcp0  0 10.12.59.52:38718  10.12.59.64:5222  
>ESTABLISHED
>
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of Wachauer Harald
>
>Sent: Wednesday, February 13, 2019 10:17:45 AM
>To: spacewalk-list@redhat.com
>Subject: [Spacewalk-list] Spacewalk 2.8 | Offline Clients
>
>Hi  all,
>
>I have the problem that most of my systems (CentOS 6 & 7) are going
>offline after approximately one day.
>Only if I run rhn_check the systems come online again, but only for
>short time.
>
>I have tried to install osad service, the service is running but
>nerveless the client is going offline.
>
>Any help would be very appreciated.

Don't you have "rhnsd" running? It should get in contact with your server at 
least every 4 hours (by default).

Robert
>
>
>Best regards,
>
>Harald


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Continuing issues with ubuntu client and Spacewalk 2.9

[Robert Paschedag]

>'mod_wsgi.queue_start': '1549877218030134', 'mod_wsgi.request_handler':
>'wsgi-script', 'mod_wsgi.version': (3, 4),
>'HTTP_X_RHN_AUTH_SERVER_TIME':
>'1549877217.79', 'X-RHN-Auth-Server-Time': '1549877217.79',
>'X-RHN-Transport-Capability': 'follow-redirects=3', 'PATH_TRANSLATED':
>'/var/www/html/GET-REQ/ubuntu_16_security/repodata/Packages.diff/Index',
>'SERVER_PORT': '443', 'wsgi.multiprocess': True,
>'mod_wsgi.input_chunked':
>'0', 'SERVER_ADDR'!
> : '128.23.191.174', 'DOCUMENT_ROOT': '/var/www/html',
>'mod_wsgi.process_group': '', 'Accept-Encoding': 'identity',
>'X-RHN-Auth':
>'ypurldsBntWwk8h4ERfMaKIw7D5U8gkjnAWhhs0/Kyw=',
>'X-RHN-Auth-Expire-Offset':
>'3600.0', 'SCRIPT_FILENAME': '/usr/share/rhn/wsgi/xmlrpc.py',
>'SERVER_ADMIN': 'root@localhost', 'SCRIPT_URI': '
>https://spacewalk.mdc.musc.edu/XMLRPC/GET-REQ/ubuntu_16_security/repodata/Packages.diff/Index',
>'wsgi.input': , 'HTTP_HOST': '
>spacewalk.mdc.musc.edu', 'SCRIPT_URL':
>'/XMLRPC/GET-REQ/ubuntu_16_security/repodata/Packages.diff/Index',
>'wsgi.multithread': False, 'HTTP_X_RHN_AUTH_EXPIRE_OFFSET': '3600.0',
>'mod_wsgi.callable_object': 'application', 'CONTEXT_PREFIX': '',
>'REQUEST_URI':
>'///XMLRPC/GET-REQ/ubuntu_16_security/repodata/Packages.diff/Index',
>'HTTP_X_RHN_AUTH_USER_ID': '', 'Host': 'spacewalk.mdc.musc.edu',
>'wsgi.version': (1, 0), 'X-RHN-Server-Id': '110001',
>'GATEWAY_INTERFACE': 'CGI/1.1', 'wsgi.run_once': False, 'w!
> sgi.errors': , 'REMOTE_!
>PORT': '37160', 'mod_wsgi.listener_host': '', 'REQUEST_SCHEME':
>'https',
>'HTTP_X_RHN_AUTH': 'ypurldsBntWwk8h4ERfMaKIw7D5U8gkjnAWhhs0/Kyw=',
>'HTTP_X_RHN_TRANSPORT_CAPABILITY': 'follow-redirects=3',
>'mod_wsgi.application_group': 'spacewalk.mdc.musc.edu|/xmlrpc',
>'mod_wsgi.script_reloading': '1', 'X-RHN-Auth-User-Id': '',
>'wsgi.file_wrapper': object at 0x7f505871b0a8>, 'HTTP_ACCEPT_ENCODING': 'identity',
>'UNIQUE_ID':
>'XGE-4kPmPEtzDHi66YmkFAE'}
>
>
>Environment for PID=99069 on exception:
>LANG = C
>NOTIFY_SOCKET = /run/systemd/notify
>PATH = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
>
>--
>--
>James W. Krych
>CCNP, CCNA, Net+, Security+, A+, Linux+
>Mobile: 843-847-1446
>james.w.kr...@gmail.com
>
>
>On Thu, Feb 7, 2019 at 11:54 AM James Krych 
>wrote:
>
>> Sorry, I failed to show you what I did on the server side:
>> /usr/bin/spacewalk-repo-sync --channel ubuntu_16_security --type deb
>> /usr/bin/spacewalk-repo-sync --channel ubuntu_16_updates --type deb
>>
>>
>>
>> --
>> --
>> James W. Krych
>> CCNP, CCNA, Net+, Security+, A+, Linux+
>> Mobile: 843-847-1446
>> james.w.kr...@gmail.com
>>
>>
>> On Thu, Feb 7, 2019 at 11:48 AM Robert Paschedag
>
>> wrote:
>>
>>> Am 7. Februar 2019 17:19:59 MEZ schrieb James Krych <
>>> james.w.kr...@gmail.com>:
>>> >*Syncing the repo again.*
>>> >
>>> This does *not* sync the repo! It only gets the metadata *for* the
>repo
>>> onto the client.
>>>
>>> The repo on the server (the channel) has to be updated.
>>>
>>> Robert
>>>
>>> >*That being done, this is the command I use to stop requesting
>diffs*
>>> >
>>> >#grouper-dev-loader-v:/root: !9949
>>> >apt-get update -o Acquire::Pdiffs=false
>>> >Apt-Spacewalk: Updating sources.list
>>> >Ign:1 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel InRelease
>>> >Ign:2 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security
>InRelease
>>> >Hit:3 http://us.archive.ubuntu.com/ubuntu xenial InRelease
>>> >Ign:4 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates
>InRelease
>>> >Ign:5 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel Release
>>> >Get:6 http://us.archive.ubuntu.com/ubuntu xenial-updates InRelease
>[109
>>> >kB]
>>> >Get:7 http://security.ubuntu.com/ubuntu xenial-security InRelease
>[109
>>> >kB]
>>> >Ign:8 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security Release
>>> >Ign:9
>>> >
>>>
>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/xUbuntu_16.04
>>> >InRelease
>>> >Ign:10 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates Release
>>> >Hit:11
>>> >
>>>
>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/xUbuntu_16.04
>>> >Release
>>> >Ign:12 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata
>amd64
>>> >Packages
>>> >Ign:14 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repo

Re: [Spacewalk-list] Cannot sync confluent (debian) repository to Spacewalk repo

[Robert Paschedag]

Am 7. Februar 2019 18:18:51 MEZ schrieb Ihor Lawrin :
>I forgot to mention that the Ubuntu client is able to install the
>Confluent software (using the Confluent install procedure) when it has
>access to the internet. 
>We want to have the software available via Spacewalk so that we don't
>have to connect all our clients to the internet.
>
>Hope this helps.
>
>
>Ihor Lawrin
>Technical Services
>Senior System Administrator (UNIX)
>Delta Dental of Michigan, Ohio, and Indiana
>(517) 381-4207 Direct Line
>(517) 648-7312 Cell
>
>
>ISO 9001 Quality Certified  •  Certified Call Center of Excellence  • 
>Rated A (Excellent) by A.M. Best Company
>
>
>
>-Original Message-
>From: Ihor Lawrin 
>Sent: Thursday, February 7, 2019 12:00 PM
>To: spacewalk-list@redhat.com; Robert Paschedag
>
>Subject: RE: [Spacewalk-list] Cannot sync confluent (debian) repository
>to Spacewalk repo
>
>I'm guessing that it might be the way the debian repository is
>configured on the Confluent site.
>1. We're able to sync update/base/security repos.
>2. We're also able to sync the "rpm" repo from the Confluent site. Just
>not able to sync the "deb" version
>
>Ihor Lawrin
>Technical Services
>Senior System Administrator (UNIX)
>Delta Dental of Michigan, Ohio, and Indiana
>(517) 381-4207 Direct Line
>(517) 648-7312 Cell
>
>
>ISO 9001 Quality Certified  •  Certified Call Center of Excellence  • 
>Rated A (Excellent) by A.M. Best Company
>
>
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
> On Behalf Of Ihor Lawrin
>Sent: Thursday, February 7, 2019 11:54 AM
>To: Robert Paschedag ;
>spacewalk-list@redhat.com; spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Cannot sync confluent (debian) repository
>to Spacewalk repo
>
>Looks like the same messages
>
>[root@c7spcwlk29tst01 rhn]# cat reposync/confluent-ubuntu-amd64.log |
>grep "2019/02/07 08:20"
>2019/02/07 08:20:45 -04:00 Command: ['/usr/bin/spacewalk-repo-sync',
>'-vv', '--channel', 'confluent-ubuntu-amd64']
>2019/02/07 08:20:45 -04:00 Sync of channel started.
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>server/rhnChannel.channel_info('confluent-ubuntu-amd64',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params("Converting query
>for PostgreSQL: \nselect\nca.label arch,\nc.id,\n  
>c.parent_channel,\nc.org_id,\nc.label,\n   
>c.name,\nc.summary,\nc.description,\n   
>to_char(c.last_modified, 'MMDDHH24MISS') last_modified\nfrom\n 
>rhnChannel c,\nrhnChannelArch ca\nwhere\n 
>c.channel_arch_id = ca.id\n  and c.label = :channel\n",)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params("New query: \n   
>select\nca.label arch,\nc.id,\n   
>c.parent_channel,\nc.org_id,\nc.label,\n   
>c.name,\nc.summary,\nc.description,\n   
>to_char(c.last_modified, 'MMDDHH24MISS') last_modified\nfrom\n 
>rhnChannel c,\nrhnChannelArch ca\nwhere\n 
>c.channel_arch_id = ca.id\n  and c.label = %(channel)s\n",)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql._execute_wrapper('Executing SQL: "\n   
>select\nca.label arch,\nc.id,\n   
>c.parent_channel,\nc.org_id,\nc.label,\n   
>c.name,\nc.summary,\nc.description,\n   
>to_char(c.last_modified, \'MMDDHH24MISS\') last_modified\n   
>from\nrhnChannel c,\nrhnChannelArch ca\nwhere\n
>c.channel_arch_id = ca.id\n  and c.label = %(channel)s\n" with
>bind params: {channel: confluent-ubuntu-amd64}',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('Converting query
>for PostgreSQL: select s.id, s.source_url, s.label as repo_label,
>cst.label as repo_type_label\n  from
>rhnContentSource s,\n  
>rhnChannelContentSource cs,\n  
>rhnContentSourceType cst\n where s.id =
>cs.source_id\n   and cst.id =
>s.type_id\n   and cs.channel_id =
>:channel_id',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('New query: select
>s.id, s.source_url, s.label as repo_label, cst.label as
>repo_type_label\n  from
>rhnContentSource s,\n 

Re: [Spacewalk-list] Continuing issues with ubuntu client and Spacewalk 2.9

[Robert Paschedag]

spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>Translation-en
>Ign:23 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>amd64
>Packages
>Ign:24 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>i386
>Packages
>Ign:25 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>all
>Packages
>Ign:26 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>Translation-en_US
>Ign:27 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>Translation-en
>Get:12 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata amd64
>Packages [20 B]
>Get:14 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata i386
>Packages [20 B]
>Get:15 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata all
>Packages [20 B]
>Ign:16 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata
>Translation-en_US
>Ign:17 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata
>Translation-en
>Get:18 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>amd64
>Packages [585 kB]
>Get:19 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>i386
>Packages [585 kB]
>Get:20 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>all
>Packages [585 kB]
>Ign:21 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>Translation-en_US
>Ign:22 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>Translation-en
>Get:23 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>amd64
>Packages [895 kB]
>Get:24 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>i386
>Packages [895 kB]
>Get:25 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>all
>Packages [895 kB]
>Ign:26 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>Translation-en_US
>Ign:27 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>Translation-en
>Ign:16 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata
>Translation-en_US
>Ign:17 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata
>Translation-en
>Ign:21 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>Translation-en_US
>Ign:22 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>Translation-en
>Ign:26 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>Translation-en_US
>Ign:27 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>Translation-en
>Ign:16 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata
>Translation-en_US
>Ign:17 spacewalk://spacewalk.mdc.musc.edu ubuntu_channel/repodata
>Translation-en
>Ign:21 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>Translation-en_US
>Ign:22 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_security/repodata
>Translation-en
>Ign:26 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>Translation-en_US
>Ign:27 spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates/repodata
>Translation-en
>Fetched 218 kB in 2s (94.0 kB/s)
>Reading package lists... Done
>W: The repository 'spacewalk://spacewalk.mdc.musc.edu ubuntu_channel
>Release' does not have a Release file.
>N: Data from such a repository can't be authenticated and is therefore
>potentially dangerous to use.
>N: See apt-secure(8) manpage for repository creation and user
>configuration
>details.
>W: The repository 'spacewalk://spacewalk.mdc.musc.edu
>ubuntu_16_security
>Release' does not have a Release file.
>N: Data from such a repository can't be authenticated and is therefore
>potentially dangerous to use.
>N: See apt-secure(8) manpage for repository creation and user
>configuration
>details.
>W: The repository 'spacewalk://spacewalk.mdc.musc.edu ubuntu_16_updates
>Release' does not have a Release file.
>N: Data from such a repository can't be authenticated and is therefore
>potentially dangerous to use.
>N: See apt-secure(8) manpage for repository creation and user
>configuration
>details.
>#grouper-dev-loader-v:/root:
>--
>--
>James W. Krych
>CCNP, CCNA, Net+, Security+, A+, Linux+
>Mobile: 843-847-1446
>james.w.kr...@gmail.com
>
>
>On Thu, Feb 7, 2019 at 11:03 AM Robert Paschedag
>
>wrote:
>
>> Am 7. Februar 2019 14:09:23 MEZ schrieb James Krych <
>> james.w.kr...@gmail.com>:
>> >*Sadly,*
>> >
>> >*I am still getting the TRACEBACK error regarding diffs. Message
>from
>> >today:*
>> >Exception reported from spacewalk
>> >Time: Thu Feb  7 04:55:20 2019
>> >Exception type 
>> >Exception while handling function repodata
>> >Request object information:
>> >URI:
>///XMLRPC/GET-REQ/ubuntu_16_updates/repodata/Packages.diff/Index
>> >Re

Re: [Spacewalk-list] Cannot sync confluent (debian) repository to Spacewalk repo

[Robert Paschedag]

Am 7. Februar 2019 14:26:03 MEZ schrieb Ihor Lawrin :
>I ran my sync with high verbosity hoping that someone can help with my
>sync failure...
>
>2019/02/07 08:20:45 -04:00 Command: ['/usr/bin/spacewalk-repo-sync',
>'-vv', '--channel', 'confluent-ubuntu-amd64']
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('Converting query
>for PostgreSQL: \n   select s.source_url, c.label\n
>from rhnContentSource s,\n  
>rhnChannelContentSource cs,\n   rhnChannel c\n 
>   where s.id = cs.source_id and cs.channel_id=c.id\n   ',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('New query: \n 
>select s.source_url, c.label\n   from
>rhnContentSource s,\n   rhnChannelContentSource
>cs,\n   rhnChannel c\n   where
>s.id = cs.source_id and cs.channel_id=c.id\n   ',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql._execute_wrapper('Executing SQL: "\n  
>select s.source_url, c.label\n   from
>rhnContentSource s,\n   rhnChannelContentSource
>cs,\n   rhnChannel c\n   where
>s.id = cs.source_id and cs.channel_id=c.id\n   " with bind
>params: {}',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('Converting query
>for PostgreSQL: select 1',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('New query: select
>1',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql._execute_wrapper('Executing SQL: "select 1"
>with bind params: {}',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('Converting query
>for PostgreSQL: \nselect c1.label, c2.label parent_channel,
>c1.id\nfrom rhnChannel c1 left outer join rhnChannel c2 on
>c1.parent_channel = c2.id\norder by c2.label desc, c1.label
>asc\n',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('New query: \n 
>select c1.label, c2.label parent_channel, c1.id\nfrom
>rhnChannel c1 left outer join rhnChannel c2 on c1.parent_channel =
>c2.id\norder by c2.label desc, c1.label asc\n',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql._execute_wrapper('Executing SQL: "\n   
>select c1.label, c2.label parent_channel, c1.id\nfrom
>rhnChannel c1 left outer join rhnChannel c2 on c1.parent_channel =
>c2.id\norder by c2.label desc, c1.label asc\n" with bind
>params: {}',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>server/rhnChannel.isCustomChannel(104,)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('Converting query
>for PostgreSQL: \nselect\nrcf.label\nfrom\n   
>rhnChannelFamily rcf,\nrhnChannelFamilyMembers rcfm\n   
>where\nrcfm.channel_id = :channel_id\nand
>rcfm.channel_family_id = rcf.id\nand rcf.org_id is not null\n  
> ',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('New query: \n   
>select\nrcf.label\nfrom\nrhnChannelFamily rcf,\n   
>rhnChannelFamilyMembers rcfm\nwhere\nrcfm.channel_id =
>%(channel_id)s\nand rcfm.channel_family_id = rcf.id\n   
>and rcf.org_id is not null\n',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql._execute_wrapper('Executing SQL: "\n   
>select\nrcf.label\nfrom\nrhnChannelFamily rcf,\n   
>rhnChannelFamilyMembers rcfm\nwhere\nrcfm.channel_id =
>%(channel_id)s\nand rcfm.channel_family_id = rcf.id\n   
>and rcf.org_id is not null\n" with bind params: {channel_id:
>104}',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>server/rhnChannel.isCustomChannel(104, 'is a custom channel')
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>server/rhnChannel.isCustomChannel(101,)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('Converting query
>for PostgreSQL: \nselect\nrcf.label\nfrom\n   
>rhnChannelFamily rcf,\nrhnChannelFamilyMembers rcfm\n   
>where\nrcfm.channel_id = :channel_id\nand
>rcfm.channel_family_id = rcf.id\nand rcf.org_id is not null\n  
> ',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:
>rhnSQL/driver_postgresql.convert_named_query_params('New query: \n   
>select\nrcf.label\nfrom\nrhnChannelFamily rcf,\n   
>rhnChannelFamilyMembers rcfm\nwhere\nrcfm.channel_id =
>%(channel_id)s\nand rcfm.channel_family_id = rcf.id\n   
>and rcf.org_id is not null\n',)
>2019/02/07 08:20:45 -04:00 1817 0.0.0.0:

Re: [Spacewalk-list] Continuing issues with ubuntu client and Spacewalk 2.9

[Robert Paschedag]

Am 7. Februar 2019 14:09:23 MEZ schrieb James Krych :
>*Sadly,*
>
>*I am still getting the TRACEBACK error regarding diffs. Message from
>today:*
>Exception reported from spacewalk
>Time: Thu Feb  7 04:55:20 2019
>Exception type 
>Exception while handling function repodata
>Request object information:
>URI: ///XMLRPC/GET-REQ/ubuntu_16_updates/repodata/Packages.diff/Index
>Remote Host: grouper-dev-loader-v.mdc.musc.edu
>Server Name: spacewalk.mdc.musc.edu:443
>Headers passed in:
>Accept-Encoding: identity
>CONTEXT_DOCUMENT_ROOT: /var/www/html
>CONTEXT_PREFIX:
>DOCUMENT_ROOT: /var/www/html
>GATEWAY_INTERFACE: CGI/1.1
>HTTP_ACCEPT_ENCODING: identity
>HTTP_HOST: spacewalk.mdc.musc.edu
>HTTP_X_RHN_AUTH: nL53lMc41V96u3uWpqa4tAArkXsFdl15WUjBfmzzDKQ=
>HTTP_X_RHN_AUTH_EXPIRE_OFFSET: 3600.0
>HTTP_X_RHN_AUTH_SERVER_TIME: 1549533319.96
>HTTP_X_RHN_AUTH_USER_ID:
>HTTP_X_RHN_SERVER_ID: 110001
>HTTP_X_RHN_TRANSPORT_CAPABILITY: follow-redirects=3
>Host: spacewalk.mdc.musc.edu
> PATH_INFO: /GET-REQ/ubuntu_16_updates/repodata/Packages.diff/Index
>PATH_TRANSLATED:
>/var/www/html/GET-REQ/ubuntu_16_updates/repodata/Packages.diff/Index
>QUERY_STRING:
>REMOTE_ADDR: 128.23.182.201
>REMOTE_PORT: 59130
>REQUEST_METHOD: GET
>REQUEST_SCHEME: https
>REQUEST_URI:
>///XMLRPC/GET-REQ/ubuntu_16_updates/repodata/Packages.diff/Index
>SCRIPT_FILENAME: /usr/share/rhn/wsgi/xmlrpc.py
>SCRIPT_NAME: /XMLRPC
>SCRIPT_URI:
>https://spacewalk.mdc.musc.edu/XMLRPC/GET-REQ/ubuntu_16_updates/repodata/Packages.diff/Index
>SCRIPT_URL:
>/XMLRPC/GET-REQ/ubuntu_16_updates/repodata/Packages.diff/Index
>SERVER_ADDR: 128.23.191.174
>SERVER_ADMIN: root@localhost
>SERVER_NAME: spacewalk.mdc.musc.edu
>SERVER_PORT: 443
>SERVER_PROTOCOL: HTTP/1.1
>SERVER_SIGNATURE:
>SERVER_SOFTWARE: Apache
>UNIQUE_ID: XFwAiOeFCYNstcIeYzFMcgQ
>X-RHN-Auth: nL53lMc41V96u3uWpqa4tAArkXsFdl15WUjBfmzzDKQ=
>X-RHN-Auth-Expire-Offset: 3600.0
>X-RHN-Auth-Server-Time: 1549533319.96
>X-RHN-Auth-User-Id:
>X-RHN-Server-Id: 110001
>X-RHN-Transport-Capability: follow-redirects=3
>mod_wsgi.application_group: spacewalk.mdc.musc.edu|/xmlrpc
>mod_wsgi.callable_object: application
>mod_wsgi.enable_sendfile: 0
>mod_wsgi.handler_script:
>mod_wsgi.input_chunked: 0
>mod_wsgi.listener_host:
>mod_wsgi.listener_port: 443
>mod_wsgi.process_group:
>mod_wsgi.queue_start: 1549533320284352
>mod_wsgi.request_handler: wsgi-script
>mod_wsgi.script_reloading: 1
>mod_wsgi.version: (3, 4)
>wsgi.errors: 
>wsgi.file_wrapper: mod_wsgi.Adapter object at 0x7f14150260a8>
>wsgi.input: 
>wsgi.multiprocess: True
>wsgi.multithread: False
>wsgi.run_once: False
>wsgi.url_scheme: https
>wsgi.version: (1, 0)
>Extra information about this error:
>Response sent back to the caller:
>While running 'repodata': caught
> : repodata() takes exactly 2 arguments (3
>given)
>
>
>
>Exception Handler Information
>Traceback (most recent call last):
>  File
>"/usr/lib/python2.7/site-packages/spacewalk/server/apacheRequest.py",
>line
>135, in call_function
>response = func(*params)
>TypeError: repodata() takes exactly 2 arguments (3 given)
>
>Local variables by frame
>Frame call_function in
>/usr/lib/python2.7/site-packages/spacewalk/server/apacheRequest.py at
>line
>154
>   fault =  1
>self = 
>0x7f140ec680e0>
>  force_rollback =  1
>  method =  repodata
>  exctype =  
> params =  ('Packages.diff', 'Index')
>   e_type =  
>func =  Repository.repodata of instance
>at 0x7f140ec7acf8>>
> e_value =  repodata()
>takes exactly 2 arguments (3 given)
>  response =  running 'repodata': caught\n : repodata()
>takes exactly 2 arguments (3 given)\n">
>
>Frame process in
>/usr/lib/python2.7/site-packages/spacewalk/server/apacheRequest.py at
>line
>593
>self = 
>0x7f140ec680e0>
> params =  ('Packages.diff', 'Index')
>  method =  repodata
>
>Frame handler in
>/usr/lib/python2.7/site-packages/spacewalk/server/apacheHandler.py at
>line
>203
>   h = 
>0x7f140ecadd88>
>self = 
>0x7f14132c4ab8>
> req = 
>
> ret =  1
> templateStrings =  {'email_account_info':
>'\nAccount Information:\n  Your Spacewalk login: \n 
>Your
>Spacewalk email address: ', 'email_footer': '--the
>Spacewalk Team', 'hostname': 'spacewalk.mdc.musc.edu'}
>  

Re: [Spacewalk-list] Issues with the first Ubuntu client under Spacewalk 2.9

[Robert Paschedag]

Am 5. Februar 2019 18:52:12 MEZ schrieb James Krych :
>I am still getting the spacewalk TRACEBACK error:
>Exception reported from spacewalk
>Time: Tue Feb  5 12:47:09 2019
>Exception type 
>Exception while handling function repodata
>Request object information:
>URI: ///XMLRPC/GET-REQ/ubuntu_channel/repodata/Packages.diff/Index
>Remote Host: grouper-dev-loader-v.mdc.musc.edu
>Server Name: spacewalk.mdc.musc.edu:443
>Headers passed in:
>
>(only partial)
>
>However, when I tried to do an apt-get upgrade, I ended up with the
>following error for each and every package:
> E: Failed to fetch spacewalk://
>spacewalk.mdc.musc.edu/XMLRPC/GET-REQ/ubuntu_16_updates/getPackage/xdg-user-dirs_0.15-2ubuntu6.16.04.1.amd64-deb.deb
>404  Not Found
>
>This was from the command line. I have scheduled an package
>install/upgrade
>via the web UI -- it hasn't shown to be completed yet.
>
>What am I doing wrong here?
>
>Respectfully,
>
>James

Deactivate use of package "diffs" within apt on the clients. See apt(8) or apt 
conf(5)

Robert

>
>
>--
>--
>James W. Krych
>CCNP, CCNA, Net+, Security+, A+, Linux+
>Mobile: 843-847-1446
>james.w.kr...@gmail.com


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Migreating servers to new Spacewalk server

[Robert Paschedag]

Am 28. Januar 2019 20:25:19 MEZ schrieb Paul Deveau :
>Hi,
>
>
>Thank you Robert. I may have fixed it. I have changed my Spacewalk
>server name. Just where are all of those config files?
>
>
>Thanks,

/etc/sysconfig/rhn

Robert
>
>--
>Paul Deveau
>Analyste de systèmes principal|Senior Systems Analyst
>Technologies de l’information|Information Technology
>Université d’Ottawa|University of Ottawa
>613-562-5800 (3774)
>
>
>
>
>From: Robert Paschedag 
>Sent: Monday, January 28, 2019 1:01 PM
>To: spacewalk-list@redhat.com; Paul Deveau; spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Migreating servers to new Spacewalk
>server
>
>Am 28. Januar 2019 17:15:32 MEZ schrieb Paul Deveau
>:
>>Hi,
>>
>>
>>Two things:
>>
>>
>> 1.  What is the best way to migrate Spacewalk clients to a new
>server?
>>2.  Have created a new Spacewalk server and have deleted Spacewalk
>>clients from the original server and re-registered the servers to the
>>new server. OSAD no longer starts. I get the following error:
>>
>>
>># systemctl status osad.service
>>● osad.service - OSAD daemon
>>Loaded: loaded (/usr/lib/systemd/system/osad.service; disabled; vendor
>>preset: disabled)
>>Active: failed (Result: exit-code) since Fri 2019-01-25 15:00:00 EST;
>>5s ago
>>Process: 13335 ExecStart=/usr/sbin/osad --pid-file /var/run/osad.pid
>>(code=exited, status=1/FAILURE)
>> Main PID: 5067 (code=exited, status=0/SUCCESS)
>>
>>Jan 25 15:00:00 CAP-D100 osad[13335]: Error: [('SSL routines',
>>'ssl3_get_server_certificate', 'certificate verify failed')]
>>Jan 25 15:00:00 CAP-D100 osad[13335]: 2019-01-25 15:00:00
>>rhn_log.log_error: Traceback caught:
>>Jan 25 15:00:00 CAP-D100 osad[13335]: 2019-01-25 15:00:00
>>rhn_log.log_error: Traceback (most recent call last):
>>Jan 25 15:00:00 CAP-D100 osad[13335]: File
>>"/usr/share/rhn/osad/jabber_lib.py", line 662, in connect
>>Jan 25 15:00:00 CAP-D100 osad[13335]: ssl.do_handshake()
>>Jan 25 15:00:00 CAP-D100 osad[13335]: Error: [('SSL routines',
>>'ssl3_get_server_certificate', 'certificate verify failed')]
>>Jan 25 15:00:00 CAP-D100 systemd[1]: osad.service: control process
>>exited, code=exited status=1
>>Jan 25 15:00:00 CAP-D100 systemd[1]: Failed to start OSAD daemon.
>>Jan 25 15:00:00 CAP-D100 systemd[1]: Unit osad.service entered failed
>>state.
>>Jan 25 15:00:00 CAP-D100 systemd[1]: osad.service failed.
>>
>>
>>
>>Thank you.
>>
>Deletion of software on client isn't necessary.
>
>Get the CA cert of your new spacewalk server (RHN-ORG-TRUSTED-SSL-CERT)
>onto your clients.
>Add the cert to the "trusted certificates" on the client (see
>update-ca-certificates) and
>Re-register the client with "rhnreg_ks --force --activationkey
> --serverUrl 
>Delete the osad-auth.conf from /etc/sysconfig/rhn and restart osad.
>
>That should be it, as long you did not change the server name. In this
>case, you have to modify your configs on *all* clients.
>
>Robert
>
>>
>>--
>>Paul Deveau
>>Analyste de systèmes principal|Senior Systems Analyst
>>Technologies de l’information|Information Technology
>>Université d’Ottawa|University of Ottawa
>>613-562-5800 (3774)
>
>
>--
>sent from my mobile device


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Migreating servers to new Spacewalk server

[Robert Paschedag]

Am 28. Januar 2019 17:15:32 MEZ schrieb Paul Deveau :
>Hi,
>
>
>Two things:
>
>
> 1.  What is the best way to migrate Spacewalk clients to a new server?
>2.  Have created a new Spacewalk server and have deleted Spacewalk
>clients from the original server and re-registered the servers to the
>new server. OSAD no longer starts. I get the following error:
>
>
># systemctl status osad.service
>● osad.service - OSAD daemon
>Loaded: loaded (/usr/lib/systemd/system/osad.service; disabled; vendor
>preset: disabled)
>Active: failed (Result: exit-code) since Fri 2019-01-25 15:00:00 EST;
>5s ago
>Process: 13335 ExecStart=/usr/sbin/osad --pid-file /var/run/osad.pid
>(code=exited, status=1/FAILURE)
> Main PID: 5067 (code=exited, status=0/SUCCESS)
>
>Jan 25 15:00:00 CAP-D100 osad[13335]: Error: [('SSL routines',
>'ssl3_get_server_certificate', 'certificate verify failed')]
>Jan 25 15:00:00 CAP-D100 osad[13335]: 2019-01-25 15:00:00
>rhn_log.log_error: Traceback caught:
>Jan 25 15:00:00 CAP-D100 osad[13335]: 2019-01-25 15:00:00
>rhn_log.log_error: Traceback (most recent call last):
>Jan 25 15:00:00 CAP-D100 osad[13335]: File
>"/usr/share/rhn/osad/jabber_lib.py", line 662, in connect
>Jan 25 15:00:00 CAP-D100 osad[13335]: ssl.do_handshake()
>Jan 25 15:00:00 CAP-D100 osad[13335]: Error: [('SSL routines',
>'ssl3_get_server_certificate', 'certificate verify failed')]
>Jan 25 15:00:00 CAP-D100 systemd[1]: osad.service: control process
>exited, code=exited status=1
>Jan 25 15:00:00 CAP-D100 systemd[1]: Failed to start OSAD daemon.
>Jan 25 15:00:00 CAP-D100 systemd[1]: Unit osad.service entered failed
>state.
>Jan 25 15:00:00 CAP-D100 systemd[1]: osad.service failed.
>
>
>
>Thank you.
>
Deletion of software on client isn't necessary.

Get the CA cert of your new spacewalk server (RHN-ORG-TRUSTED-SSL-CERT) onto 
your clients.
Add the cert to the "trusted certificates" on the client (see 
update-ca-certificates) and
Re-register the client with "rhnreg_ks --force --activationkey  
--serverUrl 
>--
>Paul Deveau
>Analyste de systèmes principal|Senior Systems Analyst
>Technologies de l’information|Information Technology
>Université d’Ottawa|University of Ottawa
>613-562-5800 (3774)


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Fwd: spacewalk-repo-sync

[Robert Paschedag]

Am 26. Januar 2019 09:35:06 MEZ schrieb Vasileios Baousis :
>T
>

I can confirm, that the ".../repodata/repomd.xml" is present on the server. So 
I would suggest you to run a "tcpdump" in parallel on the server to track, what 
URL exactly your server tries to download and why it is failing. Easiest way to 
solve your problem, as you're not using HTTPS.

Robert

>more centos7_x86_64_ceph1.1.log
>2019/01/25 21:28:28 +01:00 Command: ['/usr/bin/spacewalk-repo-sync', 
>'-c', 'centos7_x86_64_ceph1.1', '--include=*x86_64*', 
>'--exclude=*ia64*,*noarch*,*.i686']
>2019/01/25 21:28:28 +01:00 Sync of channel started.
>2019/01/25 21:28:28 +01:00
>2019/01/25 21:28:28 +01:00   Processing repository with URL: 
>http://download.ceph.com/rpm-luminous/el7/x86_64/
>2019/01/25 21:28:58 +01:00 ERROR: Cannot retrieve repository metadata 
>(repomd.xml) for repository: centos7_x86_64_ceph1.1. Please verify its 
>path and try again
>2019/01/25 21:28:58 +01:00 ERROR: Cannot retrieve repository metadata 
>(repomd.xml) for repository: centos7_x86_64_ceph1.1. Please verify its 
>path and try again
>2019/01/25 21:28:58 +01:00 Sync of channel completed in 0:00:30.
>2019/01/25 22:12:24 +01:00 Command: ['/usr/bin/spacewalk-repo-sync', 
>'-c', 'centos7_x86_64_ceph1.1', '--include=*x86_64*', 
>'--exclude=*ia64*,*noarch*,*.i686', '-t', 'yum', '-vvv']
>2019/01/25 22:12:24 +01:00 Sync of channel started.
>2019/01/25 22:12:24 +01:00 3171 0.0.0.0: 
>server/rhnChannel.channel_info('centos7_x86_64_ceph1.1',)
>2019/01/25 22:12:25 +01:00
>2019/01/25 22:12:25 +01:00   Processing repository with URL: 
>http://download.ceph.com/rpm-luminous/el7/x86_64/
>2019/01/25 22:12:55 +01:00 ERROR: Cannot retrieve repository metadata 
>(repomd.xml) for repository: centos7_x86_64_ceph1.1. Please verify its 
>path and try again
>2019/01/25 22:12:55 +01:00 ERROR: Cannot retrieve repository metadata 
>(repomd.xml) for repository: centos7_x86_64_ceph1.1. Please verify its 
>path and try again
>2019/01/25 22:12:55 +01:00 Sync of channel completed in 0:00:30.
>2019/01/26 00:32:04 +01:00 Command: ['/usr/bin/spacewalk-repo-sync', 
>'-p', 'centos7-x86_64', '--include=*x86_64*', 
>'--exclude=*ia64*,*noarch*,*.i686']
>2019/01/26 00:32:04 +01:00 Sync of channel started.
>2019/01/26 00:32:04 +01:00
>2019/01/26 00:32:04 +01:00   Processing repository with URL: 
>http://download.ceph.com/rpm-luminous/el7/x86_64/
>2019/01/26 00:32:34 +01:00 ERROR: Cannot retrieve repository metadata 
>(repomd.xml) for repository: centos7_x86_64_ceph1.1. Please verify its 
>path and try again
>2019/01/26 00:32:34 +01:00 ERROR: Cannot retrieve repository metadata 
>(repomd.xml) for repository: centos7_x86_64_ceph1.1. Please verify its 
>path and try again
>2019/01/26 00:32:34 +01:00 Sync of channel completed in 0:00:30.
>2019/01/26 04:32:03 +01:00 Command: ['/usr/bin/spacewalk-repo-sync', 
>'-p', 'centos7-x86_64', '--include=*x86_64*', 
>'--exclude=*ia64*,*noarch*,*.i686']
>2019/01/26 04:32:03 +01:00 Sync of channel started.
>2019/01/26 04:32:03 +01:00
>2019/01/26 04:32:03 +01:00   Processing repository with URL: 
>http://download.ceph.com/rpm-luminous/el7/x86_64/
>2019/01/26 04:32:33 +01:00 ERROR: Cannot retrieve repository metadata 
>(repomd.xml) for repository: centos7_x86_64_ceph1.1. Please verify its 
>path and try again
>2019/01/26 04:32:33 +01:00 ERROR: Cannot retrieve repository metadata 
>(repomd.xml) for repository: centos7_x86_64_ceph1.1. Please verify its 
>path and try again
>2019/01/26 04:32:33 +01:00 Sync of channel completed in 0:00:30.
>2019/01/26 08:32:02 +01:00 Command: ['/usr/bin/spacewalk-repo-sync', 
>'-p', 'centos7-x86_64', '--include=*x86_64*', 
>'--exclude=*ia64*,*noarch*,*.i686']
>2019/01/26 08:32:02 +01:00 Sync of channel started.
>2019/01/26 08:32:02 +01:00
>2019/01/26 08:32:02 +01:00   Processing repository with URL: 
>http://download.ceph.com/rpm-luminous/el7/x86_64/
>
>
>
>
>  22:43, Dennis Pittman wrote:
>> Please attach the output of the commands and your logs?
>>
>>
>> Get Outlook for iOS 
>>
>
>> *From:* Vasileios Baousis 
>> *Sent:* Friday, January 25, 2019 4:50 PM
>> *To:* Dennis Pittman
>> *Cc:* spacewalk-list@redhat.com
>> *Subject:* Re: [Spacewalk-list] Fwd: spacewalk-repo-sync
>> All the files were generated in the respective repos, however command
>
>> spacewalk-repo-syn still fails . I encountered this problem some
>years 
>> ago( from version 2.4 to 2.5 of before)  and I cannot remember the 
>> solution.
>> Something with a white space in a configuration file but I cannot 
>> remember this fix.
>>
>> Thanks
>>
>> Vasilis
>> ---
>> Vasileios Baousis
>>
>> On 25 Jan 2019, at 21:36, Dennis Pittman > > wrote:
>>
>>> It’s not automatic sometimes it takes a little while for the 
>>> repomd.xml to be generated. You can use “taskotop” to monitor the 
>>> progress of the jobs.
>>>
>>> Get Outlook for iOS 
>>>

Re: [Spacewalk-list] Taskomatic : Debian repodata generation issue

[Robert Paschedag]

Am 24. Januar 2019 11:41:45 MEZ schrieb philippe bidault 
:
>Hi all,
>
>Something strange is happening on my Spacewalk 2.9: taskomatic is
>regenerating my Ubuntu repodatas some times to times:
>
>INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,144
>[Thread-3446] INFO 
>com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
>- File Modified Date:2019-01-24 03:05:24 CET
>INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,144
>[Thread-3446] INFO 
>com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
>- Channel Modified Date:2019-01-24 03:33:49
>CET
>INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,374
>[Thread-3447] INFO 
>com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
>- Generating new DEB repository for channel
>bionic-security
>INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,544
>[Thread-3446] INFO 
>com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
>- Generating new DEB repository for channel
>bionic-updates
>
>I know that this is the purpose of taskomatic, but this is really
>annoying
>as the "Packages" and "Release" files are "manually" generated, thus
>having
>taskomatic triggering their re-generation just break everything.
>
>I don't think remember having seen such behaviour in Spacewaok 2.8. Is
>there a way to force taskomatic to ignore the DEB repodatas ?
>
>Regards,
>Philippe.

This always happens. You have to make sure, that you keep (transfer) the 
timestamp of the original Packages and Packages.gz file after you modified 
them. See "touch -r ..."

Robert


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Missing Ubuntu Package properties in Spacewalk

[Robert Paschedag]

Am 20. Januar 2019 22:17:05 MEZ schrieb philippe bidault 
:
>And you are right, my mistake, I was checking a previouly generated
>Packages.gz. I still need to use your script to have all the headers.
>
>And yes, you are right again, the bug you did create is similar to the
>issue I have described. I guess that a workaroud is to replace the
>"Depends" header.
>

I'm not yet sure, if there is a problem within the spacewalk code or if there 
might be a problem with that repo but with "debbuild" by Neal Gompa.

@Neal: just from top of my mind Maybe the package names within the 
"Depends" header need to be separated by ', ' (comma + space) and not ',' only?

Robert

>Philippe.
>
>On Sun, 20 Jan 2019 at 21:17, Robert Paschedag
>
>wrote:
>
>> Am 20. Januar 2019 20:48:24 MEZ schrieb Robert Paschedag <
>> robert.pasche...@web.de>:
>> >Am 20. Januar 2019 14:03:03 MEZ schrieb philippe bidault
>> >:
>> >>Good news, I have upgraded to Spacewalk 2.9, and seems that the
>> >headers
>> >>issue did definively go away, no need to manually add them.
>>
>> What?? Now really all headers are added to packages.gz? I do not yet
>> believe this. The database schema would have been tuned a lot to
>support
>> all Debian headers.
>>
>> Can someone else confirm this? I'm currently not that often at the
>> customers site to test this.
>>
>> Robert
>>
>> >>
>> >>However, a new issue did come up. If I add for exemple this repo in
>> >SPW
>> >>:
>> >>
>>
>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/xUbuntu_18.04/
>> ,
>> >>I can notice that the "Depends" header is truncated for some
>packages
>> >>wich
>> >>results on a malformed Packages file.
>> >>
>> >>For exemple, original headers of package rhn-setup-gnome :
>> >>
>> >>Package: rhn-setup-gnome
>> >>Version: 2.9.36-1.ubuntu18.04.1
>> >>Architecture: all
>> >>Maintainer: Spacewalk Project 
>> >>Installed-Size: 339*Depends: rhn-client-tools (=
>> >>2.9.36-1.ubuntu18.04.1),python2-rhn-setup (=
>> >>2.9.36-1.ubuntu18.04.1),python2-rhn-setup-gnome (=
>> >>2.9.36-1.ubuntu18.04.1),rhn-setup (=
>>
>>
>>>2.9.36-1.ubuntu18.04.1),libpam0g,libpam-modules,libpam-runtime,libpam-gnome-keyring*
>> >>
>> >>"Depends" header apparearing in the Package file generated by
>> >>Spacewalk:
>> >>
>> >>Package: rhn-setup-gnome
>> >>Version: 2.9.36-1.ubuntu18.04.1
>> >>Architecture: all
>> >>Maintainer: Spacewalk Project 
>> >>Installed-Size: 339
>> >>*Depends: rhn-client-tools  (=
>> >>2.9.36-1.ubuntu18.04.1),python2-rhn-setup )*
>> >>
>> >>Result of this is the following error on the clients registered
>> >against
>> >>this channel :
>> >>
>> >>E: Problem parsing dependency 21
>> >>E: Error occurred while processing rhn-setup-gnome (NewVersion2)
>> >>E: Problem with MergeList
>>
>>
>>>/var/lib/apt/lists/space01-fr_dists_bionic-spacewalk29-client_repodata_binary-amd64_Packages
>> >>E: The package lists or status file could not be parsed or opened.
>> >>
>> >>which is due to the malformed/incomplet "Depends" header.
>> >>
>> >>Will try to dig, but if somebody did have this same issue or more
>> >>information, please let me know.
>> >>
>> >>Regards,
>> >>Philippe.
>> >
>> >Sounds like this , didn't it?
>> >https://bugzilla.redhat.com/show_bug.cgi?id=1658772
>> >
>> >Robert
>> >>
>> >>On Sat, 12 Jan 2019 at 02:12, Paul-Andre Panon <
>> >>paul-andre.pa...@avigilon.com> wrote:
>> >>
>> >>> On Thu, 10 Jan 2019 09:47:25 +0100, philippe bidault
>> >>>  wrote:
>> >>>
>> >>> >Hi Paul-Andre,
>> >>>
>> >>> >Robert did send me some weeks ago a new script which fetch all
>the
>> >>> missing
>> >>> >headers. I am using it, and for the moment, seems to correctly
>work
>> >>:
>> >>>
>> >>>
>> >>>
>>
>https://www.redhat.com/archives/spacewalk-list/2018-December/msg00015.htm
>> >>> l
>> >>>
>> >>> >Regards,
>> >>> >Philippe.
>> >>>
>> >>> Ah, merci Phillipe and thanks Robert! That should do it going
>> >>forward.
>> >>>
>> >>> ___
>> >>> Spacewalk-list mailing list
>> >>> Spacewalk-list@redhat.com
>> >>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> >>>
>>
>>
>> --
>> sent from my mobile device
>>


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Missing Ubuntu Package properties in Spacewalk

[Robert Paschedag]

Am 20. Januar 2019 20:48:24 MEZ schrieb Robert Paschedag 
:
>Am 20. Januar 2019 14:03:03 MEZ schrieb philippe bidault
>:
>>Good news, I have upgraded to Spacewalk 2.9, and seems that the
>headers
>>issue did definively go away, no need to manually add them.

What?? Now really all headers are added to packages.gz? I do not yet believe 
this. The database schema would have been tuned a lot to support all Debian 
headers.

Can someone else confirm this? I'm currently not that often at the customers 
site to test this.

Robert

>>
>>However, a new issue did come up. If I add for exemple this repo in
>SPW
>>:
>>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/xUbuntu_18.04/,
>>I can notice that the "Depends" header is truncated for some packages
>>wich
>>results on a malformed Packages file.
>>
>>For exemple, original headers of package rhn-setup-gnome :
>>
>>Package: rhn-setup-gnome
>>Version: 2.9.36-1.ubuntu18.04.1
>>Architecture: all
>>Maintainer: Spacewalk Project 
>>Installed-Size: 339*Depends: rhn-client-tools (=
>>2.9.36-1.ubuntu18.04.1),python2-rhn-setup (=
>>2.9.36-1.ubuntu18.04.1),python2-rhn-setup-gnome (=
>>2.9.36-1.ubuntu18.04.1),rhn-setup (=
>>2.9.36-1.ubuntu18.04.1),libpam0g,libpam-modules,libpam-runtime,libpam-gnome-keyring*
>>
>>"Depends" header apparearing in the Package file generated by
>>Spacewalk:
>>
>>Package: rhn-setup-gnome
>>Version: 2.9.36-1.ubuntu18.04.1
>>Architecture: all
>>Maintainer: Spacewalk Project 
>>Installed-Size: 339
>>*Depends: rhn-client-tools  (= 
>>2.9.36-1.ubuntu18.04.1),python2-rhn-setup )*
>>
>>Result of this is the following error on the clients registered
>against
>>this channel :
>>
>>E: Problem parsing dependency 21
>>E: Error occurred while processing rhn-setup-gnome (NewVersion2)
>>E: Problem with MergeList
>>/var/lib/apt/lists/space01-fr_dists_bionic-spacewalk29-client_repodata_binary-amd64_Packages
>>E: The package lists or status file could not be parsed or opened.
>>
>>which is due to the malformed/incomplet "Depends" header.
>>
>>Will try to dig, but if somebody did have this same issue or more
>>information, please let me know.
>>
>>Regards,
>>Philippe.
>
>Sounds like this , didn't it?
>https://bugzilla.redhat.com/show_bug.cgi?id=1658772
>
>Robert 
>>
>>On Sat, 12 Jan 2019 at 02:12, Paul-Andre Panon <
>>paul-andre.pa...@avigilon.com> wrote:
>>
>>> On Thu, 10 Jan 2019 09:47:25 +0100, philippe bidault
>>>  wrote:
>>>
>>> >Hi Paul-Andre,
>>>
>>> >Robert did send me some weeks ago a new script which fetch all the
>>> missing
>>> >headers. I am using it, and for the moment, seems to correctly work
>>:
>>>
>>>
>>>https://www.redhat.com/archives/spacewalk-list/2018-December/msg00015.htm
>>> l
>>>
>>> >Regards,
>>> >Philippe.
>>>
>>> Ah, merci Phillipe and thanks Robert! That should do it going
>>forward.
>>>
>>> ___
>>> Spacewalk-list mailing list
>>> Spacewalk-list@redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Missing Ubuntu Package properties in Spacewalk

[Robert Paschedag]

Am 20. Januar 2019 14:03:03 MEZ schrieb philippe bidault 
:
>Good news, I have upgraded to Spacewalk 2.9, and seems that the headers
>issue did definively go away, no need to manually add them.
>
>However, a new issue did come up. If I add for exemple this repo in SPW
>:
>http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/xUbuntu_18.04/,
>I can notice that the "Depends" header is truncated for some packages
>wich
>results on a malformed Packages file.
>
>For exemple, original headers of package rhn-setup-gnome :
>
>Package: rhn-setup-gnome
>Version: 2.9.36-1.ubuntu18.04.1
>Architecture: all
>Maintainer: Spacewalk Project 
>Installed-Size: 339*Depends: rhn-client-tools (=
>2.9.36-1.ubuntu18.04.1),python2-rhn-setup (=
>2.9.36-1.ubuntu18.04.1),python2-rhn-setup-gnome (=
>2.9.36-1.ubuntu18.04.1),rhn-setup (=
>2.9.36-1.ubuntu18.04.1),libpam0g,libpam-modules,libpam-runtime,libpam-gnome-keyring*
>
>"Depends" header apparearing in the Package file generated by
>Spacewalk:
>
>Package: rhn-setup-gnome
>Version: 2.9.36-1.ubuntu18.04.1
>Architecture: all
>Maintainer: Spacewalk Project 
>Installed-Size: 339
>*Depends: rhn-client-tools  (= 
>2.9.36-1.ubuntu18.04.1),python2-rhn-setup )*
>
>Result of this is the following error on the clients registered against
>this channel :
>
>E: Problem parsing dependency 21
>E: Error occurred while processing rhn-setup-gnome (NewVersion2)
>E: Problem with MergeList
>/var/lib/apt/lists/space01-fr_dists_bionic-spacewalk29-client_repodata_binary-amd64_Packages
>E: The package lists or status file could not be parsed or opened.
>
>which is due to the malformed/incomplet "Depends" header.
>
>Will try to dig, but if somebody did have this same issue or more
>information, please let me know.
>
>Regards,
>Philippe.

Sounds like this , didn't it? 
https://bugzilla.redhat.com/show_bug.cgi?id=1658772

Robert 
>
>On Sat, 12 Jan 2019 at 02:12, Paul-Andre Panon <
>paul-andre.pa...@avigilon.com> wrote:
>
>> On Thu, 10 Jan 2019 09:47:25 +0100, philippe bidault
>>  wrote:
>>
>> >Hi Paul-Andre,
>>
>> >Robert did send me some weeks ago a new script which fetch all the
>> missing
>> >headers. I am using it, and for the moment, seems to correctly work
>:
>>
>>
>>https://www.redhat.com/archives/spacewalk-list/2018-December/msg00015.htm
>> l
>>
>> >Regards,
>> >Philippe.
>>
>> Ah, merci Phillipe and thanks Robert! That should do it going
>forward.
>>
>> ___
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] spacecmd ssm -> UI

[Robert Paschedag]

Am 9. Januar 2019 23:02:45 MEZ schrieb Guy Matz :
>Hi!  I'd like to add systems to a System Set using 'spacecmd ssm_add
>HOSTNAME' command, then act on the SSM group using the UI . . .  is
>that
>possible?  I need to use the UI because I need to create an action
>chain
>for the group, which is apparently not possible to done in spacecmd . .
>.
>
>Thanks,
>Guy

Well... If you need to use the UI, then you can also add the systems via the UI 
into SSM.

Or you use the API.
Robert


-- 
sent from my mobile device

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list