Re: [Spacewalk-list] PCX boot for spacewalk client

[Robert Paschedag]

Am 25. April 2018 06:43:58 MESZ schrieb "Afify, Sherif S (IBS)" 
:
>Ok I got the issue its all about SElinux , once I disabled it   worked
>fine.
>
>But still need the selinux , I tried the below  steps :
>
>
>1.  If SELinux is enabled in enforcing mode on your system, configure
>SELinux for Cobbler operation as follows:
> *   Permit the httpd service to act as a proxy for Cobbler.
># setsebool -P httpd_can_network_connect=1
>
>*   Set the public_content_t file type on the /var/lib/tftpboot file
>and /var/www/cobbler/images directory hierarchies as follows:
>c.  # /usr/sbin/semanage fcontext -a -t public_content_t
>"/var/lib/tftpboot/.*"
># /usr/sbin/semanage fcontext -a -t public_content_t
>"/var/www/cobbler/images/.*"
>Note
>The semanage command is provided by the policycoreutils-python package.
>
>  1.  Restart the cobblerd service:
># service cobblerd restart
>
>
>And it set the dir/file as shown below and the boot issue of the
>filename //images/centos7-x86_64-server:2:usip-lab/vmlinuz not find is
>fixed.
>
>[root@vm1 ~]# ls -lZ /var/lib/tftpboot/.
>drwxr-xr-x. root root system_u:object_r:public_content_t:s0 aarch64
>drwxr-xr-x. root root system_u:object_r:public_content_t:s0 etc
>drwxr-xr-x. root root system_u:object_r:public_content_t:s0 grub
>drwxr-xr-x. root root system_u:object_r:public_content_t:s0 images
>-rw-r--r--. root root system_u:object_r:cobbler_var_lib_t:s0 memdisk
>-rw-r--r--. root root system_u:object_r:cobbler_var_lib_t:s0 menu.c32
>drwxr-xr-x. root root system_u:object_r:public_content_t:s0 ppc
>-rw-r--r--. root root system_u:object_r:cobbler_var_lib_t:s0 pxelinux.0
>drwxr-xr-x. root root system_u:object_r:public_content_t:s0
>pxelinux.cfg
>drwxr-xr-x. root root system_u:object_r:public_content_t:s0 s390x
>-rw-r--r--. root root system_u:object_r:cobbler_var_lib_t:s0 yaboot
>[root@vm1 ~]# ls -lZ /var/www/cobbler/
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0 aux
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0 images
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0
>ks_mirror
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0 links
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0
>localmirror
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0 pub
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0
>rendered
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0
>repo_mirror
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0 svc
>drwxr-xr-x. apache apache system_u:object_r:cobbler_var_lib_t:s0 web
>[root@vm1 ~]#
>
>
>But new issue appear when I try to run "cobbler sync" (check the below
>)
>
>So my question what is right configuration for  SELinux for Cobbler ?
>
>
>[root@vm1 ~]# cobbler sync
>task started: 2018-04-24_182931_sync
>task started (id=Sync, time=Tue Apr 24 18:29:31 2018)
>running pre-sync triggers
>cleaning trees
>removing: /var/www/cobbler/images/centos7-x86_64-server:1:usip
>removing: /var/lib/tftpboot/pxelinux.cfg/01-00-1a-4a-16-01-77
>Exception occured: 
>Exception value: [Errno 13] Permission denied:
>'/var/lib/tftpboot/pxelinux.cfg/01-00-1a-4a-16-01-77'
>Exception Info:
>File "/usr/lib/python2.7/site-packages/cobbler/utils.py", line 1192, in
>rmfile
>os.unlink(path)
>
>Exception occured: 
>Exception value: 'Error deleting
>/var/lib/tftpboot/pxelinux.cfg/01-00-1a-4a-16-01-77'
>Exception Info:
>File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 95, in
>run
>rc = self._run(self)
>File "/usr/lib/python2.7/site-packages/cobbler/remote.py", line 186, in
>runner
>return
>self.remote.api.sync(self.options.get("verbose",False),logger=self.logger)
>File "/usr/lib/python2.7/site-packages/cobbler/api.py", line 609, in
>sync
>return sync.run()
>File "/usr/lib/python2.7/site-packages/cobbler/action_sync.py", line
>110, in run
>self.clean_trees()
>File "/usr/lib/python2.7/site-packages/cobbler/action_sync.py", line
>199, in clean_trees
>utils.rmtree_contents(self.pxelinux_dir,logger=self.logger)
>File "/usr/lib/python2.7/site-packages/cobbler/utils.py", line 1204, in
>rmtree_contents
>rmtree(x,logger=logger)
>File "/usr/lib/python2.7/site-packages/cobbler/utils.py", line 1209, in
>rmtree
>return rmfile(path,logger=logger)
>File "/usr/lib/python2.7/site-packages/cobbler/utils.py", line 1198, in
>rmfile
>raise CX(_("Error deleting %s") % path)
>
>!!! TASK FAILED !!!
>[root@vm1 ~]#
>
>From: Afify, Sherif S (IBS)
>Sent: Tuesday, April 24, 2018 12:12 PM
>To: Paschedag, Robert ;
>spacewalk-list@redhat.com
>Subject: RE: PCX boot for spacewalk client
>
>Thanks rob, I got the same error I see on the console ,
>
>
>Apr 23 23:57:53 vm1 in.tftpd[14018]: RRQ from 10.222.21.2 filename
>//images/centos7-x86_64-server:2:usip-lab/vmlinuz
>Apr 23 23:57:53 vm1 in.tftpd[14019]: RRQ from 10.222.21.2 filename
>//images/centos7-x86_64-server:2:usip-lab/vmlinuz.cbt

Re: [Spacewalk-list] Spacewalk 2.7 && Ubuntu 15.04 && Debian 9 [ working solution ]

[Robert Paschedag]

Am 19. April 2018 15:08:05 MESZ schrieb Florin :
>So, finally after so much trial and error here is what I've done to 
>allow smooth integration of Debian 9 and Ubuntu 16.0 with spacewalk
>
>Just to keep it simple
>
>1. create channels: xenial-main + xenial-updates, xenial-security, 
>xenial-universe
>
>2. tricky part  syncing channels [ adding multi-arch header]:
>
>#!/bin/bash
>
>_BIN_PATH=/var/www/html/pub/spw_scripts
>_URL_MAIN='http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64'
>_URL_SEC='http://us.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64'
>_URL_UPD='http://de.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64'
>_URL_UNIV='http://de.archive.ubuntu.com/ubuntu/dists/xenial/universe/binary-amd64'
>_PKG_MAIN=/var/cache/rhn/repodata/xenial-main
>_PKG_SEC=/var/cache/rhn/repodata/xenial-security
>_PKG_UPD=/var/cache/rhn/repodata/xenial-updates
>_PKG_UNIV=/var/cache/rhn/repodata/xenial-universe
>_USER=bugs
>_PASS=bunny
>
>$_BIN_PATH/spacewalk-debian-sync.pl  --url $_URL_MAIN --channel 
>xenial-main    --username=$_USER  --password $_PASS
>$_BIN_PATH/spacewalk-debian-sync.pl  --url $_URL_SEC  --channel 
>xenial-security --username=$_USER  --password $_PASS
>$_BIN_PATH/spacewalk-debian-sync.pl  --url $_URL_UPD  --channel 
>xenial-updates    --username=$_USER  --password $_PASS
>$_BIN_PATH/spacewalk-debian-sync.pl  --url $_URL_UNIV  --channel 
>xenial-universe  --username=$_USER  --password $_PASS
>
>s=180
>trap 'echo "Ctrl-C detected."' 2
>for (( i=$s ; i>0; i--));
>     do
>    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
>$_PKG_MAIN/Packages  
>/tmp/xenial-main
>$_BIN_PATH/spacewalk-add-debian-multiarch-header.py 
>$_PKG_SEC/Packages    /tmp/xenial-security
>$_BIN_PATH/spacewalk-add-debian-multiarch-header.py
>$_PKG_UPD/Packages   
>/tmp/xenial-updates
>$_BIN_PATH/spacewalk-add-debian-multiarch-header.py
>$_PKG_UNIV/Packages  
>/tmp/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_SEC/Packages > $_PKG_SEC/Packages.gz
>     gzip < $_PKG_UPD/Packages > $_PKG_UPD/Packages.gz
>     gzip < $_PKG_UNIV/Packages > $_PKG_UNIV/Packages.gz
>
>3. client side  [ ubuntu/debian clients]
>
>spw_srv=192.168.100.101
>
>cat >/etc/apt/apt.conf.d/50spacewalk<#
># The configuration for apt-spacewalk
>#
>APT {
>   Update {
>     List-Refresh "true";
>     Pre-Invoke {
>     "/usr/lib/apt-spacewalk/pre_invoke.py";
>     }
>     Post-Invoke {
>     "/bin/sed -rie 's/^Package: 
>(cpp|guile-2.0|python(2.7|3)?)$/\0\nMulti-Arch: allowed/' 
>/var/lib/apt/lists/${spw_srv}_dists_channels\:_xenial-main_binary-amd64_Packages";
>     }

You don't need this Post-Invoke hack as the python script adds the missing 
header.

>   }
>};
>DPkg::Post-Invoke {
>     "[ ! -e /usr/lib/apt-spacewalk/post_invoke.py ] || 
>/usr/lib/apt-spacewalk/post_invoke.py";
>};
>FIX
>sed  -i "s|'main'|'xenial-main'|g" /usr/lib/apt-spacewalk/pre_invoke.py
>perl -pi -e "s/type='deb'/type='deb [trusted=yes] '/g" 
>/usr/lib/apt-spacewalk/pre_invoke.py
>
>4. Now can perform apt-get update/upgrade w/o any issues after
>disabling 
>/etc/apt/source.list

One thing "missing". Secure the channels with @philicious "secureApt.sh" 
script. Find it at my fork  https://github.com/rpasche/spacewalk-scripts or 
"origin" https://github.com/philicious/spacewalk-scripts. 
Also have a look at PR #636 and #637 of the SW GitHub repo.

You can then also try to import errata information for Ubuntu and Debian. 

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

Re: [Spacewalk-list] Updating python2.7 packages on Ubuntu 16.04 causes removal of spacewalk client packages and multiple python 2.7 packages

[Robert Paschedag]

Am 17. April 2018 19:27:17 MESZ schrieb Paul-Andre Panon 
<paul-andre.pa...@avigilon.com>:
>
>-Original Message-
>On Monday, April 16, 2018 10:17 PM, Robert Paschedag
>[mailto:robert.pasche...@web.de] wrote:
>>Am 17. April 2018 01:27:11 MESZ schrieb Paul-Andre Panon
><paul-andre.pa...@avigilon.com>:
>>>Hi,
>>>
>>>When trying to apply python 2.7 package updates on our Ubuntu 16.04 
>>>systems, Spacewalk tries to commit suicide by removing all the 
>>>Spacewalk packages and multiple python packages (as well as sssd if 
>>>it's in use). To fix the problem we need to back up the Spacewalk 
>>>sources.list and Spacewalk repo files, switch back to Ubuntu repos by
>
>>>swapping to pre-Spacewalk sources.list, re-install python2.7 and the 
>>>Spacewalk client, and the switch to the Spacewalk sources.list and
>repo 
>>>file again.

Hmmm.. does this happen everytime on those clients?

I'm thinking about the headers of the packages already "installed" on the 
clients (where this error occurs)

Please check the headers in (where is that stored again??) 
/var/lib/dpkg/state?

Robert


>>>
>>>We've had problems with the Multi-Arch header in Packages before.
>>>However I've checked but the Multi-Arch: header for python2.7
>packages 
>>>is still set up correctly in the main, update, and security channel 
>>>Packages files since I fixed them the last time, so that doesn't
>appear 
>>>to be the problem. Does anybody have any idea what might be going on?
>>>
>>Did you manually set the Multi-Arch headers the "last" time? For me it
>sounds
>>as this is not done automatically and if you changed something in one
>of the 
>>channels, that information might be lost.
>That was one of the things I double checked. The packages that had 
>Multi-Arch: Allowed in the Ubuntu repo Packages files still had it in
>our rebuilt and
>manually generated local channel "copies" as well. Whatever is
>happening to cause those
>packages to be removed, I don't think it's got anything to do with
>Multi-Arch. 
>However the python2.7 package upgrades being the trigger for that
>removal raised
>my suspicions and I tried to eliminate that possibility first.
>
>>
>>Please have a look here. Might help.
>>
>>https://www.redhat.com/archives/spacewalk-list/2018-March/msg00100.html
>>
>Cool. We had e-mailed about what would be needed to retrofit that
>functionality into
>Spacewalk db and code properly quite a few months back but I haven't
>had time to work on it.
>
>Paul-Andre Panon
>Senior Systems Administrator
>Avigilon
>A Motorola Solutions Company


-- 
sent from my mobile device

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

Re: [Spacewalk-list] Updating python2.7 packages on Ubuntu 16.04 causes removal of spacewalk client packages and multiple python 2.7 packages

[Robert Paschedag]

Am 17. April 2018 19:27:17 MESZ schrieb Paul-Andre Panon 
<paul-andre.pa...@avigilon.com>:
>
>-Original Message-
>On Monday, April 16, 2018 10:17 PM, Robert Paschedag
>[mailto:robert.pasche...@web.de] wrote:
>>Am 17. April 2018 01:27:11 MESZ schrieb Paul-Andre Panon
><paul-andre.pa...@avigilon.com>:
>>>Hi,
>>>
>>>When trying to apply python 2.7 package updates on our Ubuntu 16.04 
>>>systems, Spacewalk tries to commit suicide by removing all the 
>>>Spacewalk packages and multiple python packages (as well as sssd if 
>>>it's in use). To fix the problem we need to back up the Spacewalk 
>>>sources.list and Spacewalk repo files, switch back to Ubuntu repos by
>
>>>swapping to pre-Spacewalk sources.list, re-install python2.7 and the 
>>>Spacewalk client, and the switch to the Spacewalk sources.list and
>repo 
>>>file again.
>>>
>>>We've had problems with the Multi-Arch header in Packages before.
>>>However I've checked but the Multi-Arch: header for python2.7
>packages 
>>>is still set up correctly in the main, update, and security channel 
>>>Packages files since I fixed them the last time, so that doesn't
>appear 
>>>to be the problem. Does anybody have any idea what might be going on?
>>>
>>Did you manually set the Multi-Arch headers the "last" time? For me it
>sounds
>>as this is not done automatically and if you changed something in one
>of the 
>>channels, that information might be lost.
>That was one of the things I double checked. The packages that had 
>Multi-Arch: Allowed in the Ubuntu repo Packages files still had it in
>our rebuilt and
>manually generated local channel "copies" as well. Whatever is
>happening to cause those
>packages to be removed, I don't think it's got anything to do with
>Multi-Arch. 
>However the python2.7 package upgrades being the trigger for that
>removal raised
>my suspicions and I tried to eliminate that possibility first.

I think I once had a similar error on SLES systems with one special "rhnlib" 
version that caused some dependency problems and thus removed some spacewalk 
stuff.

>
>>
>>Please have a look here. Might help.
>>
>>https://www.redhat.com/archives/spacewalk-list/2018-March/msg00100.html
>>
>Cool. We had e-mailed about what would be needed to retrofit that
>functionality into
>Spacewalk db and code properly quite a few months back but I haven't
>had time to work on it.

I remember. I think, it shouldn't be hard to modify that so you point it to the 
original "packages.gz", parse it and add the missing "Multi-Arch" header to the 
packages.gz created by spacewalk.

In fact, this could be used to add *all* missing original headers to the 
packages.gz file on spacewalk (when I think about it right now).

Robert

>
>Paul-Andre Panon
>Senior Systems Administrator
>Avigilon
>A Motorola Solutions Company


-- 
sent from my mobile device

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

Re: [Spacewalk-list] Updating python2.7 packages on Ubuntu 16.04 causes removal of spacewalk client packages and multiple python 2.7 packages

[Robert Paschedag]

Am 17. April 2018 01:27:11 MESZ schrieb Paul-Andre Panon 
:
>Hi,
>
>When trying to apply python 2.7 package updates on our Ubuntu 16.04
>systems, Spacewalk tries to commit suicide by removing all the
>Spacewalk packages and multiple python packages (as well as sssd if
>it's in use). To fix the problem we need to back up the Spacewalk
>sources.list and Spacewalk repo files, switch back to Ubuntu repos by
>swapping to pre-Spacewalk sources.list, re-install python2.7 and the
>Spacewalk client, and the switch to the Spacewalk sources.list and repo
>file again.
>
>We've had problems with the Multi-Arch header in Packages before.
>However I've checked but the Multi-Arch: header for python2.7 packages
>is still set up correctly in the main, update, and security channel
>Packages files since I fixed them the last time, so that doesn't appear
>to be the problem. Does anybody have any idea what might be going on?
>
>root@u16server:/home/local/YORK/ppanon# sudo rhn_check -vvv
>D: check_action{'action': "version='1.0'?>\n\npackages.update\n\n\n\n\nlibpython-stdlib\n2.7.12\n1~16.04\n\namd64-deb\n\n\npython\n2.7.12\n1~16.04\n\namd64-deb\n\n\npython-minimal\n2.7.12\n1~16.04\n\namd64-deb\n\n\n\n\n\n",
>'version': 2, 'id': 1968}
>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 1523920847.76 with expiration of
>1523924447.76 seconds.
>successfully retrieved authentication token from up2date server
>D: logininfo:{'X-RHN-Server-Id': 110078, 'X-RHN-Auth-Server-Time':
>'1523920847.75', 'X-RHN-Auth':
>'Y1ME414TmOz4KzZw2TldrrD/57wOcaVxdYol4N4YRSY=', 'X-RHN-Auth-Channels':
>[['xenial', '20180408040248', '1', '1'], ['xenial-security',
>'20180408040949', '0', '1'], ['xenial-security-universe',
>'20180408040914', '0', '1'], ['xenial-updates-universe',
>'20180408040914', '0', '1'], ['xenial-updates', '20180408040949', '0',
>'1'], ['xenial-backports', '20180408040307', '0', '1']],
>'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
>D: handle_action{'action': "version='1.0'?>\n\npackages.update\n\n\n\n\nlibpython-stdlib\n2.7.12\n1~16.04\n\namd64-deb\n\n\npython\n2.7.12\n1~16.04\n\namd64-deb\n\n\npython-minimal\n2.7.12\n1~16.04\n\namd64-deb\n\n\n\n\n\n",
>'version': 2, 'id': 1968}
>D: handle_action actionid = 1968, version = 2
>D: do_call packages.update([['libpython-stdlib', '2.7.12', '1~16.04',
>'', 'amd64-deb'], ['python', '2.7.12', '1~16.04', '', 'amd64-deb'],
>['python-minimal', '2.7.12', '1~16.04', '',
>'amd64-deb']],){'cache_only': None}
>D: Called update[['libpython-stdlib', '2.7.12', '1~16.04', '',
>'amd64-deb'], ['python', '2.7.12', '1~16.04', '', 'amd64-deb'],
>['python-minimal', '2.7.12', '1~16.04', '', 'amd64-deb']]
>Apt-Spacewalk: Updating sources.list
>(Reading database ... 265831 files and directories currently
>installed.)
>Removing apt-transport-spacewalk (1.0.6-4.1) ...
>Removing gufw (16.04.1-0ubuntu1.1) ...
>Removing ndiff (7.01-2ubuntu2) ...
>Removing rhnsd (5.0.4-3) ...
>Removing rhn-client-tools (1.8.26-4) ...
>Removing python-apt (1.1.0~beta1ubuntu0.16.04.1) ...
>Removing python-bs4 (4.4.1-1) ...
>Removing zenmap (7.01-2ubuntu2) ...
>Removing python-gtk2 (2.24.0-4ubuntu1) ...
>Removing python-cairo (1.8.8-2) ...
>Removing python-chardet (2.3.0-2) ...
>Removing python-rhn (2.5.55-2) ...
>Removing python-openssl (0.15.1-2build1) ...
>Removing python-cryptography (1.2.3-1ubuntu0.1) ...
>Removing python-dbus (1.2.0-3) ...
>Removing python-dmidecode (3.12.2-2) ...
>Removing python-enum34 (1.1.2-1) ...
>Removing python-gudev (147.2-3) ...
>Removing python-gobject (3.20.0-0ubuntu1) ...
>Removing python-gi (3.20.0-0ubuntu1) ...
>Removing python-gobject-2 (2.28.6-12ubuntu1) ...
>Removing python-html5lib (0.999-4) ...
>Removing python-idna (2.0-3) ...
>Removing python-ipaddress (1.0.16-1) ...
>Removing python-jabber (0.5.0-1.6) ...
>Removing python-pkg-resources (20.7.0-1) ...
>Removing python-pyasn1 (0.1.9-1) ...
>Removing python-six (1.10.0-3) ...
>Processing triggers for man-db (2.7.5-1) ...
>Processing triggers for hicolor-icon-theme (0.15-0ubuntu1) ...
>Processing triggers for bamfdaemon (0.5.3~bzr0+16.04.20180209-0ubuntu1)
>...
>Rebuilding /usr/share/applications/bamf-2.index...
>Processing triggers for mime-support (3.59ubuntu1) ...
>Processing triggers for desktop-file-utils (0.22-1ubuntu5.1) ...
>Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
>Processing triggers for libc-bin (2.23-0ubuntu10) ...
>Processing triggers for doc-base (0.10.7) ...
>Processing 1 removed doc-base file...
>Registering documents with scrollkeeper...
>(Reading database ... 264545 files and directories currently
>installed.)
>Preparing to unpack .../python-minimal_2.7.12-1~16.04_amd64.deb ...
>Unpacking python-minimal (2.7.12-1~16.04) over (2.7.11-1) ...
>Processing triggers for man-db (2.7.5-1) ...
>Setting up python-minimal 

Re: [Spacewalk-list] Updating python2.7 packages on Ubuntu 16.04 causes removal of spacewalk client packages and multiple python 2.7 packages

[Robert Paschedag]

Am 17. April 2018 01:27:11 MESZ schrieb Paul-Andre Panon 
:
>Hi,
>
>When trying to apply python 2.7 package updates on our Ubuntu 16.04
>systems, Spacewalk tries to commit suicide by removing all the
>Spacewalk packages and multiple python packages (as well as sssd if
>it's in use). To fix the problem we need to back up the Spacewalk
>sources.list and Spacewalk repo files, switch back to Ubuntu repos by
>swapping to pre-Spacewalk sources.list, re-install python2.7 and the
>Spacewalk client, and the switch to the Spacewalk sources.list and repo
>file again.
>
>We've had problems with the Multi-Arch header in Packages before.
>However I've checked but the Multi-Arch: header for python2.7 packages
>is still set up correctly in the main, update, and security channel
>Packages files since I fixed them the last time, so that doesn't appear
>to be the problem. Does anybody have any idea what might be going on?

Did you manually set the Multi-Arch headers the "last" time? For me it sounds 
as this is not done automatically and if you changed something in one of the 
channels, that information might be lost.

>
>root@u16server:/home/local/YORK/ppanon# sudo rhn_check -vvv
>D: check_action{'action': "version='1.0'?>\n\npackages.update\n\n\n\n\nlibpython-stdlib\n2.7.12\n1~16.04\n\namd64-deb\n\n\npython\n2.7.12\n1~16.04\n\namd64-deb\n\n\npython-minimal\n2.7.12\n1~16.04\n\namd64-deb\n\n\n\n\n\n",
>'version': 2, 'id': 1968}
>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 1523920847.76 with expiration of
>1523924447.76 seconds.
>successfully retrieved authentication token from up2date server
>D: logininfo:{'X-RHN-Server-Id': 110078, 'X-RHN-Auth-Server-Time':
>'1523920847.75', 'X-RHN-Auth':
>'Y1ME414TmOz4KzZw2TldrrD/57wOcaVxdYol4N4YRSY=', 'X-RHN-Auth-Channels':
>[['xenial', '20180408040248', '1', '1'], ['xenial-security',
>'20180408040949', '0', '1'], ['xenial-security-universe',
>'20180408040914', '0', '1'], ['xenial-updates-universe',
>'20180408040914', '0', '1'], ['xenial-updates', '20180408040949', '0',
>'1'], ['xenial-backports', '20180408040307', '0', '1']],
>'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
>D: handle_action{'action': "version='1.0'?>\n\npackages.update\n\n\n\n\nlibpython-stdlib\n2.7.12\n1~16.04\n\namd64-deb\n\n\npython\n2.7.12\n1~16.04\n\namd64-deb\n\n\npython-minimal\n2.7.12\n1~16.04\n\namd64-deb\n\n\n\n\n\n",
>'version': 2, 'id': 1968}
>D: handle_action actionid = 1968, version = 2
>D: do_call packages.update([['libpython-stdlib', '2.7.12', '1~16.04',
>'', 'amd64-deb'], ['python', '2.7.12', '1~16.04', '', 'amd64-deb'],
>['python-minimal', '2.7.12', '1~16.04', '',
>'amd64-deb']],){'cache_only': None}
>D: Called update[['libpython-stdlib', '2.7.12', '1~16.04', '',
>'amd64-deb'], ['python', '2.7.12', '1~16.04', '', 'amd64-deb'],
>['python-minimal', '2.7.12', '1~16.04', '', 'amd64-deb']]
>Apt-Spacewalk: Updating sources.list
>(Reading database ... 265831 files and directories currently
>installed.)
>Removing apt-transport-spacewalk (1.0.6-4.1) ...
>Removing gufw (16.04.1-0ubuntu1.1) ...
>Removing ndiff (7.01-2ubuntu2) ...
>Removing rhnsd (5.0.4-3) ...
>Removing rhn-client-tools (1.8.26-4) ...
>Removing python-apt (1.1.0~beta1ubuntu0.16.04.1) ...
>Removing python-bs4 (4.4.1-1) ...
>Removing zenmap (7.01-2ubuntu2) ...
>Removing python-gtk2 (2.24.0-4ubuntu1) ...
>Removing python-cairo (1.8.8-2) ...
>Removing python-chardet (2.3.0-2) ...
>Removing python-rhn (2.5.55-2) ...
>Removing python-openssl (0.15.1-2build1) ...
>Removing python-cryptography (1.2.3-1ubuntu0.1) ...
>Removing python-dbus (1.2.0-3) ...
>Removing python-dmidecode (3.12.2-2) ...
>Removing python-enum34 (1.1.2-1) ...
>Removing python-gudev (147.2-3) ...
>Removing python-gobject (3.20.0-0ubuntu1) ...
>Removing python-gi (3.20.0-0ubuntu1) ...
>Removing python-gobject-2 (2.28.6-12ubuntu1) ...
>Removing python-html5lib (0.999-4) ...
>Removing python-idna (2.0-3) ...
>Removing python-ipaddress (1.0.16-1) ...
>Removing python-jabber (0.5.0-1.6) ...
>Removing python-pkg-resources (20.7.0-1) ...
>Removing python-pyasn1 (0.1.9-1) ...
>Removing python-six (1.10.0-3) ...
>Processing triggers for man-db (2.7.5-1) ...
>Processing triggers for hicolor-icon-theme (0.15-0ubuntu1) ...
>Processing triggers for bamfdaemon (0.5.3~bzr0+16.04.20180209-0ubuntu1)
>...
>Rebuilding /usr/share/applications/bamf-2.index...
>Processing triggers for mime-support (3.59ubuntu1) ...
>Processing triggers for desktop-file-utils (0.22-1ubuntu5.1) ...
>Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
>Processing triggers for libc-bin (2.23-0ubuntu10) ...
>Processing triggers for doc-base (0.10.7) ...
>Processing 1 removed doc-base file...
>Registering documents with scrollkeeper...
>(Reading database ... 264545 files and directories currently
>installed.)

Re: [Spacewalk-list] Cannot install updates on spacewalk client

[Robert Paschedag]

Please go to

Channels -> manage software channels -> manage software packages

Select your channel with problematic packages

Can you find the packages in there?

If yes, remove the packages from the channel. If that works, go to the same view
and search for "packages in no channels". Your previously remove packages 
should show up.
Finally delete these packages from spacewalk and try to resync.

Robert


> Gesendet: Montag, 09. April 2018 um 15:17 Uhr
> Von: "Michael Watters" 
> An: spacewalk-list@redhat.com
> Betreff: [Spacewalk-list]  Cannot install updates on spacewalk client
>
> 
> On 04/04/2018 05:09 AM, Michael Mraka wrote:
> > Michael Watters:
> >>> You can check the path with
> >>>
> >>> select * from rhnpackage where id = 11570;
> >>>
> >>> But the message indicates some sort of error while you were synchronizing 
> >>> your repos. I would try to locate this problem "package" within SW in the 
> >>> "Channels" -> "Manage Software Channels" -> "Manage software packages" 
> >>> and try to *fully* delete this package and try to re-sync.
> >>>
> >>> Robert
> >> No luck.  I deleted the package and reran spacewalk-repo-sync which
> >> claims to have downloaded the package but yum updates still fail.  The
> >> interesting part is spacewalk-repo-sync keeps trying to download the
> >> same 33 packages every time I download it.  For example, here's the output.
> > Hello Michael,
> >
> > How did you deleted the package? Just the file in /var/satellite?
> > Then the the wrong record in database is still there.
> >
> > You can try spacewalk-data-fsck to if there's any see mismatch between
> > db and filesystem (and there's also a limited functionality to "repair"
> > errors).
> 
> I removed the file in /var/satellite and then ran spacewalk-repo-sync
> which showed the package being downloaded again.  Here is what is shown
> when I sync the channel.
> 
> https://gist.github.com/blackknight36/0397f18b0167ae37759a96c1cd2728d1
> 
> Running the spacewalk-repo-sync again results in the same packages being
> imported, it's almost as if they're never making it into the database.
> 
> I've ran spacewalk-data-fsck to remove packages missing in the database
> and to fix missing files which also did not help.
> 
> ___
> 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 install updates on spacewalk client

[Robert Paschedag]

> Gesendet: Montag, 09. April 2018 um 15:17 Uhr
> Von: "Michael Watters" 
> An: spacewalk-list@redhat.com
> Betreff: [Spacewalk-list]  Cannot install updates on spacewalk client
>
> 
> On 04/04/2018 05:09 AM, Michael Mraka wrote:
> > Michael Watters:
> >>> You can check the path with
> >>>
> >>> select * from rhnpackage where id = 11570;
> >>>
> >>> But the message indicates some sort of error while you were synchronizing 
> >>> your repos. I would try to locate this problem "package" within SW in the 
> >>> "Channels" -> "Manage Software Channels" -> "Manage software packages" 
> >>> and try to *fully* delete this package and try to re-sync.
> >>>
> >>> Robert
> >> No luck.  I deleted the package and reran spacewalk-repo-sync which
> >> claims to have downloaded the package but yum updates still fail.  The
> >> interesting part is spacewalk-repo-sync keeps trying to download the
> >> same 33 packages every time I download it.  For example, here's the output.
> > Hello Michael,
> >
> > How did you deleted the package? Just the file in /var/satellite?
> > Then the the wrong record in database is still there.
> >
> > You can try spacewalk-data-fsck to if there's any see mismatch between
> > db and filesystem (and there's also a limited functionality to "repair"
> > errors).
> 
> I removed the file in /var/satellite and then ran spacewalk-repo-sync
> which showed the package being downloaded again.  Here is what is shown
> when I sync the channel.
> 
> https://gist.github.com/blackknight36/0397f18b0167ae37759a96c1cd2728d1
> 
> Running the spacewalk-repo-sync again results in the same packages being
> imported, it's almost as if they're never making it into the database.
> 
> I've ran spacewalk-data-fsck to remove packages missing in the database
> and to fix missing files which also did not help.

That is exactly the error. You did not also check to remove the packages
from the database, which are not on the filesystem.

As told, it looks like you have the error within your DB...so you need
to fix the DB, not the downloaded packages.

So run spacewalk-data-fsck again, but this time, remove packages from the
DB which are not found on disk

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] Suse Service pack migration

[Robert Paschedag]

Am 6. April 2018 17:41:57 MESZ schrieb suhail.siddi...@visitor.upm.com:
>Hi ,
>
>Any one have idea about SUSE linux service pack migration from
>spacewalk web GUI?
>Like SUSE 12 SP2 to SP3?
>
>Best Regards,
>Suhail Siddiqui
>
>
>
>Please note. The information contained in this message is confidential
>and is intended only for the use of the individual named above and
>others who have been specially authorized to receive it. If you are not
>the intended recipient, you are hereby notified that any dissemination,
>distribution or copying of this communication is strictly prohibited.
>The attachments have been scanned for viruses prior to leaving our
>E-mail system. UPM-Kymmene Corporation shall not be liable for any
>consequences of any virus being passed on.

Just subscribe the system to the higher channels, and run "zypper dup".

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] Create Kickstart Distribution issue

[Robert Paschedag]

Am 5. April 2018 20:13:22 MESZ schrieb "Afify, Sherif S (IBS)" 
:
>Also the /var/log/audit/audit.log show the below error 
>
>
>type=AVC msg=audit(1522929930.084:173): avc:  denied  { search } for 
>pid=13523 comm="java" name="/" dev="loop0" ino=1856
>scontext=system_u:system_r:tomcat_t:s0
>tcontext=system_u:object_r:iso9660_t:s0 tclass=dir
>type=SYSCALL msg=audit(1522929930.084:173): arch=c03e syscall=4
>success=no exit=-13 a0=7fbc04144aa0 a1=7fbbf42c9c90 a2=7fbbf42c9c90
>a3=5 items=0 ppid=1 pid=13523 auid=4294967295 uid=91 gid=91 euid=91
>suid=91 fsuid=91 egid=91 sgid=91 fsgid=91 tty=(none) ses=4294967295
>comm="java"
>exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64/jre/bin/java"
>subj=system_u:system_r:tomcat_t:s0 key=(null)
>type=PROCTITLE msg=audit(1522929930.084:173):
>proctitle=2F7573722F6C69622F6A766D2F6A72652F62696E2F6A617661002D6561002D586D733235366D002D586D783235366D002D446A6176612E6177742E686561646C6573733D74727565002D446F72672E786D6C2E7361782E6472697665723D6F72672E6170616368652E7865726365732E706172736572732E5341585061727365
>
>-Original Message-
>From: Afify, Sherif S (IBS) 
>Sent: Thursday, April 5, 2018 7:55 PM
>To: spacewalk-list@redhat.com
>Subject: Create Kickstart Distribution issue 
>
>I am getting the below when I create new Kickstart Distribution from
>web interface :
>
>The initrd could not be found at the specified location:
>/var/distro-trees/centos7-x86_64-server/images/pxeboot/initrd.img 
>
>What I did so far and didn't fix the issue :
>
>1- set its SELinux file type as httpd_sys_content_t "
>/usr/sbin/semanage fcontext -a -t httpd_sys_content_t
>"/var/distro-trees(/.*)?" " & /sbin/restorecon -R -v /var/distro-trees
>2- 644 apache.apache for all files and 755 apache.root for all
>directories
>
>
>Can you help me what exactly I am missing ?
>
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Try to first extract the iso to the target folder and set the selinux 
permissions.

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] Read only account to access and view spacewalk

[Robert Paschedag]

Am 5. April 2018 19:24:27 MESZ schrieb "Yakin, Francis" 
:
>>>Hello Francis,
>
>>>You can mark user as "Read-only API user". (Read-only API users are
>forbidden from the Red Hat Satellite web interface, and allowed access
>only to a limited subset of the public API.) Unfortunately there isn't
>read-only WebUI user
>
>Yeah, it doesn't help, we need WebUI
>
>Thanks
>
>Francis
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Michael Mraka
>Sent: Thursday, April 05, 2018 1:00 AM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Read only account to access and view
>spacewalk
>
>Yakin, Francis:
>> I created an account with (normal user) roles, but he can not not see
>the systems when he tried to go to spacewalk GUI.
>> I want him be able to "read" only, can not do any patch or install or
>upgrade any packages, only be able to see(read) what packages or errata
>on the system.
>> 
>> I tied to modify the user by assigning  a specific group, he is able
>to see the systems, but it looks like he also be able to install
>patches or packages. Which I don't want him to do.
>> 
>> What procedure that I need to follow to make it works?
>
>Hello Francis,
>
>You can mark user as "Read-only API user". (Read-only API users are
>forbidden from the Red Hat Satellite web interface, and allowed access
>only to a limited subset of the public API.) Unfortunately there isn't
>read-only WebUI user.
>
>
>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

Well.. Then you might start contributing to the project.

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] RollBack issue

[Robert Paschedag]

Am 3. April 2018 22:28:51 MESZ schrieb "Yakin, Francis" 
<francis.ya...@windriver.com>:
>1) For example I have a system named "abc", it has 32 packages needed
>to be patched
>2) Before I patch "abc" , I created a snapshot tags, called
>"abc-snapshot-tag", this is will take a snap on the system with 32
>packages needed.
>3) then I upgrade the system, the result is successful, now "abc"
>packages is 0
>4) then I went to provisioning - > snapshot tag , showing the tag name
>"abc-snapshot-tag", click on that , Rollback to Snaphot
>5) then I went to event - > history - > it's successful the downgrade,
>but the system stil showing 0 packages, it should be 32, because I roll
>back before I upgraded
>
>
>Francis
>-----Original Message-
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Robert
>Paschedag
>Sent: Tuesday, April 03, 2018 1:01 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] RollBack issue
>
>On 04/03/18 19:16, Yakin, Francis wrote:
>> First I created a snapshot tag before I upgraded 32 packages, after I
>upgraded is become 0 packages.
>> Now, I want to roll back to the system to be needed 32 packages, but 
>> It doesn't work, still showing 0 It should be roll back to 32
>packages needed right?
>> 
>> Thanks
>
>Sorry, but you still don't tell, if the packages on the client *really*
>have been downgraded or not.
>
>How do you "roll-back"? You go to the system (in Spacewalk)
>
>-> Software -> Profile
>
>compare it with the previously created profile, see, that 32 packages
>differ, "select all" and click on "sync packages to "
>
>??
>
>And if this is true, you verified, that all these 32 packages have the
>"old" version installed?
>
>If this is also true, then maybe the "new" (old) list of installed
>packages did not yet get back to the spacewalk server.
>
>Try to run "rhn-profile-sync" and see, if the display within spacewalk
>changes after some seconds.
>
>Robert
>
>> 
>> Francis
>> 
>> From: spacewalk-list-boun...@redhat.com 
>> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Paschedag, 
>> Robert
>> Sent: Monday, April 02, 2018 11:43 PM
>> To: spacewalk-list@redhat.com
>> Subject: Re: [Spacewalk-list] RollBack issue
>> 
>> You did not mention, if the 32 packages have been successfully
>"downgraded"? If not, then showing 0 packages to upgrade is correct.
>> 
>> Robert
>> 
>> 
>> Von: 
>>
>spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-bounces@redhat
>> .com> 
>>
><spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-bounces@redha
>> t.com>> Im Auftrag von Yakin, Francis
>> Gesendet: Samstag, 31. März 2018 02:29
>> An: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
>> Betreff: [Spacewalk-list] RollBack issue
>> 
>> Apparently, I am having issue with rollback after I upgraded the
>packages, it doesn't roll back to previous snapshot for some reason.
>> 
>> The system is running centOS 6.8, I had 32 packages upgraded, I
>created a snapshot tag before I ran the upgrade.
>> The upgraded was fine, now packages is 0.
>> 
>> Now, I want to rollback to the snapshot tag that I created, so the
>system should have 32 packages packages needs to be upgraded.
>> 
>> It doesn't work for some reason. No error, it showing successful, but
>the system still showing 0 packages.
>> 
>> What did I do wrong? Please advice.
>> 
>> Thanks
>> 
>> 
>> Francis Yakin | IT System Admin |  direct: 510-749-2027
>> 500 Wind River Way, Alameda, CA  94501 
>>
>[cid:image001.png@01D12D0C.E17713F0]<https://emea01.safelinks.protecti
>>
>on.outlook.com/?url=http%3A%2F%2Fwww.windriver.com%2F=02%7C01%7CP
>>
>aschedag.Netlution%40swr.de%7C2e03bad67b8f4f3c094b08d5969e9096%7Cbcca0
>>
>95d88d442f88260cc216b81f62d%7C0%7C1%7C636580530143472137=dun7kdI
>> WcXRzgSe772u3CxCM19plRVDZGcpcOkyIDQQ%3D=0>
>> AN INTEL COMPANY
>> 
>> 
>> 
>> 
>> ___
>> 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

Did you try to run the rhn-profile-sync on the client?
-- 
sent from my mobile device

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

Re: [Spacewalk-list] RollBack issue

[Robert Paschedag]

On 04/03/18 19:16, Yakin, Francis wrote:
> First I created a snapshot tag before I upgraded 32 packages, after I 
> upgraded is become 0 packages.
> Now, I want to roll back to the system to be needed 32 packages, but It 
> doesn't work, still showing 0
> It should be roll back to 32 packages needed right?
> 
> Thanks

Sorry, but you still don't tell, if the packages on the client *really*
have been downgraded or not.

How do you "roll-back"? You go to the system (in Spacewalk)

-> Software -> Profile

compare it with the previously created profile,
see, that 32 packages differ,
"select all" and click on
"sync packages to "

??

And if this is true, you verified, that all these 32 packages have the
"old" version installed?

If this is also true, then maybe the "new" (old) list of installed
packages did not yet get back to the spacewalk server.

Try to run "rhn-profile-sync" and see, if the display within spacewalk
changes after some seconds.

Robert

> 
> Francis
> 
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Paschedag, Robert
> Sent: Monday, April 02, 2018 11:43 PM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] RollBack issue
> 
> You did not mention, if the 32 packages have been successfully "downgraded"? 
> If not, then showing 0 packages to upgrade is correct.
> 
> Robert
> 
> 
> Von: 
> spacewalk-list-boun...@redhat.com 
> > 
> Im Auftrag von Yakin, Francis
> Gesendet: Samstag, 31. März 2018 02:29
> An: spacewalk-list@redhat.com
> Betreff: [Spacewalk-list] RollBack issue
> 
> Apparently, I am having issue with rollback after I upgraded the packages, it 
> doesn't roll back to previous snapshot for some reason.
> 
> The system is running centOS 6.8, I had 32 packages upgraded, I created a 
> snapshot tag before I ran the upgrade.
> The upgraded was fine, now packages is 0.
> 
> Now, I want to rollback to the snapshot tag that I created, so the system 
> should have 32 packages packages needs to be upgraded.
> 
> It doesn't work for some reason. No error, it showing successful, but the 
> system still showing 0 packages.
> 
> What did I do wrong? Please advice.
> 
> Thanks
> 
> 
> Francis Yakin | IT System Admin |  direct: 510-749-2027
> 500 Wind River Way, Alameda, CA  94501
> [cid:image001.png@01D12D0C.E17713F0]
> AN INTEL COMPANY
> 
> 
> 
> 
> ___
> 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] all packages listed as upgradable on debian 9 and ubuntu 1604

[Robert Paschedag]

Am 19. März 2018 17:11:06 MEZ schrieb Andrei Popenta <andrei.pope...@visma.com>:
>Hi Robert,
>Thanks a million for the info you've provided. It really helped me
>solve my
>problem.
>
>I am using spacewalk's capability to sync the debian repo, so I was not
>using Steve's script to "rhnpush" packages.
>But I made a bash script (not skilled in python)  to extract the
>Multi-Arch
>header from the official repo and then patch/update my Packages file,
>and
>after that used the secureAPT script for gpg signing.
>It seems to be working.
>
>Thank you, again :)
>
>On Sat, Mar 17, 2018 at 12:04 AM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> On 03/15/18 18:23, Robert Paschedag wrote:
>> > Am 14. März 2018 16:25:30 MEZ schrieb Andrei Popenta <
>> andrei.pope...@visma.com>:
>> >> Hi guys
>> >>
>> >> i'm running spacewalk 2.7 with debian 8, debian 9 and ubuntu 16.04
>> >> channels.
>> >>
>> >> one problem I am facing is that if apt uses
>> >> only /etc/apt/sources.list.d/spacewalk.list as lists when I run
>apt
>> >> update
>> >> it shows that 400 packages are available for upgrade.
>> >> If I add the official sources in /etc/apt/sources.list it shows
>that
>> >> only
>> >> 29 packages are available for upgrade which is true.
>> >> This happens both for debian 9 and ubuntu 16.04.
>> >> Debian 8 is not affected by this.
>> >>
>> >> I know that someone else has faced this issue before, as I noticed
>2
>> >> comments on this article
>> >> http://www.devops-blog.net/spacewalk/registering-ubuntu-
>> and-debian-servers-with-spacewalk
>> >> but couldn't find any solution for it.
>> >>
>> >> Do you know what might cause this ?
>> >>
>> >> I have added Dirk's workaround mentioned
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1243387
>> >> to  /etc/apt/apt.conf.d/50spacewalk.
>> >>
>> >> thanks,
>> >> Andrei
>> >
>> > Hi,
>> >
>> > in Debian 9, apt got some improvements. These improvements caused
>me a
>> lot headache. My problem was, that although I ran apt-get upgrade,
>all
>> packages were again upgradable (over and over again)
>> >
>> > This is caused by the "Multi-Arch" header, which is missing in the
>> packages.gz files generated by SW.
>> >
>> > To compensate this, I'm really using a lot of workarounds.
>> >
>> > First... Use Steve Meiers Script to download all packages and
>(rhnpush)
>> them into the database.
>> >
>> > But I modified this script to also extract the "Multi-Arch" header
>of a
>> package (if present) and store this information for later usage
>(name,
>> version, architecture)
>> >
>> > After the import, I wait several minutes to let SW do its jobs
>(create
>> the packages.gz files).
>> >
>> > I then patch these files and add the missing "Multi-Arch" headers
>to the
>> packages.gz.
>> >
>> > Before Debian 9, the official repo had only a few packages with
>> "Multi-Arch" headers.
>> >
>> > In Debian 9, the "main" channel has nearly 9000 packages with these
>> headers.
>> >
>> > Robert
>> >
>>
>> See here the modified version of Steve Meiers
>spacewalk-debian-sync.pl
>> script + my spacewalk-add-debian-multiarch-header.py script which
>adds
>> the missing Multi-Arch headers to the packages.gz
>>
>>
>https://github.com/rpasche/spacewalk-debian-sync/tree/add-multiarch-header
>>
>> Robert
>>
>> ___
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list

Glad it helped :-)

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] all packages listed as upgradable on debian 9 and ubuntu 1604

[Robert Paschedag]

On 03/15/18 18:23, Robert Paschedag wrote:
> Am 14. März 2018 16:25:30 MEZ schrieb Andrei Popenta 
> <andrei.pope...@visma.com>:
>> Hi guys
>>
>> i'm running spacewalk 2.7 with debian 8, debian 9 and ubuntu 16.04
>> channels.
>>
>> one problem I am facing is that if apt uses
>> only /etc/apt/sources.list.d/spacewalk.list as lists when I run apt
>> update
>> it shows that 400 packages are available for upgrade.
>> If I add the official sources in /etc/apt/sources.list it shows that
>> only
>> 29 packages are available for upgrade which is true.
>> This happens both for debian 9 and ubuntu 16.04.
>> Debian 8 is not affected by this.
>>
>> I know that someone else has faced this issue before, as I noticed 2
>> comments on this article
>> http://www.devops-blog.net/spacewalk/registering-ubuntu-and-debian-servers-with-spacewalk
>> but couldn't find any solution for it.
>>
>> Do you know what might cause this ?
>>
>> I have added Dirk's workaround mentioned
>> https://bugzilla.redhat.com/show_bug.cgi?id=1243387
>> to  /etc/apt/apt.conf.d/50spacewalk.
>>
>> thanks,
>> Andrei
> 
> Hi,
> 
> in Debian 9, apt got some improvements. These improvements caused me a lot 
> headache. My problem was, that although I ran apt-get upgrade, all packages 
> were again upgradable (over and over again)
> 
> This is caused by the "Multi-Arch" header, which is missing in the 
> packages.gz files generated by SW.
> 
> To compensate this, I'm really using a lot of workarounds.
> 
> First... Use Steve Meiers Script to download all packages and (rhnpush) them 
> into the database.
> 
> But I modified this script to also extract the "Multi-Arch" header of a 
> package (if present) and store this information for later usage (name, 
> version, architecture)
> 
> After the import, I wait several minutes to let SW do its jobs (create the 
> packages.gz files).
> 
> I then patch these files and add the missing "Multi-Arch" headers to the 
> packages.gz.
> 
> Before Debian 9, the official repo had only a few packages with "Multi-Arch" 
> headers.
> 
> In Debian 9, the "main" channel has nearly 9000 packages with these headers.
> 
> Robert
> 

See here the modified version of Steve Meiers spacewalk-debian-sync.pl
script + my spacewalk-add-debian-multiarch-header.py script which adds
the missing Multi-Arch headers to the packages.gz

https://github.com/rpasche/spacewalk-debian-sync/tree/add-multiarch-header

Robert

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

[Spacewalk-list] Importing Debian security errata into Spacewalk

[Robert Paschedag]

Hi all,

since a while, I use Steve Meiers script to synchronize Debian
repositories to our spacewalk server. From @philicious
(https://github.com/philicious/spacewalk-scripts) and @pandujar
(https://github.com/pandujar) I also use the excellent work to add
Ubuntu errata information into spacewalk. I used these scripts as basis
to build scripts, that do the same work for Debian security announcements.

So everone who is using Debian systems and uses Spacewalk to "manage"
these systems, feel free to test these scripts.

@philicious just "merged" my PR into its master branch. I requested this
PR, so all "debian" based scripts are held on one place.

Currently there is one requirement.

The "channel" labels for the "distributions" (e.g. "jessie", "stretch")
must "start" with the distribution name.

As said, I use Steve Meiers script to synchronize the debian repos

Here is a list of "channel:url" mapping I use

jessie_main;http://ftp.de.debian.org/debian/dists/jessie/main/binary-amd64/
jessie_contrib;http://ftp.de.debian.org/debian/dists/jessie/contrib/binary-amd64/
jessie_non-free;http://ftp.de.debian.org/debian/dists/jessie/non-free/binary-amd64/
jessie_updates_main;http://ftp.de.debian.org/debian/dists/jessie-updates/main/binary-amd64/
jessie_updates_contrib;http://ftp.de.debian.org/debian/dists/jessie-updates/contrib/binary-amd64/
jessie_updates_non-free;http://ftp.de.debian.org/debian/dists/jessie-updates/non-free/binary-amd64/
jessie_backports_main;http://ftp.de.debian.org/debian/dists/jessie-backports/main/binary-amd64/
jessie_backports_contrib;http://ftp.de.debian.org/debian/dists/jessie-backports/contrib/binary-amd64/
jessie_backports_non-free;http://ftp.de.debian.org/debian/dists/jessie-backports/non-free/binary-amd64/
jessie_security_main;http://security.debian.org/dists/jessie/updates/main/binary-amd64/
jessie_security_contrib;http://security.debian.org/dists/jessie/updates/contrib/binary-amd64/
jessie_security_non-free;http://security.debian.org/dists/jessie/updates/non-free/binary-amd64/

## stretch
stretch_main_main;http://ftp.de.debian.org/debian/dists/stretch/main/binary-amd64/
stretch_main_contrib;http://ftp.de.debian.org/debian/dists/stretch/contrib/binary-amd64/
stretch_main_non-free;http://ftp.de.debian.org/debian/dists/stretch/non-free/binary-amd64/
stretch_updates_main;http://ftp.de.debian.org/debian/dists/stretch-updates/main/binary-amd64/
stretch_updates_contrib;http://ftp.de.debian.org/debian/dists/stretch-updates/contrib/binary-amd64/
stretch_updates_non-free;http://ftp.de.debian.org/debian/dists/stretch-updates/non-free/binary-amd64/
stretch_backports_main;http://ftp.de.debian.org/debian/dists/stretch-backports/main/binary-amd64/
stretch_backports_contrib;http://ftp.de.debian.org/debian/dists/stretch-backports/contrib/binary-amd64/
stretch_backports_non-free;http://ftp.de.debian.org/debian/dists/stretch-backports/non-free/binary-amd64/
stretch_security_main;http://security.debian.org/dists/stretch/updates/main/binary-amd64/
stretch_security_contrib;http://security.debian.org/dists/stretch/updates/contrib/binary-amd64/
stretch_security_non-free;http://security.debian.org/dists/stretch/updates/non-free/binary-amd64/

As said before, there is the current limitation that the channel label
must start with the name of the distribution (e.g. "jessie" or
"stretch"). This might be changed in
https://github.com/philicious/spacewalk-scripts/blob/fb82685ab78e18138f94584b26759ba039eb5617/errata-import-debian.py#L158

But if you have the channels like I have and already have the packages
synchronized, you start with

getDebianAnnouncement.py

to download the debian security announcements of *this* year and the
year before. These files also gets parsed through "html2text" (you need
to install this package on the SW server - yum install html2text).

parseDebian.py

parses these files and creates an XML file (just like parseUbuntu.py).
For every distribution that is listed within a security announcement,
one errata (for this distribution will be created, as long there are
packages found for this distribution within SW). So if you have
"stretch" and "jessie", you will get "jessie-DSA-1234" errata and
"stretch-DSA-1234" errata within SW.

Use

errata-import-debian.py

to parse the XML file and create the errata within SW.

This is how the output of "errata-import-debian.py" looks if called with
"-d 1" (is just from today, only 2 new announcements parsed)

Started errata import. Debug level: 1
[+] Creating inventory from Server:
[+] Including channel(s): ['jessie_security_main',
'jessie_security_contrib', 'jessie_security_non-free',
'stretch_security_main', 'stretch_security_contrib',
'stretch_security_non-free']
[+] Retrieving Package List from Channel: jessie_security_main
[+] Retrieving Package List from Channel: jessie_security_contrib
[+] Retrieving Package List from Channel: jessie_security_non-free
[+] Retrieving Package List from Channel: stretch_security_main
[+] Retrieving Package List 

Re: [Spacewalk-list] all packages listed as upgradable on debian 9 and ubuntu 1604

[Robert Paschedag]

Am 14. März 2018 16:25:30 MEZ schrieb Andrei Popenta :
>Hi guys
>
>i'm running spacewalk 2.7 with debian 8, debian 9 and ubuntu 16.04
>channels.
>
>one problem I am facing is that if apt uses
>only /etc/apt/sources.list.d/spacewalk.list as lists when I run apt
>update
>it shows that 400 packages are available for upgrade.
>If I add the official sources in /etc/apt/sources.list it shows that
>only
>29 packages are available for upgrade which is true.
>This happens both for debian 9 and ubuntu 16.04.
>Debian 8 is not affected by this.
>
>I know that someone else has faced this issue before, as I noticed 2
>comments on this article
>http://www.devops-blog.net/spacewalk/registering-ubuntu-and-debian-servers-with-spacewalk
>but couldn't find any solution for it.
>
>Do you know what might cause this ?
>
>I have added Dirk's workaround mentioned
>https://bugzilla.redhat.com/show_bug.cgi?id=1243387
>to  /etc/apt/apt.conf.d/50spacewalk.
>
>thanks,
>Andrei

Hi,

in Debian 9, apt got some improvements. These improvements caused me a lot 
headache. My problem was, that although I ran apt-get upgrade, all packages 
were again upgradable (over and over again)

This is caused by the "Multi-Arch" header, which is missing in the packages.gz 
files generated by SW.

To compensate this, I'm really using a lot of workarounds.

First... Use Steve Meiers Script to download all packages and (rhnpush) them 
into the database.

But I modified this script to also extract the "Multi-Arch" header of a package 
(if present) and store this information for later usage (name, version, 
architecture)

After the import, I wait several minutes to let SW do its jobs (create the 
packages.gz files).

I then patch these files and add the missing "Multi-Arch" headers to the 
packages.gz.

Before Debian 9, the official repo had only a few packages with "Multi-Arch" 
headers.

In Debian 9, the "main" channel has nearly 9000 packages with these headers.

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] osa-dispatcher fails to start

[Robert Paschedag]

On 03/13/18 21:07, Robert Paschedag wrote:
> On 03/13/18 20:30, Daryl Rose wrote:
>> Alex,
>>
>>
>> I just realized that I had more errors to look at.   I didn't check the 
>> error log prior to my last update.
>>
>>
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.check_cert('Loading 
>> cert', > L.L.C./CN=Network Solutions OV Server CA 2'>)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
>> rhnSQL/driver_postgresql.convert_named_query_params('Converting query for 
>> PostgreSQL: \nselect id, password\n  from rhnPushDispatcher\n 
>> where jabber_id like :jabber_id\n',)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
>> rhnSQL/driver_postgresql.convert_named_query_params('New query: \nselect 
>> id, password\n  from rhnPushDispatcher\n where jabber_id like 
>> %(jabber_id)s\n',)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
>> rhnSQL/driver_postgresql._execute_wrapper('Executing SQL: "\nselect id, 
>> password\n  from rhnPushDispatcher\n where jabber_id like 
>> %(jabber_id)s\n" with bind params: {jabber_id: rhn-dispatcher-sat%}',)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
>> osad/jabber_lib.setup_connection('Connecting to', '')
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib._get_jabber_client
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
>> osad/jabber_lib._get_jabber_client('Connecting to', '')
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.__init__
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.__init__
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.check_cert('Loading 
>> cert', > L.L.C./CN=Network Solutions OV Server CA 2'>)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Attempting 
>> to connect',)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process(300,)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process('before 
>> select(); timeout', 299.9904632568)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process('select() 
>> returned',)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
>> osad/jabber_lib._auth_dispatch(> 0x24bf950>,)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
>> osad/jabber_lib.connect('Connected',)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Expecting 
>> features stanza, got:', > 'http://affinix.com/jabber/address' >:::> 'http://jabber.org/features/iq-auth'  />> 'http://jabber.org/features/iq-register'  />> 'urn:ietf:params:xml:ns:xmpp-tls' >)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('starttls 
>> node', )
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process(None,)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process('before 
>> select(); timeout', None)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process('select() 
>> returned',)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
>> osad/jabber_lib._auth_dispatch(> 0x2538b90>,)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Expecting 
>> proceed stanza, got:', )
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Preparing 
>> for TLS handshake',)
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('ERROR', 
>> 'Traceback caught:')
>> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.main('ERROR', 
>> 'Error caught:')
>>
>> Anything here that might be a clue as to what is going on?
>>
>> Thanks
>>
>> Daryl
>>
> 
> So your jabber cert seems to be /etc/pki/spacewalk/jabberd/server.pem
> 
> What does
> 
> openssl x509 -in /etc/pki/spacewalk/jabberd/server.pem -noout -enddate
> -subject
> 
> tell?
> 
> Robert

You also might look into this old messagebut this is a more
"generic" message

https://www.redhat.com/archives/spacewalk-list/2015-September/msg00040.html


>> 
>> From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> 
>> on behalf of Daryl Rose <darylr...@outlook.com>
>> Sent: Tuesday, March 13, 2018 1:51 PM
>> To: spacewalk-list@redhat.com
>> Subject: Re: [Spacewalk-list] osa-dispatcher fails to start
>>
>>
>> Alex,
>>
>>
>> Sorry, can't/won't post /etc/hosts and /etc/sysconfig/network.  Trust me 
>> when I say that he server name is fully qualified.  Nothing in that regard 
>> has

Re: [Spacewalk-list] Upgrading 2.6 to 2.7 Spacewalk - on centOS

[Robert Paschedag]

On 03/13/18 21:10, Yakin, Francis wrote:
> 
> Any one have some experience with upgrading Spacewalk server from 2.6 to 2.7?
> 
> Thanks
> 
> Francis Yakin | IT System Admin |  direct: 510-749-2027
> 500 Wind River Way, Alameda, CA  94501
> [cid:image001.png@01D12D0C.E17713F0]
> AN INTEL COMPANY
> 

Just read the docs

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

> 
> 
> 
> ___
> 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 fails to start

[Robert Paschedag]

On 03/13/18 20:30, Daryl Rose wrote:
> Alex,
> 
> 
> I just realized that I had more errors to look at.   I didn't check the error 
> log prior to my last update.
> 
> 
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.check_cert('Loading 
> cert',  L.L.C./CN=Network Solutions OV Server CA 2'>)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
> rhnSQL/driver_postgresql.convert_named_query_params('Converting query for 
> PostgreSQL: \nselect id, password\n  from rhnPushDispatcher\n 
> where jabber_id like :jabber_id\n',)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
> rhnSQL/driver_postgresql.convert_named_query_params('New query: \nselect 
> id, password\n  from rhnPushDispatcher\n where jabber_id like 
> %(jabber_id)s\n',)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
> rhnSQL/driver_postgresql._execute_wrapper('Executing SQL: "\nselect id, 
> password\n  from rhnPushDispatcher\n where jabber_id like 
> %(jabber_id)s\n" with bind params: {jabber_id: rhn-dispatcher-sat%}',)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
> osad/jabber_lib.setup_connection('Connecting to', '')
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib._get_jabber_client
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
> osad/jabber_lib._get_jabber_client('Connecting to', '')
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.__init__
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.__init__
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.check_cert('Loading 
> cert',  L.L.C./CN=Network Solutions OV Server CA 2'>)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Attempting 
> to connect',)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process(300,)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process('before 
> select(); timeout', 299.9904632568)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process('select() 
> returned',)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
> osad/jabber_lib._auth_dispatch(,)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Connected',)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Expecting 
> features stanza, got:',  'http://affinix.com/jabber/address' >::: 'http://jabber.org/features/iq-auth'  /> 'http://jabber.org/features/iq-register'  /> 'urn:ietf:params:xml:ns:xmpp-tls' >)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('starttls 
> node', )
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process(None,)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process('before 
> select(); timeout', None)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.process('select() 
> returned',)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: 
> osad/jabber_lib._auth_dispatch(,)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Expecting 
> proceed stanza, got:', )
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('Preparing 
> for TLS handshake',)
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.connect('ERROR', 
> 'Traceback caught:')
> 2018/03/13 14:24:59 -05:00 8164 0.0.0.0: osad/jabber_lib.main('ERROR', 'Error 
> caught:')
> 
> Anything here that might be a clue as to what is going on?
> 
> Thanks
> 
> Daryl
> 

So your jabber cert seems to be /etc/pki/spacewalk/jabberd/server.pem

What does

openssl x509 -in /etc/pki/spacewalk/jabberd/server.pem -noout -enddate
-subject

tell?

Robert
> 
> From: spacewalk-list-boun...@redhat.com  
> on behalf of Daryl Rose 
> Sent: Tuesday, March 13, 2018 1:51 PM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] osa-dispatcher fails to start
> 
> 
> Alex,
> 
> 
> Sorry, can't/won't post /etc/hosts and /etc/sysconfig/network.  Trust me when 
> I say that he server name is fully qualified.  Nothing in that regard has 
> changed.  My suspicion was and still is that it's the cert.
> 
> 
> Looking back on this, I realize that I should have kept the self-signed certs 
> in place, but for some reason I had to use a signed cert.  I used a doc that 
> I found on Oracle explaining how to replace the self-signed certs with a CA 
> signed cert.
> 
> 
> The cert expired in January.  I posted a question asking if I have to 
> re-register all of our clients with a new, updated cert.  I was told no, that 
> all I had to do was update the certificate for the WUI portion of SW.  
> However, I see that the jabber certificate, server.pem, did expire in January.
> 
> 
> I replaced the server.pem cert with the one that was generated when I updated 
> the cert earlier this year.   I just now verified it against 
> /var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT and it came back okay.
> 
> 
> openssl verify -CAfile /var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT 
> 

Re: [Spacewalk-list] osa-dispatcher fails to start

[Robert Paschedag]

Am 13. März 2018 19:51:21 MEZ schrieb Daryl Rose :
>Alex,
>
>
>Sorry, can't/won't post /etc/hosts and /etc/sysconfig/network.  Trust
>me when I say that he server name is fully qualified.  Nothing in that
>regard has changed.  My suspicion was and still is that it's the cert.
>
>
>Looking back on this, I realize that I should have kept the self-signed
>certs in place, but for some reason I had to use a signed cert.  I used
>a doc that I found on Oracle explaining how to replace the self-signed
>certs with a CA signed cert.
>
>
>The cert expired in January.  I posted a question asking if I have to
>re-register all of our clients with a new, updated cert.  I was told
>no, that all I had to do was update the certificate for the WUI portion
>of SW.  However, I see that the jabber certificate, server.pem, did
>expire in January.
>
>
>I replaced the server.pem cert with the one that was generated when I
>updated the cert earlier this year.   I just now verified it against
>/var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT and it came back okay.
>
>
>openssl verify -CAfile /var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT
>/etc/pki/spacewalk/jabberd/server.pem
>/etc/pki/spacewalk/jabberd/server.pem: OK
>
>
>However, I still get the same error when starting the osa-dispatcher.
>
>
>--> xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
>
><-- >:::'http://jabber.org/features/iq-auth'  />'http://jabber.org/features/iq-register'  />'urn:ietf:params:xml:ns:xmpp-tls' >
>
><-- 
>
>Spacewalk 6928 2018/03/13 13:41:37 -05:00: ('Traceback caught:',)
>Spacewalk 6928 2018/03/13 13:41:37 -05:00: ('Error caught:',)
>
>ERROR: unhandled exception occurred: (can't write str to text stream).
>
>
>One question that I have, is what are these URL's?
>
>http://affinix.com/jabber/address
>
>http://jabber.org/features/iq-register
>
>
>I'm not knowledgeable in python, but it looks to me as if its
>registering with an external url and is using tls.   First of, why is
>jabber registering with an external url?  And, if it is, is it possible
>that the ca-certificates are out of date and need to be updated?
>
>
>Thanks
>
>
>Daryl
>
>
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of Alexandru Raceanu
>
>Sent: Tuesday, March 13, 2018 12:18 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] osa-dispatcher fails to start
>
>Can you post the /etc/hosts and /etc/sysconfig/network ?
>if not... check this one: https://access.redhat.com/solutions/327903
>
>/Alex
>
>
>From: "Daryl Rose" 
>To: spacewalk-list@redhat.com
>Sent: Tuesday, March 13, 2018 4:22:41 PM
>Subject: Re: [Spacewalk-list] osa-dispatcher fails to start
>
>
>Yes, really, that was all.
>
>
>Here is the output from the very verbose osa-dispatcher start:
>
>
>/usr/sbin/osa-dispatcher -N -v -v -v -v -v -v -v
>--> xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
>
><-- >:::10.255.0.6'http://jabber.org/features/iq-auth'  />'http://jabber.org/features/iq-register'  />'urn:ietf:params:xml:ns:xmpp-tls' >
>
><-- 
>
>Spacewalk 653 2018/03/13 10:18:35 -05:00: ('Traceback caught:',)
>Spacewalk 653 2018/03/13 10:18:35 -05:00: ('Error caught:',)
>
>ERROR: unhandled exception occurred: (can't write str to text stream).
>
>Thank you
>
>
>Daryl
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of Paschedag, Robert
>
>Sent: Tuesday, March 13, 2018 8:47 AM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] osa-dispatcher fails to start
>
>
>Is that really all??
>
>
>
>With this information only, it is impossible to help.
>
>
>
>You can try to run osa-dispatcher manually
>
>
>
>Stop it
>
>
>
>/etc/init.d/osa-dispatcher stop
>
>
>
>Run it manually
>
>
>
>/usr/sbin/osa-dispatcher -N -v -v -v -v -v -v -v
>
>
>
>and post errors you get.
>
>
>
>Robert
>
>
>
>
>
>Von: spacewalk-list-boun...@redhat.com
> Im Auftrag von Daryl Rose
>Gesendet: Dienstag, 13. März 2018 14:14
>An: spacewalk-list@redhat.com
>Betreff: Re: [Spacewalk-list] osa-dispatcher fails to start
>
>
>
>Here are the requested entries.
>
>
>
>2018/03/13 08:11:08 -05:00 45604 0.0.0.0: osad/jabber_lib.__init__
>
>2018/03/13 08:11:08 -05:00 45604 0.0.0.0:
>osad/jabber_lib.connect('ERROR', 'Traceback caught:')
>
>2018/03/13 08:11:08 -05:00 45604 0.0.0.0: osad/jabber_lib.main('ERROR',
>'Error caught:')
>
>
>
>Thank you.
>
>
>
>Daryl
>
>
>
>
>
>
>
>From:
>spacewalk-list-boun...@redhat.com
>>
>on behalf of Alexandru Raceanu
>>
>Sent: Monday, March 12, 2018 12:52 PM
>To: 

Re: [Spacewalk-list] osa-dispatcher fails to start

[Robert Paschedag]

Am 13. März 2018 16:22:41 MEZ schrieb Daryl Rose :
>Yes, really, that was all.
>
>
>Here is the output from the very verbose osa-dispatcher start:
>
>
>/usr/sbin/osa-dispatcher -N -v -v -v -v -v -v -v
>--> xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
>
><-- >:::10.255.0.6'http://jabber.org/features/iq-auth'  />'http://jabber.org/features/iq-register'  />'urn:ietf:params:xml:ns:xmpp-tls' >
>
><-- 
>
>Spacewalk 653 2018/03/13 10:18:35 -05:00: ('Traceback caught:',)
>Spacewalk 653 2018/03/13 10:18:35 -05:00: ('Error caught:',)
>
>ERROR: unhandled exception occurred: (can't write str to text stream).
>
>Thank you
>
>
>Daryl
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of Paschedag, Robert
>
>Sent: Tuesday, March 13, 2018 8:47 AM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] osa-dispatcher fails to start
>
>
>Is that really all??
>
>
>
>With this information only, it is impossible to help.
>
>
>
>You can try to run osa-dispatcher manually
>
>
>
>Stop it
>
>
>
>/etc/init.d/osa-dispatcher stop
>
>
>
>Run it manually
>
>
>
>/usr/sbin/osa-dispatcher -N -v -v -v -v -v -v -v
>
>
>
>and post errors you get.
>
>
>
>Robert
>
>
>
>
>
>Von: spacewalk-list-boun...@redhat.com
> Im Auftrag von Daryl Rose
>Gesendet: Dienstag, 13. März 2018 14:14
>An: spacewalk-list@redhat.com
>Betreff: Re: [Spacewalk-list] osa-dispatcher fails to start
>
>
>
>Here are the requested entries.
>
>
>
>2018/03/13 08:11:08 -05:00 45604 0.0.0.0: osad/jabber_lib.__init__
>
>2018/03/13 08:11:08 -05:00 45604 0.0.0.0:
>osad/jabber_lib.connect('ERROR', 'Traceback caught:')
>
>2018/03/13 08:11:08 -05:00 45604 0.0.0.0: osad/jabber_lib.main('ERROR',
>'Error caught:')
>
>
>
>Thank you.
>
>
>
>Daryl
>
>
>
>
>
>
>
>From:
>spacewalk-list-boun...@redhat.com
>>
>on behalf of Alexandru Raceanu
>>
>Sent: Monday, March 12, 2018 12:52 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] osa-dispatcher fails to start
>
>
>
>Can you provide the entries after a "/etc/init.d/osa-dispatcher
>restart" from /var/log/rhn/osa-dispatcher.log ?
>
>
>
>/Alex
>
>
>
>
>
>
>
>From: "Daryl Rose"
>>
>To: spacewalk-list@redhat.com
>Sent: Monday, March 12, 2018 4:28:18 PM
>Subject: Re: [Spacewalk-list] osa-dispatcher fails to start
>
>
>
>I'm sorry, I just realized that I should have provided more
>information.
>
>
>
>  1.  This is a RHEL 6.8 server
>  2.  SW v2.6.
>
>
>
>Also, we use a signed cert and the certificate expired January.  I
>inquired on this list and I was told that I only needed to update the
>cert for the website portion of the cert that they cert used to
>communicate between the systems did not need to be changed.
>
>
>
>I'm guessing its a cert issue from some of the research that I did, but
>I'm not sure what I should update, or if I really need to.
>
>
>
>Thanks
>
>
>
>Daryl
>
>
>
>
>
>From:
>spacewalk-list-boun...@redhat.com
>>
>on behalf of Daryl Rose
>>
>Sent: Monday, March 12, 2018 10:19 AM
>To: spacewalk-list@redhat.com
>Subject: [Spacewalk-list] osa-dispatcher fails to start
>
>
>
>osa-dispatcher is down and won't start.   I get the following error
>when trying to start it:
>
>
>
>Starting osa-dispatcher: Spacewalk 43238 2018/03/12 10:17:13 -05:00:
>('Traceback caught:',)
>
>Spacewalk 43238 2018/03/12 10:17:13 -05:00: ('Error caught:',)
>
>
>
>ERROR: unhandled exception occurred: (can't write str to text stream).
>
>   [FAILED]
>
>
>
>Any suggestions?
>
>
>
>Thanks
>
>
>
>Daryl
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Did you update some python modules on the server?


-- 
sent from my mobile device

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

Re: [Spacewalk-list] Error code 32

[Robert Paschedag]

Am 13. März 2018 15:57:22 MEZ schrieb Soham Chakraborty :
>Hi all,
>
>I am trying to figure out whether anyone has seen this problem. After I
>posted this thread, I had some discussion with Jan Hutar and although I
>tried all the steps he suggested (which are below), I am still stuck
>with
>this problem.
>
>1) So far, I have tried to increase the memory
>in /usr/share/rhn/config-defaults/rhn_taskomatic_daemon.conf file from
>1024
>to 3072 for the parameter wrapper.java.maxmemory. Restarted taskomatic.
>Same problem.
>
>2) I deleted /var/cache/repodata/rhn/ and
>regenerated
>metadata again. Same problem.
>
>3) yum-rhn-plugin is updated in both server and client.
>
>4) Ran 'yum clean all' and tried to schedule update from the server.
>Same
>problem.
>
>>From the /var/log/up2date file of the client, I see this:
>
>up2date successfully retrieved authentication token from up2date server
>up2date E: Package samba4-libs-0:4.2.10-12.el6_9.x86_64 is not
>available
>for installation
>up2date updateLoginInfo() login info
>up2date logging into up2date server
>up2date successfully retrieved authentication token from up2date server
>up2date E: Package samba4-libs-0:4.2.10-12.el6_9.x86_64 is not
>available
>for installation
>
>But the packages are present on the spacewalk server.
>
># ll
>/spacewalk/redhat/1/fdb/samba4-libs/0:4.2.10-12.el6_9/x86_64/fdbbc812af803aa8a715ae23398ac177b64de178a56d1d6750f41a6730de787c/samba4-libs-4.2.10-12.el6_9.x86_64.rpm
>-rw-r--r-- 1 root root 4567480 Nov 29 02:20
>/spacewalk/redhat/1/fdb/samba4-libs/0:4.2.10-12.el6_9/x86_64/fdbbc812af803aa8a715ae23398ac177b64de178a56d1d6750f41a6730de787c/samba4-libs-4.2.10-12.el6_9.x86_64.rpm
>
>The sha256sum matches as well.
>
>The spacewalk-schema is spacewalk-schema-2.6.17-1.el7.noarch. Do I need
>to
>update the schema as advised in
>https://access.redhat.com/solutions/1263213?
>
>What could be wrong? Any help would be much appreciated.
>
>@Michael, do you reckon this could be any way related to
>https://bugzilla.redhat.com/show_bug.cgi?id=1421674? Not as an end
>result
>but rather as a symptom?
>
>Thanks,
>
>On Tue, Aug 15, 2017 at 6:30 PM, Soham Chakraborty
>
>wrote:
>
>> Hi all,
>>
>> I faced an odd problem today while trying to update my clients. I had
>> several security patches and I got most of them installed but few of
>the
>> updates refused to get installed and I could not install them
>manually as
>> well.
>>
>> The error message from event logs of spacewalk say this:
>>
>> Client execution returned "Failed: Packages failed to install
>properly:
>> Package bind-utils-32:9.8.2-0.62.rc1.el6_9.4.x86_64 is not available
>for
>> installation Package bind-libs-32:9.8.2-0.62.rc1.el6_9.4.x86_64 is
>not
>> available for installation" (code 32)
>>
>> Interwebz tells different methods to fix this. But I do not see any
>> smoking guns from those articles.
>>
>> Does anyone know why this is happening? I see this happening only for
>few
>> particular packages and few particular clients. Any thoughts?
>>
>> Thanks,
>>

And your client is definitely subscribing to a channel, that has this package?

What does 

yum search samba4-libs and
yum info samba4-libs

tell on the client?

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] Pre-check before applyng packages

[Robert Paschedag]

Am 13. März 2018 00:41:12 MEZ schrieb "Yakin, Francis" 
:
>Is there any way that Spacewalk can do pre-check before applying any
>packages on the clients.
>
>See my screen shot.
>
>Thanks
>
>
>Francis Yakin | IT System Admin |  direct: 510-749-2027
>500 Wind River Way, Alameda, CA  94501
>[cid:image001.png@01D12D0C.E17713F0]
>AN INTEL COMPANY

I'm not sure, if this needs to (and should) be done. At least, the action would 
also "fail" because of a pre-check error (not enough space on device)

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] Upgrade/install packages in spacewalk

[Robert Paschedag]

Am 10. März 2018 19:50:30 MEZ schrieb "Yakin, Francis" 
<francis.ya...@windriver.com>:
>I did , but it still there is delay from the time I initialize it from
>the GUI to the client execute the action. Its about more than 30 mins
>delay. See my attachment on my previous email.
>
>Thanks
>
>Francis
>
>Sent from my iPhone
>
>> On Mar 10, 2018, at 3:17 AM, Robert Paschedag
><robert.pasche...@web.de> wrote:
>> 
>> Am 9. März 2018 20:12:56 MEZ schrieb "Yakin, Francis"
><francis.ya...@windriver.com>:
>>> 
>>> 
>>> 1)  Where can we see the activity/progress during when I patch
>the
>>> machines
>>> 
>>> 
>>> 2)  Why there is a time delay between when I run the upgrade and
>>> the client pick the action(see my screen shot on the attachment)
>>> 
>>> 
>>> 
>>> This action will be executed after 3/8/18 6:42:00 PM PST
>>> 
>>> The client picked up this action on 3/8/18 7:26PM
>>> 
>>> 
>>> 
>>> Can we make the client pick up the action immediately instead of
>>> waiting for more than 30 mins?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Thanks
>>> 
>>> 
>>> 
>>> Francis Yakin | IT System Admin |  direct: 510-749-2027
>>> 500 Wind River Way, Alameda, CA  94501
>>> [cid:image001.png@01D12D0C.E17713F0]<http://www.windriver.com/>
>>> AN INTEL COMPANY
>> 
>> Install osad on the clients. Then, actions will start immediately.
>> 
>> Robert
>> -- 
>> sent from my mobile device

The picture doesn't tell very much. If osad is installed on the client, then 
there is something broken here.

Try to stop osad on the client, remove /etc/sysconfig/rhn/osad-auth and start 
it again.

Check in SW GUI that the osad status is "online" and try to ping it from there. 
Then try the installation 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] Upgrade/install packages in spacewalk

[Robert Paschedag]

Am 9. März 2018 20:12:56 MEZ schrieb "Yakin, Francis" 
:
>
>
>1)  Where can we see the activity/progress during when I patch the
>machines
>
>
>2)  Why there is a time delay between when I run the upgrade and
>the client pick the action(see my screen shot on the attachment)
>
>
>
>This action will be executed after 3/8/18 6:42:00 PM PST
>
>The client picked up this action on 3/8/18 7:26PM
>
>
>
>Can we make the client pick up the action immediately instead of
>waiting for more than 30 mins?
>
>
>
>
>
>Thanks
>
>
>
>Francis Yakin | IT System Admin |  direct: 510-749-2027
>500 Wind River Way, Alameda, CA  94501
>[cid:image001.png@01D12D0C.E17713F0]
>AN INTEL COMPANY

Install osad on the clients. Then, actions will start immediately.

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] Unable to fully domain join server during bootstrap

[Robert Paschedag]

Am 7. März 2018 21:08:05 MEZ schrieb "DiOrio, Max" 
:
>Hi,
>
>I have a slightly convoluted setup.  We use OpenNebula to deploy VM's,
>which has a customization piece.  The customization file used to run:
>
>kinit svc_sc_user@DOMAIN -k -t /tmp/svc_sc_user.keytab
>realm join domain.com --os-name='RedHat Enterprise Linux'
>--os-version='7.4'
>--computer-ou=OU=Linux,OU=DevPortal,OU=Servers,OU=Devices
>Download and extract nsswich.conf and sssd.conf to the appropriate
>directories
>Service sssd restart
>
>This has worked flawlessly for months.  Now we decided to implement
>SpaceWalk for better control over patching and config file management. 
>So I moved the domain join script over to a configuration channel, and
>now instead of running the join directly, OpenNebula customization
>pulls down and runs my Spacewalk bootstrap.
>
>I have my bootstrap script pulling down a managed configuration file
>which is a script to /usr/opt/bin/domainjoin  (root:root 755).  At the
>end of the bootstrap script, I run the script it downloaded.
>
>The script is quite simple.
>
>#!/bin/bash
>rhncfg-client get /tmp/svc_sc_user.keytab
>kinit svc_sc_user@DOMAIN -k -t /tmp/svc_sc_user.keytab
>realm join domain.com --os-name='RedHat Enterprise Linux'
>--os-version='7.4'
>--computer-ou=OU=Linux,OU=DevPortal,OU=Servers,OU=Devices
>rm /tmp/svc_sc_user.keytab
>rhncfg-client get /etc/sssd/sssd.conf
>rhncfg-client get /etc/nsswitch.conf
>service sssd restart
>
>When running the script manually logged in as root, everything works
>perfectly.
>
>When running through the OpenNebula customization and running
>bootstrap, it claims it joins the domain, but fails to create the
>/etc/krb5.keytab file, never actually joins the domain and sssd fails
>to start.
>
>I'm completely baffled by this.  How does the same essential script
>work fine from OpenNebula config, but not from the script downloaded
>via boostrap?
>
>
>Max DiOrio
>Global Systems Administrator
>[cid:image002.jpg@01D26A5C.D5C0BF00]
>201 Fuller Road, Suite 202
>Albany, NY 12203-3621
>Phone: +518-238-6516 | Mobile: +518-944-5289
>max.dio...@ieeeglobalspec.com

This sounds, as if the script is not executed as root. 

Also maybe selinux might be a problem, as the configuration jobs are called by 
"rhnsd" (or osad?) and there might be a "profile" for it?

Maybe you could test deployment with selinux set to disabled once?

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] Question about errata removal

[Robert Paschedag]

Am 7. März 2018 16:35:55 MEZ schrieb Steve Meier :
>Hi Robert,
>
>Am 2018-03-07 16:20, schrieb Paschedag, Robert:
>> Hi all,
>> 
>> just a quick question. I might need to "reimport" all my custom
>> errata. In case I want to remove the "old" errata, I need to
>> 
>>  * first remove all packages within that errata from the errata
>> itself and
>>  * then remove the errata
>> 
>> ?
>> 
>> Removing an errata directly (with containing packages) will also
>> remove the packages from spacewalk server?
>> 
>> Correct? I'm not sure anymore.
>
>Yes.
>I just tested this yesterday with Spacewalk 2.7.
>
>Kind regards,
>   Steve
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Hi Steve,

thank you for that quick answer.

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] postgres DB backup question

[Robert Paschedag]

Am 28. Februar 2018 19:15:20 MEZ schrieb Nicole Beck :
>Thanks everyone. There are a lot of different ways to do it!
>
>The man page for pg_dumpall says "pg_dumpall also dumps global objects
>that are common to all databases. (pg_dump does not save these
>objects.) This currently includes information about database users and
>groups, tablespaces, and properties such as access permissions that
>apply to databases as a whole."  Is that something we have to worry
>about if we just use the "pg_dump rhnschema" method to backup?
>Spacewalk is the only database I have.
>
>
>Nicole
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of Brian Long
>
>Sent: Tuesday, February 27, 2018 10:49 AM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] postgres DB backup question
>
>I use the "db-control" program to handle an online (DB running) backup.
>db-control online-backup /local/backups/satellite-pgsql.$DATE
>1>/dev/null
>
>/Brian/
>
>On Mon, Feb 26, 2018 at 1:23 PM, Nicole Beck
>> wrote:
>Hello!
>I’m trying to backup my postgress DB using the Spacewalk install
>documentation at
>https://github.com/spacewalkproject/spacewalk/wiki/SpacewalkBackup, and
>it fails with the errors below. If I try it without spacewalk running, 
>it gives an error and creates an empty backup file. If I try it with
>spacewalk running, it creates a 3.9 GB backup file, but I can’t restore
>it. Spacewalk is the only thing using this database. How do you all do
>your database backups?
>
>Errors when spacewalk not running(creates empty backup file):
>
>[root@spacewalk ~]# spacewalk-service stop
>Shutting down spacewalk services...
>Redirecting to /bin/systemctl stop taskomatic.service
>Stopping cobblerd (via systemctl): [  OK  ]
>Redirecting to /bin/systemctl stop rhn-search.service
>Redirecting to /bin/systemctl stop osa-dispatcher.service
>Redirecting to /bin/systemctl stop httpd.service
>Redirecting to /bin/systemctl stop tomcat.service
>Redirecting to /bin/systemctl stop jabberd.service
>Redirecting to /bin/systemctl stop postgresql.service
>Done.
>[root@spacewalk ~]# su - postgres -c  'pg_dumpall >
>/var/lib/pgsql/backups/full_postgres_backup-`date +%Y%m%d`.sql'
>pg_dumpall: could not connect to database "template1": could not
>connect to server: No such file or directory
>Is the server running locally and accepting
> connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
>[root@spacewalk ~]# ls -al /var/lib/pgsql/backups
>total 0
>drwx-- 2 postgres postgres  47 Feb 26 12:32 .
>drwx-- 6 postgres postgres 122 Nov  1 14:55 ..
>-rw-r--r-- 1 postgres postgres   0 Feb 26 12:32
>full_postgres_backup-20180226.sql
>
>
>Errors when spacewalk running
>
>[root@spacewalk ~]# spacewalk-service start
>Starting spacewalk services...
>Redirecting to /bin/systemctl start
>Redirecting to /bin/systemctl start postgresql.service
>Redirecting to /bin/systemctl start jabberd.service
>Redirecting to /bin/systemctl start tomcat.service
>Waiting for tomcat to be ready ...
>Redirecting to /bin/systemctl start httpd.service
>Redirecting to /bin/systemctl start osa-dispatcher.service
>Redirecting to /bin/systemctl start rhn-search.service
>Starting cobblerd (via systemctl): [  OK  ]
>Redirecting to /bin/systemctl start taskomatic.service
>Done.
>[root@spacewalk ~]# su - postgres -c  'pg_dumpall >
>/var/lib/pgsql/backups/full_postgres_backup-`date +%Y%m%d`.sql'
>pg_dump: [archiver (db)] connection to database "template1" failed:
>FATAL:  no pg_hba.conf entry for host "[local]", user "postgres",
>database "template1", SSL off
>pg_dumpall: pg_dump failed on database "template1", exiting
>[root@spacewalk backups]# ls -al
>total 3910032
>drwx-- 2 postgres postgres 47 Feb 26 12:32 .
>drwx-- 6 postgres postgres122 Nov  1 14:55 ..
>-rw-r--r-- 1 postgres postgres 4003869597 Feb 26 12:40
>full_postgres_backup-20180226.sql
>
>But you can’t restore per the github.com directions:
>
>[root@spacewalk backups]# su - postgres
>Last login: Mon Feb 26 12:38:18 EST 2018 on pts/0
>-bash-4.2$ SPACEWALK_DB_NAME=spacewalkdb
>-bash-4.2$ ls /var/lib/pgsql/backups
>full_postgres_backup-20180226.sql
>-bash-4.2$
>SPACEWALK_DB_BACKUPFILE=/var/lib/pgsql/backups/full_postgres_backup-20180226.sql
>-bash-4.2$ full_postgres_backup-20180226.sql^C
>-bash-4.2$ id
>uid=26(postgres) gid=26(postgres) groups=26(postgres)
>-bash-4.2$ dropdb $SPACEWALK_DB_NAME
>dropdb: could not connect to database template1: could not connect to
>server: No such file or directory
>Is the server running locally and accepting
> connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
>
>Thanks!
>Nicole
>
>
>Nicole Beck
>Information Technology Analyst
>Information Technolgy Services – Core Infrustructure Services - Unix

Re: [Spacewalk-list] postgres DB backup question

[Robert Paschedag]

Am 26. Februar 2018 19:23:52 MEZ schrieb Nicole Beck :
>Hello!
>I'm trying to backup my postgress DB using the Spacewalk install
>documentation at
>https://github.com/spacewalkproject/spacewalk/wiki/SpacewalkBackup, and
>it fails with the errors below. If I try it without spacewalk running, 
>it gives an error and creates an empty backup file. If I try it with
>spacewalk running, it creates a 3.9 GB backup file, but I can't restore
>it. Spacewalk is the only thing using this database. How do you all do
>your database backups?
>
>Errors when spacewalk not running(creates empty backup file):
>
>[root@spacewalk ~]# spacewalk-service stop
>Shutting down spacewalk services...
>Redirecting to /bin/systemctl stop taskomatic.service
>Stopping cobblerd (via systemctl): [  OK  ]
>Redirecting to /bin/systemctl stop rhn-search.service
>Redirecting to /bin/systemctl stop osa-dispatcher.service
>Redirecting to /bin/systemctl stop httpd.service
>Redirecting to /bin/systemctl stop tomcat.service
>Redirecting to /bin/systemctl stop jabberd.service
>Redirecting to /bin/systemctl stop postgresql.service
>Done.
>[root@spacewalk ~]# su - postgres -c  'pg_dumpall >
>/var/lib/pgsql/backups/full_postgres_backup-`date +%Y%m%d`.sql'
>pg_dumpall: could not connect to database "template1": could not
>connect to server: No such file or directory
>Is the server running locally and accepting
> connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
>[root@spacewalk ~]# ls -al /var/lib/pgsql/backups
>total 0
>drwx-- 2 postgres postgres  47 Feb 26 12:32 .
>drwx-- 6 postgres postgres 122 Nov  1 14:55 ..
>-rw-r--r-- 1 postgres postgres   0 Feb 26 12:32
>full_postgres_backup-20180226.sql
>
>
>Errors when spacewalk running
>
>[root@spacewalk ~]# spacewalk-service start
>Starting spacewalk services...
>Redirecting to /bin/systemctl start
>Redirecting to /bin/systemctl start postgresql.service
>Redirecting to /bin/systemctl start jabberd.service
>Redirecting to /bin/systemctl start tomcat.service
>Waiting for tomcat to be ready ...
>Redirecting to /bin/systemctl start httpd.service
>Redirecting to /bin/systemctl start osa-dispatcher.service
>Redirecting to /bin/systemctl start rhn-search.service
>Starting cobblerd (via systemctl): [  OK  ]
>Redirecting to /bin/systemctl start taskomatic.service
>Done.
>[root@spacewalk ~]# su - postgres -c  'pg_dumpall >
>/var/lib/pgsql/backups/full_postgres_backup-`date +%Y%m%d`.sql'
>pg_dump: [archiver (db)] connection to database "template1" failed:
>FATAL:  no pg_hba.conf entry for host "[local]", user "postgres",
>database "template1", SSL off
>pg_dumpall: pg_dump failed on database "template1", exiting
>[root@spacewalk backups]# ls -al
>total 3910032
>drwx-- 2 postgres postgres 47 Feb 26 12:32 .
>drwx-- 6 postgres postgres122 Nov  1 14:55 ..
>-rw-r--r-- 1 postgres postgres 4003869597 Feb 26 12:40
>full_postgres_backup-20180226.sql
>
>But you can't restore per the github.com directions:
>
>[root@spacewalk backups]# su - postgres
>Last login: Mon Feb 26 12:38:18 EST 2018 on pts/0
>-bash-4.2$ SPACEWALK_DB_NAME=spacewalkdb
>-bash-4.2$ ls /var/lib/pgsql/backups
>full_postgres_backup-20180226.sql
>-bash-4.2$
>SPACEWALK_DB_BACKUPFILE=/var/lib/pgsql/backups/full_postgres_backup-20180226.sql
>-bash-4.2$ full_postgres_backup-20180226.sql^C
>-bash-4.2$ id
>uid=26(postgres) gid=26(postgres) groups=26(postgres)
>-bash-4.2$ dropdb $SPACEWALK_DB_NAME
>dropdb: could not connect to database template1: could not connect to
>server: No such file or directory
>Is the server running locally and accepting
> connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
>
>Thanks!
>Nicole
>
>
>Nicole Beck
>Information Technology Analyst
>Information Technolgy Services - Core Infrustructure Services - Unix
>315.506.9744
>nsky...@syr.edu
>215 Machinery Hall, Syracuse, NY 13244
>syracuse.edu
>Syracuse University

The DB needs to be running so you can back it up. Use pg_dump.
-- 
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.7 how to manage auto installation for SUSE Linux

[Robert Paschedag]

Am 24. Februar 2018 15:37:23 MEZ schrieb suhail.siddi...@visitor.upm.com:
>Hi Team,
>
>Any one aware how to configured kickstart profile in Spacewalk for SUSE
>Linux provisioning  via PXE boot?
>
>Best Regards,
>Suhail Siddiqui
>
>
>Please note. The information contained in this message is confidential
>and is intended only for the use of the individual named above and
>others who have been specially authorized to receive it. If you are not
>the intended recipient, you are hereby notified that any dissemination,
>distribution or copying of this communication is strictly prohibited.
>The attachments have been scanned for viruses prior to leaving our
>E-mail system. UPM-Kymmene Corporation shall not be liable for any
>consequences of any virus being passed on.

To get started, install a SLES system by hand. Then run yast. Somewhere in 
there you can say... "create autoyast from this install"

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.7 how to manage auto installation for SUSE Linux

[Robert Paschedag]

Am 24. Februar 2018 15:37:23 MEZ schrieb suhail.siddi...@visitor.upm.com:
>Hi Team,
>
>Any one aware how to configured kickstart profile in Spacewalk for SUSE
>Linux provisioning  via PXE boot?
>
>Best Regards,
>Suhail Siddiqui
>
>
>Please note. The information contained in this message is confidential
>and is intended only for the use of the individual named above and
>others who have been specially authorized to receive it. If you are not
>the intended recipient, you are hereby notified that any dissemination,
>distribution or copying of this communication is strictly prohibited.
>The attachments have been scanned for viruses prior to leaving our
>E-mail system. UPM-Kymmene Corporation shall not be liable for any
>consequences of any virus being passed on.

You need to create an autoyast xml file. See 
https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html

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] Server not creating/updating /var/cache/rhn after upgrade

[Robert Paschedag]

Am 20. Februar 2018 20:34:36 MEZ schrieb "Glennie, Jonathan - 0443 - MITLL" 
:
>Hi All-
>
> 
>
>I'm having an interesting issue where none of our software channels are
>creating any repomd.xml files.  There is a long history with this
>server,
>which may or may not be relevant to this problem, but it's worth
>mentioning
>that this used to be a physical machine running 2.6 that we upgraded to
>2.7.
>After running in to various issue, we migrated the server to a VM
>running
>2.7 using the procedure discussed here
>https://www.redhat.com/archives/spacewalk-list/2013-November/msg00070.html
>
> 
>
>I have tried manually restarting taskomatic and also using the spacecmd
>commands to regenerate the yum repodata, but nothing is being created
>in
>/var/cache/rhn.  The repodata directory is completely missing.  I
>checked
>the taskomatic logs and I don't see any errors that would point to an
>issue,
>not sure where else to check.  
>
> 
>
>When running a yum list from a client, we get an error that the
>repomd.xml
>file (not surpsingly) couldn't be found.  Out of curiosity, I tried
>manually
>copying over the old /var/cache/rhn/repodata directory over from the
>old
>server and after doing so, I can get past the repomd.xml error, but
>obviously this isn't good if these repo files aren't updating.  
>
> 

This sounds as if taskomatic is not running the jobs for recreating the repos.

If you have selinux enabled, please check the selinux permissions if that 
directory or reset them.

Does the synchronisation of the report work?

Robert

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

Re: [Spacewalk-list] Spacewalk 2.7 - OpenVZ Debian containers

[Robert Paschedag]

Am 16. Februar 2018 12:54:18 MEZ schrieb Ben Myatt <b...@myattzone.org.uk>:
>Hi,
>
>I have checked my ifconfig and you were correct, it was set to
>venet0:0. I have changed this which now gets rid of the I/O error, but
>I know get the following:
>lscpu: failed to determine number of CPUs:
>/sys/devices/system/cpu/possible: No such file or directory
>
>Within the directory /sys/devices/system/cpu/ there are 2 folders
>“cpu0” & “cpu1”.
>
>/var/log/up2date shows "up2date Warning: haldaemon or messagebus
>service not running. Cannot probe hardware and DMI information” still.
>
>Kind Regards
>Ben Myatt
>
>> On 15 Feb 2018, at 20:13, Robert Paschedag <robert.pasche...@web.de>
>wrote:
>> 
>> Am 15. Februar 2018 20:40:19 MEZ schrieb Ben Myatt
><b...@myattzone.org.uk>:
>>> Hi,
>>> 
>>> I don’t believe this is the case as the containers only have 1 IP
>>> address and the newer ones being on Debian 9, the ifconfig setup
>should
>>> be the latest. 
>>> 
>>> I will double check though.
>>> 
>>> Kind Regards
>>> Ben Myatt
>>> 
>>>> On 15 Feb 2018, at 18:18, Robert Paschedag
><robert.pasche...@web.de>
>>> wrote:
>>>> 
>>>> Am 15. Februar 2018 18:54:06 MEZ schrieb Ben Myatt
>>> <b...@myattzone.org.uk>:
>>>>> Hi,
>>>>> 
>>>>> I am trying to register a Debian 9 client with spacewalk 2.7. The
>>>>> client is configured as a container on a CentOS 7 host, running
>>> openvz,
>>>>> virtuozzo kernel 2.6.32-042stab127.2. It has also been tested with
>a
>>>>> newer kernel version of 3.10.0-693.11.6.vz7.42.5.
>>>>> 
>>>>> I can get CentOS containers registered but cannot get any Debian
>>>>> machines to register properly. 
>>>>> The error I get is :Error reading network interface information:
>>> >>>> 'exceptions.IOError’>” and in the up2date log file it reads the
>>>>> following "[Mon Feb 12 12:55:30 2018] up2date Warning: haldaemon
>or
>>>>> messagebus service not running. Cannot probe hardware and DMI
>>>>> information.”
>>>>> This does actually register it with the server but I does not
>allow
>>> a
>>>>> base channel to be set.
>>>>> 
>>>>> All Debian machines that aren’t containers are fine.
>>>>> 
>>>>> Do you have any info on this?
>>>>> 
>>>>> 
>>>>> Kind Regards
>>>>> Ben Myatt
>>>>> 
>>>>> 
>>>>> ___
>>>>> Spacewalk-list mailing list
>>>>> Spacewalk-list@redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>> 
>>>> Please check if you have old style ifconfig "aliases" defined (e.g.
>>> eth0:0). This causes that message. Had that also on several servers.
>>>> 
>>>> Robert
>> 
>> Maybe you could check, if you get the same error if you run
>rhn-profile-sync on the Debian system.
>> 
>> Robert

Don't know that error. Would also have to go done the python modules rabbit 
hole and start debugging

Robert

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

Re: [Spacewalk-list] Spacewalk 2.7 - OpenVZ Debian containers

[Robert Paschedag]

Am 15. Februar 2018 20:40:19 MEZ schrieb Ben Myatt <b...@myattzone.org.uk>:
>Hi,
>
>I don’t believe this is the case as the containers only have 1 IP
>address and the newer ones being on Debian 9, the ifconfig setup should
>be the latest. 
>
>I will double check though.
>
>Kind Regards
>Ben Myatt
>
>> On 15 Feb 2018, at 18:18, Robert Paschedag <robert.pasche...@web.de>
>wrote:
>> 
>> Am 15. Februar 2018 18:54:06 MEZ schrieb Ben Myatt
><b...@myattzone.org.uk>:
>>> Hi,
>>> 
>>> I am trying to register a Debian 9 client with spacewalk 2.7. The
>>> client is configured as a container on a CentOS 7 host, running
>openvz,
>>> virtuozzo kernel 2.6.32-042stab127.2. It has also been tested with a
>>> newer kernel version of 3.10.0-693.11.6.vz7.42.5.
>>> 
>>> I can get CentOS containers registered but cannot get any Debian
>>> machines to register properly. 
>>> The error I get is :Error reading network interface information:
>>> 'exceptions.IOError’>” and in the up2date log file it reads the
>>> following "[Mon Feb 12 12:55:30 2018] up2date Warning: haldaemon or
>>> messagebus service not running. Cannot probe hardware and DMI
>>> information.”
>>> This does actually register it with the server but I does not allow
>a
>>> base channel to be set.
>>> 
>>> All Debian machines that aren’t containers are fine.
>>> 
>>> Do you have any info on this?
>>> 
>>> 
>>> Kind Regards
>>> Ben Myatt
>>> 
>>> 
>>> ___
>>> Spacewalk-list mailing list
>>> Spacewalk-list@redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> 
>> Please check if you have old style ifconfig "aliases" defined (e.g.
>eth0:0). This causes that message. Had that also on several servers.
>> 
>> Robert

Maybe you could check, if you get the same error if you run rhn-profile-sync on 
the Debian system.

Robert

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

Re: [Spacewalk-list] Spacewalk 2.7 - OpenVZ Debian containers

[Robert Paschedag]

Am 15. Februar 2018 18:54:06 MEZ schrieb Ben Myatt :
>Hi,
>
>I am trying to register a Debian 9 client with spacewalk 2.7. The
>client is configured as a container on a CentOS 7 host, running openvz,
>virtuozzo kernel 2.6.32-042stab127.2. It has also been tested with a
>newer kernel version of 3.10.0-693.11.6.vz7.42.5.
>
>I can get CentOS containers registered but cannot get any Debian
>machines to register properly. 
>The error I get is :Error reading network interface information: 'exceptions.IOError’>” and in the up2date log file it reads the
>following "[Mon Feb 12 12:55:30 2018] up2date Warning: haldaemon or
>messagebus service not running. Cannot probe hardware and DMI
>information.”
>This does actually register it with the server but I does not allow a
>base channel to be set.
>
>All Debian machines that aren’t containers are fine.
>
>Do you have any info on this?
>
>
>Kind Regards
>Ben Myatt
>
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Please check if you have old style ifconfig "aliases" defined (e.g. eth0:0). 
This causes that message. Had that also on several servers.

Robert

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

Re: [Spacewalk-list] Fix yum repo definitions on spacewalk clients

[Robert Paschedag]

Am 12. Februar 2018 10:51:55 MEZ schrieb Isaac Hailperin 
:
>Dear list,
>
>I have spacewalk 2.4 installed on a CentOS 7 host, and manage CentOS 7
>servers with it. Now I found that in /etc/yum.repos.d/ all configured
>repositories point to Internet repos. Which is not really how it should
>be, hosts should use the internal spacewalk repos. I assume this is due
>to packages like centos-release* being installed. I am just taking over
>this environment, so I am not 100% sure how all this came together.
>
>Nonetheless, I need to fix this. If I just delete the packages to which
>the repo definitions belong to, I am left without any repositories (I
>have checked - none point to the internal repo, all belong to some
>installed package). As the clients are assigned to certain channels, I
>would like to add the corresponding repositories again.
>
>So far I have tried re-registering the client with
>
># rhnreg_ks --serverUrl=https://YourSpacewalk.example.org/XMLRPC
>--sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
>--activationkey= --force
>No success. I have also removed all channel subscriptions, and then
>added them again, no success.
>
>What would be the easiest, or most reliable way to get the correct repo
>definitions back?
>
>Maybe my assumption is wrong, but since the spacewalk client tools have
>knowledge of the subscribed channels, I assume that there is also a way
>to get the corresponding repository definitions in some automated way.
>What would that be?
>
>Any hint or feedback is appreciated.
>
>Regards,
>Isaac

It should just work the way you tried. So it would be interesting to know, what 
error you get when you run the rhnreg_ks tool?

Do you get an error?

If not, do your servers show up as "system" within spacewalk?

If the servers show up in spacewalk, check they really have the channels 
subscribed. If they do not have channels subscribed, then something's wrong 
with the activation key.

Robert

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

Re: [Spacewalk-list] can not join a client to spacewalk master server

[Robert Paschedag]

Am 28. Januar 2018 12:31:15 MEZ schrieb "Afify, Sherif S (IBS)" 
:
>I am getting the below error when I try to register client to spacewalk
> , any ideas?
>
>
>
>
>
>[Sun Jan 28 11:27:10.469571 2018] [:error] [pid 31001] Exception
>Handler Information
>
>[Sun Jan 28 11:27:10.469572 2018] [:error] [pid 31001] Traceback (most
>recent call last):
>
>[Sun Jan 28 11:27:10.469582 2018] [:error] [pid 31001]   File
>"/usr/lib/python2.7/site-packages/spacewalk/server/apacheHandler.py",
>line 87, in headerParserHandler
>
>[Sun Jan 28 11:27:10.469585 2018] [:error] [pid 31001]
>rhnSQL.initDB()
>
>[Sun Jan 28 11:27:10.469586 2018] [:error] [pid 31001]   File
>"/usr/lib/python2.7/site-packages/spacewalk/server/rhnSQL/__init__.py",
>line 158, in initDB
>
>[Sun Jan 28 11:27:10.469588 2018] [:error] [pid 31001]
>raise_with_tb(e, sys.exc_info()[2])
>
>[Sun Jan 28 11:27:10.469589 2018] [:error] [pid 31001]   File
>"/usr/lib/python2.7/site-packages/spacewalk/server/rhnSQL/__init__.py",
>line 145, in initDB
>
>[Sun Jan 28 11:27:10.469591 2018] [:error] [pid 31001]
>__init__DB(backend, host, port, username, password, database, sslmode,
>sslrootcert)
>
>[Sun Jan 28 11:27:10.469593 2018] [:error] [pid 31001]   File
>"/usr/lib/python2.7/site-packages/spacewalk/server/rhnSQL/__init__.py",
>line 57, in __init__DB
>
>[Sun Jan 28 11:27:10.469652 2018] [:error] [pid 31001]
>__DB.connect()
>
>[Sun Jan 28 11:27:10.469655 2018] [:error] [pid 31001]   File
>"/usr/lib/python2.7/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
>line 194, in connect
>
>[Sun Jan 28 11:27:10.469656 2018] [:error] [pid 31001] return
>self.connect(reconnect=reconnect - 1)
>
>[Sun Jan 28 11:27:10.469658 2018] [:error] [pid 31001]   File
>"/usr/lib/python2.7/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
>line 199, in connect
>
>[Sun Jan 28 11:27:10.469659 2018] [:error] [pid 31001] "All
>attempts to connect to the database failed"), sys.exc_info()[2])
>
>[Sun Jan 28 11:27:10.469661 2018] [:error] [pid 31001]   File
>"/usr/lib/python2.7/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
>line 184, in connect
>
>[Sun Jan 28 11:27:10.469663 2018] [:error] [pid 31001] self.dbh =
>psycopg2.connect(" ".join("%s=%s" % (k, re.escape(str(v))) for k, v in
>dsndata.items()))
>
>[Sun Jan 28 11:27:10.469664 2018] [:error] [pid 31001]   File
>"/usr/lib64/python2.7/site-packages/psycopg2/__init__.py", line 164, in
>connect
>
>[Sun Jan 28 11:27:10.469666 2018] [:error] [pid 31001] conn =
>_connect(dsn, connection_factory=connection_factory, async=async)
>
>[Sun Jan 28 11:27:10.469667 2018] [:error] [pid 31001] SQLConnectError:
>(None, None, 'rhnschema', 'All attempts to connect to the database
>failed')
>
>[Sun Jan 28 11:27:10.469672 2018] [:error] [pid 31001]

Check the credentials in /etc/rhn/rhn.conf.

Normally, these are

db: rhnschema
user: rhnuser
pw: rhnpw

Try to login manually with these. If it works, check in conf file, if there is 
something different.

Robert

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

Re: [Spacewalk-list] SUSE 11 SP4 repository error in Spacewalk 2.7 on centos 6.7

[Robert Paschedag]

Am 25. Januar 2018 06:50:49 MEZ schrieb suhail.siddi...@visitor.upm.com:
>
>Hi Team,
>
>Please help me for below issue.
>
>Best Regards,
>Suhail Siddiqui
>Service Delivery – Datacenter Services
>HCL Technologies Ltd. – UPM Partner for IT Services
>Mob: +91-9717193941<%20%20>
>
>From: Suhail Siddiqui, HCL
>Sent: Thursday, January 18, 2018 7:48 PM
>To: spacewalk-list@redhat.com
>Subject: SUSE 11 SP4 repository error in Spacewalk 2.7 on centos 6.7
>
>Hi Team,
>
>Can you please help me to fix the below issue in spacewalk while adding
>repository  for SUSE 11 SP4
>
>
>2018/01/18 13:30:50 +03:00 ERROR: Cannot retrieve repository metadata
>(repomd.xml) for repository: repo__SLES11-SP4-Pool_sle-11-x86_64_.
>Please verify its path and try again
>
>2018/01/18 13:23:10 +03:00 Command: ['/usr/bin/spacewalk-repo-sync',
>'-t', 'yum', '-c', 'susesp114_product', '-u',
>'https://updates.suse.com/repo//SLES11-SP4-Pool/sle-11-x86_64']
>
>2018/01/18 13:23:10 +03:00 Sync of channel started.
>
>2018/01/18 13:23:10 +03:00 Repo URL:
>https://updates.suse.com/repo//SLES11-SP4-Pool/sle-11-x86_64
>
>2018/01/18 13:24:10 +03:00 ERROR: Cannot retrieve repository metadata
>(repomd.xml) for repository: repo__SLES11-SP4-Pool_sle-11-x86_64.
>Please verify its path and try again
>
>2018/01/18 13:24:10 +03:00 ERROR: Cannot retrieve repository metadata
>(repomd.xml) for repository: repo__SLES11-SP4-Pool_sle-11-x86_64.
>Please verify its path and try again
>
>2018/01/18 13:24:10 +03:00 Sync of channel completed in 0:01:00.
>
>2018/01/18 13:30:09 +03:00 Command: ['/usr/bin/spacewalk-repo-sync',
>'-t', 'yum', '-c', 'susesp114_product', '-u',
>'https://nu.novell.com/repo//SLES11-SP4-Pool/sle-11-x86_64/']
>
>2018/01/18 13:30:09 +03:00 Sync of channel started.
>
>2018/01/18 13:30:09 +03:00 Repo URL:
>https://nu.novell.com/repo//SLES11-SP4-Pool/sle-11-x86_64/
>
>2018/01/18 13:30:12 +03:00 ERROR: Cannot retrieve repository metadata
>(repomd.xml) for repository: repo__SLES11-SP4-Pool_sle-11-x86_64_.
>Please verify its path and try again
>
>2018/01/18 13:30:12 +03:00 ERROR: Cannot retrieve repository metadata
>(repomd.xml) for repository: repo__SLES11-SP4-Pool_sle-11-x86_64_.
>Please verify its path and try again
>
>2018/01/18 13:30:12 +03:00 Sync of channel completed in 0:00:03.
>
>
>
>
>2018/01/18 13:30:50 +03:00 ERROR: Cannot retrieve repository metadata
>(repomd.xml) for repository: repo__SLES11-SP4-Pool_sle-11-x86_64_.
>Please verify its path and try again
>
>2018/01/18 13:30:50 +03:00 ERROR: Cannot retrieve repository metadata
>(repomd.xml) for repository: repo__SLES11-SP4-Pool_sle-11-x86_64_.
>Please verify its path and try again
>
>2018/01/18 13:30:50 +03:00 Sync of channel completed in 0:00:02.
>
>
>Best Regards,
>Suhail Siddiqui
>Service Delivery – Datacenter Services
>HCL Technologies Ltd. – UPM Partner for IT Services
>Mob: +91-9717193941<%20%20>
>
>
>
>Please note. The information contained in this message is confidential
>and is intended only for the use of the individual named above and
>others who have been specially authorized to receive it. If you are not
>the intended recipient, you are hereby notified that any dissemination,
>distribution or copying of this communication is strictly prohibited.
>The attachments have been scanned for viruses prior to leaving our
>E-mail system. UPM-Kymmene Corporation shall not be liable for any
>consequences of any virus being passed on.

Sles11 needs to be pulled from Novell, not suse.

Login to Novell customer center and lookup the repo URL within the mirror 
credentials overview.

Or maybe wait 'till I'm in the office to lookup the URL ;-)

Robert

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

Re: [Spacewalk-list] OSAD can't connect to host and port - Fresh Install of Spacewalk 2.7

[Robert Paschedag]

- This was a fresh install and NO client works?

- You don't see any osa-dispatcher or jabber errors in /var/log/messages?

Which jabber DB backend do you use? Default BDB?

Normally, I do not recommend just removing the jabber database but if
really NO clients works on a fresh install, stop jabber and
osa-dispatcher on the server, remove (rm -rf /var/lib/jabber/db/*) the
jabber database (in case of BDB) and restart the osad on the clients.

In case, everything is setup correctly (FQDN, correct SSL cert als for
jabberd), this should just work.

Robert

Am 07.01.2018 um 20:48 schrieb Francis Lee Mondia:
> Hi Robert,
> 
> It was not me on that original post but we had very similar issues.
> 
> - Your clients do not show up as "online" for osad status? - YES
> - Scheduling a simple remote command for a client does NOT get picked up
> immediatly by the client? You have to login to the client and run
> "rhn_check" to execute the task? - YES
> 
> I would have thought it was resolved in 2.7 but it appears not the case
> and others are reporting more or less the same. 
> 
> Any thoughts?
> 
> Kind regards,
> Francis
> 
> 
> On Sun, Jan 7, 2018 at 11:15 AM, Robert Paschedag
> <robert.pasche...@web.de <mailto:robert.pasche...@web.de>> wrote:
> 
> In your original post, you said, you can telnet to 5222 and run
> osad in *very* verbose mode and get connected.
> 
> So.where do you have problems now?
> 
> - Your clients do not show up as "online" for osad status?
> - Scheduling a simple remote command for a client does NOT
>   get picked up immediatly by the client? You have to login
>   to the client and run "rhn_check" to execute the task?
> 
> Robert
> 
> Am 05.01.2018 um 02:50 schrieb Francis Lee Mondia:
> > Hi,
> >
> > I'm still having the same issue per the original thread below.
> This is a
> > fresh install of Spacewalk on CentOS 7, as was having the same issues
> > with the legacy system that I inherited (upgraded to 2.6, CentOS 6.9)
> >
> > I can telnet the port from the client (5222) and OSA dispatcher
> service
> > is running on both the server and client.
> >
> > Any thoughts? Let me know what information you need to help
> troubleshoot
> > this.
> >
> > Original Thread:
> >
> https://www.redhat.com/archives/spacewalk-list/2017-February/msg00028.html
> 
> <https://www.redhat.com/archives/spacewalk-list/2017-February/msg00028.html>
> >
> > Kind regards,
> > Francis
> >
> >
> > ___
> > Spacewalk-list mailing list
> > Spacewalk-list@redhat.com <mailto:Spacewalk-list@redhat.com>
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> <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] OSAD can't connect to host and port - Fresh Install of Spacewalk 2.7

[Robert Paschedag]

In your original post, you said, you can telnet to 5222 and run
osad in *very* verbose mode and get connected.

So.where do you have problems now?

- Your clients do not show up as "online" for osad status?
- Scheduling a simple remote command for a client does NOT
  get picked up immediatly by the client? You have to login
  to the client and run "rhn_check" to execute the task?

Robert

Am 05.01.2018 um 02:50 schrieb Francis Lee Mondia:
> Hi,
> 
> I'm still having the same issue per the original thread below. This is a
> fresh install of Spacewalk on CentOS 7, as was having the same issues
> with the legacy system that I inherited (upgraded to 2.6, CentOS 6.9)
> 
> I can telnet the port from the client (5222) and OSA dispatcher service
> is running on both the server and client.
> 
> Any thoughts? Let me know what information you need to help troubleshoot
> this.
> 
> Original Thread:
> https://www.redhat.com/archives/spacewalk-list/2017-February/msg00028.html
> 
> Kind regards,
> Francis
> 
> 
> ___
> 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] Upgrading 2.6 to 2.7 - package errors

[Robert Paschedag]

Am 26. Dezember 2017 21:09:04 MEZ schrieb "Rusch, Andy" 
:
>Sure enough, yes! Thank you very much for the help.
>
>Andy
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Christoph
>Galuschka
>Sent: Tuesday, December 26, 2017 12:07 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Upgrading 2.6 to 2.7 - package errors
>
>Is it possible, you have cglib excluded from updates in yum.conf?
>
>Am 26.12.2017 um 21:02 schrieb Rusch, Andy:
>> Per the instruction, I removed that. This is output just now:
>> 
>> [root@server ~]# yum versionlock list
>> 
>> Loaded plugins: fastestmirror, langpacks, versionlock
>> 
>> versionlock list done
>> 
>> *From:* spacewalk-list-boun...@redhat.com 
>> [mailto:spacewalk-list-boun...@redhat.com] *On Behalf Of *Bruce
>Wainer
>> *Sent:* Tuesday, December 26, 2017 12:01 PM
>> *To:* spacewalk-list@redhat.com
>> *Subject:* Re: [Spacewalk-list] Upgrading 2.6 to 2.7 - package errors
>> 
>> It looks like you might still have a versionlock on cglib.
>> 
>> 
>> Bruce Wainer
>> 
>> On Tue, Dec 26, 2017 at 2:54 PM, Rusch, Andy 
>> > wrote:
>> 
>> I am following the upgrade procedure (I am on CentOS 7.4) and I
>get
>> the following after # yum upgrade (I have removed the jpackage
>repo
>> per instructions and all that good stuff.)
>> 
>> Error: Package: cglib-2.1.3-4.jpp5.noarch (@jpackage-generic)
>> 
>>     Requires: asm >= 1.5.3
>> 
>>     Removing: asm-1.5.3-7.jpp5.noarch (@jpackage-generic)
>> 
>>     asm = 1.5.3-7.jpp5
>> 
>>     Obsoleted By: spacewalk-java-2.7.116-1.el7.noarch
>> (spacewalk)
>> 
>>     Not found
>> 
>> Error: Package: google-guice-3.1.3-9.el7.noarch (base)
>> 
>>     Requires: mvn(cglib:cglib)
>> 
>> I tried:
>> 
>> # yum upgrade–-skip-broken
>> 
>> Transaction check error:
>> 
>>    file /usr/share/java/commons-validator.jar from install of
>> apache-commons-validator-1.5.0-2.sw.noarch conflicts with file
>from
>> package spacewalk-jpp-workaround-2.3.5-1.el7.noarch
>> 
>> Error Summary
>> 
>> -
>> 
>> Any advice/things to try?
>> 
>> Thanks in advance for your input
>> 
>> -Andy
>> 
>> 
>> ___
>> 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
>> 
>
>--
>Christoph Galuschka
>CentOS-QA-Team member | IRC: tigalch
>
>---
>Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
>https://www.avast.com/antivirus
>
>___
>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

Remove all packages with jpp5 manually and try again.

rpm -e -nodeps $(rpm -qa |grep jpp5 | xargs)

Robert

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

Re: [Spacewalk-list] some system not updating

[Robert Paschedag]

Am 11. Dezember 2017 22:40:58 MEZ schrieb Dimitri Yioulos 
:
>Have you tried removing the jabber databases?
>
>/usr/sbin/spacewalk-service stop
>rm -rf /var/lib/jabberd/db/*
>/usr/sbin/spacewalk-service stop
>(osa-dispatcher can be a bit balky on my system, so I always make sure,
>especially, that it's running)
>
>I then usually stop osad, remove osad-auth.conf, and start osad on my
>clients.  If you use Ansible in your environment, both of the above are
>easy to create a playbook around.
>
>Dimitri
>
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Sean Roe
>Sent: Monday, December 11, 2017 3:55 PM
>To: spacewalk-list@redhat.com
>Subject: [Spacewalk-list] some system not updating
>
>Hi All,
>
>I am getting some weird errors that don't appear to be consistent
>across our environment.
>
>I am releasing updates and I login to receiving system and run
>rhn_check -vvv and I am getting errors like:
>: added key gpg-pubkey-2945-579ec98c to keyring
>D: Using legacy gpg-pubkey(s) from rpmdb
>D:  read h#2064 Header sanity check: OK
>D:  read h#2671 Header sanity check: OK
>E: Package nss-softokn-freebl-0:3.14.3-23.3.0.1.el6_8.x86_64 is not
>available for installation
>D:  read h#2929 Header sanity check: OK
>E: Package nfs-utils-1:1.2.3-75.0.6.el6_9.x86_64 is not available for
>installation
>D:  read h#2771 Header sanity check: OK
>E: Package libuuid-0:2.17.2-12.28.el6_9.1.x86_64 is not available for
>installation
>D:  read h#3256 Header sanity check: OK
>E: Package httpd-0:2.2.15-60.0.1.el6_9.6.x86_64 is not available for
>installation
>D:  read h#3039 Header sanity check: OK
>E: Package libcgroup-0:0.40.rc1-24.el6_9.x86_64 is not available for
>installation
>D:  read h#3239 Header sanity check: OK
>E: Package kernel-firmware-0:2.6.32-696.16.1.el6.noarch is not
>available for installation
>D:  read h#3262 Header sanity check: OK
>E: Package libsmbclient-0:3.6.23-45.0.1.el6_9.x86_64 is not available
>for installation
>D:  read h#3102 Header sanity check: OK
>E: Package device-mapper-multipath-0:0.4.9-100.0.1.el6_9.1.x86_64 is
>not available for installation
>D:  read h#3224 Header sanity check: OK
>E: Package samba-winbind-0:3.6.23-45.0.1.el6_9.x86_64 is not available
>for installation
>D:  read h#2930 Header sanity check: OK
>E: Package postgresql-libs-0:8.4.20-8.el6_9.x86_64 is not available for
>installation
>D:  read h#2912 Header sanity check: OK
>E: Package device-mapper-multipath-libs-0:0.4.9-100.0.1.el6_9.1.x86_64
>is not available for installation
>D:  read h#3210 Header sanity check: OK
>E: Package samba4-libs-0:4.2.10-12.el6_9.x86_64 is not available for
>installation
>D:  read h#3214 Header sanity check: OK
>E: Package nss-0:3.28.4-4.0.1.el6_9.x86_64 is not available for
>installation
>D:  read h#2835 Header sanity check: OK
>E: Package kpartx-0:0.4.9-100.0.1.el6_9.1.x86_64 is not available for
>installation
>D:  read h#2119 Header sanity check: OK
>E: Package nss-softokn-0:3.14.3-23.3.0.1.el6_8.x86_64 is not available
>for installation
>..
>E: Package postgresql-devel-0:8.4.20-8.el6_9.x86_64 is not available
>for installation
>D:  read h#3045 Header sanity check: OK
>E: Package autofs-1:5.0.5-133.0.1.el6_9.x86_64 is not available for
>installation
>D: Sending back response(32, 'Failed: Packages failed to install
>properly:\nPackage nss-softokn-freebl-0:3.14.3-23.3.0.1.el6_8.x86_64 is
>not available for installation\nPackage
>nfs-utils-1:1.2.3-75.0.6.el6_9.x86_64 is not available for
>installation\nPackage libuuid-0:2.17.2-12.28.el6_9.1.x86_64 is not
>available for installation\nPackage
>httpd-0:2.2.15-60.0.1.el6_9.6.x86_64 is not available for
>installation\nPackage libcgroup-0:0.40.rc1-24.el6_9.x86_64 is not
>available for installation\nPackage
>kernel-firmware-0:2.6.32-696.16.1.el6.noarch is not available for
>installation\nPackage libsmbclient-0:3.6.23-45.0.1.el6_9.x86_64 is not
>available for installation\nPackage
>device-mapper-multipath-0:0.4.9-100.0.1.el6_9.1.x86_64 is not available
>for installation\nPackage samba-winbind-0:3.6.23-45.0.1.el6_9.x86_64 is
>not available for installation\nPackage
>postgresql-libs-0:8.4.20-8.el6_9.x86_64 is not available for
>installation\nPackage
>device-mapper-multipath-libs-0:0.4.9-100.0.1.el6_9.1.x86_64 is not
>available for installation\nPackage
>samba4-libs-0:4.2.10-12.el6_9.x86_64 is not available for
>installation\nPackage nss-0:3.28.4-4.0.1.el6_9.x86_64 is not available
>for installation\nPackage kpartx-0:0.4.9-100.0.1.el6_9.1.x86_64 is not
>available for installation\nPackage
>nss-softokn-0:3.14.3-23.3.0.1.el6_8.x86_64 is not available for
>installation\nPackage tzdata-0:2017c-1.el6.noarch is not available for
>installation\nPackage apr-0:1.3.9-5.el6_9.1.x86_64 is not available for
>installation\nPackage scl-utils-0:20120927-29.el6_9.x86_64 is not
>available for installation\nPackage

Re: [Spacewalk-list] Issue after registering Ubuntu to spacewalk - In apt-get update

[Robert Paschedag]

Am 22. November 2017 21:13:55 MEZ schrieb Robert Paschedag 
<robert.pasche...@web.de>:
>Am 22. November 2017 17:19:14 MEZ schrieb "Arumugam, Saravanan(Aswath)"
><saravanan.arumu...@astrazeneca.com>:
>>Thanks for the Reply!!
>>
>>As per your suggestion I've removed the content which I've added in
>the
>>respective file, And reloaded the Setting by "apt-get update".
>>
>>After the changes made, I get a new error.
>>
>>- -error- -
>># apt-get update
>>- OUTPUT  TRUNCATED 
>>Reading package lists... Done
>>W: The repository 'spacewalk://spacewalk.server.com channels: 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.
>>
>>root@ubuntu:~# rhn-channel -l
>>ubuntu-xenial-main
>>ubuntu-xenial-multiverse
>>ubuntu-xenial-restricted
>>ubuntu-xenial-universe
>>root@ubuntu:~#
>>
>>Thank You,
>>Saravanan Arumugam
>>Unix/Linux Architect
>>
>>-Original Message-
>>From: Robert Paschedag [mailto:robert.pasche...@web.de]
>>Sent: 22 November 2017 09:31 PM
>>To: spacewalk-list@redhat.com; Arumugam, Saravanan(Aswath)
>><saravanan.arumu...@astrazeneca.com>; spacewalk-list
>>(spacewalk-list@redhat.com) <spacewalk-list@redhat.com>
>>Subject: Re: [Spacewalk-list] Issue after registering Ubuntu to
>>spacewalk - In apt-get update
>>
>>Am 22. November 2017 14:46:29 MEZ schrieb "Arumugam,
>Saravanan(Aswath)"
>><saravanan.arumu...@astrazeneca.com>:
>>>Hello,
>>>
>>>I've setup Spacewalk server successfully and already sync'd Ubuntu
>>>16.04 channels.
>>>
>>>After that I've built a test Ubuntu Desktop and registered to
>>spacewalk
>>>successfully.
>>>
>>>After Registering - I've added spacewalk Channel details under
>>>"/etc/apt/sources.list" and "/etc/apt/sources.list.d/spacewalk.list".
>>>with the following content.
>>>
>>>deb spacewalk://Spacewalk.server.com channels: main
>>>ubuntu-xenial-universe ubuntu-xenial-multiverse
>>>ubuntu-xenial-restricted
>>>
>>>I've attached the Repo Details along "repo_details.txt"
>>>
>>>After all the successful operation when I run "apt-get update" I get
>>>the following error
>>>
>>>--error-
>>>Reading package lists... Done
>>>W: The repository 'spacewalk://Spacewalk.server.com channels:
>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.
>>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>>IncompleteRead(0 bytes read)
>>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>>IncompleteRead(0 bytes read)
>>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>>IncompleteRead(0 bytes read)
>>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>>IncompleteRead(0 bytes read)
>>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>>IncompleteRead(0 bytes read)
>>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>>IncompleteRead(0 bytes read)
>>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>>IncompleteRead(0 bytes read)
>>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>>IncompleteRead(0 bytes read)
>>>root@ubuntu:/etc/apt#
>>>
>>>
>>>Thank You,
>>>Saravanan Arumugam
>>>
>>>
>>>
>>>Confidentiality Notice: This message is private and may contain
>>>confidential and proprietary information. If you have received this
>>>message in error, please notify us and remove it from your system and
>>>note that you must not copy, distribute or take any action in
>reliance
>>>on it. Any unauthorized use or disclosure of the contents of this
>>>message is not permitted and may be unlawful.
>>
>>Don't add the repos manually into the spacewalk.list file! It gets
>>overwritten every time "apt-get update" runs.
>>
>>If the registration was successful and "rh

Re: [Spacewalk-list] Issue after registering Ubuntu to spacewalk - In apt-get update

[Robert Paschedag]

Am 22. November 2017 17:19:14 MEZ schrieb "Arumugam, Saravanan(Aswath)" 
<saravanan.arumu...@astrazeneca.com>:
>Thanks for the Reply!!
>
>As per your suggestion I've removed the content which I've added in the
>respective file, And reloaded the Setting by "apt-get update".
>
>After the changes made, I get a new error.
>
>- -error- -
># apt-get update
>- OUTPUT  TRUNCATED 
>Reading package lists... Done
>W: The repository 'spacewalk://spacewalk.server.com channels: 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.
>
>root@ubuntu:~# rhn-channel -l
>ubuntu-xenial-main
>ubuntu-xenial-multiverse
>ubuntu-xenial-restricted
>ubuntu-xenial-universe
>root@ubuntu:~#
>
>Thank You,
>Saravanan Arumugam
>Unix/Linux Architect
>
>-Original Message-
>From: Robert Paschedag [mailto:robert.pasche...@web.de]
>Sent: 22 November 2017 09:31 PM
>To: spacewalk-list@redhat.com; Arumugam, Saravanan(Aswath)
><saravanan.arumu...@astrazeneca.com>; spacewalk-list
>(spacewalk-list@redhat.com) <spacewalk-list@redhat.com>
>Subject: Re: [Spacewalk-list] Issue after registering Ubuntu to
>spacewalk - In apt-get update
>
>Am 22. November 2017 14:46:29 MEZ schrieb "Arumugam, Saravanan(Aswath)"
><saravanan.arumu...@astrazeneca.com>:
>>Hello,
>>
>>I've setup Spacewalk server successfully and already sync'd Ubuntu
>>16.04 channels.
>>
>>After that I've built a test Ubuntu Desktop and registered to
>spacewalk
>>successfully.
>>
>>After Registering - I've added spacewalk Channel details under
>>"/etc/apt/sources.list" and "/etc/apt/sources.list.d/spacewalk.list".
>>with the following content.
>>
>>deb spacewalk://Spacewalk.server.com channels: main
>>ubuntu-xenial-universe ubuntu-xenial-multiverse
>>ubuntu-xenial-restricted
>>
>>I've attached the Repo Details along "repo_details.txt"
>>
>>After all the successful operation when I run "apt-get update" I get
>>the following error
>>
>>--error-
>>Reading package lists... Done
>>W: The repository 'spacewalk://Spacewalk.server.com channels: 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.
>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>IncompleteRead(0 bytes read)
>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>IncompleteRead(0 bytes read)
>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>IncompleteRead(0 bytes read)
>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>IncompleteRead(0 bytes read)
>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>IncompleteRead(0 bytes read)
>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>IncompleteRead(0 bytes read)
>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>IncompleteRead(0 bytes read)
>>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>>IncompleteRead(0 bytes read)
>>root@ubuntu:/etc/apt#
>>
>>
>>Thank You,
>>Saravanan Arumugam
>>
>>
>>
>>Confidentiality Notice: This message is private and may contain
>>confidential and proprietary information. If you have received this
>>message in error, please notify us and remove it from your system and
>>note that you must not copy, distribute or take any action in reliance
>>on it. Any unauthorized use or disclosure of the contents of this
>>message is not permitted and may be unlawful.
>
>Don't add the repos manually into the spacewalk.list file! It gets
>overwritten every time "apt-get update" runs.
>
>If the registration was successful and "rhn-channel -l" returns your
>subscribed channels, run "apt-get update" twice!!!
>
>The first will update the spacewalk.list file, the second will actually
>download repo metadata.
>
>Robert
>
>
>
>Confidentiality Notice: This message is private and may contain
>confidential and proprietary information. If you have received this
>message in error, please notify us and remove it from your system and
>note that you must not copy, distribute or take any action in reliance
>on it. Any unauthorized use or disclosure of the contents of this
>message is not permitted and may be unlawful.

Yes. But this warning is - for now - the normal case. You will have to patch 
your system and gpg sign your repos. See @phils blog here at 
http://www.devops-blog.net/spacewalk/gpg-signing-apt-repository-in-spacewalk

Robert

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

Re: [Spacewalk-list] Issue after registering Ubuntu to spacewalk - In apt-get update

[Robert Paschedag]

Am 22. November 2017 14:46:29 MEZ schrieb "Arumugam, Saravanan(Aswath)" 
:
>Hello,
>
>I've setup Spacewalk server successfully and already sync'd Ubuntu
>16.04 channels.
>
>After that I've built a test Ubuntu Desktop and registered to spacewalk
>successfully.
>
>After Registering - I've added spacewalk Channel details under
>"/etc/apt/sources.list" and "/etc/apt/sources.list.d/spacewalk.list".
>with the following content.
>
>deb spacewalk://Spacewalk.server.com channels: main
>ubuntu-xenial-universe ubuntu-xenial-multiverse
>ubuntu-xenial-restricted
>
>I've attached the Repo Details along "repo_details.txt"
>
>After all the successful operation when I run "apt-get update" I get
>the following error
>
>--error-
>Reading package lists... Done
>W: The repository 'spacewalk://Spacewalk.server.com channels: 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.
>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>IncompleteRead(0 bytes read)
>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>IncompleteRead(0 bytes read)
>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>IncompleteRead(0 bytes read)
>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>IncompleteRead(0 bytes read)
>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>IncompleteRead(0 bytes read)
>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>IncompleteRead(0 bytes read)
>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>IncompleteRead(0 bytes read)
>E: Method gave invalid 400 URI Failure message: IncompleteRead:
>IncompleteRead(0 bytes read)
>root@ubuntu:/etc/apt#
>
>
>Thank You,
>Saravanan Arumugam
>
>
>
>Confidentiality Notice: This message is private and may contain
>confidential and proprietary information. If you have received this
>message in error, please notify us and remove it from your system and
>note that you must not copy, distribute or take any action in reliance
>on it. Any unauthorized use or disclosure of the contents of this
>message is not permitted and may be unlawful.

Don't add the repos manually into the spacewalk.list file! It gets overwritten 
every time "apt-get update" runs.

If the registration was successful and "rhn-channel -l" returns your subscribed 
channels, run "apt-get update" twice!!!

The first will update the spacewalk.list file, the second will actually 
download repo metadata.

Robert

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

Re: [Spacewalk-list] can I get history out of spacewalk?

[Robert Paschedag]

Am 7. November 2017 15:33:38 MEZ schrieb Sean Roe :
>Hi All,
>
>I need to get a list of all our package updates by linux host sorted by
>date out of my Spacewalk 2.6 install.  I need all of the patches
>applied since the first of the year (it's a sox thing) so if anybody
>has any guidance I would be forever in your debt.
>
>Thanks,
>Sean Roe

I think

"rpm -qa --last"

on each host could do what you need.

Robert

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

Re: [Spacewalk-list] question of upgrading

[Robert Paschedag]

Am 7. November 2017 14:40:17 MEZ schrieb Robin Beardsley 
:
>What is best way to upgrade Spacewalk V2.4  to Spacewalk V2.7
>
>Can I go  from 2.4 to 2.6 and then 2.6 to 2.7, leaving 2.5 completely
>out.
>
>Thanks

You can go directly from 2.4 to 2.7. Did that also.

Robert

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

Re: [Spacewalk-list] Some servers never receiving or acting on remote commands

[Robert Paschedag]

Am 6. November 2017 21:06:54 MEZ schrieb Christoph Galuschka 
:
>
>
>Am 06.11.2017 um 17:21 schrieb oogiej...@yahoo.com:
>> I am trying to set up all my servers to act on remote commands. 
>These 
>> servers are all redhat linux, all running 6.8.
>You should update to 6.9
>> I set them all up the same way, with the following command --
>> 
>> yum install -y osad; yum install -y rhncfg-actions ; cd
>/usr/share/rhn; wget
>http://myspacewalkserver/pub/RHN-ORG-TRUSTED-SSL-CERT ;/usr/bin/perl
>-pi -e 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g'
>/etc/sysconfig/rhn/up2date ; /sbin/service osad start ; /sbin/chkconfig
>--add osad ; rhn-actions-control --enable-all
>> 
>> I have 7 servers that are just not working.  If I try to send remote 
>> commands to them they will sit there at pending forever until I login
>to 
>> them and manually run rhn_check.  They should be identical to all the
>
>> other servers.  I've confirmed that osad is running and 
>> rhn-actions-control is enable-all.  Any ideas on what else I can
>check?  
>> We are running spacewalk 2.4.
>Have you tried with more recent versions like 2.7?
>> 
>> 
>> ___
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> 
>
>-- 
>Christoph Galuschka
>CentOS-QA-Team member | IRC: tigalch
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

It should also work with 2.4.

Did you clone some of these servers due testing?

You could also stop osad on those clients, remove the "osad-auth" file in 
/etc/sysconfig/rhn and restart osad. This should generate new ids on the 
clients.

Might fix your problem.

Robert

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

Re: [Spacewalk-list] Issue in Spacewalk client

[Robert Paschedag]

Am 5. November 2017 12:13:37 MEZ schrieb ANKIT SETHI :
>Hello Team,
>
>Can anyone help me in resolving one issue I am facing as mentioned
>below:
>
>I have installed spacewalk server on Centos 7 it is working fine and
>also
>clients are registered with the server but after reboot or after few
>hours
>client is not connected to server.
>
>The basics commands like rhn_check  -vvv OR rhnreg_ks are not found on
>client machine , If i try to reinstall client tools in client machine.
>
>[root@client /]# yum -y install rhn-client-tools rhn-check rhn-setup
>rhnsd
>m2crypto yum-rhn-plugin
>Loaded plugins: search-disabled-repos
>Package rhn-client-tools-2.7.16-1.el7.noarch already installed and
>latest
>version
>Resolving Dependencies
>--> Running transaction check
>---> Package rhn-check.noarch 0:2.7.16-1.el7 will be installed
>---> Package rhn-setup.noarch 0:2.7.16-1.el7 will be installed
>---> Package rhnsd.x86_64 0:5.0.30-1.el7 will be installed
>--> Processing Dependency: initscripts for package:
>rhnsd-5.0.30-1.el7.x86_64
>---> Package yum-rhn-plugin.noarch 0:2.7.7-1.el7 will be installed
>--> Finished Dependency Resolution
>Error: Package: rhnsd-5.0.30-1.el7.x86_64 (spacewalk-client)
>   Requires: initscripts
> You could try using --skip-broken to work around the problem
> You could try running: rpm -Va --nofiles --nodigest
>
>Please help me to proceed further.
>
>Regards,
>Ankit Sethi

I think your clients are deinstalling some packages because of dependency 
problems.


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

Re: [Spacewalk-list] "Peer's certificate issuer has been marked as not trusted by the user."

[Robert Paschedag]

Am 2. November 2017 09:40:02 MEZ schrieb Robert Paschedag 
<robert.pasche...@web.de>:
>Am 2. November 2017 08:47:00 MEZ schrieb "Vipul Sharma (DevOps)"
><sharma.vi...@in.g4s.com>:
>>Hi,
>>
>>I imported the new keyfile downloaded from Red-Hat -
>>
>>
>>
>>*gpg: key FD431D51: public key "Red Hat, Inc. (release key 2)
>><secur...@redhat.com <secur...@redhat.com>>" importedgpg: Total number
>>processed: 1gpg:   imported: 1  (RSA: 1)*
>>
>>
>>But, If we run gpg --list-keys - It shows me 2 different versions of
>>that,
>>What's that about, Any ideas?
>>
>>
>>
>>
>>
>>*pub   1024D/F24F1B08 2002-04-23 [expired: 2004-04-22]uid
>>Red Hat, Inc (Red Hat Network) <rhn-feedb...@redhat.com
>><rhn-feedb...@redhat.com>>pub   4096R/FD431D51
>>2009-10-22uid  Red Hat, Inc. (release key 2)
>><secur...@redhat.com <secur...@redhat.com>>*
>>
>>
>>
>>Also, I checked ca-bundle.crt, I found no chain for Red-Hat over there
>>-
>>
>>Thanks
>>Vipul
>>
>>On Thu, Nov 2, 2017 at 12:58 PM, Robert Paschedag
>><robert.pasche...@web.de>
>>wrote:
>>
>>> Am 2. November 2017 08:24:10 MEZ schrieb "Vipul Sharma (DevOps)" <
>>> sharma.vi...@in.g4s.com>:
>>> >I have tested 2 different URL'S -
>>> >
>>> >*This one was was from your article -*
>>> >
>>> >curl -v https://cdn.redhat.com/content/dist/rhel/server/7/
>>> >7Server/x86_64/os/repodata/repomd.xml
>>> >* About to connect() to cdn.redhat.com port 443 (#0)
>>> >*   Trying 2.16.30.83...
>>> >* Connected to cdn.redhat.com (2.16.30.83) port 443 (#0)
>>> >* Initializing NSS with certpath: sql:/etc/pki/nssdb
>>> >*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>>> >  CApath: none
>>> >* Server certificate:
>>> >*   subject: CN=cdn.redhat.com,OU=Red Hat Network,O=Red
>>> >Hat,L=Raleigh,ST=North Carolina,C=US
>>> >*   start date: May 14 19:48:02 2014 GMT
>>> >*   expire date: May 11 19:48:02 2024 GMT
>>> >*   common name: cdn.redhat.com
>>> >*   issuer: E=ca-supp...@redhat.com,CN=Red Hat Entitlement
>>> >Operations
>>> >Authority,OU=Red Hat Network,O="Red Hat, Inc.",ST=North
>>Carolina,C=US
>>> >* *NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)*
>>> >* Peer's certificate issuer has been marked as not trusted by the
>>user.
>>> >* Closing connection 0
>>> >curl: (60) Peer's certificate issuer has been marked as not trusted
>>by
>>> >the
>>> >user.
>>> >
>>> >---
>>> >
>>> >*This is from Google-Cloud - Pretty much the same result -*
>>> >
>>> >curl -v https://cds.rhel.updates.googlecloud.com/pulp/mirror/
>>>
>>>content/dist/rhel/rhui/server/7/7Server/x86_64/os/repodata/repomd.xml
>>> >* About to connect() to cds.rhel.updates.googlecloud.com port 443
>>(#0)
>>> >*   Trying 23.236.57.179...
>>> >* Connected to cds.rhel.updates.googlecloud.com (23.236.57.179)
>port
>>> >443
>>> >(#0)
>>> >* Initializing NSS with certpath: sql:/etc/pki/nssdb
>>> >*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>>> >  CApath: none
>>> >* Server certificate:
>>> >*   subject:
>>>
>>>CN=cds.rhel.updates.googlecloud.com,OU=SomeOrgUnit,O=SomeOrg,ST=North
>>> >Carolina,C=US
>>> >*   start date: Sep 23 05:18:30 2017 GMT
>>> >*   expire date: Sep 25 05:18:30 2037 GMT
>>> >*   common name: cds.rhel.updates.googlecloud.com
>>> >*   issuer: CN=RHUI Certificate
>>> >Authority,OU=SomeOrgUnit,O=SomeOrg,L=Raleigh,ST=North
>>> >Carolina,C=US
>>> >* *NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)*
>>> >* Peer's certificate issuer has been marked as not trusted by the
>>user.
>>> >* Closing connection 0
>>> >curl: (60) Peer's certificate issuer has been marked as not trusted
>>by
>>> >the
>>> >user.
>>> >
>>> >Thanks
>>> >
>>> >On Thu, Nov 2, 2017 at 12:36 PM, Robert Paschedag
>>> ><robert.pasche...@web.de>
>>> >wrote:
>>> >
>>> >> Am 2. 

Re: [Spacewalk-list] "Peer's certificate issuer has been marked as not trusted by the user."

[Robert Paschedag]

Am 2. November 2017 08:47:00 MEZ schrieb "Vipul Sharma (DevOps)" 
<sharma.vi...@in.g4s.com>:
>Hi,
>
>I imported the new keyfile downloaded from Red-Hat -
>
>
>
>*gpg: key FD431D51: public key "Red Hat, Inc. (release key 2)
><secur...@redhat.com <secur...@redhat.com>>" importedgpg: Total number
>processed: 1gpg:   imported: 1  (RSA: 1)*
>
>
>But, If we run gpg --list-keys - It shows me 2 different versions of
>that,
>What's that about, Any ideas?
>
>
>
>
>
>*pub   1024D/F24F1B08 2002-04-23 [expired: 2004-04-22]uid
>Red Hat, Inc (Red Hat Network) <rhn-feedb...@redhat.com
><rhn-feedb...@redhat.com>>pub   4096R/FD431D51
>2009-10-22uid  Red Hat, Inc. (release key 2)
><secur...@redhat.com <secur...@redhat.com>>*
>
>
>
>Also, I checked ca-bundle.crt, I found no chain for Red-Hat over there
>-
>
>Thanks
>Vipul
>
>On Thu, Nov 2, 2017 at 12:58 PM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 2. November 2017 08:24:10 MEZ schrieb "Vipul Sharma (DevOps)" <
>> sharma.vi...@in.g4s.com>:
>> >I have tested 2 different URL'S -
>> >
>> >*This one was was from your article -*
>> >
>> >curl -v https://cdn.redhat.com/content/dist/rhel/server/7/
>> >7Server/x86_64/os/repodata/repomd.xml
>> >* About to connect() to cdn.redhat.com port 443 (#0)
>> >*   Trying 2.16.30.83...
>> >* Connected to cdn.redhat.com (2.16.30.83) port 443 (#0)
>> >* Initializing NSS with certpath: sql:/etc/pki/nssdb
>> >*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>> >  CApath: none
>> >* Server certificate:
>> >*   subject: CN=cdn.redhat.com,OU=Red Hat Network,O=Red
>> >Hat,L=Raleigh,ST=North Carolina,C=US
>> >*   start date: May 14 19:48:02 2014 GMT
>> >*   expire date: May 11 19:48:02 2024 GMT
>> >*   common name: cdn.redhat.com
>> >*   issuer: E=ca-supp...@redhat.com,CN=Red Hat Entitlement
>> >Operations
>> >Authority,OU=Red Hat Network,O="Red Hat, Inc.",ST=North
>Carolina,C=US
>> >* *NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)*
>> >* Peer's certificate issuer has been marked as not trusted by the
>user.
>> >* Closing connection 0
>> >curl: (60) Peer's certificate issuer has been marked as not trusted
>by
>> >the
>> >user.
>> >
>> >---
>> >
>> >*This is from Google-Cloud - Pretty much the same result -*
>> >
>> >curl -v https://cds.rhel.updates.googlecloud.com/pulp/mirror/
>>
>>content/dist/rhel/rhui/server/7/7Server/x86_64/os/repodata/repomd.xml
>> >* About to connect() to cds.rhel.updates.googlecloud.com port 443
>(#0)
>> >*   Trying 23.236.57.179...
>> >* Connected to cds.rhel.updates.googlecloud.com (23.236.57.179) port
>> >443
>> >(#0)
>> >* Initializing NSS with certpath: sql:/etc/pki/nssdb
>> >*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>> >  CApath: none
>> >* Server certificate:
>> >*   subject:
>>
>>CN=cds.rhel.updates.googlecloud.com,OU=SomeOrgUnit,O=SomeOrg,ST=North
>> >Carolina,C=US
>> >*   start date: Sep 23 05:18:30 2017 GMT
>> >*   expire date: Sep 25 05:18:30 2037 GMT
>> >*   common name: cds.rhel.updates.googlecloud.com
>> >*   issuer: CN=RHUI Certificate
>> >Authority,OU=SomeOrgUnit,O=SomeOrg,L=Raleigh,ST=North
>> >Carolina,C=US
>> >* *NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)*
>> >* Peer's certificate issuer has been marked as not trusted by the
>user.
>> >* Closing connection 0
>> >curl: (60) Peer's certificate issuer has been marked as not trusted
>by
>> >the
>> >user.
>> >
>> >Thanks
>> >
>> >On Thu, Nov 2, 2017 at 12:36 PM, Robert Paschedag
>> ><robert.pasche...@web.de>
>> >wrote:
>> >
>> >> Am 2. November 2017 07:29:16 MEZ schrieb "Vipul Sharma (DevOps)" <
>> >> sharma.vi...@in.g4s.com>:
>> >> >In spacewalk, I had to manually create this file -->*
>> >> >file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release*, & then
>> >copy/pasted
>> >> >the
>> >> >KEY from RHEL server to this location in Spacewalk server.
>> >> >
>> >> >Some Doubts :-
>> >> >
>> >> >Do this requires importing this file ??
>>

Re: [Spacewalk-list] "Peer's certificate issuer has been marked as not trusted by the user."

[Robert Paschedag]

Am 2. November 2017 08:24:10 MEZ schrieb "Vipul Sharma (DevOps)" 
<sharma.vi...@in.g4s.com>:
>I have tested 2 different URL'S -
>
>*This one was was from your article -*
>
>curl -v https://cdn.redhat.com/content/dist/rhel/server/7/
>7Server/x86_64/os/repodata/repomd.xml
>* About to connect() to cdn.redhat.com port 443 (#0)
>*   Trying 2.16.30.83...
>* Connected to cdn.redhat.com (2.16.30.83) port 443 (#0)
>* Initializing NSS with certpath: sql:/etc/pki/nssdb
>*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>  CApath: none
>* Server certificate:
>*   subject: CN=cdn.redhat.com,OU=Red Hat Network,O=Red
>Hat,L=Raleigh,ST=North Carolina,C=US
>*   start date: May 14 19:48:02 2014 GMT
>*   expire date: May 11 19:48:02 2024 GMT
>*   common name: cdn.redhat.com
>*   issuer: E=ca-supp...@redhat.com,CN=Red Hat Entitlement
>Operations
>Authority,OU=Red Hat Network,O="Red Hat, Inc.",ST=North Carolina,C=US
>* *NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)*
>* Peer's certificate issuer has been marked as not trusted by the user.
>* Closing connection 0
>curl: (60) Peer's certificate issuer has been marked as not trusted by
>the
>user.
>
>---
>
>*This is from Google-Cloud - Pretty much the same result -*
>
>curl -v https://cds.rhel.updates.googlecloud.com/pulp/mirror/
>content/dist/rhel/rhui/server/7/7Server/x86_64/os/repodata/repomd.xml
>* About to connect() to cds.rhel.updates.googlecloud.com port 443 (#0)
>*   Trying 23.236.57.179...
>* Connected to cds.rhel.updates.googlecloud.com (23.236.57.179) port
>443
>(#0)
>* Initializing NSS with certpath: sql:/etc/pki/nssdb
>*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>  CApath: none
>* Server certificate:
>*   subject:
>CN=cds.rhel.updates.googlecloud.com,OU=SomeOrgUnit,O=SomeOrg,ST=North
>Carolina,C=US
>*   start date: Sep 23 05:18:30 2017 GMT
>*   expire date: Sep 25 05:18:30 2037 GMT
>*   common name: cds.rhel.updates.googlecloud.com
>*   issuer: CN=RHUI Certificate
>Authority,OU=SomeOrgUnit,O=SomeOrg,L=Raleigh,ST=North
>Carolina,C=US
>* *NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)*
>* Peer's certificate issuer has been marked as not trusted by the user.
>* Closing connection 0
>curl: (60) Peer's certificate issuer has been marked as not trusted by
>the
>user.
>
>Thanks
>
>On Thu, Nov 2, 2017 at 12:36 PM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 2. November 2017 07:29:16 MEZ schrieb "Vipul Sharma (DevOps)" <
>> sharma.vi...@in.g4s.com>:
>> >In spacewalk, I had to manually create this file -->*
>> >file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release*, & then
>copy/pasted
>> >the
>> >KEY from RHEL server to this location in Spacewalk server.
>> >
>> >Some Doubts :-
>> >
>> >Do this requires importing this file ??
>> >
>> >I'm running spacewalk without CA certified certificate, Does that
>> >impact
>> >the overall config for RHEL Repo in Spacewalk.
>> >
>> >Thanks
>> >Vipul
>> >
>> >On Thu, Nov 2, 2017 at 11:49 AM, Robert Paschedag
>> ><robert.pasche...@web.de>
>> >wrote:
>> >
>> >> Am 2. November 2017 05:13:12 MEZ schrieb "Vipul Sharma (DevOps)" <
>> >> sharma.vi...@in.g4s.com>:
>> >> >Hi Michael,
>> >> >
>> >> >We are using registered system through 'Google-Cloud' - I have
>> >copied
>> >> >everything very carefully from RHEL.repo into spacewalk,
>Including
>> >all
>> >> >the
>> >> >.cert & .pem files.
>> >> >
>> >> >Just unable to figure out what's wrong with it for the time being
>-
>> >> >
>> >> >Thanks
>> >> >
>> >> >On Wed, Nov 1, 2017 at 5:36 PM, Michael Mraka
>> >> ><michael.mr...@redhat.com>
>> >> >wrote:
>> >> >
>> >> >> Vipul Sharma (DevOps):
>> >> >> > Hi Robert,
>> >> >> >
>> >> >> > I need your 'HELP' - I went according to your configuration
>for
>> >> >> downloading
>> >> >> > RHEL repos into 'Spacewalk'  - But, I'm facing some issues
>while
>> >> >doing
>> >> >> > that, Can you be humble enough to take a look into my issue
>--
>> >> >> >
>> >> >> > *This is the error -*
>> >> >> >

Re: [Spacewalk-list] "Peer's certificate issuer has been marked as not trusted by the user."

[Robert Paschedag]

Am 2. November 2017 07:29:16 MEZ schrieb "Vipul Sharma (DevOps)" 
<sharma.vi...@in.g4s.com>:
>In spacewalk, I had to manually create this file -->*
>file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release*, & then copy/pasted
>the
>KEY from RHEL server to this location in Spacewalk server.
>
>Some Doubts :-
>
>Do this requires importing this file ??
>
>I'm running spacewalk without CA certified certificate, Does that
>impact
>the overall config for RHEL Repo in Spacewalk.
>
>Thanks
>Vipul
>
>On Thu, Nov 2, 2017 at 11:49 AM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 2. November 2017 05:13:12 MEZ schrieb "Vipul Sharma (DevOps)" <
>> sharma.vi...@in.g4s.com>:
>> >Hi Michael,
>> >
>> >We are using registered system through 'Google-Cloud' - I have
>copied
>> >everything very carefully from RHEL.repo into spacewalk, Including
>all
>> >the
>> >.cert & .pem files.
>> >
>> >Just unable to figure out what's wrong with it for the time being -
>> >
>> >Thanks
>> >
>> >On Wed, Nov 1, 2017 at 5:36 PM, Michael Mraka
>> ><michael.mr...@redhat.com>
>> >wrote:
>> >
>> >> Vipul Sharma (DevOps):
>> >> > Hi Robert,
>> >> >
>> >> > I need your 'HELP' - I went according to your configuration for
>> >> downloading
>> >> > RHEL repos into 'Spacewalk'  - But, I'm facing some issues while
>> >doing
>> >> > that, Can you be humble enough to take a look into my issue --
>> >> >
>> >> > *This is the error -*
>> >> >
>> >> > 10:01:26 | Channel: rhel-base
>> >> > 10:01:26 ==
>> >> > 10:01:26 Sync of channel started.
>> >> > 10:01:26 Repo URL:
>> >> >
>https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os
>> >> > 10:01:27 ERROR: failure: repodata/repomd.xml from
>> >> > content_dist_rhel_server_7_7Server_x86_64_os: [Errno 256] No
>more
>> >> mirrors
>> >> > to try.
>> >> > *https://cdn.redhat.com/content/dist/rhel/server/7/
>> >> 7Server/x86_64/os/repodata/repomd.xml
>> >> > <https://cdn.redhat.com/content/dist/rhel/server/7/
>> >> 7Server/x86_64/os/repodata/repomd.xml>:
>> >> > [Errno 14] curl#60 - "Peer's certificate issuer has been marked
>as
>> >not
>> >> > trusted by the user."*
>> >> > 10:01:27 Sync of channel completed in 0:00:00.
>> >> > 10:01:27 Total time: 0:00:00
>> >> >
>> >> > -
>> >> >
>> >> > My Spacewalk server is running unauthorized CA-CERT, Is this
>> >because of
>> >> > that ?
>> >>
>> >> You need a proper Red Hat Subscription to be able to download Red
>Hat
>> >> content from CDN.
>> >>
>> >> 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
>>
>> For me, this sounds as one of the "signing" CA of RedHat's servers is
>not
>> trusted by "you".
>>
>> Robert
>>

Please try to curl the URL.

curl -vv -1 https://

See the same error?

Robert

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

Re: [Spacewalk-list] "Peer's certificate issuer has been marked as not trusted by the user."

[Robert Paschedag]

Am 2. November 2017 05:13:12 MEZ schrieb "Vipul Sharma (DevOps)" 
:
>Hi Michael,
>
>We are using registered system through 'Google-Cloud' - I have copied
>everything very carefully from RHEL.repo into spacewalk, Including all
>the
>.cert & .pem files.
>
>Just unable to figure out what's wrong with it for the time being -
>
>Thanks
>
>On Wed, Nov 1, 2017 at 5:36 PM, Michael Mraka
>
>wrote:
>
>> Vipul Sharma (DevOps):
>> > Hi Robert,
>> >
>> > I need your 'HELP' - I went according to your configuration for
>> downloading
>> > RHEL repos into 'Spacewalk'  - But, I'm facing some issues while
>doing
>> > that, Can you be humble enough to take a look into my issue --
>> >
>> > *This is the error -*
>> >
>> > 10:01:26 | Channel: rhel-base
>> > 10:01:26 ==
>> > 10:01:26 Sync of channel started.
>> > 10:01:26 Repo URL:
>> > https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os
>> > 10:01:27 ERROR: failure: repodata/repomd.xml from
>> > content_dist_rhel_server_7_7Server_x86_64_os: [Errno 256] No more
>> mirrors
>> > to try.
>> > *https://cdn.redhat.com/content/dist/rhel/server/7/
>> 7Server/x86_64/os/repodata/repomd.xml
>> > > 7Server/x86_64/os/repodata/repomd.xml>:
>> > [Errno 14] curl#60 - "Peer's certificate issuer has been marked as
>not
>> > trusted by the user."*
>> > 10:01:27 Sync of channel completed in 0:00:00.
>> > 10:01:27 Total time: 0:00:00
>> >
>> > -
>> >
>> > My Spacewalk server is running unauthorized CA-CERT, Is this
>because of
>> > that ?
>>
>> You need a proper Red Hat Subscription to be able to download Red Hat
>> content from CDN.
>>
>> 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

For me, this sounds as one of the "signing" CA of RedHat's servers is not 
trusted by "you".

Robert

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

Re: [Spacewalk-list] Spacewalk 2.6 Debian repo sync file handle leaking

[Robert Paschedag]

Am 31. Oktober 2017 19:49:11 MEZ schrieb Jay McCanta <j.mcca...@f5.com>:
>I think I found the issue.  Here's the patch I applied to get
>spacewalk-repo-sync working. It closes the files opened when they are
>no longer used.  This prevents the file-handle leakage. 
>
>diff -ruN spacewalk.orig/common/rhn_deb.py spacewalk/common/rhn_deb.py
>--- spacewalk.orig/common/rhn_deb.py   2017-05-19 08:11:17.0
>+
>+++ spacewalk/common/rhn_deb.py2017-10-31 17:05:52.438187084 +
>@@ -88,6 +88,7 @@
> except Exception:
> e = sys.exc_info()[1]
> raise_with_tb(InvalidPackageError(e), sys.exc_info()[2])
>+self.deb = None
> 
> @staticmethod
> def checksum_type():
>@@ -138,3 +139,4 @@
> if output_stream:
> self.payload_stream = output_stream
> self.payload_size = output_stream.tell() - output_start
>+    self.header_data.close()
>
>
>
>-Original Message-
>From: Robert Paschedag [mailto:robert.pasche...@web.de] 
>Sent: Tuesday, October 31, 2017 12:16 AM
>To: spacewalk-list@redhat.com; Jay McCanta <j.mcca...@f5.com>;
>spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Spacewalk 2.6 Debian repo sync file
>handle leaking
>
>EXTERNAL MAIL: robert.pasche...@web.de
>
>Am 31. Oktober 2017 00:17:56 MEZ schrieb Jay McCanta
><j.mcca...@f5.com>:
>>I am running spacewalk 2.6 on CentOS7 trying to an sync Ubuntu 
>>repository.  I have discovered that somewhere in 
>>/usr/bin/spacewalk-sync-repo file handles are leaked.  It seems to
>leak
>>2 handles for every file it needs to import.  At some point, I run out
>
>>of handles.  The files are all temp files '/tmp/tmpXX.  Once all 
>>the open handles are exhausted, I get 'ERROR:
>>requests.exceptions.RequestException occurred'  over and over and
>over.
>>
>>I have tried looking in
>>/usr/lib/python2.7/site-packages/spacewalk/common/rhn_deb.py
>>/usr/lib/python2.7/site-packages/spacewalk/satellite_tools/repo_plugins
>>/deb_src.py
>>
>>To see if I can find it, but I cannot.  The repo (xenial-universe) has
>>43567 packages in it.  Has anyone else encountered (and fixed) this?
>>
>>Jay McCanta
>>F5 Networks, Inc.
>>Seattle,  WA 98119
>>
>>We Make Apps GO
>
>Hi,
>
>because I just upgraded from SW 2.4 to 2.7 I'm still using Steve
>Meier's "spacewalk-debian-sync" script to import Debian packages .I
>also tried to import Debian repos with spacewalk-repo-sync but that
>often had errors importing many packages. Someone then suggested, to
>use the script from Steve for the first, large import and then switch
>to SW default script. That should work, but I did not yet test it.
>
>Robert

Hi Jay,

If the import works now, you should open a pull request on GitHub so this patch 
finds its way into the master branch.

Good work.

Robert

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

Re: [Spacewalk-list] Spacewalk 2.6 Debian repo sync file handle leaking

[Robert Paschedag]

Am 31. Oktober 2017 00:17:56 MEZ schrieb Jay McCanta :
>I am running spacewalk 2.6 on CentOS7 trying to an sync Ubuntu
>repository.  I have discovered that somewhere in
>/usr/bin/spacewalk-sync-repo file handles are leaked.  It seems to leak
>2 handles for every file it needs to import.  At some point, I run out
>of handles.  The files are all temp files '/tmp/tmpXX.  Once all
>the open handles are exhausted, I get 'ERROR:
>requests.exceptions.RequestException occurred'  over and over and over.
>
>I have tried looking in
>/usr/lib/python2.7/site-packages/spacewalk/common/rhn_deb.py
>/usr/lib/python2.7/site-packages/spacewalk/satellite_tools/repo_plugins/deb_src.py
>
>To see if I can find it, but I cannot.  The repo (xenial-universe) has
>43567 packages in it.  Has anyone else encountered (and fixed) this?
>
>Jay McCanta
>F5 Networks, Inc.
>Seattle,  WA 98119
>
>We Make Apps GO

Hi,

because I just upgraded from SW 2.4 to 2.7 I'm still using Steve Meier's 
"spacewalk-debian-sync" script to import Debian packages .I also tried to 
import Debian repos with spacewalk-repo-sync but that often had errors 
importing many packages. Someone then suggested, to use the script from Steve 
for the first, large import and then switch to SW default script. That should 
work, but I did not yet test it.

Robert

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

Re: [Spacewalk-list] Error with PAM authentication after Upgrade to CentOS 7.4

[Robert Paschedag]

Am 28. Oktober 2017 20:37:08 MESZ schrieb "Millage, Joel" 
:
>I am using Spacewalk 2.6 with PAM authentication and have been for a
>few months without issues. I updated from CentOS 7.3 to 7.4 this week
>and now my PAM authentication no longer works with any of my users.  I
>use PAM authentication with Kerberos 1.5.
>
>Since CentOS 7.4 I get the following error in the tomcat.service of
>Spacewalk:
>
>pam_krb5[9598]: error reading keytab 'FILE:/etc/krb5.keytab'
>Oct 28 14:34:19 ccam-thorcp2.integrity-apps.com java[9598]:
>pam_krb5[9598]: TGT verified
>Oct 28 14:34:19 ccam-thorcp2.integrity-apps.com java[9598]:
>pam_krb5[9598]: authentication succeeds for 'jmillage'
>Oct 28 14:34:19 ccam-thorcp2.integrity-apps.com server[9598]:
>2017-10-28 14:34:19,091 [ajp-bio-0:0:0:0:0:0:0:1-8009-exec-3] WARN 
>com.redhat.rhn.domain.user.legacy.UserImpl - PAM login for user User
>jmillage (id 1, org_id 1) failed with error System error.
>Oct 28 14:34:21 ccam-thorcp2.integrity-apps.com server[9598]:
>2017-10-28 14:34:21,091 [ajp-bio-0:0:0:0:0:0:0:1-8009-exec-3] INFO 
>com.redhat.rhn.frontend.action.LoginAction - LOCAL AUTH FAILURE:
>[jmillage]
>
>I realize now I shouldn't have made my only admin user on PAM
>authentication as I can't even login with spacecmd.  Is there any way I
>can disable PAM auth on this user so I can login without PAM?  All the
>tools I have found allow me to reset my password, but not disable PAM.
>Any help would be great thanks!
>
>Joel

I think the rhnuser table should be a good starting point. But I don't know, if 
the authentication "type" is also stored there.

Robert

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

Re: [Spacewalk-list] ERROR WHILE USING YUM UPDATE ON SPACEWALK CLIENT VERSION 2.6

[Robert Paschedag]

Am 27. Oktober 2017 13:35:04 MESZ schrieb Sreenivasa Katra 
:
>Hi Team,
>
>Not able to update spacewalk client version 2.6  with yum update
>command.
>Error is
>"failed to retrieve repodata/repomd.xml from centos7-updates
>error was [Errno 14] curl#51 - "Unable to communicate securely with
>peer:
>requested domain name does not match the server's certificate."
>
>Server is Centos 7  installed with spacewalk 2.6.
>
>Please advise.
>
>Regards,
>Sreenivasa Rao.K

Well... Looks like yum does not use your spacewalk CA certificate as trusted 
certificate, thus this error message.


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

Re: [Spacewalk-list] SpaceWalk 2.7 no updates available in GUI no updates on clientss

[Robert Paschedag]

Am 24. Oktober 2017 19:19:57 MESZ schrieb Robert Paschedag 
<robert.pasche...@web.de>:
>Am 24. Oktober 2017 18:46:21 MESZ schrieb "Berrigan, Patrick M"
><patrick.berri...@mantech.com>:
>>The systems are not up to date. For example I take one brand newly
>>deployed CentOS 7 machine and run a yum update and I see about 200 MB
>>worth of packages that need to be updated. If I take that same machine
>>and register it with the Spacewalk server that has updated repos from
>>the same repos listed in /etc/yum.repos.d/ it shows No packages marked
>>for update.
>>
>>
>>
>>
>>VR,
>>
>>Patrick Berrigan
>>Systems Engineer
>>ManTech International Corporation
>>patrick.berri...@mantech.com
>>COMM (703) 654-9149
>>
>>
>>-Original Message-
>>From: Robert Paschedag [mailto:robert.pasche...@web.de]
>>Sent: Tuesday, October 24, 2017 12:01 AM
>>To: spacewalk-list@redhat.com; Berrigan, Patrick M
>><patrick.berri...@mantech.com>; spacewalk-list@redhat.com
>>Subject: Re: [Spacewalk-list] SpaceWalk 2.7 no updates available in
>GUI
>>no updates on clientss
>>
>>Am 23. Oktober 2017 19:15:48 MESZ schrieb "Berrigan, Patrick M"
>><patrick.berri...@mantech.com>:
>>>Currently running CentOS7.
>>>
>>>I am having an issue where my SpaceWalk server is not displaying any
>>>updates being available for my clients. I only have two clients, a
>>>Syslog server and the spacewalk server itself. Both are registered in
>>>spacewalk and performing a yum repolist shows that they are
>subscribed
>>>to the correct channels. The repos in the channel are populating
>>>correctly as I can see the package count increase as the nightly
>syncs
>>>finish. I have restarted taskomatic and have ensured that the name in
>>>up2date matches the cert of the SpaceWalk server.
>>>
>>>I have also increased the max java memory to 3GB after checking the
>>log
>>>of rhn_taskomatic_daemon. There wasn't any errors about memory but I
>>>read that this sometimes is the cause.
>>>
>>>OSAD works normally on both clients as I can run simple reboot
>>commands
>>>from the SpaceWalk web GUI.
>>>
>>>Anyone else have any thoughts on resolving this issue?
>>>
>>>VR,
>>>
>>>Patrick Berrigan
>>>Systems Engineer
>>>ManTech International Corporation
>>>patrick.berri...@mantech.com
>>>COMM (703) 654-9149
>>>
>>>
>>>
>>>
>>>This e-mail and any attachments are intended only for the use of the
>>>addressee(s) named herein and may contain proprietary information. If
>>>you are not the intended recipient of this e-mail or believe that you
>>>received this email in error, please take immediate action to notify
>>>the sender of the apparent error by reply e-mail; permanently delete
>>>the e-mail and any attachments from your computer; and do not
>>>disseminate, distribute, use, or copy this message and any
>>attachments.
>>
>>Are there any packages listed as "installed" for the registered
>>systems?
>>
>>Run a "rhn-profile-sync -" on a client. This should update the
>>package list from the client on the server.
>>
>>Also look at the task schedules in "Admin" - "Task Schedule" if all
>>tasks have run AND ended within the last day.
>>
>>Edit:
>>
>>Ah... Just remember...I think there was a bug in c3po package which
>>"might" cause this and must be downgraded on CentOS 7. Please search
>>the mailing list archives for that package
>>
>>
>>
>>This e-mail and any attachments are intended only for the use of the
>>addressee(s) named herein and may contain proprietary information. If
>>you are not the intended recipient of this e-mail or believe that you
>>received this email in error, please take immediate action to notify
>>the sender of the apparent error by reply e-mail; permanently delete
>>the e-mail and any attachments from your computer; and do not
>>disseminate, distribute, use, or copy this message and any
>attachments.
>>
>>___
>>Spacewalk-list mailing list
>>Spacewalk-list@redhat.com
>>https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>Ok. But this is why I think some task is not running correctly. It
>does not finish.
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

What does the task engine status page say? Did the jobs finish within 24 hours?

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

Re: [Spacewalk-list] SpaceWalk 2.7 no updates available in GUI no updates on clientss

[Robert Paschedag]

Am 24. Oktober 2017 18:46:21 MESZ schrieb "Berrigan, Patrick M" 
<patrick.berri...@mantech.com>:
>The systems are not up to date. For example I take one brand newly
>deployed CentOS 7 machine and run a yum update and I see about 200 MB
>worth of packages that need to be updated. If I take that same machine
>and register it with the Spacewalk server that has updated repos from
>the same repos listed in /etc/yum.repos.d/ it shows No packages marked
>for update.
>
>
>
>
>VR,
>
>Patrick Berrigan
>Systems Engineer
>ManTech International Corporation
>patrick.berri...@mantech.com
>COMM (703) 654-9149
>
>
>-Original Message-
>From: Robert Paschedag [mailto:robert.pasche...@web.de]
>Sent: Tuesday, October 24, 2017 12:01 AM
>To: spacewalk-list@redhat.com; Berrigan, Patrick M
><patrick.berri...@mantech.com>; spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] SpaceWalk 2.7 no updates available in GUI
>no updates on clientss
>
>Am 23. Oktober 2017 19:15:48 MESZ schrieb "Berrigan, Patrick M"
><patrick.berri...@mantech.com>:
>>Currently running CentOS7.
>>
>>I am having an issue where my SpaceWalk server is not displaying any
>>updates being available for my clients. I only have two clients, a
>>Syslog server and the spacewalk server itself. Both are registered in
>>spacewalk and performing a yum repolist shows that they are subscribed
>>to the correct channels. The repos in the channel are populating
>>correctly as I can see the package count increase as the nightly syncs
>>finish. I have restarted taskomatic and have ensured that the name in
>>up2date matches the cert of the SpaceWalk server.
>>
>>I have also increased the max java memory to 3GB after checking the
>log
>>of rhn_taskomatic_daemon. There wasn't any errors about memory but I
>>read that this sometimes is the cause.
>>
>>OSAD works normally on both clients as I can run simple reboot
>commands
>>from the SpaceWalk web GUI.
>>
>>Anyone else have any thoughts on resolving this issue?
>>
>>VR,
>>
>>Patrick Berrigan
>>Systems Engineer
>>ManTech International Corporation
>>patrick.berri...@mantech.com
>>COMM (703) 654-9149
>>
>>
>>
>>
>>This e-mail and any attachments are intended only for the use of the
>>addressee(s) named herein and may contain proprietary information. If
>>you are not the intended recipient of this e-mail or believe that you
>>received this email in error, please take immediate action to notify
>>the sender of the apparent error by reply e-mail; permanently delete
>>the e-mail and any attachments from your computer; and do not
>>disseminate, distribute, use, or copy this message and any
>attachments.
>
>Are there any packages listed as "installed" for the registered
>systems?
>
>Run a "rhn-profile-sync -" on a client. This should update the
>package list from the client on the server.
>
>Also look at the task schedules in "Admin" - "Task Schedule" if all
>tasks have run AND ended within the last day.
>
>Edit:
>
>Ah... Just remember...I think there was a bug in c3po package which
>"might" cause this and must be downgraded on CentOS 7. Please search
>the mailing list archives for that package
>
>
>
>This e-mail and any attachments are intended only for the use of the
>addressee(s) named herein and may contain proprietary information. If
>you are not the intended recipient of this e-mail or believe that you
>received this email in error, please take immediate action to notify
>the sender of the apparent error by reply e-mail; permanently delete
>the e-mail and any attachments from your computer; and do not
>disseminate, distribute, use, or copy this message and any attachments.
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Ok. But this is why I think some task is not running correctly. It does not 
finish.

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

Re: [Spacewalk-list] SpaceWalk 2.7 no updates available in GUI no updates on clientss

[Robert Paschedag]

Am 23. Oktober 2017 19:15:48 MESZ schrieb "Berrigan, Patrick M" 
:
>Currently running CentOS7.
>
>I am having an issue where my SpaceWalk server is not displaying any
>updates being available for my clients. I only have two clients, a
>Syslog server and the spacewalk server itself. Both are registered in
>spacewalk and performing a yum repolist shows that they are subscribed
>to the correct channels. The repos in the channel are populating
>correctly as I can see the package count increase as the nightly syncs
>finish. I have restarted taskomatic and have ensured that the name in
>up2date matches the cert of the SpaceWalk server.
>
>I have also increased the max java memory to 3GB after checking the log
>of rhn_taskomatic_daemon. There wasn't any errors about memory but I
>read that this sometimes is the cause.
>
>OSAD works normally on both clients as I can run simple reboot commands
>from the SpaceWalk web GUI.
>
>Anyone else have any thoughts on resolving this issue?
>
>VR,
>
>Patrick Berrigan
>Systems Engineer
>ManTech International Corporation
>patrick.berri...@mantech.com
>COMM (703) 654-9149
>
>
>
>
>This e-mail and any attachments are intended only for the use of the
>addressee(s) named herein and may contain proprietary information. If
>you are not the intended recipient of this e-mail or believe that you
>received this email in error, please take immediate action to notify
>the sender of the apparent error by reply e-mail; permanently delete
>the e-mail and any attachments from your computer; and do not
>disseminate, distribute, use, or copy this message and any attachments.

Are there any packages listed as "installed" for the registered systems?

Run a "rhn-profile-sync -" on a client. This should update the package list 
from the client on the server.

Also look at the task schedules in "Admin" - "Task Schedule" if all tasks have 
run AND ended within the last day.

Edit:

Ah... Just remember...I think there was a bug in c3po package which "might" 
cause this and must be downgraded on CentOS 7. Please search the mailing list 
archives for that package

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

Re: [Spacewalk-list] Problems with Debian Stretch on SW 2.7. Can reinstall packages over and over again

[Robert Paschedag]

On 10/16/17 21:25, Paul-Andre Panon wrote:

On Saturday, October 14, 2017 12:02 AM, Robert Paschedag 
[mailto:robert.pasche...@web.de] wrote:

Am 14. Oktober 2017 01:38:59 MESZ schrieb Paul-Andre Panon 
<paul-andre.pa...@avigilon.com>:

On Fri, 13 Oct 2017 19:17:12, Robert Paschedag

Hi Robert,

I can confirm that. I've been experiencing the same thing with Ubuntu
14 clients last month and Ubuntu 16 clients this month. The python
packages had updated and attempts to update kept on cycling through
with the same packages identified as needing updates, until I went
through and manually copied the Multi-Arch: allowed settings for the
packages that had it (looking at the Packages on the Ubuntu repos). I
was thinking of doing what you propose but I've been to busy to dig
into the code to try to add the Multi-Arch field to the copied data. I
look forward to your changes.

Paul-Andre Panon
Senior systems administrator


Hi Paul-Andre,

the big problem is... "allowed" is not the only value for Multi-Arch. In Debian stretch 
"main" repo, there are 8979 Packages with "Multi-Arch" header. No way to do that by hand.

Agreed, but so far I have only had problems with packages where the missing Multi-Arch value is 
"allowed". Maybe I've just been lucky though. The annoying thing is that, even with the ~couple 
dozen cases of "Multi-Arch: allowed" in the Ubuntu main and universe repos (mostly from python and 
the gcc toolchain), every sync wipes out your last set of manual fixes.  When I ran into the problem, I found 
the clue to a workaround in matus' Jan 30th 2015 comment at 
http://www.devops-blog.net/spacewalk/registering-ubuntu-and-debian-servers-with-spacewalk, so this isn't a 
new issue. I'm not happy with his kludgy "fix" though since it also winds up adding that property 
to many packages where it doesn't apply.
Yeah. I'm also using that workaround from the bugzilla report about the 
missing Multi-Arch headers and in jessie, this really works quite good.
Now, with "stretch", this is just a nightmare. I was so happy, that now 
in SW2.7, the debian version string parsing has been improved and now 
debian has "improved" "apt". But that improvement somehow throws a big 
stick between your legs while you're running at max speed, causing you 
to crash and break with your face on the ground :-P





Another thing. I hope you can give me a hint. Apt now tries (or even just generates) 
"binary-all" package files for all "amd64" repos, the client has subscribed.
How can I stop that? All "architecture" settings are set to "amd64". Don't know, where 
this *feature* came from but it looks like breaking my "workaround" I'm trying to implement.

I'm not sure, we've only been using the 64-bit amd64 images, not the 32-bit 
i386 images. When I look at the Packages file on the binary-amd64 Ubuntu 
directory from the closest mirror, there doesn't seem to be a package with 
something other than Architecture: amd64 . Since we've been all 64-bit it 
hasn't been an issue for us, and maybe that's why I'm not having any issues 
with other possible values of Multi-Arch as well.


Thanks
Robert

Paul-Andre Panon
Senior systems administrator

Office: 604.629.5182 ext 2341 Mobile: 604.679.1617


I found the "error". It is really because of the "missing" "Release" 
file. If this is found, and there is an "Architectures:" header, the new 
"apt" will download the Packages for this architectures. If the 
"Release" is missing, "apt" will download the Packages for the clients 
configured "architectures" + "all".


This is a new behaviour.

But I think, that this is not my main error. Because I'm still using 
Steve Meier's "debian sync" tool to download and import the debian 
packages, I modified that to create a "temporary" file with the 
"package" name and possible "multi-arch" header, which I can insert, 
after SW has created his own "Packages" file.


But this does not yet work 100%, because there are sometimes more than 
one package with exact same name. I have to improve that and keep trying.


Really the best thing would be, if the "Multi-Arch" header would be 
added to the database. If I'm right, this header is already "present", 
while the .deb files gets parsed but it just gets ignored. And I don't 
know, how much work and modification is needed to fully implement this 
header to every .deb package.


Would be cool, if the main developers of SW could look into that issue 
and I'll really try to support them with as much information as possible 
to get this fixed.


As final information. This is not an error in SW. This is "an 
improvement" in Debian 9, which most of us (and I think most of SW 
developers) just did not get but its a major problem to "manage" debian 
9 with spacewalk.


Robert


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

Re: [Spacewalk-list] Problems with Debian Stretch on SW 2.7. Can reinstall packages over and over again

[Robert Paschedag]

Am 14. Oktober 2017 01:38:59 MESZ schrieb Paul-Andre Panon 
<paul-andre.pa...@avigilon.com>:
>On Fri, 13 Oct 2017 19:17:12, Robert Paschedag
><robert.pasche...@web.de> wrote:
>>
>>Hi all,
>>
>>after fixing my problems with the errata import, I found another
>problem with Debian...especially with
>>
>>Debian "stretch" and SW 2.7. At least, I did not yet see a major (or
>even minor) error with Debian jessie on SW 2.7
>>
>>I can successfully deploy a Debian stretch system via SW 2.7, register
>
>>it and install packages.
>>
>>The "installed" packages on the client is reported to SW. No problem
>so far.
>>
>>But, even if SW reports, that there are no newer packages in SW for
>the 
>>client, and I have done
>>
>>"apt-get upgrade" several times, the "client" does not recognize, that
>a 
>>particular package
>>
>
>Hi Robert,
>
>I can confirm that. I've been experiencing the same thing with Ubuntu
>14 clients last month and Ubuntu 16 clients this month. The python
>packages had updated and attempts to update kept on cycling through
>with the same packages identified as needing updates, until I went
>through and manually copied the Multi-Arch: allowed settings for the
>packages that had it (looking at the Packages on the Ubuntu repos). I
>was thinking of doing what you propose but I've been to busy to dig
>into the code to try to add the Multi-Arch field to the copied data. I
>look forward to your changes.
>
>Paul-Andre Panon
>Senior systems administrator
>
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Hi Paul-Andre,

the big problem is... "allowed" is not the only value for Multi-Arch. In Debian 
stretch "main" repo, there are 8979 Packages with "Multi-Arch" header. No way 
to do that by hand.

Another thing. I hope you can give me a hint. Apt now tries (or even just 
generates) "binary-all" package files for all "amd64" repos, the client has 
subscribed.

How can I stop that? All "architecture" settings are set to "amd64". Don't 
know, where this *feature* came from but it looks like breaking my "workaround" 
I'm trying to implement.

Thanks
Robert

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

Re: [Spacewalk-list] Problems with Debian Stretch on SW 2.7. Can reinstall packages over and over again

[Robert Paschedag]

ok. Couldn't sit still. Tested the "Multi-Arch" header on stretch, 
andthat seems to work


Using the Packages.gz file created by spacewalk, I can install "alex" 
over and over again


root@stretch:/tmp# dpkg -l alex
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  alex   3.1.7-4  amd64lexical analyser generator 
for Ha

root@stretch:/tmp# apt-get install alex
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  alex
1 upgraded, 0 newly installed, 0 to remove and 358 not upgraded.
Need to get 0 B/605 kB of archives.
After this operation, 0 B of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  alex
Authentication warning overridden.
(Reading database ... 43532 files and directories currently installed.)
Preparing to unpack .../alex_3.1.7-4_amd64.deb ...
Unpacking alex (3.1.7-4) over (3.1.7-4) ...
Setting up alex (3.1.7-4) ...
Processing triggers for man-db (2.7.6.1-2) ...
Apt-Spacewalk: Updating package profile
root@stretch:/tmp# apt-get install alex
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  alex
1 upgraded, 0 newly installed, 0 to remove and 358 not upgraded.
Need to get 0 B/605 kB of archives.
After this operation, 0 B of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  alex
Authentication warning overridden.
(Reading database ... 43532 files and directories currently installed.)
Preparing to unpack .../alex_3.1.7-4_amd64.deb ...
Unpacking alex (3.1.7-4) over (3.1.7-4) ...
Setting up alex (3.1.7-4) ...
Processing triggers for man-db (2.7.6.1-2) ...
Apt-Spacewalk: Updating package profile
root@stretch:/tmp#

Now changing /var/lib/apt/lists/ and add

"Multi-Arch: foreign"

as included in "control" of "alex" package, results in

root@stretch:/tmp# apt-get install alex
Reading package lists... Done
Building dependency tree
Reading state information... Done
alex is already the newest version (3.1.7-4).
0 upgraded, 0 newly installed, 0 to remove and 358 not upgraded.
root@stretch:/tmp#

If I remove the "Multi-Arch" header again, the old behaviour just returns.


So I think, including the "Multi-Arch" header for the package into the 
database is a must have to support "stretch".


But maybe I just have a strange error and someone can give me a hint.

I still have to test that with *all* packages.

Regards,

Robert



On 10/13/17 21:17, Robert Paschedag wrote:

Hi all,

after fixing my problems with the errata import, I found another 
problem with Debian...especially with


Debian "stretch" and SW 2.7. At least, I did not yet see a major (or 
even minor) error with Debian jessie on SW 2.7



I can successfully deploy a Debian stretch system via SW 2.7, register 
it and install packages.


The "installed" packages on the client is reported to SW. No problem 
so far.



But, even if SW reports, that there are no newer packages in SW for 
the client, and I have done


"apt-get upgrade" several times, the "client" does not recognize, that 
a particular package


is already installed. I can install (for example "adduser") with

"apt-get install adduser"

over and over again. It does not tell.."that package is already 
installed with the newest version"


The client also reports, that it installes the "same" version above 
"the already" installed version of this package.



So, for example, my freshly installed debian system has 372 packages. 
After installation, "apt-get upgrade", it "always" upgrades about 260 
packages again and again and again.



Also after applying 
https://github.com/spacewalkproject/spacewalk/wiki/DebianUbuntuSupportIn27


on the client. It does not change. What is changed then, if that the 
"installed" packages is correctly "reflected" in the SW WebUI for that 
system.


I *think*, that the problem is located on the client, especially in 
the "improvement of apt" in Debian 9 (see 
https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#apt-improvements 
and https://wiki.debian.org/DebianRepository/Format )


...

If the following fields exist in the control file of a .deb file they 
also must exist in the record about the package in the Packages file 
and the value must match /exactly/ or a client might recognize a 
metadata mismatch and redownloads/reinstalls a package:


 * Depends et al
 * Installed-S

[Spacewalk-list] Problems with Debian Stretch on SW 2.7. Can reinstall packages over and over again

[Robert Paschedag]

Hi all,

after fixing my problems with the errata import, I found another problem 
with Debian...especially with


Debian "stretch" and SW 2.7. At least, I did not yet see a major (or 
even minor) error with Debian jessie on SW 2.7



I can successfully deploy a Debian stretch system via SW 2.7, register 
it and install packages.


The "installed" packages on the client is reported to SW. No problem so far.


But, even if SW reports, that there are no newer packages in SW for the 
client, and I have done


"apt-get upgrade" several times, the "client" does not recognize, that a 
particular package


is already installed. I can install (for example "adduser") with

"apt-get install adduser"

over and over again. It does not tell.."that package is already 
installed with the newest version"


The client also reports, that it installes the "same" version above "the 
already" installed version of this package.



So, for example, my freshly installed debian system has 372 packages. 
After installation, "apt-get upgrade", it "always" upgrades about 260 
packages again and again and again.



Also after applying 
https://github.com/spacewalkproject/spacewalk/wiki/DebianUbuntuSupportIn27


on the client. It does not change. What is changed then, if that the 
"installed" packages is correctly "reflected" in the SW WebUI for that 
system.


I *think*, that the problem is located on the client, especially in the 
"improvement of apt" in Debian 9 (see 
https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#apt-improvements 
and https://wiki.debian.org/DebianRepository/Format )


...

If the following fields exist in the control file of a .deb file they 
also must exist in the record about the package in the Packages file and 
the value must match /exactly/ or a client might recognize a metadata 
mismatch and redownloads/reinstalls a package:


 * Depends et al
 * Installed-Size
 * Multi-Arch

...

I know that the "Multi-Arch" header is not written to the packages list 
(see https://bugzilla.redhat.com/show_bug.cgi?id=1243387) and the 
workaround mentioned there (that I use for debian jessie) does not work 
here. The "Multi-Arch" header often has different values.



I just want to know, if anybody can confirm this behavior.


Next time I'm in the office, I'll try to modify the packages list to add 
the "Multi-Arch" headers (and their) values to the packages list and 
see, if this is really the problem.



Kind regards,

Robert


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

Re: [Spacewalk-list] Auto-deploying renewed cert

[Robert Paschedag]

Am 5. Oktober 2017 21:14:28 MESZ schrieb Daryl Rose :
>Avi,
>
>
>I'm using a signed cert, not the self-signed cert that is created on
>installation.  The signed cert will expire at the end of the year.
>
>
>Daryl
>
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of Avi Miller
>
>Sent: Thursday, October 5, 2017 1:37 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Auto-deploying renewed cert
>
>Hi,
>
>
>> On 5 Oct 2017, at 10:52 am, Daryl Rose  wrote:
>>
>> To the best of my knowledge, the CA is not changing.  So, even though
>the cert expires, I don't have to push out a new cert with the updated
>expiration date? That would be great.
>
>Correct. The certificate that is pushed out to clients is the Spacewalk
>CA certificate (which is self-signed by default), so if that doesn't
>change, there's nothing to update.
>
>Cheers,
>Avio
>
>--
>Oracle 
>Oracle | Integrated Cloud Applications and Platform
>Services
>www.oracle.com
>Oracle offers a comprehensive and fully integrated stack of cloud
>applications and platform services.
>
>
>
>Avi Miller | Product Management Director | +61 (3) 8616 3496
>Oracle Linux and Virtualization
>417 St Kilda Road, Melbourne, Victoria 3004 Australia
>
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list
>Spacewalk-list Info Page - Red
>Hat
>www.redhat.com
>Red Hat Linux is the centerpiece of a complete solution that includes
>software, support, training, and services. We feature a broad range of
>solutions to serve a ...

I'm not sure, if we are talking about the same certs. So I define some 
statements.

Server cert: the certificate your spacewalk webserver uses and which you see 
when you go to the "admin" page.

CA cert: this is the cert, that signed the "server cert". This is the cert, 
that has to be deployed (and currently "is" deployed)  to all your SW clients.

Now which expires? The "ca cert" or the "server cert"?

If "server cert", then renew it and you're done.

If "ca cert", you have to deploy that to the clients.

Robert



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

Re: [Spacewalk-list] Importing errata from RPM channel failes with ERROR: 'list' object has no attribute 'keys'

[Robert Paschedag]

Hmm...still don't know, why this errata is parsed different right now. Within the updateinfo.xml.gz, this one (for examle) is imported correctly (as it looks)

 


  maint-co...@suse.de" status="stable" type="security" version="2740">
    sdksp1-tomcat6
    Security update for tomcat6
    SUSE Linux Enterprise Software Development Kit 11 SP1
    
    
  https://bugzilla.novell.com/show_bug.cgi?id=622188" id="622188" title="bug number 622188" type="bugzilla" />
  https://bugzilla.novell.com/show_bug.cgi?id=599554" id="599554" title="bug number 599554" type="bugzilla" />
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2227" id="CVE-2010-2227" title="CVE-2010-2227" type="cve" />
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1157" id="CVE-2010-1157" title="CVE-2010-1157" type="cve" />
    
    
This update of tomcat fixes denial of service and information disclosure
vulnerabilities which could potentially be exploited by remote attackers to
crash tomcat or to obtain sensitive information (CVE-2010-2227,
CVE-2010-1157).

Security Issues:


    * CVE-2010-2227
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2227
    * CVE-2010-1157
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1157


    
  
    
  tomcat6-6.0.18-20.5.1.noarch.rpm
    
    
  tomcat6-admin-webapps-6.0.18-20.5.1.noarch.rpm
    
    
  tomcat6-docs-webapp-6.0.18-20.5.1.noarch.rpm
    
    
  tomcat6-javadoc-6.0.18-20.5.1.noarch.rpm
    
    
  tomcat6-jsp-2_1-api-6.0.18-20.5.1.noarch.rpm
    
    
  tomcat6-lib-6.0.18-20.5.1.noarch.rpm
    
    
  tomcat6-servlet-2_5-api-6.0.18-20.5.1.noarch.rpm
    
    
  tomcat6-webapps-6.0.18-20.5.1.noarch.rpm
    
  
    
  

 

But this one not. In the errata above (and all others?), "erratum['packages']" is a "dict()". And in the one below, it is a "list()", causing the error.

 


  maint-co...@suse.de" status="stable" type="recommended" version="4361">
    sdksp1-tomcat6
    Recommended update for tomcat6
    SUSE Linux Enterprise Software Development Kit 11 SP1
    
    
  https://bugzilla.novell.com/show_bug.cgi?id=681914" id="681914" title="bug number 681914" type="bugzilla" />
    
    
This update fixes the _expression_ Language parser.

The parser was previously unable parse expressions without additional
whitespaces - like '${not(true)}'. This is addressed in apache bug #45511.
And the last character of namespace is lost during a parsing, which makes
this feature unusable. This is apache bug #45648. Both issues are fixed by
this update.


    
  
    
  tomcat6-6.0.18-20.23.1.noarch.rpm
    
    
  tomcat6-admin-webapps-6.0.18-20.23.1.noarch.rpm
    
    
  tomcat6-docs-webapp-6.0.18-20.23.1.noarch.rpm
    
    
  tomcat6-javadoc-6.0.18-20.23.1.noarch.rpm
    
    
  tomcat6-jsp-2_1-api-6.0.18-20.23.1.noarch.rpm
    


      tomcat6-lib-6.0.18-20.23.1.noarch.rpm
    
    
  tomcat6-servlet-2_5-api-6.0.18-20.23.1.noarch.rpm
    
    
  tomcat6-webapps-6.0.18-20.23.1.noarch.rpm
    
  
    
  
 

 



 

Gesendet: Donnerstag, 28. September 2017 um 15:06 Uhr
Von: "Robert Paschedag" <robert.pasche...@web.de>
An: "Paul Robert Marino" <prmari...@gmail.com>
Cc: "spacewalk-list@redhat.com" <spacewalk-list@redhat.com>
Betreff: Re: [Spacewalk-list] Importing errata from RPM channel failes with ERROR: 'list' object has no attribute 'keys'




this is exactly what I have done. This is a test system and I ran nightly because of PR500 (debian and ubuntu package version handling) and that is what I have tested. Now that 2.7 has been released, I wanted to upgrade to the "release" and test all other stuff.

 

Nohad started debugging and located the error in some "old" erratas.

 

Sorry for long output. But this is the line in "errataImport.py", where the error occures. As you can see in this "one" errata I debugged now, "packages" is truely a "list" of "IncompletePackage" instances and not a "dict".

 

263 # 'package in erratum['packages'].values()' here. But for (to me) unknown
264 # reason it sometimes has package.id == None which makes whole import fail.
265 # And self.packages[nevrao].id contains always right value.
266 for nevrao in erratum['packages'].keys():
(Pdb) p erratum
['maint-co...@suse.d

Re: [Spacewalk-list] Importing errata from RPM channel failes with ERROR: 'list' object has no attribute 'keys'

[Robert Paschedag]

this is exactly what I have done. This is a test system and I ran nightly because of PR500 (debian and ubuntu package version handling) and that is what I have tested. Now that 2.7 has been released, I wanted to upgrade to the "release" and test all other stuff.

 

Nohad started debugging and located the error in some "old" erratas.

 

Sorry for long output. But this is the line in "errataImport.py", where the error occures. As you can see in this "one" errata I debugged now, "packages" is truely a "list" of "IncompletePackage" instances and not a "dict".

 

263 # 'package in erratum['packages'].values()' here. But for (to me) unknown
264 # reason it sometimes has package.id == None which makes whole import fail.
265 # And self.packages[nevrao].id contains always right value.
266 for nevrao in erratum['packages'].keys():
(Pdb) p erratum
['maint-co...@suse.de', 'locally_modified': None, 'refers_to': None, 'solution': ' ', 'topic': ' ', 'last_modified': None, 'keywords': [],

 

list starts...

 

'packages': [[

 

list ended...

 

 'files': [], 'advisory_type': 'Bug Fix Advisory', 'issue_date': '2011-04-12 14:42:21', 'notes': '', 'org_id': 1, 'bugs': [[

...


 

I wil try to remove that errata (and following, that break the import) and see, if this is "reimported" correctly.

 

Robert

 


Gesendet: Donnerstag, 28. September 2017 um 14:12 Uhr
Von: "Paul Robert Marino" <prmari...@gmail.com>
An: "Robert Paschedag" <robert.pasche...@web.de>
Cc: "spacewalk-list@redhat.com" <spacewalk-list@redhat.com>
Betreff: Re: Re: [Spacewalk-list] Importing errata from RPM channel failes with ERROR: 'list' object has no attribute 'keys'


well and that may be the root of your problem. you should never run the nightly version in production! Only run the nightly version in a QA/Dev environment here you are specifically testing for the next release of spacewalk. if you run the nightly version in production you are asking for things to break, while in theory you should be able to upgrade fom a nightly to a new release that doesn't mean that damage done by a broken nightly version will corrected.
the only time i ever run a nightly build is when I'm trying to test prior to a new release or if i wrote a patch and want to test it against the latest version of the code, and when i do it is usually an instance on a VM that manages a few other VM's just to test functionality.


 
On Thu, Sep 28, 2017 at 6:49 AM, Robert Paschedag <robert.pasche...@web.de> wrote:

Damnlooks like I got this error before upgrading to 2.7 release. Went back to snapshot (with 2.7 nightly) and this error is present. Will start to debug this.

> Gesendet: Donnerstag, 28. September 2017 um 08:31 Uhr
> Von: "Robert Paschedag" <robert.pasche...@web.de>
> An: spacewalk-list@redhat.com, "Paul Robert Marino" <prmari...@gmail.com>, "Spacewalk Userlist" <spacewalk-list@redhat.com>
> Betreff: Re: [Spacewalk-list] Importing errata from RPM channel failes with ERROR: 'list' object has no attribute 'keys'

>
> Am 27. September 2017 23:58:29 MESZ schrieb Paul Robert Marino <prmari...@gmail.com>:
> >___
> >Spacewalk-list mailing list
> >Spacewalk-list@redhat.com
> >https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> This is 2.7. Just upgraded from nightly. But I'm not sure, if I had this error within nightly as I was testing other stuff all time.
>
>
> ___
> 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] Importing errata from RPM channel failes with ERROR: 'list' object has no attribute 'keys'

[Robert Paschedag]

Damnlooks like I got this error before upgrading to 2.7 release. Went back 
to snapshot (with 2.7 nightly) and this error is present. Will start to debug 
this.

> Gesendet: Donnerstag, 28. September 2017 um 08:31 Uhr
> Von: "Robert Paschedag" <robert.pasche...@web.de>
> An: spacewalk-list@redhat.com, "Paul Robert Marino" <prmari...@gmail.com>, 
> "Spacewalk Userlist" <spacewalk-list@redhat.com>
> Betreff: Re: [Spacewalk-list] Importing errata from RPM channel failes with 
> ERROR: 'list' object has no attribute 'keys'
>
> Am 27. September 2017 23:58:29 MESZ schrieb Paul Robert Marino 
> <prmari...@gmail.com>:
> >___
> >Spacewalk-list mailing list
> >Spacewalk-list@redhat.com
> >https://www.redhat.com/mailman/listinfo/spacewalk-list
> 
> This is 2.7. Just upgraded from nightly. But I'm not sure, if I had this 
> error within nightly as I was testing other stuff all time.
> 
> 
> ___
> 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] Importing errata from RPM channel failes with ERROR: 'list' object has no attribute 'keys'

[Robert Paschedag]

Am 27. September 2017 23:58:29 MESZ schrieb Paul Robert Marino 
:
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

This is 2.7. Just upgraded from nightly. But I'm not sure, if I had this error 
within nightly as I was testing other stuff all time.


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

Re: [Spacewalk-list] How to Sync SLES 11/12 in Spacewalk

[Robert Paschedag]

Am 22. September 2017 16:22:56 MESZ schrieb "Arumugam, Saravanan(Aswath)" 
:
>
>Hello,
>
>I have Spacewalk 2.6 version and I am Using Spacewalk to Sync
>OEL/CentOS/Ubuntu/RHEL Already.
>
>I'm trying to Sync SLES Channels, But seems I am not able to Sync due
>to new Token Authentication.
>
>Is there any way I can use spacewalk to sync the SUSE Channels to my
>existing Setup.
>
>P.S : got some Archives links to spacewalk sync SLES - But I was not
>able to sync or make it work.
>
>Thank You,
>Saravanan Arumugam
>
>
>Confidentiality Notice: This message is private and may contain
>confidential and proprietary information. If you have received this
>message in error, please notify us and remove it from your system and
>note that you must not copy, distribute or take any action in reliance
>on it. Any unauthorized use or disclosure of the contents of this
>message is not permitted and may be unlawful.
>
>
>Confidentiality Notice: This message is private and may contain
>confidential and proprietary information. If you have received this
>message in error, please notify us and remove it from your system and
>note that you must not copy, distribute or take any action in reliance
>on it. Any unauthorized use or disclosure of the contents of this
>message is not permitted and may be unlawful.

You need an smt server that syncs the packages and sync from that. At least, 
this is what I'm currently doing

Robert

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

Re: [Spacewalk-list] How to Sync SLES 11/12 in Spacewalk

[Robert Paschedag]

Am 22. September 2017 16:59:35 MESZ schrieb "Flores, Javier (D4\INF\IT ID)" 
:
>Hi
>
>What worked best for me is to just setup a SLES server and register to
>scc.suse.com.
>
>After finishing, just use "zypper lr --uri" to show the URL to the
>repo. Copy that URL to spacewalk.
>
>Regards,
>Javier
>
>Von: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Arumugam,
>Saravanan(Aswath)
>Gesendet: Freitag, 22. September 2017 16:23
>An: Arumugam, Saravanan(Aswath); spacewalk-list@redhat.com
>Betreff: Re: [Spacewalk-list] How to Sync SLES 11/12 in Spacewalk
>
>
>Hello,
>
>I have Spacewalk 2.6 version and I am Using Spacewalk to Sync
>OEL/CentOS/Ubuntu/RHEL Already.
>
>I'm trying to Sync SLES Channels, But seems I am not able to Sync due
>to new Token Authentication.
>
>Is there any way I can use spacewalk to sync the SUSE Channels to my
>existing Setup.
>
>P.S : got some Archives links to spacewalk sync SLES - But I was not
>able to sync or make it work.
>
>Thank You,
>Saravanan Arumugam
>
>
>Confidentiality Notice: This message is private and may contain
>confidential and proprietary information. If you have received this
>message in error, please notify us and remove it from your system and
>note that you must not copy, distribute or take any action in reliance
>on it. Any unauthorized use or disclosure of the contents of this
>message is not permitted and may be unlawful.
>
>Confidentiality Notice: This message is private and may contain
>confidential and proprietary information. If you have received this
>message in error, please notify us and remove it from your system and
>note that you must not copy, distribute or take any action in reliance
>on it. Any unauthorized use or disclosure of the contents of this
>message is not permitted and may be unlawful.

Hmmm... Have to give this a try...

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

Re: [Spacewalk-list] osa-dispatcher dies shortly after starting [SEC=UNOFFICIAL]

[Robert Paschedag]

Am 19. September 2017 02:15:10 MESZ schrieb Jonathan Payne 
:
>Additional debug shows the following in osa-dispatcher:
>
><-- 'jabber:iq:roster' >subscription='to' />subscription='to' />subscription='to' />subscription='to' />subscription='to' />subscription='to' />subscription='to' />
>
><-- id='texv6hlicjon2s1ele1cst0zq28ux8krmimtz8bc'>'jabber:iq:roster' >subscription='both' />
>
>--> 'jabber:iq:roster'  />
>
><-- id='r00us18egaq83r8ttgorp9ibr54qdg35g3z957nl'>'jabber:iq:roster' >subscription='both' />
>
><-- id='rvh4518kr3dw1cj29f9ez20xo92ex6np14u762rx'>'jabber:iq:roster' >subscription='both' />
>
><-- id='65u7heaquj4tl5raftod0c22gw9nz1l56gdounfp'>'jabber:iq:roster' >subscription='both' />
>
><-- id='jqxob49tlib3dzrn04townj807aoyihh8e5kjfd4'>'jabber:iq:roster' >subscription='both' />
>
><-- id='presence-088791-33'
>to='rhn-dispatcher-sat@SPACEWALKSERVER/superclient' />
>
>--> id='presence-088791-33' />
>
><-- 'jabber:iq:roster' >subscription='to' />subscription='both' />subscription='both' />subscription='both' />subscription='both' />subscription='both' />subscription='to' />
>
><-- id='l3ey7ycp9eljg1wmwxypgealw91g1cmng0lozyd8'>'jabber:iq:roster' >subscription='both' />
>
>--> 'jabber:iq:roster'  />
>
><-- 'jabber:iq:roster' >subscription='both' />subscription='both' />subscription='both' />subscription='both' />subscription='both' />subscription='both' />subscription='to' />
>
>--> 'jabber:iq:roster'  />
>
><-- id='presence-6458c3-47'
>to='rhn-dispatcher-sat@SPACEWALKSERVER/superclient' />
>
>--> id='presence-6458c3-47' />
>
>Spacewalk 18579 2017/09/18 17:49:47 -06:00: ('Error caught:',)
>
>ERROR: unhandled exception occurred: (can't write str to text stream).
>
>
>
>I don’t see any errors in /var/log/messages relating to jabberd, just
>the usual:
>
>Sep 18 17:42:52 spacewalk2 jabberd/sm[18460]: [SPACEWALKSERVER]
>configured
>Sep 18 17:42:52 spacewalk2 jabberd/sm[18460]: attempting connection to
>router at ::1, port=5347
>Sep 18 17:42:52 spacewalk2 jabberd/router[18452]: [::1, port=34632]
>connect
>Sep 18 17:42:52 spacewalk2 jabberd/router[18452]: [::1, port=34632]
>authenticated as jabberd@jabberd-router
>Sep 18 17:42:52 spacewalk2 jabberd/sm[18460]: connection to router
>established
>Sep 18 17:42:52 spacewalk2 jabberd/router[18452]: [SPACEWALKSERVER]
>online (bound to ::1, port 34632)
>Sep 18 17:42:52 spacewalk2 jabberd/c2s[18468]: modules search path:
>/usr/lib64/jabberd
>Sep 18 17:42:52 spacewalk2 jabberd/c2s[18468]: loading 'db' authreg
>module
>Sep 18 17:42:52 spacewalk2 jabberd/c2s[18468]: initialized auth module
>'db'
>Sep 18 17:42:52 spacewalk2 jabberd/c2s[18468]: starting up
>Sep 18 17:42:52 spacewalk2 jabberd/c2s[18468]: process id is 18468,
>written to /var/lib/jabberd/pid/c2s.pid
>Sep 18 17:42:52 spacewalk2 jabberd/sm[18460]: SPACEWALKSERVER ready for
>sessions
>Sep 18 17:42:52 spacewalk2 jabberd/s2s[18476]: starting up (interval=3,
>queue=60, keepalive=0, idle=86400)
>Sep 18 17:42:52 spacewalk2 jabberd/s2s[18476]: process id is 18476,
>written to /var/lib/jabberd/pid/s2s.pid
>Sep 18 17:42:52 spacewalk2 jabberd/s2s[18476]: attempting connection to
>router at ::1, port=5347
>Sep 18 17:42:52 spacewalk2 jabberd/router[18452]: [::1, port=34634]
>connect
>Sep 18 17:42:52 spacewalk2 jabberd/router[18452]: [::1, port=34634]
>authenticated as jabberd@jabberd-router
>Sep 18 17:42:52 spacewalk2 jabberd/s2s[18476]: connection to router
>established
>Sep 18 17:42:52 spacewalk2 jabberd/router[18452]: [s2s] set as default
>route
>Sep 18 17:42:52 spacewalk2 jabberd/router[18452]: [s2s] online (bound
>to ::1, port 34634)
>Sep 18 17:42:53 spacewalk2 jabberd/c2s[18468]: [SPACEWALKSERVER]
>configured; realm=, authreg=db, registration enabled, using
>PEM:/etc/pki/spacewalk/jabberd/server.pem
>Sep 18 17:42:53 spacewalk2 jabberd/c2s[18468]: attempting connection to
>router at ::1, port=5347
>Sep 18 17:42:53 spacewalk2 jabberd/router[18452]: [::1, port=34636]
>connect
>Sep 18 17:42:53 spacewalk2 jabberd/router[18452]: [::1, port=34636]
>authenticated as jabberd@jabberd-router
>Sep 18 17:42:53 spacewalk2 jabberd/c2s[18468]: connection to router
>established
>Sep 18 17:42:53 spacewalk2 jabberd/router[18452]: [c2s] online (bound
>to ::1, port 34636)
>Sep 18 17:42:53 spacewalk2 jabberd/s2s[18476]: [::, port=5269]
>listening for connections
>Sep 18 17:42:53 spacewalk2 jabberd/s2s[18476]: ready for connections
>Sep 18 17:42:53 spacewalk2 jabberd/c2s[18468]: [::, port=5222]
>listening for connections
>Sep 18 17:42:53 spacewalk2 jabberd/c2s[18468]: ready for connections
>Sep 18 17:42:53 spacewalk2 jabberd/c2s[18468]: [7] [:::IPADDRESS,
>port=38292] connect
>Sep 18 17:42:53 spacewalk2 jabberd/c2s[18468]: [7] [:::IPADDRESS,
>port=38292] disconnect jid=unbound, packets: 0, bytes: 163
>Sep 18 17:42:54 spacewalk2 jabberd/c2s[18468]: [7]
>[:::192.168.0.85, port=58130] connect
>Sep 18 17:42:54 spacewalk2 jabberd/c2s[18468]: [7] created user:
>user=osad-8041749890; realm=
>Sep 18 

Re: [Spacewalk-list] Spacewalk and Ubuntu version handling

[Robert Paschedag]

Am 18. September 2017 23:38:14 MESZ schrieb Paul-Andre Panon 
<paul-andre.pa...@avigilon.com>:
>Guten abend Herr Paschedag,
>
>The upgrade documentation wasn't clear, so I wiped out all the
>channels, repos, and orphan packages using
>http://www.hrbac.cz/2017/06/proper-way-to-delete-channelrepositorypackages-in-spacewalk/
>(except for the last step since /srv/satellite is empty, and
>/var/satellite had no symlinks)
>Then I rebuilt my channels and repos, and re-synced the packages from
>the repos. And then for good measure I decided I had made a mistake,
>deleted my security and update channels with combined main/universe
>repos (same cleanup process) and rebuilt them with 1 repo/channel. So
>those channels got cleaned twice :-)
>
>I have a separate file system set up for the Spacewalk var tree, and
>the space usage had gone down significantly during the cleanups
>(90+%=>20+%), with the remaining usage consistent with the CentOS
>channels that were left untouched, so I'm fairly sure they were
>effective. However I'll run any DB queries you might suggest to
>confirm.
>
>Cheers,
>
>Paul-Andre Panon
>Senior systems administrator
>
>Office: 604.629.5182 ext 2341 Mobile: 604.679.1617
>
>
>-Original Message-
>From: Robert Paschedag [mailto:robert.pasche...@web.de] 
>Sent: Saturday, September 16, 2017 2:27 AM
>To: spacewalk-list@redhat.com; Paul-Andre Panon
><paul-andre.pa...@avigilon.com>; spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Spacewalk and Ubuntu version handling
>
>Am 15. September 2017 21:46:56 MESZ schrieb Paul-Andre Panon
><paul-andre.pa...@avigilon.com>:
>>We switched to Spacewalk 2.7 late last week to see how things are 
>>working out with Ubuntu and the PR500 changes. It does seem to have 
>>improved a lot but we're still seeing some issues. We have some
>systems 
>>where Spacewalk appears to recommend upgrading to packages that are 
>>actually a downgrade.
>>
>>Latest Package
>
>>  Installed
>Package
>>compiz-0.9.11+14.04.20140409-0ubuntu1:1.all-deb   
>
>> 
>compiz-0.9.11.3+14.04.20160425-0ubuntu1:1.all-deb
>>compiz-core-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb
>
>> compiz-core-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>>compiz-gnome-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb   
>
>>compiz-gnome-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>>compiz-plugins-default-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb 
>
>>  compiz-plugins-default-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>>gcc-4.9-base-4.9-20140406-0ubuntu1.amd64-deb  
>
>> gcc-4.9-base-4.9.3-0ubuntu4.amd64-deb
>>libcompizconfig0-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb   
>
>> libcompizconfig0-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>>libdecoration0-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb 
>
>>   
>libdecoration0-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>>libgcc1-4.9-20140406-0ubuntu1:1.amd64-deb 
>
>>   libgcc1-4.9.3-0ubuntu4:1.amd64-deb
>>
>>If we select them by accident, the client notices that the packages
>are 
>>a downgrade and refuses to install them. However it does mean that we 
>>have systems being reported as having a number of outstanding patches 
>>when they are actually up to date.
>>
>>Paul-Andre Panon
>>Senior systems administrator
>>
>>Office: 604.629.5182 ext 2341 Mobile: 604.679.1617
>>
>>
>>___
>>Spacewalk-list mailing list
>>Spacewalk-list@redhat.com
>>https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>Did you "fully" remove all packages from spacewalk and synced them
>again before you tried that?
>
>Robert

No... That is exactly what I asked for. It's because the version string parsing 
changed and therefore, ALL packages need to be removed from the database and 
loaded in again.

If you keep the packages and just upgrade to 2.7 nightly, you still have all 
the packages with the old algorithm (and old "wrong" version strings) in the 
database and this can cause such trouble as you described.

That's why I asked.

But if you already did fully wipe all packages and synced them again AND the 
error persists, then we have to dig deeper.

Regards
Robert

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

Re: [Spacewalk-list] Spacewalk and Ubuntu version handling

[Robert Paschedag]

Am 15. September 2017 21:46:56 MESZ schrieb Paul-Andre Panon 
:
>We switched to Spacewalk 2.7 late last week to see how things are
>working out with Ubuntu and the PR500 changes. It does seem to have
>improved a lot but we're still seeing some issues. We have some systems
>where Spacewalk appears to recommend upgrading to packages that are
>actually a downgrade.
>
>Latest Package 
>  Installed Package
>compiz-0.9.11+14.04.20140409-0ubuntu1:1.all-deb
>  compiz-0.9.11.3+14.04.20160425-0ubuntu1:1.all-deb
>compiz-core-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb 
> compiz-core-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>compiz-gnome-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb
>compiz-gnome-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>compiz-plugins-default-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb  
>  compiz-plugins-default-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>gcc-4.9-base-4.9-20140406-0ubuntu1.amd64-deb   
> gcc-4.9-base-4.9.3-0ubuntu4.amd64-deb
>libcompizconfig0-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb
> libcompizconfig0-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>libdecoration0-0.9.11+14.04.20140409-0ubuntu1:1.amd64-deb  
>libdecoration0-0.9.11.3+14.04.20160425-0ubuntu1:1.amd64-deb
>libgcc1-4.9-20140406-0ubuntu1:1.amd64-deb  
>   libgcc1-4.9.3-0ubuntu4:1.amd64-deb
>
>If we select them by accident, the client notices that the packages are
>a downgrade and refuses to install them. However it does mean that we
>have systems being reported as having a number of outstanding patches
>when they are actually up to date.
>
>Paul-Andre Panon
>Senior systems administrator
>
>Office: 604.629.5182 ext 2341 Mobile: 604.679.1617
>
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Did you "fully" remove all packages from spacewalk and synced them again before 
you tried that?

Robert

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

Re: [Spacewalk-list] OSA Dispatcher "conflict" error [SEC=UNCLASSIFIED]

[Robert Paschedag]

Am 12. September 2017 05:13:36 MESZ schrieb Andrew Bergman 
<andrew.berg...@bom.gov.au>:
>I just removed the jabber RPM, reinstalled with a clean slate, ran
>spacewalk-setup-jabberd
>
>Jabberd runs fine using the SSL cert I provided built with the FQDN,
>but again, osa-dispatcher fails with same error.
>
>Maybe I should reinstall osa-dispatcher?
>
>Regards
>
>Andrew 
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Paschedag,
>Robert
>Sent: Monday, 11 September 2017 5:09 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Okay...thenwhat error do you get, when you try to setup jabberd
>from scratch (via the setup script) and ".dist" files?
>
>
>
>-Ursprüngliche Nachricht-
>Von: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Andrew
>Bergman
>Gesendet: Montag, 11. September 2017 08:39
>An: spacewalk-list@redhat.com
>Betreff: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>There is no clients using this - I adopted this spacewalk server which
>had been built by someone who did not understand Spacewalk/Satellite. 
>It was a glorified yum repository with a pretty front end.  Most
>functionality didn't work and it wasn't even receiving updates
>properly.
>
>I fixed all that up and now am at the point of getting OSA Dispatcher
>and OSAD working on clients when I discover that since I upgraded to
>2.6 OSA Dispatcher has failed to start.
>
>None of the clients have OSAD installed and nor can they hit port 5222
>due to firewall rules.
>
>The only error we get is when we try to start OSA Dispatcher.
>
>Regards
>
>Andrew
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Paschedag,
>Robert
>Sent: Monday, 11 September 2017 4:35 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Hmma hard one.
>
>What errors do you get on the "client" side?
>
>
>-Ursprüngliche Nachricht-
>Von: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Andrew
>Bergman
>Gesendet: Montag, 11. September 2017 07:43
>An: spacewalk-list@redhat.com
>Betreff: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Trust me, that was the first thing I tried ;)
>
>-Original Message-
>From: Robert Paschedag [mailto:robert.pasche...@web.de]
>Sent: Monday, 11 September 2017 3:33 PM
>To: spacewalk-list@redhat.com; Andrew Bergman;
>spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Am 11. September 2017 02:55:54 MESZ schrieb Andrew Bergman
><andrew.berg...@bom.gov.au>:
>>There are other ID's in the logs that are osad related.  Looking at
>the 
>>logs that's the one in the request when the conflict occurs:
>>
>>[root@sdcvp-spacewalk01 jabberd]# osa-dispatcher -N -vvv
>>--> >to='sdcvp-spacewalk01.bom.gov.au' xmlns='jabber:client'
>>xmlns:stream='https://emea01.safelinks.protection.outlook.com/?url=http
>>%3A%2F%2Fetherx.jabber.org%2Fstreams=02%7C01%7CPaschedag.Netlution
>>%40swr.de%7C066e91b3227745d69c5908d4f8d8f846%7Cbcca095d88d442f88260cc21
>>6b81f62d%7C0%7C0%7C636407058161574802=bE%2BPcIfY6%2BOZfhh5AYInJpu
>>z5vUHs3JSU5rcJdv5OX0%3D=0' version='1.0'>
>>
>><-- 'https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Faffinix.com%2Fjabber%2Faddress=02%7C01%7CPaschedag.Netlution%40swr.de%7C066e91b3227745d69c5908d4f8d8f846%7Cbcca095d88d442f88260cc216b81f62d%7C0%7C0%7C636407058161574802=hgOOLVQoxgPD1o%2BQVX%2Bs2UbkpW6PXKRFGgOxdwq8NeI%3D=0'
>>>134.178.145.92>'https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjabb
>>er.org%2Ffeatures%2Fiq-auth=02%7C01%7CPaschedag.Netlution%40swr.de
>>%7C066e91b3227745d69c5908d4f8d8f846%7Cbcca095d88d442f88260cc216b81f62d%
>>7C0%7C0%7C636407058161574802=eO6CwoaOmrVZdY2uSR6WgvYPlGtgzDPuoS%2
>>BanJk8stU%3D=0'  />>'https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjabb
>>er.org%2Ffeatures%2Fiq-register=02%7C01%7CPaschedag.Netlution%40sw
>>r.de%7C066e91b3227745d69c5908d4f8d8f846%7Cbcca095d88d442f88260cc216b81f
>>62d%7C0%7C0%7C636407058161574802=4p%2BrR4rREwE02sakNKJFw2PQmUwQyt
>>LD0sdcXlj1Ov0%3D=0'  />>'urn:ietf:params:xml:ns:xmpp-tls' >
>>
>><-- 
>&

Re: [Spacewalk-list] OSA Dispatcher "conflict" error [SEC=UNCLASSIFIED]

[Robert Paschedag]

Am 12. September 2017 05:13:36 MESZ schrieb Andrew Bergman 
<andrew.berg...@bom.gov.au>:
>I just removed the jabber RPM, reinstalled with a clean slate, ran
>spacewalk-setup-jabberd
>
>Jabberd runs fine using the SSL cert I provided built with the FQDN,
>but again, osa-dispatcher fails with same error.
>
>Maybe I should reinstall osa-dispatcher?
>
>Regards
>
>Andrew 
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Paschedag,
>Robert
>Sent: Monday, 11 September 2017 5:09 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Okay...thenwhat error do you get, when you try to setup jabberd
>from scratch (via the setup script) and ".dist" files?
>
>
>
>-Ursprüngliche Nachricht-
>Von: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Andrew
>Bergman
>Gesendet: Montag, 11. September 2017 08:39
>An: spacewalk-list@redhat.com
>Betreff: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>There is no clients using this - I adopted this spacewalk server which
>had been built by someone who did not understand Spacewalk/Satellite. 
>It was a glorified yum repository with a pretty front end.  Most
>functionality didn't work and it wasn't even receiving updates
>properly.
>
>I fixed all that up and now am at the point of getting OSA Dispatcher
>and OSAD working on clients when I discover that since I upgraded to
>2.6 OSA Dispatcher has failed to start.
>
>None of the clients have OSAD installed and nor can they hit port 5222
>due to firewall rules.
>
>The only error we get is when we try to start OSA Dispatcher.
>
>Regards
>
>Andrew
>
>-Original Message-
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Paschedag,
>Robert
>Sent: Monday, 11 September 2017 4:35 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Hmma hard one.
>
>What errors do you get on the "client" side?
>
>
>-Ursprüngliche Nachricht-
>Von: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Andrew
>Bergman
>Gesendet: Montag, 11. September 2017 07:43
>An: spacewalk-list@redhat.com
>Betreff: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Trust me, that was the first thing I tried ;)
>
>-Original Message-
>From: Robert Paschedag [mailto:robert.pasche...@web.de]
>Sent: Monday, 11 September 2017 3:33 PM
>To: spacewalk-list@redhat.com; Andrew Bergman;
>spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Am 11. September 2017 02:55:54 MESZ schrieb Andrew Bergman
><andrew.berg...@bom.gov.au>:
>>There are other ID's in the logs that are osad related.  Looking at
>the 
>>logs that's the one in the request when the conflict occurs:
>>
>>[root@sdcvp-spacewalk01 jabberd]# osa-dispatcher -N -vvv
>>--> >to='sdcvp-spacewalk01.bom.gov.au' xmlns='jabber:client'
>>xmlns:stream='https://emea01.safelinks.protection.outlook.com/?url=http
>>%3A%2F%2Fetherx.jabber.org%2Fstreams=02%7C01%7CPaschedag.Netlution
>>%40swr.de%7C066e91b3227745d69c5908d4f8d8f846%7Cbcca095d88d442f88260cc21
>>6b81f62d%7C0%7C0%7C636407058161574802=bE%2BPcIfY6%2BOZfhh5AYInJpu
>>z5vUHs3JSU5rcJdv5OX0%3D=0' version='1.0'>
>>
>><-- 'https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Faffinix.com%2Fjabber%2Faddress=02%7C01%7CPaschedag.Netlution%40swr.de%7C066e91b3227745d69c5908d4f8d8f846%7Cbcca095d88d442f88260cc216b81f62d%7C0%7C0%7C636407058161574802=hgOOLVQoxgPD1o%2BQVX%2Bs2UbkpW6PXKRFGgOxdwq8NeI%3D=0'
>>>134.178.145.92>'https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjabb
>>er.org%2Ffeatures%2Fiq-auth=02%7C01%7CPaschedag.Netlution%40swr.de
>>%7C066e91b3227745d69c5908d4f8d8f846%7Cbcca095d88d442f88260cc216b81f62d%
>>7C0%7C0%7C636407058161574802=eO6CwoaOmrVZdY2uSR6WgvYPlGtgzDPuoS%2
>>BanJk8stU%3D=0'  />>'https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjabb
>>er.org%2Ffeatures%2Fiq-register=02%7C01%7CPaschedag.Netlution%40sw
>>r.de%7C066e91b3227745d69c5908d4f8d8f846%7Cbcca095d88d442f88260cc216b81f
>>62d%7C0%7C0%7C636407058161574802=4p%2BrR4rREwE02sakNKJFw2PQmUwQyt
>>LD0sdcXlj1Ov0%3D=0'  />>'urn:ietf:params:xml:ns:xmpp-tls' >
>>
>><-- 
>&

Re: [Spacewalk-list] OSA Dispatcher "conflict" error [SEC=UNCLASSIFIED]

[Robert Paschedag]

Am 8. September 2017 07:16:13 MESZ schrieb Andrew Bergman 
<andrew.berg...@bom.gov.au>:
>Yes, I did an upgrade from 2.2 to 2.6
>
>No ID's that I can see in any of those jabber configs in /etc/jabber
>
>-Original Message-
>From: Robert Paschedag [mailto:robert.pasche...@web.de] 
>Sent: Friday, 8 September 2017 3:11 PM
>To: spacewalk-list@redhat.com; Andrew Bergman;
>spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Am 8. September 2017 06:36:13 MESZ schrieb Andrew Bergman
><andrew.berg...@bom.gov.au>:
>>Where would I find these configured?
>>
>>-Original Message-
>>From: Robert Paschedag [mailto:robert.pasche...@web.de]
>>Sent: Friday, 8 September 2017 2:35 PM
>>To: spacewalk-list@redhat.com; Andrew Bergman; 
>>spacewalk-list@redhat.com
>>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error 
>>[SEC=UNCLASSIFIED]
>>
>>Am 8. September 2017 03:29:15 MESZ schrieb Andrew Bergman
>><andrew.berg...@bom.gov.au>:
>>>Hi Spacewalk list,
>>>
>>>I am seeing an error on the Spacewalk 2.6 server I am responsible
>for:
>>>
>>>Jabber is running, port 5222 TCP is running from c2s process and is
>>>communicable via telnet.   I see no errors in the logs except from
>>>osa-dispatcher.
>>>
>>># osa-dispatcher -N -
>>>
>>>The last messages are:
>>>--> >>type='subscribed' id='presence-fb3eba-37' />
>>>
>>><-- >>'jabber:iq:roster' >>>jid='osad-bb7d64e...@sdcvp-spacewalk01.bom.gov.au' subscription='to'
>>>/>>>subscription='to' />
>>>
>>><-- >>to='rhn-dispatcher-...@sdcvp-spacewalk01.bom.gov.au/superclient'
>>>type='set' id='zb6g3gnj6oylakzw0ntgapdin3tlgajgmqwq6j9c'>>=
>>>'jabber:iq:roster' >>>jid='osad-441293a...@sdcvp-spacewalk01.bom.gov.au'
>subscription='both'
>>>/>
>>>
>>>--> >>'jabber:iq:roster'  />
>>>
>>><-- >>to='rhn-dispatcher-...@sdcvp-spacewalk01.bom.gov.au/superclient'
>>>type='set' id='78xisxfsl88wymemq876irn4hjvn340bcyt5w8xh'>>=
>>>'jabber:iq:roster' >>>jid='osad-bb7d64e...@sdcvp-spacewalk01.bom.gov.au'
>subscription='both'
>>>/>
>>>
>>><-- >>/>
>>>
>>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an error
>>stanza:
>>>', >>/>)
>>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an conflict.
>>>Restarting with new credentials.',)
>>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Error caught:',)
>>>
>>>ERROR: unhandled exception occurred: (can't write str to text
>stream).
>>>
>>>This looks similar to: 
>>>http://spacewalk-list.redhat.narkive.com/aH2kex2k/osa-dispatcher-probl
>>>e
>>>ms-no-system-ever-reports
>>>
>>>However, I see no SSL errors, my hosts file is fine, with ipv6 ::1 
>>>entry for localhost, fully qualified hostname and the system hostname
>
>>>set to FQDN correctly.
>>>
>>>Does anyone have any suggestions?
>>>
>>>Thanks
>>>
>>>Andrew Bergman
>>
>>Do you use 2 IDs within your jabber configuration? The different "id"s
>
>>add the "switch" to other credentials looks strange to me.
>>
>>Robert
>>
>>___
>>Spacewalk-list mailing list
>>Spacewalk-list@redhat.com
>>https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>In the c2c or s2.xml I think. Within /etc/jabberd.
>
>Did you update your system some time ago?
>
>Robert
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Did you run the "rhnconf" tool after the upgrade? I think it's stated in the 
upgrade guide.

It "diffs" the configuration files from rpm packages.

And there MUST be an  tag within the config. I'm pretty pretty sure.

Robert


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

Re: [Spacewalk-list] OSA Dispatcher "conflict" error [SEC=UNCLASSIFIED]

[Robert Paschedag]

Am 8. September 2017 06:45:13 MESZ schrieb Andrew Bergman 
:
>Definitely multiple IDs:
>
>[root@sdcvp-spacewalk01 rhn]# cat /tmp/osad_output.txt |grep "id="|sed
>-e "s/.*id='\(.*\)'.*$/\1/g"
>auth-get-d2f7c1-0'>>type='subscribed' id='presence-fb3eba-37' />
>>
>><-- >'jabber:iq:roster' >>jid='osad-bb7d64e...@sdcvp-spacewalk01.bom.gov.au' subscription='to'
>>/>>subscription='to' />
>>
>><-- >to='rhn-dispatcher-...@sdcvp-spacewalk01.bom.gov.au/superclient'
>>type='set' id='zb6g3gnj6oylakzw0ntgapdin3tlgajgmqwq6j9c'>= 
>>'jabber:iq:roster' >>jid='osad-441293a...@sdcvp-spacewalk01.bom.gov.au' subscription='both'
>>/>
>>
>>--> >'jabber:iq:roster'  />
>>
>><-- >to='rhn-dispatcher-...@sdcvp-spacewalk01.bom.gov.au/superclient'
>>type='set' id='78xisxfsl88wymemq876irn4hjvn340bcyt5w8xh'>= 
>>'jabber:iq:roster' >>jid='osad-bb7d64e...@sdcvp-spacewalk01.bom.gov.au' subscription='both'
>>/>
>>
>><-- >/>
>>
>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an error
>stanza:
>>', >/>)
>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an conflict.
>>Restarting with new credentials.',)
>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Error caught:',)
>>
>>ERROR: unhandled exception occurred: (can't write str to text stream).
>>
>>This looks similar to: 
>>http://spacewalk-list.redhat.narkive.com/aH2kex2k/osa-dispatcher-proble
>>ms-no-system-ever-reports
>>
>>However, I see no SSL errors, my hosts file is fine, with ipv6 ::1 
>>entry for localhost, fully qualified hostname and the system hostname 
>>set to FQDN correctly.
>>
>>Does anyone have any suggestions?
>>
>>Thanks
>>
>>Andrew Bergman
>
>Do you use 2 IDs within your jabber configuration? The different "id"s
>add the "switch" to other credentials looks strange to me.
>
>Robert
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Look into the XML configuration files in /etc/jabberd. Should be an "" tag.
You'll see it.

Just on my way to work.

Robert

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

Re: [Spacewalk-list] OSA Dispatcher "conflict" error [SEC=UNCLASSIFIED]

[Robert Paschedag]

Am 8. September 2017 06:36:13 MESZ schrieb Andrew Bergman 
<andrew.berg...@bom.gov.au>:
>Where would I find these configured?
>
>-Original Message-
>From: Robert Paschedag [mailto:robert.pasche...@web.de] 
>Sent: Friday, 8 September 2017 2:35 PM
>To: spacewalk-list@redhat.com; Andrew Bergman;
>spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] OSA Dispatcher "conflict" error
>[SEC=UNCLASSIFIED]
>
>Am 8. September 2017 03:29:15 MESZ schrieb Andrew Bergman
><andrew.berg...@bom.gov.au>:
>>Hi Spacewalk list,
>>
>>I am seeing an error on the Spacewalk 2.6 server I am responsible for:
>>
>>Jabber is running, port 5222 TCP is running from c2s process and is
>>communicable via telnet.   I see no errors in the logs except from
>>osa-dispatcher.
>>
>># osa-dispatcher -N -
>>
>>The last messages are:
>>--> >type='subscribed' id='presence-fb3eba-37' />
>>
>><-- >'jabber:iq:roster' >>jid='osad-bb7d64e...@sdcvp-spacewalk01.bom.gov.au' subscription='to'
>>/>>subscription='to' />
>>
>><-- >to='rhn-dispatcher-...@sdcvp-spacewalk01.bom.gov.au/superclient'
>>type='set' id='zb6g3gnj6oylakzw0ntgapdin3tlgajgmqwq6j9c'>= 
>>'jabber:iq:roster' >>jid='osad-441293a...@sdcvp-spacewalk01.bom.gov.au' subscription='both'
>>/>
>>
>>--> >'jabber:iq:roster'  />
>>
>><-- >to='rhn-dispatcher-...@sdcvp-spacewalk01.bom.gov.au/superclient'
>>type='set' id='78xisxfsl88wymemq876irn4hjvn340bcyt5w8xh'>= 
>>'jabber:iq:roster' >>jid='osad-bb7d64e...@sdcvp-spacewalk01.bom.gov.au' subscription='both'
>>/>
>>
>><-- >/>
>>
>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an error
>stanza:
>>', >/>)
>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an conflict.
>>Restarting with new credentials.',)
>>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Error caught:',)
>>
>>ERROR: unhandled exception occurred: (can't write str to text stream).
>>
>>This looks similar to: 
>>http://spacewalk-list.redhat.narkive.com/aH2kex2k/osa-dispatcher-proble
>>ms-no-system-ever-reports
>>
>>However, I see no SSL errors, my hosts file is fine, with ipv6 ::1 
>>entry for localhost, fully qualified hostname and the system hostname 
>>set to FQDN correctly.
>>
>>Does anyone have any suggestions?
>>
>>Thanks
>>
>>Andrew Bergman
>
>Do you use 2 IDs within your jabber configuration? The different "id"s
>add the "switch" to other credentials looks strange to me.
>
>Robert
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

In the c2c or s2.xml I think. Within /etc/jabberd.

Did you update your system some time ago?

Robert

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

Re: [Spacewalk-list] OSA Dispatcher "conflict" error [SEC=UNCLASSIFIED]

[Robert Paschedag]

Am 8. September 2017 03:29:15 MESZ schrieb Andrew Bergman 
:
>Hi Spacewalk list,
>
>I am seeing an error on the Spacewalk 2.6 server I am responsible for:
>
>Jabber is running, port 5222 TCP is running from c2s process and is
>communicable via telnet.   I see no errors in the logs except from
>osa-dispatcher.
>
># osa-dispatcher -N -
>
>The last messages are:
>--> type='subscribed' id='presence-fb3eba-37' />
>
><-- 'jabber:iq:roster' >jid='osad-bb7d64e...@sdcvp-spacewalk01.bom.gov.au' subscription='to'
>/>subscription='to' />
>
><-- to='rhn-dispatcher-...@sdcvp-spacewalk01.bom.gov.au/superclient'
>type='set' id='zb6g3gnj6oylakzw0ntgapdin3tlgajgmqwq6j9c'>'jabber:iq:roster' >jid='osad-441293a...@sdcvp-spacewalk01.bom.gov.au' subscription='both'
>/>
>
>--> 'jabber:iq:roster'  />
>
><-- to='rhn-dispatcher-...@sdcvp-spacewalk01.bom.gov.au/superclient'
>type='set' id='78xisxfsl88wymemq876irn4hjvn340bcyt5w8xh'>'jabber:iq:roster' >jid='osad-bb7d64e...@sdcvp-spacewalk01.bom.gov.au' subscription='both'
>/>
>
><-- />
>
>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an error stanza:
>', />)
>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Received an conflict.
>Restarting with new credentials.',)
>Spacewalk 20123 2017/09/07 06:49:21 -00:00: ('Error caught:',)
>
>ERROR: unhandled exception occurred: (can't write str to text stream).
>
>This looks similar to: 
>http://spacewalk-list.redhat.narkive.com/aH2kex2k/osa-dispatcher-problems-no-system-ever-reports
>
>However, I see no SSL errors, my hosts file is fine, with ipv6 ::1
>entry for localhost, fully qualified hostname and the system hostname
>set to FQDN correctly.
>
>Does anyone have any suggestions?
>
>Thanks
>
>Andrew Bergman

Do you use 2 IDs within your jabber configuration? The different "id"s add the 
"switch" to other credentials looks strange to me.

Robert

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

Re: [Spacewalk-list] bug in channel.software.mergeErrata?

[Robert Paschedag]

Am 30. August 2017 15:33:37 MESZ schrieb "Lichtinger, Bernhard" 
:
>Hello,
>
>I see a strange behavior of spacewalk using
>spacewalk-manage-channel-lifecycle:
>Everytime I promote a channel all erratas which source and destination
>channel have in common are removed from the source channel.
>
>For example: source channel has 4 (newer) errata more than the
>destination channel. Then after running
>"spacewalk-manage-channel-lifecycle -c source_channel --promote" my
>destination channel has all old errata plus the 4 new ones, but my
>source channel has only the 4 new errata left.
>
>The rpm packages in each channel are still linked to the errata, but
>the source channel looses all "old" erratas.
>
>It happens with all my channels, RHEL-6,7 and SLES-11,12.
>
>I have spacewalk-2.6 on centos-7. I can also reproduce the behavior on
>my test machine with spacewalk-2.6 on centos-6:
>I have 2 phases for spacewalk-manage-channel-lifecycle defined: test
>and prod. 
>So I have 3 baselines of channels: daily (is synced daily with upstream
>repos), test and prod.
>
>For a fresh start I clear all erratas from the database:
>rhnschema=# truncate rhnErrata CASCADE;;
>
>After a full sync of daily with upstream repo, errata count for my
>channels:
>daily: 590
>test:  0
>prod:  0
>
>After "spacewalk-manage-channel-lifecycle -c daily --promote" errata
>count for my channels:
>daily: 590
>test:  590
>prod:  0
>
>After "spacewalk-manage-channel-lifecycle -c test --promote" errata
>count for my channels:
>daily: 590
>test:  590
>prod:  590
>
>So far everything is ok.
>
>Now I after a second "spacewalk-manage-channel-lifecycle -c daily
>--promote" errata count for my channels:
>daily: 0
>test:  590
>prod:  590
>
>And after a second "spacewalk-manage-channel-lifecycle -c test
>--promote" errata count for my channels:
>daily: 0
>test:  0
>prod:  590
>
>With the next sync of daily with upstream daily gets again all erratas:
>daily: 590
>test:  0
>prod:  590
>
>And this cycle can go on and on.
>
>I am not sure, but I think this started after the upgrade from 2.5 to
>2.6, but I could not find any relevant changes in the source code of
>the channel.software.mergeErrata API call. This is all code which was
>not touched in recent times.
>
>So, is this a bug in spacewalk or did I only break my installations?
>
>
>Regards,
>Bernhard

Sounds like an intersection instead of a union.

Robert

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

Re: [Spacewalk-list] update hostname identifiers

[Robert Paschedag]

Am 30. August 2017 01:07:54 MESZ schrieb "Valencia ..." 
:
>Hello,
>
>We need to update the host identifiers of the client computers
>registered in SpaceWalk, I need to update them, but in SpaceWalk I can
>not find update the hostname, and in database it has triggers.
>
>is there any way update the hostnames?
>
>regards
>
>Javier Valencia.

I think a "rhn-profile-sync" on the clients should update that information.

Robert

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

Re: [Spacewalk-list] Migration question

[Robert Paschedag]

Am 21. August 2017 19:49:49 MESZ schrieb Sean Roe :
>I found a solution that I am sharing with you. Because the linux
>postgresql database would barf on the ALF32UTF8 input file generated by
>doing the spacewalk-dump-schema command I had to take the output from
>that command and I ran it through the following command:
>
>iconv -c -t utf-8 migrate-to-postgres.sql > migrate-to-postgres2.sql
>
>and then do the:
>
>spacewalk-sql -verbose migrate-to-postgres2.sql
>
>Just thought I would share my solution.
>
>Thanks,
>Sean
>
>From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Sean Roe
>Sent: Friday, August 18, 2017 8:45 AM
>To: spacewalk-list@redhat.com
>Subject: [Spacewalk-list] Migration question
>
>Hi All,
>
>
>I have updated my spacewalk install to 2.6 and it appears to be running
>fine at this point.  We wish to migrate it off of Oracle and on to its
>own internal postgres instance.  I am following the document
>https://github.com/spacewalkproject/spacewalk/wiki/DatabaseMigrations
>and I have completed the dump of the database using
>
>
>
>spacewalk-dump-schema --to=postgresql > blahblahblah.sql .
>
>
>
>When I went to import it into postgres it appears there is some
>incompatibilities between AL32UTF8 and UTF8.  It appears to be an issue
>with \x0a characters in the data.  Has anybody come across this and how
>did they solve it?  Right now I am running the dump through sed like
>this:
>
>
>
>sed 's/\\x0a/\\N/g' blahblahblah.sql  > postconv.sql
>
>
>
>Any input would be helpful.
>
>
>
>Thanks,
>
>Sean

Hi Sean,

thank you for this information. I appreciate it.

Robert

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

Re: [Spacewalk-list] upgrade of 2.6 to 2.7-nightly fails on RHEL/CentOS 6

[Robert Paschedag]

Am 11. August 2017 18:28:18 MESZ schrieb "Miller, Jeffrey L" 
:
>I’m not sure where to send this so I figured to the list would be a
>good idea. I saw rumblings of a release soon, and I was testing the
>upgrade of a Spacewalk 2.6 server to 2.7-nightly on both RHEL 6 and
>CentOS 6 VMs; however, I encountered the following error on dependency
>checking from a yum upgrade command:
>
>---> Package spacewalk-java.noarch 0:2.7.108-1.el6 will be obsoleting
>--> Processing Dependency: jakarta-commons-logging < 1.1 for package:
>spacewalk-java-2.7.108-1.el6.noarch
>--> Finished Dependency Resolution
>Error: Package: jakarta-commons-logging-mvn-2.7.12-1.sw.noarch
>(group_spacewalkproject-epel6-addons)
>   Requires: jakarta-commons-logging = 1.0.4
>Installed: jakarta-commons-logging-1.1-8.jpp5.noarch
>(@jpackage-generic)
>   jakarta-commons-logging = 1.1-8.jpp5
>  Available: jakarta-commons-logging-1.0.4-10.el6.noarch (base)
>   jakarta-commons-logging = 1.0.4-10.el6
>Error: Package: spacewalk-java-2.7.108-1.el6.noarch (spacewalk-nightly)
>   Requires: jakarta-commons-logging < 1.1
>Installed: jakarta-commons-logging-1.1-8.jpp5.noarch
>(@jpackage-generic)
>   jakarta-commons-logging = 1.1-8.jpp5
>  Available: jakarta-commons-logging-1.0.4-10.el6.noarch (base)
>   jakarta-commons-logging = 1.0.4-10.el6
>You could try using --skip-broken to work around the problem
>You could try running: rpm -Va --nofiles --nodigest
>
>I believe the error is coming from the requirements specified in the
>spec file for spacewalk-java on GitHub
>(https://github.com/spacewalkproject/spacewalk/blob/master/java/spacewalk-java.spec),
>line 127 reads: “Requires: jakarta-commons-logging < 1.1”. The package
>version for jakarta-commons-logging on a Spacewalk 2.6 install on
>CentOS 6 is jakarta-commons-logging-1.1-8.jpp5.noarch. In other words,
>1.1 < 1.1 fails the yum dependency check, and yum cannot downgrade to
>1.0.4 since 1.1 is required for other components.
>
>
>Jeffrey
>
>=
>Jeffrey Miller
>Senior Systems Administrator
>The University of Iowa
>ITS – Research Services
>19 Lindquist Center South
>Iowa City, IA 52242-1727
>(319) 467-1636
>=

Hi,

We had this problem also. Before upgrading, please also remove all packages 
with "jpp5"

Something like "rpm -e --nodeps $(rpm -qa | grep jpp5 | xargs)" should work.

Then do a yum upgrade

Please make a snapshot before you test this

Robert


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

Re: [Spacewalk-list] Cannot retrieve repository metadata

[Robert Paschedag]

Am 3. August 2017 07:50:15 MESZ schrieb sureshskja skja :
>Thanks for your response Paul Robert.
>
>I am trying find the path that you mentioned for deleting since it is
>not
>working after restarting taskomatic and what should be directory or
>filename under /var ?
>
>Is this the path ?
>
>[root@drp-mgt-spw-e1a sat]# pwd
>/var/log/rhn/tasko/sat
>[root@drp-mgt-spw-e1a sat]#
>auto-errata-bunch   clear-taskologs-bunch  daily-status-bunch
>kickstart-cleanup-bunch   reboot-action-cleanup-bunch 
>uuid-cleanup-bunch
>channel-repodata-bunch  cobbler-sync-bunch errata-cache-bunch
>kickstartfile-sync-bunch  sandbox-cleanup-bunch
>cleanup-data-bunch  compare-configs-bunch  errata-queue-bunch
>package-cleanup-bunch session-cleanup-bunch
>
>
>Thanks
>suresh s
>
>
>On Wed, Aug 2, 2017 at 9:50 PM, Paul Robert Marino
>
>wrote:
>
>> By the way it will take a little time for taskomatic to reindex the
>> channels so give it about 30 minutes.
>> If that doesn't work there should be a directory under /var that
>named
>> after the channel that contains the repo data delete that directory
>and let
>> taskomatic recreate it.
>>
>> Sent from my BlackBerry - the most secure mobile device
>> *From:* prmari...@gmail.com
>> *Sent:* August 2, 2017 11:21 AM
>> *To:* spacewalk-list@redhat.com
>> *Subject:* Re: [Spacewalk-list] Cannot retrieve repository metadata
>>
>> First things first try restarting taskomatic
>> There are more steps after that but they are very intrusive and 7
>times
>> out of 10 that will fix it
>>
>> Sent from my BlackBerry - the most secure mobile device
>> *From:* sureshs...@gmail.com
>> *Sent:* August 1, 2017 8:27 AM
>> *To:* spacewalk-list@redhat.com
>> *Reply-to:* spacewalk-list@redhat.com
>> *Subject:* [Spacewalk-list] Cannot retrieve repository metadata
>>
>> I need some quick help from some one immediately as I am facing
>problem
>> when registering RedHat 6 client with Spacewalk Server and below is
>the
>> error. Kindly help on this.
>>
>> Below is the error details.
>>
>> REGISTRATION
>> 
>> * registering
>> /usr/sbin/rhnreg_ks --force --activationkey
>1-East_Non_Prod_Enterprise
>>
>> *** this system should now be registered, please verify ***
>>
>>
>> OTHER ACTIONS
>> --
>> Installing Spacewalk certficate
>> yum -y upgrade yum yum-rhn-plugin; rhn-profile-sync
>> but any post configuration action can be added here.
>> --
>> * ensuring yum itself is updated
>> Loaded plugins: amazon-id, rhnplugin, rhui-lb, search-disabled-repos,
>> security
>> This system is receiving updates from RHN Classic or Red Hat
>Satellite.
>> Setting up Upgrade Process
>> Error: Cannot retrieve repository metadata (repomd.xml) for
>repository:
>> channel_oracle_linux6_x86_64. Please verify its path and try again
>> Updating package profile...
>> Updating hardware profile...
>> -bootstrap complete-
>>   % Total% Received % Xferd  Average Speed   TimeTime
>Time
>> Current
>>  Dload  Upload   Total   Spent   
>Left
>> Speed
>>   0190190 0  12500  0 --:--:-- --:--:--
>--:--:--
>> 19000
>> null[root@stg-mgt-spwtest_e1a tmp]# yum update
>> Loaded plugins: amazon-id, rhnplugin, rhui-lb, search-disabled-repos,
>> security
>> This system is receiving updates from RHN Classic or Red Hat
>Satellite.
>> Setting up Update Process
>> Error: Cannot retrieve repository metadata (repomd.xml) for
>repository:
>> channel_oracle_linux6_x86_64. Please verify its path and try again
>> [root@stg-mgt-spwtest_e1a tmp]#
>>
>> Thanks
>> Suresh S
>>
>> ___
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>

The path should be /var/cache/rhn/repodata/...

But you need to force the channel to "sync" again. I don't think that removing 
the file on disk will result in recreating this file automatically.

Robert

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

Re: [Spacewalk-list] Spacewalk 2.1 | SSL Certificate Invalid when using HTTPS for host registration

[Robert Paschedag]

Am 18. Juli 2017 02:34:25 MESZ schrieb Francis Lee Mondia 
<endace.francis.mon...@gmail.com>:
>Hi Robert,
>
>Thanks for the tips. Was able to login to the postgresql db with the
>credentials stored on the rhn.conf file. Tried to delete the referenced
>ky
>but I think the error is legit, as postgresql is enforcing a key
>constraint
>on the two tables so as not to have inconsistent keys. I dug into the
>table
>and I see that are are other keys inserted which I think were the ones
>I
>made and installed when I installed the newly-built rpms. I now think I
>don't need to do this step (delete the key) and look for another
>solution.
>
>
>I got another lead though which might get me to the bottom of this
>issue.
>I've followed the article on red hat titled "SSL certificate validation
>failure when attempting to register against RHN". One of the
>troubleshooting steps is to check the SSL certificate chain. Turns out
>I
>have a self-signed certificate in my chain which was causing
>verification
>issues.
>
>Anyone experiencing the same and have tips on how to resolve it?
>
>Kind regards,
>Francis
>
>On Tue, Jul 18, 2017 at 4:36 AM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 17. Juli 2017 16:16:50 MESZ schrieb "Paschedag, Robert" <
>> paschedag.netlut...@swr.de>:
>> >The credentials for the postgres db should be stored within
>> >/etc/rhn/rhn.conf on the satellite server.
>> >
>> >By default, this is
>> >
>> >User: rhnuser
>> >PW: rhnpw
>> >DB: rhnschema
>> >
>> >So..switching to user postgres
>> >
>> >Su – postgres
>> >
>> >And
>> >
>> >psql -U  -d 
>> >
>> >and entering password should give you access.
>> >
>> >There is also a command to “set” the password
>> >
>> >
>> >
>> >
>> >Mit freundlichen Grüßen
>> >
>> >Robert Paschedag
>> >Netlution GmbH
>> >Landteilstr. 33
>> >68163 Mannheim
>> >
>> >im Auftrag des
>> >SWR
>> >Südwestrundfunk
>> >HA IT, Medientechnik und Programmverbreitung
>> >Neckarstraße 230
>> >70190 Stuttgart
>> >
>> >Telefon +49 (0)711 /929-12654 oder
>> >Telefon +49 (0)711 /929-13714
>> >paschedag.netlut...@swr.de
>> >
>> >swr.de
>> >
>> >Von: spacewalk-list-boun...@redhat.com
>> >[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Vipul
>Sharma
>> >(GDC)
>> >Gesendet: Montag, 17. Juli 2017 14:12
>> >An: Francis Lee Mondia <endace.francis.mon...@gmail.com>
>> >Cc: spacewalk-list@redhat.com
>> >Betreff: Re: [Spacewalk-list] Spacewalk 2.1 | SSL Certificate
>Invalid
>> >when using HTTPS for host registration
>> >
>> >Hey,
>> >Do you remember the password you used when creating the DB - Please
>try
>> >this password given below -
>> >
>> >Database - spaceschema
>> >
>> >Username - spaceuser
>> >
>> >Password - spacepw
>> >
>> >
>> >#psql DBNAME USERNAME
>> >
>> >On Mon, Jul 17, 2017 at 4:45 PM, Francis Lee Mondia
>>
>><endace.francis.mon...@gmail.com<mailto:endace.francis.mon...@gmail.com>>
>> >wrote:
>> >Hi Vipul,
>> >
>> >Yes, the service is running as evidenced by the output. The problem
>as
>> >shown in the error message was that postgres actually can't update
>or
>> >delete the table stated due to a foreign key constraint validation
>on a
>> >table.
>> >
>> >There's a post on the list about it and the recommendation was to
>> >remove it. Any ideas how to remove it from the DB? I'd actually like
>to
>> >log-in to postgres and delete this key being referenced (assuming I
>> >know the password for postgres).
>> >
>> >Kind regards,
>> >Francis
>> >
>> >On Mon, Jul 17, 2017 at 10:23 PM, Vipul Sharma (GDC)
>> ><sharma.vi...@in.g4s.com<mailto:sharma.vi...@in.g4s.com>> wrote:
>> >Hey,
>> >When you are running step 8 - Make sure spacewalk service is
>running,
>> >I'm hoping you've must have stopped the service. Service is
>important
>> >to push the data to postgres.
>> >Thanks
>> >V
>> >
>> >On Mon, Jul 17, 2017 at 3:28 PM, Francis Lee Mondia
>>
>><endace.francis.mon...@gmail.com<mailto:endace.francis.mon.

Re: [Spacewalk-list] Spacewalk 2.1 | SSL Certificate Invalid when using HTTPS for host registration

[Robert Paschedag]

Am 18. Juli 2017 02:34:25 MESZ schrieb Francis Lee Mondia 
<endace.francis.mon...@gmail.com>:
>Hi Robert,
>
>Thanks for the tips. Was able to login to the postgresql db with the
>credentials stored on the rhn.conf file. Tried to delete the referenced
>ky
>but I think the error is legit, as postgresql is enforcing a key
>constraint
>on the two tables so as not to have inconsistent keys. I dug into the
>table
>and I see that are are other keys inserted which I think were the ones
>I
>made and installed when I installed the newly-built rpms. I now think I
>don't need to do this step (delete the key) and look for another
>solution.
>
>
>I got another lead though which might get me to the bottom of this
>issue.
>I've followed the article on red hat titled "SSL certificate validation
>failure when attempting to register against RHN". One of the
>troubleshooting steps is to check the SSL certificate chain. Turns out
>I
>have a self-signed certificate in my chain which was causing
>verification
>issues.
>
>Anyone experiencing the same and have tips on how to resolve it?
>
>Kind regards,
>Francis
>
>On Tue, Jul 18, 2017 at 4:36 AM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 17. Juli 2017 16:16:50 MESZ schrieb "Paschedag, Robert" <
>> paschedag.netlut...@swr.de>:
>> >The credentials for the postgres db should be stored within
>> >/etc/rhn/rhn.conf on the satellite server.
>> >
>> >By default, this is
>> >
>> >User: rhnuser
>> >PW: rhnpw
>> >DB: rhnschema
>> >
>> >So..switching to user postgres
>> >
>> >Su – postgres
>> >
>> >And
>> >
>> >psql -U  -d 
>> >
>> >and entering password should give you access.
>> >
>> >There is also a command to “set” the password
>> >
>> >
>> >
>> >
>> >Mit freundlichen Grüßen
>> >
>> >Robert Paschedag
>> >Netlution GmbH
>> >Landteilstr. 33
>> >68163 Mannheim
>> >
>> >im Auftrag des
>> >SWR
>> >Südwestrundfunk
>> >HA IT, Medientechnik und Programmverbreitung
>> >Neckarstraße 230
>> >70190 Stuttgart
>> >
>> >Telefon +49 (0)711 /929-12654 oder
>> >Telefon +49 (0)711 /929-13714
>> >paschedag.netlut...@swr.de
>> >
>> >swr.de
>> >
>> >Von: spacewalk-list-boun...@redhat.com
>> >[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Vipul
>Sharma
>> >(GDC)
>> >Gesendet: Montag, 17. Juli 2017 14:12
>> >An: Francis Lee Mondia <endace.francis.mon...@gmail.com>
>> >Cc: spacewalk-list@redhat.com
>> >Betreff: Re: [Spacewalk-list] Spacewalk 2.1 | SSL Certificate
>Invalid
>> >when using HTTPS for host registration
>> >
>> >Hey,
>> >Do you remember the password you used when creating the DB - Please
>try
>> >this password given below -
>> >
>> >Database - spaceschema
>> >
>> >Username - spaceuser
>> >
>> >Password - spacepw
>> >
>> >
>> >#psql DBNAME USERNAME
>> >
>> >On Mon, Jul 17, 2017 at 4:45 PM, Francis Lee Mondia
>>
>><endace.francis.mon...@gmail.com<mailto:endace.francis.mon...@gmail.com>>
>> >wrote:
>> >Hi Vipul,
>> >
>> >Yes, the service is running as evidenced by the output. The problem
>as
>> >shown in the error message was that postgres actually can't update
>or
>> >delete the table stated due to a foreign key constraint validation
>on a
>> >table.
>> >
>> >There's a post on the list about it and the recommendation was to
>> >remove it. Any ideas how to remove it from the DB? I'd actually like
>to
>> >log-in to postgres and delete this key being referenced (assuming I
>> >know the password for postgres).
>> >
>> >Kind regards,
>> >Francis
>> >
>> >On Mon, Jul 17, 2017 at 10:23 PM, Vipul Sharma (GDC)
>> ><sharma.vi...@in.g4s.com<mailto:sharma.vi...@in.g4s.com>> wrote:
>> >Hey,
>> >When you are running step 8 - Make sure spacewalk service is
>running,
>> >I'm hoping you've must have stopped the service. Service is
>important
>> >to push the data to postgres.
>> >Thanks
>> >V
>> >
>> >On Mon, Jul 17, 2017 at 3:28 PM, Francis Lee Mondia
>>
>><endace.francis.mon...@gmail.com<mailto:endace.francis.mon.

Re: [Spacewalk-list] Spacewalk 2.1 | SSL Certificate Invalid when using HTTPS for host registration

[Robert Paschedag]

Am 17. Juli 2017 16:16:50 MESZ schrieb "Paschedag, Robert" 
<paschedag.netlut...@swr.de>:
>The credentials for the postgres db should be stored within
>/etc/rhn/rhn.conf on the satellite server.
>
>By default, this is
>
>User: rhnuser
>PW: rhnpw
>DB: rhnschema
>
>So..switching to user postgres
>
>Su – postgres
>
>And
>
>psql -U  -d 
>
>and entering password should give you access.
>
>There is also a command to “set” the password
>
>
>
>
>Mit freundlichen Grüßen
>
>Robert Paschedag
>Netlution GmbH
>Landteilstr. 33
>68163 Mannheim
>
>im Auftrag des
>SWR
>Südwestrundfunk
>HA IT, Medientechnik und Programmverbreitung
>Neckarstraße 230
>70190 Stuttgart
>
>Telefon +49 (0)711 /929-12654 oder
>Telefon +49 (0)711 /929-13714
>paschedag.netlut...@swr.de
>
>swr.de
>
>Von: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] Im Auftrag von Vipul Sharma
>(GDC)
>Gesendet: Montag, 17. Juli 2017 14:12
>An: Francis Lee Mondia <endace.francis.mon...@gmail.com>
>Cc: spacewalk-list@redhat.com
>Betreff: Re: [Spacewalk-list] Spacewalk 2.1 | SSL Certificate Invalid
>when using HTTPS for host registration
>
>Hey,
>Do you remember the password you used when creating the DB - Please try
>this password given below -
>
>Database - spaceschema
>
>Username - spaceuser
>
>Password - spacepw
>
>
>#psql DBNAME USERNAME
>
>On Mon, Jul 17, 2017 at 4:45 PM, Francis Lee Mondia
><endace.francis.mon...@gmail.com<mailto:endace.francis.mon...@gmail.com>>
>wrote:
>Hi Vipul,
>
>Yes, the service is running as evidenced by the output. The problem as
>shown in the error message was that postgres actually can't update or
>delete the table stated due to a foreign key constraint validation on a
>table.
>
>There's a post on the list about it and the recommendation was to
>remove it. Any ideas how to remove it from the DB? I'd actually like to
>log-in to postgres and delete this key being referenced (assuming I
>know the password for postgres).
>
>Kind regards,
>Francis
>
>On Mon, Jul 17, 2017 at 10:23 PM, Vipul Sharma (GDC)
><sharma.vi...@in.g4s.com<mailto:sharma.vi...@in.g4s.com>> wrote:
>Hey,
>When you are running step 8 - Make sure spacewalk service is running,
>I'm hoping you've must have stopped the service. Service is important
>to push the data to postgres.
>Thanks
>V
>
>On Mon, Jul 17, 2017 at 3:28 PM, Francis Lee Mondia
><endace.francis.mon...@gmail.com<mailto:endace.francis.mon...@gmail.com>>
>wrote:
>Hi Vipul,
>
>Thanks for the response.
>
>Still the same, I'm failing on step 8 on this guide
>(https://github.com/spacewalkproject/spacewalk/wiki/ChangeCaCert<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspacewalkproject%2Fspacewalk%2Fwiki%2FChangeCaCert=02%7C01%7CPaschedag.Netlution%40swr.de%7Cc7d92ced12154370d03a08d4cd0d31db%7Cbcca095d88d442f88260cc216b81f62d%7C0%7C0%7C636358903948648506=6uTbKGUyx0DTFigKnfdy2kpc2bbLjoESTWBn%2BucL9to%3D=0>):
>
>[root@spw01 ~]# rhn-ssl-dbstore -vvv --ca-cert
>/root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT
>Public CA SSL certificate:  /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT
>
>ERROR: unhandled exception occurred:
>Traceback (most recent call last):
>  File "/usr/bin/rhn-ssl-dbstore", line 43, in 
>sys.exit(abs(mod.main() or 0))
>File
>"/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/rhn_ssl_dbstore.py",
>line 79, in main
>satCerts.store_rhnCryptoKey(values.label, values.ca_cert,
>verbosity=values.verbose)
>File
>"/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/satCerts.py",
>line 673, in store_rhnCryptoKey
>verbosity=verbosity)
>File
>"/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/satCerts.py",
>line 614, in _checkCertMatch_rhnCryptoKey
>h.execute(rhn_cryptokey_id=rhn_cryptokey_id)
>File
>"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py",
>line 153, in execute
>return apply(self._execute_wrapper, (self._execute, ) + p, kw)
>File
>"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
>line 290, in _execute_wrapper
>retval = apply(function, p, kw)
>File
>"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py",
>line 207, in _execute
>return self._execute_(args, kwargs)
>File
>"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
>line 309, in _execute_
>self._real_cursor.execute(self.sql, params)
>psycopg2.IntegrityError: update or delete

Re: [Spacewalk-list] Spacewalk gui irresponsive

[Robert Paschedag]

Am 7. Juli 2017 00:12:07 MESZ schrieb Konstantin Raskoshnyi 
:
>I have 7 version of java on board so it should be compatible with
>tomcat6
>
>Where can I find db.prperties?
>
>On Thu, Jul 6, 2017 at 2:14 PM Vipul Sharma (GDC)
>
>wrote:
>
>> Any catalina errors - What about the version of Java, Can you check
>the
>> compatibility with Tomcat.
>>
>> Your connection settings looks fine for Tomcat, Please verify your
>> db.properties files for postgres.
>>
>> Thanks
>> Vipul
>> DevOps
>>
>> On Fri, Jul 7, 2017 at 1:37 AM, Konstantin Raskoshnyi
>
>> wrote:
>>
>>> Hi guys, after upgrade to 2.6, when I try to remove more than 10
>packages
>>> spacewalk become irresponsive.
>>>
>>> Server config 24Gb or ram, 24 cores.
>>>
>>> I did some tuning of tomcat and pg
>>>
>>> It used to work fine, no any error in the logs though.
>>>
>>> Here's my settings:
>>>
>>> DB:
>>> autovacuum on
>>> default_statistics_target = 50 # pgtune wizard 2015-12-08
>>> maintenance_work_mem = 960MB # pgtune wizard 2015-12-08
>>> constraint_exclusion = on # pgtune wizard 2015-12-08
>>> checkpoint_completion_target = 0.9 # pgtune wizard 2015-12-08
>>> effective_cache_size = 6GB # pgtune wizard 2015-12-08
>>> work_mem = 3840kB # pgtune wizard 2015-12-08
>>> wal_buffers = 8MB # pgtune wizard 2015-12-08
>>> checkpoint_segments = 256 # pgtune wizard 2015-12-08
>>> shared_buffers = 3840MB # pgtune wizard 2015-12-08
>>> checkpoint_timeout = 30min # range 30s-1h
>>> max_connections = 600
>>>
>>>
>>> Heap for tomcat 8Gb
>>>
>>> ulimits.conf
>>>
>>> * soft nproc 65535
>>>
>>> * hard nproc 65535
>>>
>>> * soft nofile 65535
>>>
>>> * hard nofile 65535
>>>
>>> Tomcat
>>>
>>> Tomcat:
>>> /etc/tomcat6/server.xml
>>>
>>> >> redirectPort="8443" URIEncoding="UTF-8" address="127.0.0.1"
>>> maxKeepAliveRequests="1000"/>
>>>
>>>
>>> >> URIEncoding="UTF-8" address="127.0.0.1" maxThreads="1024"/>
>>>
>>> Top is almost quiet
>>>
>>>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
>>>  4810 postgres  20   0 4140m 2.0g 2.0g D 24.9  8.4   0:24.72
>*postmaster*
>>>  3914 jabber20   0  137m 4288 2396 S  5.0  0.0   0:08.77 sm
>>>  4817 postgres  20   0 4128m  17m  15m S  4.6  0.1   0:02.82
>postmaster
>>>  3906 jabber20   0 62400 2480 1876 S  3.0  0.0   0:04.60 router
>>>
>>> Any thoughts?
>>>
>>> ___
>>> Spacewalk-list mailing list
>>> Spacewalk-list@redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>
>>
>>
>>
>> Please consider the environment before printing this email.
>> *
>> This communication may contain information which is confidential,
>personal
>> and/or privileged. It is for the exclusive use of the intended
>recipient(s).
>> If you are not the intended recipient(s), please note that any
>> distribution, forwarding, copying or use of this communication or the
>> information in it is strictly prohibited. If you have received it in
>error
>> please contact the sender immediately by return e-mail. Please then
>delete
>> the e-mail and any copies of it and do not use or disclose its
>contents to
>> any person.
>> Any personal views expressed in this e-mail are those of the
>individual
>> sender and the company does not endorse or accept responsibility for
>them.
>> Prior to taking any action based upon this e-mail message, you should
>seek
>> appropriate confirmation of its authenticity.
>> This message has been checked for viruses on behalf of the company.
>> *
>>
>>

Just another question. Where do you remove the packages?

>From a channel?
Completely from spacewalk?
Remove packages from a system?

Robert

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

Re: [Spacewalk-list] Package Installation: Schedule Time not working

[Robert Paschedag]

Am 3. Juli 2017 22:51:53 MESZ schrieb "Vipul Sharma (GDC)" 
<sharma.vi...@in.g4s.com>:
>Just to update - By default, It takes around 250+ minutes for OSA to
>get
>installation started - You can change the time interval by editing
>/etc/sysconfig/rhn/rhnsd
>--
>
>Also note down - You can *rhn_check* to install the package right away
>once
>the request has been send away from Spacewalk -
>
>Just schedule the package install from Spacewalk & run this *rhn_check*
>on
>the client, You will see the magic.
>
>
>
>On Mon, Jul 3, 2017 at 11:44 PM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 3. Juli 2017 16:21:25 MESZ schrieb Sreejith P G
><sreejith@gmail.com
>> >:
>> >Team,
>> > I am trying to install a package on my client from spacwalk
>server
>> >using osa-dispatcher and getting below expected check in time and I
>am
>> >not
>> >able to schedule package installation with any scheduled time of my
>> >choice.
>> >Is there any way that I can change it to my choice?
>> >
>> > Confirm Package Install
>> >System last check-in: 7/3/17 9:52:09 PM AWST (0 days 0 hours 4
>minutes
>> >ago)
>> >Current Spacewalk time: 7/3/17 9:56:10 PM AWST
>> >Expected check-in time: 7/3/17 11:52:09 PM AWST (0 days 1 hour 55
>> >minutes
>> >from now)
>>
>> You set the installation date and time when you select the package
>for
>> installation. Just before you have to "confirm". By default, it
>says... "as
>> soon as possible"
>>
>> Robert
>>
>> ___
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>

This interval is only for the rhnsd daemon. Correct.

If you are using "osad" (and is working correctly), it should install 
immediately, if you planned it "as soon as possible"

Robert

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

Re: [Spacewalk-list] Package Installation: Schedule Time not working

[Robert Paschedag]

Am 3. Juli 2017 16:21:25 MESZ schrieb Sreejith P G :
>Team,
> I am trying to install a package on my client from spacwalk server
>using osa-dispatcher and getting below expected check in time and I am
>not
>able to schedule package installation with any scheduled time of my
>choice.
>Is there any way that I can change it to my choice?
>
> Confirm Package Install
>System last check-in: 7/3/17 9:52:09 PM AWST (0 days 0 hours 4 minutes
>ago)
>Current Spacewalk time: 7/3/17 9:56:10 PM AWST
>Expected check-in time: 7/3/17 11:52:09 PM AWST (0 days 1 hour 55
>minutes
>from now)

You set the installation date and time when you select the package for 
installation. Just before you have to "confirm". By default, it says... "as 
soon as possible"

Robert

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

Re: [Spacewalk-list] Problem installing Spacewalk on CentOS7 (Brand new install)

[Robert Paschedag]

ROR: unhandled exception
>occurred:
>(unicode argument expected, got 'str').
>Jun 27 16:59:05 NETMAN systemd: osa-dispatcher.service: control process
>exited, code=exited status=255
>Jun 27 16:59:05 NETMAN systemd: Failed to start OSA Dispatcher daemon.
>Jun 27 16:59:05 NETMAN systemd: Unit osa-dispatcher.service entered
>failed
>state.
>Jun 27 16:59:05 NETMAN systemd: osa-dispatcher.service failed.
>
>The three errors logged by osa-dispatcher seem to be caused by the
>jabberd/c2s error. Also, the URL listed in the error is a page that
>requires a RedHat support account which I do not have.
>
>As a followup to the prior messages, here is a snippet from
>/etc/jabberd/c2s.xml:
>
>...
>
>...
> pemfile="/etc/pki/spacewalk/jabberd/server.pem" realm=""
>register-enable="true">NETMAN.ad.brucewainer.com
>...
>
>...
>
>
>and from /etc/jabberd/sm.xml:
>
>NETMAN.ad.brucewainer.com
>...
>
>...
>NETMAN.ad.brucewainer.com
>...
>
>...
>
>
>Again, both of these files seem to have been pre-configured properly by
>the
>install script, and if there was a problem with these files it would
>mean
>there is a bug in the installer, as I haven't edited these files, and
>there
>was no instruction to do so.
>
>Bruce
>
>Bruce Wainer
>
>On Tue, Jun 27, 2017 at 12:19 PM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 27. Juni 2017 17:43:22 MESZ schrieb Bruce Wainer
><br...@brucewainer.com
>> >:
>> >Robert,
>> >
>> >Thanks for the attempt at helping, but I've already checked these
>two
>> >xml files. The spacewalk installer had properly set up the 
>> >entries, and the redhat troubleshooting page I linked in my original
>> >thread includes checking the contents of these files also. I believe
>I
>> >have also looked at this particular page as well in the past - I
>really
>> >have looked at almost every google result for relevant search terms
>on
>> >this error.
>> >
>> >Bruce
>> >
>> >> On Jun 27, 2017, at 7:23 AM, Robert Paschedag
>> ><robert.pasche...@web.de> wrote:
>> >>
>> >>
>> >> Hi Bruce,
>> >>
>> >> maybe this might help. Just a quick googleing.
>> >>
>> >> https://discussions.apple.com/thread/3706169?start=0=0 (not
>a
>> >spacewalk link... I know ;-) )
>> >>
>> >> Robert
>> >>
>> >> Gesendet: Dienstag, 27. Juni 2017 um 08:18 Uhr
>> >> Von: "Bruce Wainer" <br...@brucewainer.com>
>> >> An: spacewalk-list@redhat.com
>> >> Betreff: Re: [Spacewalk-list] Problem installing Spacewalk on
>CentOS7
>> >(Brand new install)
>> >> Robert,
>> >> Using any type of DNS lookup tool does properly resolve the FQDN
>to
>> >the machine's IP address, both on this machine and on others in the
>> >network that use the internal DNS servers. Is reverse lookups (IP ->
>> >FQDN) required as well?
>> >>
>> >> # host netman.ad.brucewainer.com
>> >> netman.ad.brucewainer.com has address 192.168.10.20
>> >>
>> >> Thanks,
>> >> Bruce
>> >>
>> >> Bruce Wainer
>> >>
>> >>> On Tue, Jun 27, 2017 at 12:34 AM, Robert Paschedag
>> ><robert.pasche...@web.de> wrote:
>> >>> Am 27. Juni 2017 03:25:00 MESZ schrieb Bruce Wainer
>> ><br...@brucewainer.com>:
>> >>> >Hello all,
>> >>> >
>> >>> >I have found an issue installing SpaceWalk on CentOS7 that I
>have
>> >not
>> >>> >been
>> >>> >able to diagnose/resolve (aside from the required downgrade of
>c3p0
>> >as
>> >>> >mentioned here
>https://bugzilla.redhat.com/show_bug.cgi?id=1442140
>> >).
>> >>> >
>> >>> >Issue: osa-dispatcher.service crashes on start with "'Not able
>to
>> >>> >reconnect"
>> >>> >
>> >>> >Background Information: Brand new install of CentOS7, set the
>> >hostname
>> >>> >durin the installer, ran updates, made sure hostname was correct
>in
>> >all
>> >>> >locations including /etc/hosts, followed the spacewalk
>installation
>> >>> >instructions verbatim.
>> >>> >
>> >>> >Every time osa-dispatcher is started, "journal -xe" logs the
>> >follow

Re: [Spacewalk-list] Proxy Provisioning Entitlement missing in v2.6

[Robert Paschedag]

Am 27. Juni 2017 22:02:53 MESZ schrieb Daryl Rose <darylr...@outlook.com>:
>Hmmm..not sure what you mean by that.
>
>
>When I first stood up the proxy a year or so ago, I had to specifically
>enable the provisioning entitlement in the SW server to be a proxy
>server.  Granted I was on an older version of SW, but installation
>instructions still call for an provisioning entitlement.
>
>
>[cid:90c62485-4b7a-463c-8027-c86d59c4ce3d]
>
>
>Since I don't need a specific provisioning entitlement when I register
>the proxy server to the SW server, the clients that register via the
>proxy should be able to communicate with no issues, correct?  Since
>they are not communicating,  I need to find another reason for the
>clients not connecting, correct?
>
>
>Thanks
>
>
>Daryl
>
>
>
>From: Robert Paschedag <robert.pasche...@web.de>
>Sent: Tuesday, June 27, 2017 1:54 PM
>To: spacewalk-list@redhat.com; Daryl Rose; spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Proxy Provisioning Entitlement missing in
>v2.6
>
>
>You don't need any entitlements to manage clients. Otherwise that would
>be a knock out for spacewalk as the product would be useless then.
>
>Robert

Hi Daryl,

I'm sorry, but I can't help you here, because I do - not yet - use a proxy. So 
I have no experience in using that.  Hopefully someone else can point you in 
the right direction.

Robert

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

Re: [Spacewalk-list] Proxy Provisioning Entitlement missing in v2.6

[Robert Paschedag]

Am 27. Juni 2017 20:21:58 MESZ schrieb Daryl Rose <darylr...@outlook.com>:
>Robert,
>
>
>So, what do I do?  How do I re-entitle the proxy server?
>
>
>Thanks
>
>
>Daryl
>
>
>____
>From: Robert Paschedag <robert.pasche...@web.de>
>Sent: Tuesday, June 27, 2017 11:17 AM
>To: spacewalk-list@redhat.com; Daryl Rose; spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Proxy Provisioning Entitlement missing in
>v2.6
>
>Am 27. Juni 2017 17:29:40 MESZ schrieb Daryl Rose
><darylr...@outlook.com>:
>>I initially posted this a couple of weeks ago, but I have never
>>received a response, so I'm trying again.
>>
>>
>>I rebuilt my proxy server.  We are moving from RHEL to CentOS, so the
>>new server is CentOS 7 something.  Anyway, in the previous version of
>>SW, in the "Activation Keys", there was a "Provisioning" check box.  I
>>no longer see the provisioning check box.
>>
>>
>>Does anyone know what happened to the provisioning entitlement in v2.6
>>and how do I provision the proxy to the primary SW server?
>>
>>
>>Thank you.
>>
>>
>>Daryl
>
>Hi Daryl,
>
>We just had this today. The entitlements are gone since version 2.5.
>Please see the release notes for version 2.5
>
>Robert

You don't need any entitlements to manage clients. Otherwise that would be a 
knock out for spacewalk as the product would be useless then.

Robert

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

Re: [Spacewalk-list] Problem installing Spacewalk on CentOS7 (Brand new install)

[Robert Paschedag]

Am 27. Juni 2017 17:43:22 MESZ schrieb Bruce Wainer <br...@brucewainer.com>:
>Robert,
>
>Thanks for the attempt at helping, but I've already checked these two
>xml files. The spacewalk installer had properly set up the 
>entries, and the redhat troubleshooting page I linked in my original
>thread includes checking the contents of these files also. I believe I
>have also looked at this particular page as well in the past - I really
>have looked at almost every google result for relevant search terms on
>this error.
>
>Bruce
>
>> On Jun 27, 2017, at 7:23 AM, Robert Paschedag
><robert.pasche...@web.de> wrote:
>> 
>>  
>> Hi Bruce,
>>  
>> maybe this might help. Just a quick googleing.
>>  
>> https://discussions.apple.com/thread/3706169?start=0=0 (not a
>spacewalk link... I know ;-) )
>>  
>> Robert
>>  
>> Gesendet: Dienstag, 27. Juni 2017 um 08:18 Uhr
>> Von: "Bruce Wainer" <br...@brucewainer.com>
>> An: spacewalk-list@redhat.com
>> Betreff: Re: [Spacewalk-list] Problem installing Spacewalk on CentOS7
>(Brand new install)
>> Robert,
>> Using any type of DNS lookup tool does properly resolve the FQDN to
>the machine's IP address, both on this machine and on others in the
>network that use the internal DNS servers. Is reverse lookups (IP ->
>FQDN) required as well?
>> 
>> # host netman.ad.brucewainer.com
>> netman.ad.brucewainer.com has address 192.168.10.20
>>  
>> Thanks,
>> Bruce
>>  
>> Bruce Wainer
>>  
>>> On Tue, Jun 27, 2017 at 12:34 AM, Robert Paschedag
><robert.pasche...@web.de> wrote:
>>> Am 27. Juni 2017 03:25:00 MESZ schrieb Bruce Wainer
><br...@brucewainer.com>:
>>> >Hello all,
>>> >
>>> >I have found an issue installing SpaceWalk on CentOS7 that I have
>not
>>> >been
>>> >able to diagnose/resolve (aside from the required downgrade of c3p0
>as
>>> >mentioned here https://bugzilla.redhat.com/show_bug.cgi?id=1442140
>).
>>> >
>>> >Issue: osa-dispatcher.service crashes on start with "'Not able to
>>> >reconnect"
>>> >
>>> >Background Information: Brand new install of CentOS7, set the
>hostname
>>> >durin the installer, ran updates, made sure hostname was correct in
>all
>>> >locations including /etc/hosts, followed the spacewalk installation
>>> >instructions verbatim.
>>> >
>>> >Every time osa-dispatcher is started, "journal -xe" logs the
>following
>>> >3
>>> >times (I think due to three connection attempts)
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: [7]
>>> >[:::192.168.10.20, port=45018] connect
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: [7]
>>> >[:::192.168.10.20, port=45018] disconnect jid=unbound, packets:
>0,
>>> >bytes: 168
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>>> >callback
>>> >for non-existing host: NETMAN.ad.brucewainer.com
>>

Re: [Spacewalk-list] Proxy Provisioning Entitlement missing in v2.6

[Robert Paschedag]

Am 27. Juni 2017 17:29:40 MESZ schrieb Daryl Rose :
>I initially posted this a couple of weeks ago, but I have never
>received a response, so I'm trying again.
>
>
>I rebuilt my proxy server.  We are moving from RHEL to CentOS, so the
>new server is CentOS 7 something.  Anyway, in the previous version of
>SW, in the "Activation Keys", there was a "Provisioning" check box.  I
>no longer see the provisioning check box.
>
>
>Does anyone know what happened to the provisioning entitlement in v2.6
>and how do I provision the proxy to the primary SW server?
>
>
>Thank you.
>
>
>Daryl

Hi Daryl,

We just had this today. The entitlements are gone since version 2.5. Please see 
the release notes for version 2.5

Robert

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

Re: [Spacewalk-list] Problem installing Spacewalk on CentOS7 (Brand new install)

[Robert Paschedag]

Am 27. Juni 2017 08:18:45 MESZ schrieb Bruce Wainer <br...@brucewainer.com>:
>Robert,
>Using any type of DNS lookup tool does properly resolve the FQDN to the
>machine's IP address, both on this machine and on others in the network
>that use the internal DNS servers. Is reverse lookups (IP -> FQDN)
>required
>as well?
>
># host netman.ad.brucewainer.com
>netman.ad.brucewainer.com has address 192.168.10.20
>
>Thanks,
>Bruce
>
>Bruce Wainer
>
>On Tue, Jun 27, 2017 at 12:34 AM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 27. Juni 2017 03:25:00 MESZ schrieb Bruce Wainer
><br...@brucewainer.com
>> >:
>> >Hello all,
>> >
>> >I have found an issue installing SpaceWalk on CentOS7 that I have
>not
>> >been
>> >able to diagnose/resolve (aside from the required downgrade of c3p0
>as
>> >mentioned here https://bugzilla.redhat.com/show_bug.cgi?id=1442140
>).
>> >
>> >Issue: osa-dispatcher.service crashes on start with "'Not able to
>> >reconnect"
>> >
>> >Background Information: Brand new install of CentOS7, set the
>hostname
>> >durin the installer, ran updates, made sure hostname was correct in
>all
>> >locations including /etc/hosts, followed the spacewalk installation
>> >instructions verbatim.
>> >
>> >Every time osa-dispatcher is started, "journal -xe" logs the
>following
>> >3
>> >times (I think due to three connection attempts)
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: [7]
>> >[:::192.168.10.20, port=45018] connect
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: [7]
>> >[:::192.168.10.20, port=45018] disconnect jid=unbound, packets:
>0,
>> >bytes: 168
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >Jun 26 21:09:37 NETMAN.ad.brucewainer.com jabberd/c2s[1003]: SASL
>> >callback
>> >for non-existing host: NETMAN.ad.brucewainer.com
>> >
>> >Based on this it seems like jabberd isn't recognizing the hostname,
>but
>> >I
>> >have followed the "Resolution" and "Diagnostic Steps" here:
>> >https://access.redhat.com/solutions/327903 to no avail, as well as
>> >every
>> >other google result related to "SASL callback for non-existing
>host".
>> >Since
>> >my hostname was set during the installation, it was automatically
>and
>> >correctly put into every config file that matters, other than
>> >/etc/hosts
>> >which I have rechecked a haf dozen times. You can see in the
>journalctl
>> >output that the host that jabberd is seeing matches the actual
>> >hostname.
>> >I've done the complete setup from scratch twice to make sure I
>hadn't
>> >missed any step in the installation instructions.
>> >
>> >Joe Belliveau, it sounded like you ran into an issue like this with
>> >your
>> >new install?
>> >
>> >Thanks in advance for any assistance,
>> >Bruce Wainer
>>
>> So Testing your DNS resolution with "dig" or "host" or "nslookup"
>does
>> resolve your hostname correctly?
>>
>> Just found this right now but it looks there was no answer yet...
>>
>>
>https://www.redhat.com/archives/spacewalk-list/2017-February/msg00022.html
>>
>> Robert
>>
>>
>>

Hi Bruce,

No, PTR record is not a must have here.

Please check the jabber configuration files in /etc/jabberd/

c2s.xml

And the others. Just don't have them on my mind right now. Sorry. Be sure, that 
the "" tags are correct.

Robert

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

Re: [Spacewalk-list] Unable to find any 'Entitlements' in Spacewalk

[Robert Paschedag]

 

I'm sorry.the picture I added before was from my "old" SW 2.4 installation. Not from my "testing" SW 2.6 system.

 


Gesendet: Dienstag, 27. Juni 2017 um 13:57 Uhr
Von: "Vipul Sharma (GDC)" <sharma.vi...@in.g4s.com>
An: "Robert Paschedag" <robert.pasche...@web.de>
Cc: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Unable to find any 'Entitlements' in Spacewalk


Hi,
 

There is nothing wrong with the repo - I've checked multiple times, There is nor el6 repo not it's base address anywhere in my repos.

 

Second, I have constructed a new spacewalk server now - It's based out on Centos6 this time.

 

Same issue -- So, In order to add new systems, The activation key needs to be present - When i'm adding new key, I have only 1 type of entitlement 

available over there - There are 4 different choices, I can see only 1. If i add any systems, It will only be entitled to Virtualisation. 

 

PS :- Please let me know, If i'm saying the right things.

 


​ 


 
On Tue, Jun 27, 2017 at 4:17 PM, Robert Paschedag <robert.pasche...@web.de> wrote:

Am 27. Juni 2017 11:24:07 MESZ schrieb "Vipul Sharma (GDC)" <sharma.vi...@in.g4s.com>:
>Hi Team,
>
>This is an insane issue, I don't know how to sort this one out - This
>is a
>brand new installation of spacewalk - Tom tried helping me out during
>weekends, Somehow we are still there with the problem --
>
>I'm unable to run activation *rhn-satellite-activate* due to missing
>packages - Lot of dependency errors -
>
>--> Running transaction check---> Package spacewalk-backend-cdn.noarch
>0:2.6.78-1.el6 will be updated---> Package spacewalk-backend-cdn.noarch
>0:2.6.78-1.el7 will be an update--> Processing Dependency:
>cdn-sync-mappings for package:
>spacewalk-backend-cdn-2.6.78-1.el7.noarch-->
>Finished Dependency ResolutionError: Package:
>spacewalk-backend-cdn-2.6.78-1.el7.noarch
>(spacewalk) Requires: *cdn-sync-mappings* You could try using
>--skip-broken
>to work around the problem** Found 3 pre-existing rpmdb problem(s),
>'yum
>check' output follows:spacewalk-backend-cdn-2.6.78-1.el6.noarch has
>missing
>requires of cdn-sync-mappingsspacewalk-backend-cdn-2.6.78-1.el6.noarch
>has
>missing requires of python(abi) = ('0', '2.6', None)
>spacewalk-backend-cdn-2.6.78-1.el6.noarch has missing requires of
>spacewalk-backend-server = ('0', '2.6.78', '1.el6')
>Package -- *cdn-sync-mappings, Was nowhere to be found, Tried to
>download
>it manually - But it is not available.*
>*This is a new box of 'Spacewalk' - Same issue - No entitlements ??*
>
>​

I still *think* that your repos are not setup correctly.

Please, what distribution are you using as please show output of

cat /etc/yum.repos.d/*

Because this...

>--> Running transaction check---> Package spacewalk-backend-cdn.noarch
>0:2.6.78-1.el6 will be updated---> Package spacewalk-backend-cdn.noarch
>0:2.6.78-1.el7 will be an update-->

... The same package with .el6 and .el7 does not look right.

Robert


 

 
Please consider the environment before printing this email.
*
This communication may contain information which is confidential, personal and/or privileged. It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited. If you have received it in error please contact the sender immediately by return e-mail. Please then delete the e-mail and any copies of it and do not use or disclose its contents to any person.
Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.
This message has been checked for viruses on behalf of the company.
*
 


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