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

2019-02-19 Thread 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

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

2019-02-19 Thread 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: 


Has anyone ever had this problem before?
A suggestion or an idea that could help me?

Thanks and best regards,
Jérôme


smime.p7s
Description: S/MIME cryptographic signature
___
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

2019-02-19 Thread Eric Herget 
This sounds like the issue/fix discussed here - 
https://github.com/spacewalkproject/spacewalk/wiki/DebianUbuntuSupportIn27 
- just the client change, you shouldn't need to clean and sync channels 
since you were already running the updated parsing in 2.7.


If you upgraded the clients, possibly this fix got overwritten? I'm not 
familiar with what comes from the debclients url you mentioned - I don't 
know if this fix has been applied.


Eric


On 2/19/19 9:23 AM, Florin Portase wrote:


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)




So, here are more info about:


Spacewalk server 2.9 (upgraded from 2.7)

+|spacewalk-add-debian-multiarch-header.py|

Ubuntu client: 16.04 ( basic install => only ssh server)


-here are the list of packages that are installed over and over...


The following packages will be upgraded:
  accountsservice amd64-microcode apparmor apport apt base-files bash 
bash-completion bsdutils ca-certificates cloud-guest-utils console-setup
  console-setup-linux coreutils cryptsetup cryptsetup-bin dh-python 
distro-info-data dnsmasq-base dpkg friendly-recovery gcc-5-base git 
git-man grep
  grub-common grub-pc grub2-common ifupdown init init-system-helpers 
initramfs-tools initramfs-tools-core keyboard-configuration 
klibc-utils kmod
  language-selector-common libaccountsservice0 libapt-pkg5.0 
libasprintf0v5 libaudit-common libc6 libdbus-1-3 libglib2.0-0 
libgssapi-krb5-2 libk5crypto3
  libkrb5-3 libkrb5support0 liblxc1 libpam-modules libparted2 
libperl5.22 libplymouth4 libpolkit-backend-1-0 libpolkit-gobject-1-0 
libpython2.7-minimal
  libpython2.7-stdlib libpython3.5-stdlib libsasl2-2 libsasl2-modules 
libsasl2-modules-db libstdc++6 libsystemd0 libx11-data linux-firmware
  linux-headers-4.4.0-116 linux-headers-4.4.0-142 locales login 
logrotate lsb-base lxc-common lxd lxd-client mdadm mount ntfs-3g 
open-iscsi open-vm-tools
  openssh-sftp-server perl perl-base perl-modules-5.22 plymouth 
policykit-1 procps python python-apt python-apt-common python-minimal 
python2.7
  python2.7-minimal python3-apt python3-distupgrade 
python3-update-manager python3.5-minimal resolvconf rsync snapd 
software-properties-common systemd
  systemd-sysv tar ubuntu-release-upgrader-core udev 
update-manager-core update-notifier-common util-linux uuid-runtime 
vim-common vim-runtime xfsprogs

  zlib1g
113 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/145 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.



___
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



--
Eric Herget | Senior Software Engineer
Red Hat Satellite

___
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

2019-02-19 Thread 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) 
> 
> So, here are more info about: 
> 
> Spacewalk server 2.9 (upgraded from 2.7) 
> 
> +spacewalk-add-debian-multiarch-header.py 
> 
> Ubuntu client: 16.04 ( basic install => only ssh server) 
> 
> -here are the list of packages that are installed over and over... 
> 
> The following packages will be upgraded:
> accountsservice amd64-microcode apparmor apport apt base-files bash 
> bash-completion bsdutils ca-certificates cloud-guest-utils console-setup
> console-setup-linux coreutils cryptsetup cryptsetup-bin dh-python 
> distro-info-data dnsmasq-base dpkg friendly-recovery gcc-5-base git git-man 
> grep
> grub-common grub-pc grub2-common ifupdown init init-system-helpers 
> initramfs-tools initramfs-tools-core keyboard-configuration klibc-utils kmod
> language-selector-common libaccountsservice0 libapt-pkg5.0 libasprintf0v5 
> libaudit-common libc6 libdbus-1-3 libglib2.0-0 libgssapi-krb5-2 libk5crypto3
> libkrb5-3 libkrb5support0 liblxc1 libpam-modules libparted2 libperl5.22 
> libplymouth4 libpolkit-backend-1-0 libpolkit-gobject-1-0 libpython2.7-minimal
> libpython2.7-stdlib libpython3.5-stdlib libsasl2-2 libsasl2-modules 
> libsasl2-modules-db libstdc++6 libsystemd0 libx11-data linux-firmware
> linux-headers-4.4.0-116 linux-headers-4.4.0-142 locales login logrotate 
> lsb-base lxc-common lxd lxd-client mdadm mount ntfs-3g open-iscsi 
> open-vm-tools
> openssh-sftp-server perl perl-base perl-modules-5.22 plymouth policykit-1 
> procps python python-apt python-apt-common python-minimal python2.7
> python2.7-minimal python3-apt python3-distupgrade python3-update-manager 
> python3.5-minimal resolvconf rsync snapd software-properties-common systemd
> systemd-sysv tar ubuntu-release-upgrader-core udev update-manager-core 
> update-notifier-common util-linux uuid-runtime vim-common vim-runtime xfsprogs
> zlib1g
> 113 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/145 MB of archives.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue? [Y/n] n
> Abort. 
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

signature.asc
Description: OpenPGP digital signature
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

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

2019-02-19 Thread Wachauer Harald 
Phil,

Still a problem with the offline clients.
It looks like that the rhn daemon stops working after some time.

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: inactive (dead)



And some more:

I have no /etc/sysconfig/rhn/rhnsd

[root@vie-srv-XXX log]# cd /etc/sysconfig/rhn/
[root@vie-srv-XXX rhn]# ls -la
total 24
drwxr-xr-x. 4 root root 4096 Feb 19 09:18 .
drwxr-xr-x. 7 root root 4096 Jan 23 16:48 ..
drwxr-xr-x. 4 root root   37 Jan 23 16:48 allowed-actions
drwxr-xr-x. 2 root root   37 Feb 14 12:19 clientCaps.d
-rw---. 1 root root  129 Jan 29 16:48 osad-auth.conf.rpmsave
-rw-r--r--. 1 root root 1446 Nov 26 21:50 rhncfg-client.conf
-rw---. 1 root root 1321 Jan 23 16:51 systemid
-rw-r--r--. 1 root root 1948 Jan 23 16:51 up2date

In the rhncfg-client.conf I can find a log directory: script_log_file = 
/var/log/rhn/rhncfg-action-output.log

But even this log file does not exist……


Warm regards,

Harald


Von: spacewalk-list-boun...@redhat.com  Im 
Auftrag von p.cook...@bham.ac.uk
Gesendet: Donnerstag, 14. Februar 2019 14:46
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

No problem Harald. If you want to continue using rhnsd you can still reduce the 
check-in time in /etc/sysconfig/rhn/rhnsd if you want though (default is 240 
mins):

# cat /etc/sysconfig/rhn/rhnsd
INTERVAL=240
#

Regards
Phil

From: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
On Behalf Of harald.wacha...@akm.at
Sent: 14 February 2019 11:18
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi Phil,

Thanks for your reply.
It looks like it was a rookie mistake.
I am new at Spacewalk and I followed the instructions here to register a client.

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

Unfortunately there was no hint that you have to start the rhnsd service.
So I have started the service now and configured it to start automatically.
And I need no osad at the moment. Every 4 hours check in is fine for me.

Thanks again,

Warm regards,

Harald






Von: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
Im Auftrag von p.cook...@bham.ac.uk
Gesendet: Donnerstag, 14. Februar 2019 10:01
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi Harald

Were they ok originally, and stopped working properly, or are you just trying 
to setup OSAD for the first time? Either way if you work through my personal 
notes (for OSAD), below, it may help to identify your problem. If everything 
has been done correctly it may be an infrastructure problem though ie 
un-reliable network connection or NTP?

By default, the rhnsd daemon on a client system connects to the Spacewalk 
server every four hours (see /etc/sysconfig/rhn/rhnsd) and performs any updates 
or actions that have been scheduled. If you install the OSA daemon, you can 
apply updates and actions to client systems immediately from the Spacewalk 
server.

osa-dispatcher
Server-side service that determines when an osad client instance needs to be 
pinged or run rhn_check and sends a message telling them to do so. This is 
installed when Spacewalk is installed.

Open Source Architecture Daemon (OSAD)
Client-side service that responds to pings and runs rhn_check when told to by 
osa-dispatcher.

See official documentation, at the following link, for more details:

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

Install OSAD and related RHN/Spacewalk packages
# yum -y install osad rhncfg rhncfg-actions rhncfg-client

Spacewalk Actions Control - Enable Scheduled Actions
# rhn-actions-control --enable-all

Spacewalk Actions Control - Show Status
# rhn-actions-control --report

Start OSAD
# systemctl start osad.service OR service osad start

Enable OSAD
# systemctl enable osad.service OR chkconfig osad on

OSAD Log File
/var/log/osad


Hope this is of help
Phil

From: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
On Behalf Of harald.wacha...@akm.at
Sent: 14 February 2019 08:22
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk 2.8 | Offline Clients

Hi, Jonathan,

Looks good:

[root@vie-srv-log02 ~]# netstat -tn|grep 5222
tcp0  0 172.21.0.181:46018  172.21.0.166:5222   ESTABLISHED


Nerveless the client is offline in spacewalk.

Warm regards,

Harald


Von: 
spacewalk-list-boun...@redhat.com