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

[Robert Paschedag]

 

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

 



___ 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] Unable to find any 'Entitlements' in Spacewalk

[Robert Paschedag]

Am 27. Juni 2017 11:24:07 MESZ schrieb "Vipul Sharma (GDC)" 
:
>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

___
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 03:25:00 MESZ schrieb Bruce Wainer :
>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



___
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]

Am 25. Juni 2017 18:49:40 MESZ schrieb "Vipul Sharma (GDC)" 
<sharma.vi...@in.g4s.com>:
>Hi Robert,
>
>By any chance are you available on Slack,Hangout or Skype - I'm also
>not
>sure about your time-zone. Can you let me know that, This will help me
>sort
>this out real smoothly.
>
>Thanks
>
>On Sun, Jun 25, 2017 at 5:42 PM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 25. Juni 2017 10:22:57 MESZ schrieb "Vipul Sharma (GDC)" <
>> sharma.vi...@in.g4s.com>:
>> >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.*
>> >Also, I re-launched a new box of 'Spacewalk' - Same issue - No
>> >entitlements
>> >??
>> >
>> >​
>>
>> So first check your repository setup
>>

Hi Vipul,

I got neither of these. Please look at the wiki pages here 
https://github.com/spacewalkproject/spacewalk. There is a step by step guide.

The installation is no problem if your repositories are setup right and then 
you shouldn't have a problem with the entitlements.

As I said, it looks to me that you have setup 2 repositories for the same 
"channels" One with EPEL/CENTOS 6 and one with 7.

Good luck.

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]

Am 25. Juni 2017 10:22:57 MESZ schrieb "Vipul Sharma (GDC)" 
:
>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.*
>Also, I re-launched a new box of 'Spacewalk' - Same issue - No
>entitlements
>??
>
>​

So first check your repository setup

___
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]

Am 25. Juni 2017 10:22:57 MESZ schrieb "Vipul Sharma (GDC)" 
:
>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.*
>Also, I re-launched a new box of 'Spacewalk' - Same issue - No
>entitlements
>??
>
>​

It looks like you are mixing centos 6 and 7 repositories.

See the .el6... and .el7... package names.

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]

Am 24. Juni 2017 11:08:42 MESZ schrieb "Vipul Sharma (GDC)" 
<sharma.vi...@in.g4s.com>:
>Hi Robert,
>
>I just installed Spacewalk - Due to some unknown reasons - I'm unable
>to
>see any entitlements even though i'm the spacewalk admin. I have
>checked
>the spacewalk-public.cert file and the entitlements are there, Can you
>please help me out in figuring what is wrong with the box.
>
>I searched various forums, They suggested to reactivate the certificate
>- I
>tried doing that, Somehow it's saying unknown command due missing
>packages.
>
>Second way, Was to make some changes in DB { Postgresql }, I just don't
>know what changes to make - Will really appreciate,  If you can help me
>-
>Below is the CERT-FILE --
>
>SPACEWALK-001
>Hidden by the admin
>2007-07-13 00:00:00
>2018-07-13 00:00:00
>2 name="monitoring-slots">2 name="provisioning-slots">2 name="virtualization_host">2 name="virtualization_host_platform">2
>name="satellite-version">spacewalk name="generation">2
>
>On Fri, Jun 23, 2017 at 10:33 PM, Robert Paschedag
><robert.pasche...@web.de>
>wrote:
>
>> Am 23. Juni 2017 15:01:46 MESZ schrieb "Vipul Sharma (GDC)" <
>> sharma.vi...@in.g4s.com>:
>> >Hi Team,
>> >
>> >Anyone there to help me out with this ?
>> >
>> >Thanks
>> >
>> >On Fri, Jun 23, 2017 at 3:21 PM, Vipul Sharma (GDC)
>> ><sharma.vi...@in.g4s.com
>> >> wrote:
>> >
>> >> Hi Team,
>> >>
>> >> I'm new to spacewalk & from past 24 hours struggling to figure out
>> >why
>> >> there is NO Entitlements available for me.
>> >>
>> >> Been through all the forums but this is a wicked issue - Can
>anyone
>> >please
>> >> point me to the right direction.
>> >>
>> >> Thanks
>> >> Vipul
>> >>
>> >>
>>
>> What exactly is your problem right now? Unable to manage clients?
>>
>> Robert
>>

And this does not work?

https://www.redhat.com/archives/spacewalk-list/2015-July/msg00053.html

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]

Am 23. Juni 2017 15:01:46 MESZ schrieb "Vipul Sharma (GDC)" 
:
>Hi Team,
>
>Anyone there to help me out with this ?
>
>Thanks
>
>On Fri, Jun 23, 2017 at 3:21 PM, Vipul Sharma (GDC)
>> wrote:
>
>> Hi Team,
>>
>> I'm new to spacewalk & from past 24 hours struggling to figure out
>why
>> there is NO Entitlements available for me.
>>
>> Been through all the forums but this is a wicked issue - Can anyone
>please
>> point me to the right direction.
>>
>> Thanks
>> Vipul
>>
>>

What exactly is your problem right now? Unable to manage clients?

Robert

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

Re: [Spacewalk-list] conflicting distributions for ubuntu trusty and lingering packages that still show as upgradable in console

[Robert Paschedag]

Am 9. Juni 2017 15:31:33 MESZ schrieb lrav...@us.hellmann.net:
>Good morning Everyone,
>
>I've been able to push updates to an Ubuntu Trusty box that I've been 
>testing Spacewalk with and am running into some issues.  The first
>issue 
>I've run into is when running an "apt-get update".  It will give me a 
>conflicting distribution warning:
>
>W: Conflicting distribution: spacewalk://spacewalk.domain
>trusty-security 
>Release (expected trusty-security but got trusty)
>W: Conflicting distribution: spacewalk://spacewalk.domain
>trusty-updates 
>Release (expected trusty-updates but got trusty)
>W: Conflicting distribution: spacewalk://spacewalk.domain
>trusty-backports 
>Release (expected trusty-backports but got trusty)
>
>Not too many of threads online that I've been able to get some useful 
>information from in order to resolve it and not even sure this is a
>deal 
>breaker.  I've run and "apt-get clean" and recreated the 
>/var/lib/apt/lists directory but still the issue persists.
>
>My next issue is with package installation.  I've been able to deploy
>the 
>packages from the spacewalk console but I'm still left two packages:
>
>adduser-3.113ubuntu2-X.all-deb
>python-debian-0.1.21ubuntu1-X.all-deb
>
>However, the console shows that the following two are the packages 
>installed:
>
>adduser-3.113+nmu3ubuntu3-0.all-deb 
>python-debian-0.1.21+nmu2ubuntu2-0.all-deb 
>
>Seems like the latest versions are installed but I don't understand
>enough 
>about the naming convention of debian packages to know the difference 
>here. 
>
>Related to this is the fact that if I do an apt-get upgrade on the box,
>
>there are some packages that show up that are not listed in the
>spacewalk 
>console.  If I try to upgrade them from there, I'll get a 404 Not Found
>
>error.  Let's take one of the packages, for example:
>
>E: Failed to fetch 
>spacewalk://spacewalk.domain/XMLRPC/GET-REQ/trusty-updates/getPackage/vim-2:7.4.052-1ubuntu3.1.amd64-deb.deb
>
> 404  Not Found
>
>If I run a "dpkg -s vim" on the client I'll get the following:
>
>Package: vim
>Status: install ok installed
>Priority: optional
>Section: editors
>Installed-Size: 2185
>Maintainer: Ubuntu Developers 
>Architecture: amd64
>Version: 2:7.4.052-1ubuntu3
>
>So it seems like there is a discrepancy between the client and server 
>regarding what packages are installed.  Anyone else have any experience
>
>with this?
>
>Regards,
>
>Lazaro Ravelo
>ISS Systems Engineer II
>
>Hellmann Worldwide Logistics Inc.
>10450 Doral Blvd
>Doral, FL  33178
>Phone:  +1 305 406 4500
>Fax:  +1 305 418 4992
>Direct:  +1 305 406 4574
>Mobile:  +1 305 927 1386
>Email:  lazaro.rav...@us.hellmann.net
>Web:  www.hellmann.com
> 
>THINKING AHEAD - MOVING FORWARD
>
>06/09/201709:08:43 AM
>
>
>>Disclaimer: Please note that Internet communications are not secure
>and 
>therefore HELLMANN WORLDWIDE LOGISTICS does not accept legal 
>responsibility for the contents of this message. This e-mail is
>intended 
>only for the use of the individual or entity named above and may
>contain 
>information that is confidential and privileged. If you are not the 
>intended recipient, you are hereby notified that any dissemination, 
>distribution or copying of this e-mail is strictly prohibited.
>Opinions, 
>conclusions and other information in this message that do not relate to
>
>the official business of HELLMANN WORLDWIDE LOGISTICS shall be
>understood 
>as neither given nor endorsed by it. Viruses: HELLMANN WORLDWIDE
>LOGISTICS 
>takes all possible steps to ensure that emails are virus free, but does
>
>not accept any liability or responsibility whatsoever for any claims, 
>losses or damages arising as a result of any party accessing this email
>or 
>files attached to it.

Hi Lazaro,

did you install the necessary spacewalk client packages and registered the 
client to the server with "rhnreg_ks"?

If you did the, the spacewalk plugin for apt manages the repos your client is 
subscribed to on the server and an "apt-get update" is all you need. No need to 
"recreate" the package lists.

What does "rhn-channel" and "rhn_check" tell on the client?

Robert



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

Re: [Spacewalk-list] Error connecting to jabber

[Robert Paschedag]

Am 22. Mai 2017 23:17:15 MESZ schrieb InvalidPath :
>Hey everyone.  Another person here having the whole can't connect to
>jabber
>server issue.
>
>I've gone through the verifying of hostname, hosts, resolv, etc files.
>I've ran the spacewalk-hostname-rename binary.
>
>root@automation:/usr/bin$ /usr/sbin/spacewalk-service status
>
>Redirecting to /bin/systemctl status  postgresql.service
>
>● postgresql.service - PostgreSQL database server
>
>  Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled;
>vendor preset: disabled)
>  Active: active (running) since Mon 2017-05-22 14:52:07 MDT; 44s ago
> Process: 15302 ExecStop=/usr/bin/pg_ctl stop -D ${PGDATA} -s -m fast
>(code=exited, status=0/SUCCESS)
> Process: 15331 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p
>${PGPORT} -w -t 300 (code=exited, status
>=0/SUCCESS)
> Process: 15325 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA}
>(code=exited, status=0/SUCCESS)
>Main PID: 15334 (postgres)
>  CGroup: /system.slice/postgresql.service
>  ├─15334 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432
>  ├─15335 postgres: logger process
>  ├─15337 postgres: checkpointer process
>  ├─15338 postgres: writer process
>  ├─15339 postgres: wal writer process
>  ├─15340 postgres: autovacuum launcher process
>  ├─15341 postgres: stats collector process
>  ├─15449 postgres: rhnuser rhnschema 127.0.0.1(50548) idle
>  ├─15450 postgres: rhnuser rhnschema 127.0.0.1(50549) idle
>  ├─15451 postgres: rhnuser rhnschema 127.0.0.1(50552) idle
>  ├─15452 postgres: rhnuser rhnschema 127.0.0.1(50554) idle
>  ├─15453 postgres: rhnuser rhnschema 127.0.0.1(50556) idle
>  ├─15737 postgres: rhnuser rhnschema 127.0.0.1(50560) idle
>  ├─15738 postgres: rhnuser rhnschema 127.0.0.1(50563) idle
>  ├─15739 postgres: rhnuser rhnschema 127.0.0.1(50562) idle
>  ├─15740 postgres: rhnuser rhnschema 127.0.0.1(50566) idle
>  ├─15741 postgres: rhnuser rhnschema 127.0.0.1(50568) idle
>  ├─15742 postgres: rhnuser rhnschema 127.0.0.1(50570) idle
>  ├─15743 postgres: rhnuser rhnschema 127.0.0.1(50572) idle
>  ├─15744 postgres: rhnuser rhnschema 127.0.0.1(50574) idle
>  ├─15745 postgres: rhnuser rhnschema 127.0.0.1(50576) idle
>  ├─15781 postgres: rhnuser rhnschema 127.0.0.1(50580) idle
>  ├─15828 postgres: rhnuser rhnschema 127.0.0.1(50582) idle
>  ├─15829 postgres: rhnuser rhnschema 127.0.0.1(50584) idle
>  ├─15830 postgres: rhnuser rhnschema 127.0.0.1(50586) idle
>  ├─15831 postgres: rhnuser rhnschema 127.0.0.1(50588) idle
>  ├─15832 postgres: rhnuser rhnschema 127.0.0.1(50590) idle
>  ├─15835 postgres: rhnuser rhnschema 127.0.0.1(50592) idle
>  ├─15841 postgres: rhnuser rhnschema 127.0.0.1(50606) idle
>  ├─15842 postgres: rhnuser rhnschema 127.0.0.1(50608) idle
>  └─15844 postgres: rhnuser rhnschema 127.0.0.1(50612) idle
>
>May 22 14:52:06 automation.egovmt.com systemd[1]: Starting PostgreSQL
>database server...
>May 22 14:52:07 automation.egovmt.com systemd[1]: Started PostgreSQL
>database server.
>Redirecting to /bin/systemctl status  jabberd.service
>● jabberd.service - Jabber Server
>Loaded: loaded (/usr/lib/systemd/system/jabberd.service; enabled;
>vendor
>preset: disabled)
>  Active: inactive (dead) since Mon 2017-05-22 14:52:07 MDT; 44s ago
> Process: 15362 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
>Main PID: 15362 (code=exited, status=0/SUCCESS)
>
>May 22 14:52:07 automation.egovmt.com systemd[1]: Starting Jabber
>Server...
>May 22 14:52:07 automation.egovmt.com systemd[1]: Started Jabber
>Server.
>May 22 14:52:07 automation.egovmt.com systemd[1]: Stopped Jabber
>Server.
>May 22 14:52:07 automation.egovmt.com systemd[1]: Stopping Jabber
>Server...
>Redirecting to /bin/systemctl status  tomcat.service
>● tomcat.service - Apache Tomcat Web Application Container
>Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; vendor
>preset: disabled)
>  Active: active (running) since Mon 2017-05-22 14:52:07 MDT; 44s ago
>Main PID: 15381 (java)
>  CGroup: /system.slice/tomcat.service
>  └─15381 /usr/lib/jvm/jre/bin/java -ea -Xms256m -Xmx256m
>-Djava.awt.headless=true -Dorg.xml.sax.dr...
>
>May 22 14:52:34 automation.egovmt.com server[15381]: May 22, 2017
>2:52:34
>PM org.apache.catalina.startuptor
>May 22 14:52:34 automation.egovmt.com server[15381]: INFO: Deployment
>of
>configuration descriptor /etc/to... ms
>May 22 14:52:34 automation.egovmt.com server[15381]: May 22, 2017
>2:52:34
>PM org.apache.coyote.AbstractPr...art
>May 22 14:52:34 automation.egovmt.com server[15381]: INFO: Starting
>ProtocolHandler ["http-bio-127.0.0.1-8080"]
>May 22 14:52:34 automation.egovmt.com server[15381]: May 22, 2017
>2:52:34
>PM org.apache.coyote.AbstractPr...art
>May 22 14:52:34 automation.egovmt.com 

Re: [Spacewalk-list] Clients don't pull command with rhn_check

[Robert Paschedag]

Am 12. März 2017 20:03:39 MEZ schrieb Konstantin Raskoshnyi 
:
>Hi folks, I updated to 2.6, for a week everything was fine, today none
>of
>clients cat pull any commands
>
>When I do rhn_check -v -v -v -v -v
>
>I see:
>
>D: opening  db environment /var/lib/rpm cdb:mpool:joinenv
>D: opening  db index   /var/lib/rpm/Packages rdonly mode=0x0
>D: locked   db index   /var/lib/rpm/Packages
>D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
>D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
>D: loading keyring from rpmdb
>D: opening  db index   /var/lib/rpm/Name rdonly mode=0x0
>D: added key gpg-pubkey-1d1e034b-42bfd0c5 to keyring
>D: added key gpg-pubkey-f21541eb-4a5233e7 to keyring
>D: added key gpg-pubkey-897da07a-3c979a7f to keyring
>D: added key gpg-pubkey-db42a60e-37ea5438 to keyring
>D: added key gpg-pubkey-37017186-45761324 to keyring
>D: added key gpg-pubkey-42193e6b-4624eff2 to keyring
>D: added key gpg-pubkey-fd431d51-4ae0493b to keyring
>D: added key gpg-pubkey-2fa658e0-45700c69 to keyring
>D: added key gpg-pubkey-192a7d7d-4a5769d0 to keyring
>D: added key gpg-pubkey-eb10625a-4a576ad9 to keyring
>D: added key gpg-pubkey-9505722e-4a576b54 to keyring
>D: added key gpg-pubkey-13a0a2dc-4a576ba5 to keyring
>D: added key gpg-pubkey-9b1fd350-4a576be4 to keyring
>D: Using legacy gpg-pubkey(s) from rpmdb
>D: opening  db index   /var/lib/rpm/Providename rdonly mode=0x0
>D: do_call packages.checkNeedUpdate('rhnsd=1',){}
>D: opening  db environment /var/lib/rpm cdb:mpool:joinenv
>D: opening  db index   /var/lib/rpm/Packages rdonly mode=0x0
>D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
>D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
>D: loading keyring from rpmdb
>D: opening  db index   /var/lib/rpm/Name rdonly mode=0x0
>D: added key gpg-pubkey-1d1e034b-42bfd0c5 to keyring
>D: added key gpg-pubkey-f21541eb-4a5233e7 to keyring
>D: added key gpg-pubkey-897da07a-3c979a7f to keyring
>D: added key gpg-pubkey-db42a60e-37ea5438 to keyring
>D: added key gpg-pubkey-37017186-45761324 to keyring
>D: added key gpg-pubkey-42193e6b-4624eff2 to keyring
>D: added key gpg-pubkey-fd431d51-4ae0493b to keyring
>D: added key gpg-pubkey-2fa658e0-45700c69 to keyring
>D: added key gpg-pubkey-192a7d7d-4a5769d0 to keyring
>D: added key gpg-pubkey-eb10625a-4a576ad9 to keyring
>D: added key gpg-pubkey-9505722e-4a576b54 to keyring
>D: added key gpg-pubkey-13a0a2dc-4a576ba5 to keyring
>D: added key gpg-pubkey-9b1fd350-4a576be4 to keyring
>D: Using legacy gpg-pubkey(s) from rpmdb
>D: opening  db index   /var/lib/rpm/Providename rdonly mode=0x0
>D: closed   db index   /var/lib/rpm/Providename
>D: closed   db index   /var/lib/rpm/Name
>D: closed   db index   /var/lib/rpm/Packages
>D: closed   db environment /var/lib/rpm
>Loaded plugins: rhnplugin
>Config time: 0.036
>D: login(forceUpdate=False) invoked
>D: readCachedLogin invoked
>D: Checking pickled loginInfo, currentTime=148934.88,
>createTime=1489345108.54, expire-offset=3600.0
>D: readCachedLogin(): using pickled loginInfo set to expire at
>1489348708.54
>D: rpcServer: Calling XMLRPC up2date.listChannels
>This system is receiving updates from RHN Classic or Red Hat Satellite.
>Looking for repo options for [main]
>Looking for repo options for [sl6-main]
>Repo 'sl6-main' setting option 'enabled' = '1'
>Repo 'sl6-main' setting option 'gpgcheck' = '0'
>Repo 'sl6-main' setting option 'timeout' = '120'
>Looking for repo options for [sl67-base]
>Repo 'sl67-base' setting option 'enabled' = '1'
>Repo 'sl67-base' setting option 'gpgcheck' = '0'
>Repo 'sl67-base' setting option 'timeout' = '120'
>Looking for repo options for [sl67-updates]
>Repo 'sl67-updates' setting option 'enabled' = '1'
>Repo 'sl67-updates' setting option 'gpgcheck' = '0'
>Repo 'sl67-updates' setting option 'timeout' = '120'
>Looking for repo options for [sl67-chef]
>Repo 'sl67-chef' setting option 'enabled' = '1'
>Repo 'sl67-chef' setting option 'gpgcheck' = '0'
>Repo 'sl67-chef' setting option 'timeout' = '120'
>Looking for repo options for [sl67-hpe]
>Repo 'sl67-hpe' setting option 'enabled' = '1'
>Repo 'sl67-hpe' setting option 'gpgcheck' = '0'
>Repo 'sl67-hpe' setting option 'timeout' = '120'
>Looking for repo options for [sl67-spacewalk]
>Repo 'sl67-spacewalk' setting option 'enabled' = '1'
>Repo 'sl67-spacewalk' setting option 'gpgcheck' = '0'
>Repo 'sl67-spacewalk' setting option 'timeout' = '120'
>Looking for repo options for [sl67-epel]
>Repo 'sl67-epel' setting option 'enabled' = '1'
>Repo 'sl67-epel' setting option 'gpgcheck' = '0'
>Repo 'sl67-epel' setting option 'timeout' = '120'
>rpmdb time: 0.000
>repo time: 0.000
>Setting up Package Sacks
>pkgsack time: 0.133
>D: local action status: (0, 'rpm database not modified since last
>update
>(or package list recently updated)', {})
>D: rpcServer: Calling XMLRPC registration.welcome_message
>D: closed   db index   /var/lib/rpm/Providename
>D: closed   db index 

Re: [Spacewalk-list] Switching the jabberd database to sqlite/pgsql

[Robert Paschedag]

Am 3. März 2017 22:11:27 MEZ schrieb Avi Miller :
>Hi everyone,
>
>I was searching for a simple tutorial on how to switch the jabberd
>database away from the Spacewalk default of BerkeleyDB to something
>more robust. While I did find some scattered documentation, there was
>nothing specific for Spacewalk, so I wrote up two:
>
>Switching to SQLite: 
>
>https://omg.dje.li/2017/02/configuring-spacewalks-jabberd-to-use-an-sqlite-backend/
>
>Switching to PostgreSQL: 
>
>https://omg.dje.li/2017/03/configuring-spacewalks-jabberd-to-use-a-postgresql-backend/
>
>Hopefully someone finds this useful. If anything is unclear or if you
>have any comments/improvements/corrections, please let me know!
>
>Thanks,
>Avi
>
>--
>Oracle 
>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

Hi Avi,

Thank you for sharing this information. Although I did not yet had many 
problems with the jabber db, I heard it should be far better with SQLite.

Regards
Robert

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

Re: [Spacewalk-list] Adding system to Spacewalk

[Robert Paschedag]

Am 28. Februar 2017 05:44:55 MEZ schrieb Avi Miller :
>Hi,
>
>> On 28 Feb 2017, at 3:30 pm, InvalidPath 
>wrote:
>> 
>>>self._connection.connect()
>>>  File "/usr/lib/python2.4/site-packages/rhn/connections.py", line
>185, in
>>> connect
>>>if e.errno != errno.EINTR:
>

Is this ready everything? Does not look like the "real cause". Not something 
like TypeError or something like that after the test?

>I’ve never seen this error before, to be honest.
>
>>> Let me ask a stupid question, does the fact that I do not have a RH
>>> subscriptions for up2date, nor the red Hat Network matter in the use
>of
>>> Spacewalk?
>
>No it doesn’t.
>
>> Well after some time Googling I discovered that I might need osad
>> installed and running, so I did.  Re-ran the rhnreg_ks command with
>> the same cryptic returns.
>
>Osad only works once you’ve successfully registered with Spacewalk.
>
>Are there any errors in /var/log/rhn/* or /var/log/httpd/* or
>/var/log/tomcat/* on your Spacewalk box that might shed some light on
>this?
>
>Cheers,
>Avi
>
>--
>Oracle 
>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 mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] CentOS - RHEL - SLES on Spacewalk

[Robert Paschedag]

Am 24. Februar 2017 16:03:48 MEZ schrieb rosario.matt...@accenture.com:
>Hi,
>is it possible to manage CentOS, RHEL and SLES hosts on Spacewalk,
>avoiding to use Satellite and Suse-Manager?
>
>Best regards,
>Rosario
>
>
>
>This message is for the designated recipient only and may contain
>privileged, proprietary, or otherwise confidential information. If you
>have received it in error, please notify the sender immediately and
>delete the original. Any other use of the e-mail by you is prohibited.
>Where allowed by local law, electronic communications with Accenture
>and its affiliates, including e-mail and instant messaging (including
>content), may be scanned by our systems for the purposes of information
>security and assessment of internal compliance with Accenture policy.
>__
>
>www.accenture.com

In short... Yes

Regards
Robert

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

Re: [Spacewalk-list] Fwd: Re: How to tell what Errata has been applied

[Robert Paschedag]

Am 23. Februar 2017 21:25:49 MEZ schrieb Daryl Rose <darylr...@outlook.com>:
>David,
>
>
>This does look promising.   I think that I'll play with this and see if
>I can make this work.
>
>
>Thank you for passing on this command.   I didn't have it install and
>didn't even know that it existed.
>
>
>Daryl
>
>
>From: spacewalk-list-boun...@redhat.com
><spacewalk-list-boun...@redhat.com> on behalf of David Rock
><da...@graniteweb.com>
>Sent: Thursday, February 23, 2017 1:57 PM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] Fwd: Re: How to tell what Errata has been
>applied
>
>
>> On Feb 23, 2017, at 12:14, Robert Paschedag <robert.pasche...@web.de>
>wrote:
>>
>> But this does not show you the "errata" installed... Just the
>versions of the packages.
>>
>
>what about
>
>spacewalk-report system-history-errata
>
>If you apply your errata via spacewalk directly (i.e., not by running
>yum update locally), this should give you a running list of info about
>applied errata.  It needs a little help because of using systemid, but
>might be what you need.
>
>
>
>—
>David Rock
>da...@graniteweb.com

https://fedorahosted.org/spacewalk/wiki/spacecmd

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

Re: [Spacewalk-list] Fwd: Re: How to tell what Errata has been applied

[Robert Paschedag]

Am 23. Februar 2017 07:45:41 MEZ schrieb Spamm <spa...@e.lublin.pl>:
>On Wed, 22 Feb 2017 22:31:29 +0100, Robert Paschedag wrote
>> Damn... Missed the list again. See answer at the end
>> 
>>  Ursprüngliche Nachricht ----
>> Von: Robert Paschedag <robert.pasche...@web.de>
>> Gesendet: 22. Februar 2017 17:06:55 MEZ
>> An: Daryl Rose <darylr...@outlook.com>
>> Betreff: Re: [Spacewalk-list] How to tell what Errata has been
>applied
>> 
>> Am 22. Februar 2017 16:02:22 MEZ schrieb Daryl Rose
><darylr...@outlook.com>:
>> >Robert,
>> >
>> >
>> >We don't apply every single patch to every single server.  Our
>> >environment has been neglected for so long, that by applying every
>> >patch that comes out will most certainly break something.  So, we
>have
>> >to be selective about what we patch.  I need to be able to easily
>> >identify what patch has been applied to which server when auditors
>> >come.   We are an ISO270001 shop, and get audited every year.  So
>far
>> >they've been pleased with my putting up the Spacewalk environment,
>and
>> >current patching efforts, but some day they're going to ask for a
>list
>> >of applied patches and I want to be able to produce that report when
>> >they ask.  Currently, I track everything in a spreadsheet, but
>that's
>> >getting difficult to maintain, and I was hoping for something that I
>> >could either run on the command line, or from the WUI.
>> >
>> >
>> >Thank you for your input Robert.
>> >
>> >
>> >Daryl
>> >
>> >____
>> >From: Robert Paschedag <robert.pasche...@web.de>
>> >Sent: Tuesday, February 21, 2017 2:21 PM
>> >To: spacewalk-list@redhat.com; Daryl Rose
>> >Subject: Re: [Spacewalk-list] How to tell what Errata has been
>applied
>> >
>> >Am 21. Februar 2017 20:15:13 MEZ schrieb Robert Paschedag
>> ><robert.pasche...@web.de>:
>> >>Am 21. Februar 2017 19:52:00 MEZ schrieb Daryl Rose
>> >><darylr...@outlook.com>:
>> >>>Daniel,
>> >>>
>> >>>
>> >>>I've tried that command, but it tells me what patches are
>available.
>> >>I
>> >>>need to know what patches have already been applied.
>> >>>
>> >>>
>> >>>Thanks
>> >>>
>> >>>
>> >>>Daryl
>> >>>
>> >>>
>> >>>From: spacewalk-list-boun...@redhat.com
>> >>><spacewalk-list-boun...@redhat.com> on behalf of Daniel Swan
>> >>><swan_dan...@hotmail.com>
>> >>>Sent: Tuesday, February 21, 2017 11:51 AM
>> >>>To: spacewalk-list@redhat.com
>> >>>Subject: Re: [Spacewalk-list] How to tell what Errata has been
>> >applied
>> >>>
>> >>>spacecmd system_listerrata $SYSTEM
>> >>>
>> >>>
>> >>>From: darylr...@outlook.com
>> >>>To: spacewalk-list@redhat.com
>> >>>Date: Tue, 21 Feb 2017 15:11:31 +
>> >>>Subject: [Spacewalk-list] How to tell what Errata has been applied
>> >>>
>> >>>Is there a way to list what errata has already been applied to a
>> >>>machine?  I can list what is available, but I need to know what
>has
>> >>>been applied.
>> >>>
>> >>>
>> >>>Thank you.
>> >>>
>> >>>
>> >>>Daryl
>> >>>
>> >>>___ Spacewalk-list
>> >mailing
>> >>>list Spacewalk-list@redhat.com
>> >>>https://www.redhat.com/mailman/listinfo/spacewalk-list
>> >Spacewalk-list Info Page - Red
>> >Hat<https://www.redhat.com/mailman/listinfo/spacewalk-list>
>> >www.redhat.com
>> >To see the collection of prior postings to the list, visit the
>> >Spacewalk-list Archives. Using Spacewalk-list: To post a message to
>all
>> >the list ...
>> >
>> >
>> >
>> >>
>> >>I think you have to search the history of the system which errata
>> >>succeeded.
>> >>
>> >>Regards
>> >>Robert
>> >>
>> >>___
>> >>Spacewalk-list mailing list

[Spacewalk-list] Fwd: Re: How to tell what Errata has been applied

[Robert Paschedag]

Damn... Missed the list again. See answer at the end


 Ursprüngliche Nachricht 
Von: Robert Paschedag <robert.pasche...@web.de>
Gesendet: 22. Februar 2017 17:06:55 MEZ
An: Daryl Rose <darylr...@outlook.com>
Betreff: Re: [Spacewalk-list] How to tell what Errata has been applied

Am 22. Februar 2017 16:02:22 MEZ schrieb Daryl Rose <darylr...@outlook.com>:
>Robert,
>
>
>We don't apply every single patch to every single server.  Our
>environment has been neglected for so long, that by applying every
>patch that comes out will most certainly break something.  So, we have
>to be selective about what we patch.  I need to be able to easily
>identify what patch has been applied to which server when auditors
>come.   We are an ISO270001 shop, and get audited every year.  So far
>they've been pleased with my putting up the Spacewalk environment, and
>current patching efforts, but some day they're going to ask for a list
>of applied patches and I want to be able to produce that report when
>they ask.  Currently, I track everything in a spreadsheet, but that's
>getting difficult to maintain, and I was hoping for something that I
>could either run on the command line, or from the WUI.
>
>
>Thank you for your input Robert.
>
>
>Daryl
>
>
>From: Robert Paschedag <robert.pasche...@web.de>
>Sent: Tuesday, February 21, 2017 2:21 PM
>To: spacewalk-list@redhat.com; Daryl Rose
>Subject: Re: [Spacewalk-list] How to tell what Errata has been applied
>
>Am 21. Februar 2017 20:15:13 MEZ schrieb Robert Paschedag
><robert.pasche...@web.de>:
>>Am 21. Februar 2017 19:52:00 MEZ schrieb Daryl Rose
>><darylr...@outlook.com>:
>>>Daniel,
>>>
>>>
>>>I've tried that command, but it tells me what patches are available.
>>I
>>>need to know what patches have already been applied.
>>>
>>>
>>>Thanks
>>>
>>>
>>>Daryl
>>>
>>>
>>>From: spacewalk-list-boun...@redhat.com
>>><spacewalk-list-boun...@redhat.com> on behalf of Daniel Swan
>>><swan_dan...@hotmail.com>
>>>Sent: Tuesday, February 21, 2017 11:51 AM
>>>To: spacewalk-list@redhat.com
>>>Subject: Re: [Spacewalk-list] How to tell what Errata has been
>applied
>>>
>>>spacecmd system_listerrata $SYSTEM
>>>
>>>
>>>From: darylr...@outlook.com
>>>To: spacewalk-list@redhat.com
>>>Date: Tue, 21 Feb 2017 15:11:31 +
>>>Subject: [Spacewalk-list] How to tell what Errata has been applied
>>>
>>>Is there a way to list what errata has already been applied to a
>>>machine?  I can list what is available, but I need to know what has
>>>been applied.
>>>
>>>
>>>Thank you.
>>>
>>>
>>>Daryl
>>>
>>>___ Spacewalk-list
>mailing
>>>list Spacewalk-list@redhat.com
>>>https://www.redhat.com/mailman/listinfo/spacewalk-list
>Spacewalk-list Info Page - Red
>Hat<https://www.redhat.com/mailman/listinfo/spacewalk-list>
>www.redhat.com
>To see the collection of prior postings to the list, visit the
>Spacewalk-list Archives. Using Spacewalk-list: To post a message to all
>the list ...
>
>
>
>>
>>I think you have to search the history of the system which errata
>>succeeded.
>>
>>Regards
>>Robert
>>
>>___
>>Spacewalk-list mailing list
>>Spacewalk-list@redhat.com
>>https://www.redhat.com/mailman/listinfo/spacewalk-list
>Spacewalk-list Info Page - Red
>Hat<https://www.redhat.com/mailman/listinfo/spacewalk-list>
>www.redhat.com
>To see the collection of prior postings to the list, visit the
>Spacewalk-list Archives. Using Spacewalk-list: To post a message to all
>the list ...
>
>
>
>
>Also... It is not really necessary to know which errata already have
>been applied. Either your system has one or more packages, available
>within an errata, installed (in a lower version!), then an errata "is"
>available (and can/should/must be applied) OR the system has not such
>package installed and therefore "that" errata is not needed on that
>system.
>
>Regards
>Robert

Just thinking... What if you replace your servers right before the audit to a 
brand new os version (just released with the newest versions available), where 
the are not yet any patches available? Your answer to the question will be 
"none".

But as I said...I think your only chance is to review the history of each 
system within spacewalk. 

Regards
Robert

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

Re: [Spacewalk-list] How to tell what Errata has been applied

[Robert Paschedag]

Am 21. Februar 2017 20:15:13 MEZ schrieb Robert Paschedag 
<robert.pasche...@web.de>:
>Am 21. Februar 2017 19:52:00 MEZ schrieb Daryl Rose
><darylr...@outlook.com>:
>>Daniel,
>>
>>
>>I've tried that command, but it tells me what patches are available. 
>I
>>need to know what patches have already been applied.
>>
>>
>>Thanks
>>
>>
>>Daryl
>>
>>
>>From: spacewalk-list-boun...@redhat.com
>><spacewalk-list-boun...@redhat.com> on behalf of Daniel Swan
>><swan_dan...@hotmail.com>
>>Sent: Tuesday, February 21, 2017 11:51 AM
>>To: spacewalk-list@redhat.com
>>Subject: Re: [Spacewalk-list] How to tell what Errata has been applied
>>
>>spacecmd system_listerrata $SYSTEM
>>
>>
>>From: darylr...@outlook.com
>>To: spacewalk-list@redhat.com
>>Date: Tue, 21 Feb 2017 15:11:31 +
>>Subject: [Spacewalk-list] How to tell what Errata has been applied
>>
>>Is there a way to list what errata has already been applied to a
>>machine?  I can list what is available, but I need to know what has
>>been applied.
>>
>>
>>Thank you.
>>
>>
>>Daryl
>>
>>___ Spacewalk-list mailing
>>list Spacewalk-list@redhat.com
>>https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>I think you have to search the history of the system which errata
>succeeded.
>
>Regards
>Robert
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

Also... It is not really necessary to know which errata already have been 
applied. Either your system has one or more packages, available within an 
errata, installed (in a lower version!), then an errata "is" available (and 
can/should/must be applied) OR the system has not such package installed and 
therefore "that" errata is not needed on that system.

Regards
Robert

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

Re: [Spacewalk-list] How to tell what Errata has been applied

[Robert Paschedag]

Am 21. Februar 2017 19:52:00 MEZ schrieb Daryl Rose :
>Daniel,
>
>
>I've tried that command, but it tells me what patches are available.  I
>need to know what patches have already been applied.
>
>
>Thanks
>
>
>Daryl
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of Daniel Swan
>
>Sent: Tuesday, February 21, 2017 11:51 AM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] How to tell what Errata has been applied
>
>spacecmd system_listerrata $SYSTEM
>
>
>From: darylr...@outlook.com
>To: spacewalk-list@redhat.com
>Date: Tue, 21 Feb 2017 15:11:31 +
>Subject: [Spacewalk-list] How to tell what Errata has been applied
>
>Is there a way to list what errata has already been applied to a
>machine?  I can list what is available, but I need to know what has
>been applied.
>
>
>Thank you.
>
>
>Daryl
>
>___ Spacewalk-list mailing
>list Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

I think you have to search the history of the system which errata succeeded.

Regards
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

[Robert Paschedag]

Am 15. Februar 2017 20:08:32 MEZ schrieb Daryl Rose <darylr...@outlook.com>:
>Konstantin,
>
>
>Yes, I can telnet to port 5222.
>
>
>Robert,
>
>
>Here is the verbose output.  I only did three v's, because four is just
>to much information to post.
>
>
>[root@corp-rhel-sndbx ~]# /usr/sbin/osad -N -v -v -v
>
>2017-02-15 12:58:52 osad._setup_config: Updating configuration
>
>2017-02-15 12:58:52 jabber_lib.setup_connection: Connecting to Server>
>
>2017-02-15 12:58:52 jabber_lib._get_jabber_client:
>
>2017-02-15 12:58:52 jabber_lib._get_jabber_client: Connecting to SW Server>
>
>2017-02-15 12:58:52 jabber_lib.__init__:
>
>2017-02-15 12:58:52 jabber_lib.__init__:
>
>2017-02-15 12:58:52 jabber_lib.connect:
>
>2017-02-15 12:58:52 jabber_lib.process: 300
>
>2017-02-15 12:58:52 jabber_lib.process: None
>
>2017-02-15 12:58:53 jabber_lib.process: None
>
>2017-02-15 12:58:53 jabber_lib.process: None
>
>2017-02-15 12:58:53 jabber_lib.setup_connection: Connected to jabber
>server 
>
>2017-02-15 12:58:53 osad_client.start: osad-5aecf197b4
>f6962f84b418c0bdd420 osad
>
>2017-02-15 12:58:53 jabber_lib.auth: osad-5aecf197b4
>f6962f84b418c0bdd420 osad 1
>
>2017-02-15 12:58:53 jabber_lib.process: 59.690056
>
>2017-02-15 12:58:53 jabber_lib.process: 299.38011
>
>2017-02-15 12:58:53 jabber_lib.register_callback: Client._roster_callback of 0x20c6a90>> iq None None None None
>
>2017-02-15 12:58:53 jabber_lib.process: None
>
>2017-02-15 12:58:53 jabber_lib._roster_callback: Updating the roster
>'jabber:iq:roster' >
>
>2017-02-15 12:58:53 jabber_lib.register_callback: Client._presence_callback of 0x20c6a90>> presence None None None None
>
>2017-02-15 12:58:53 jabber_lib.register_callback: Client._message_callback of 0x20c6a90>> message None None None None
>
>2017-02-15 12:58:53 jabber_lib.register_callback: Runner._error_callback of 0x7fa5ed8ece18>> error None None None None
>
>2017-02-15 12:58:53 osad.fix_connection: Time drift 0
>
>2017-02-15 12:58:53 osad.fix_connection: Client name 475c306861c30ddf
>
>2017-02-15 12:58:53 osad.fix_connection: Shared key
>c6074436a1185a81e717c5e1fa0d976b3275cc91
>
>2017-02-15 12:58:53 jabber_lib.send_presence: None None
>
>2017-02-15 12:58:53 jabber_lib.process_forever:
>
>2017-02-15 12:58:53 jabber_lib.process: 180
>
>
>And here it the established connection:
># netstat -an|grep 5222|grep ""
>tcp0  0 ::::5222  :::Address>:60441  ESTABLISHED
>
>Thank you.
>
>Daryl
>
>
>
>From: spacewalk-list-boun...@redhat.com
><spacewalk-list-boun...@redhat.com> on behalf of Robert Paschedag
><robert.pasche...@web.de>
>Sent: Wednesday, February 15, 2017 11:18 AM
>To: spacewalk-list@redhat.com; Konstantin Raskoshnyi
>Subject: Re: [Spacewalk-list] OSAD can't connect to host and port
>
>Am 15. Februar 2017 17:49:22 MEZ schrieb Konstantin Raskoshnyi
><konra...@gmail.com>:
>>Can you do a telnet to port 5222 from client to spacewalk?
>>On Wed, Feb 15, 2017 at 8:07 AM Daryl Rose <darylr...@outlook.com>
>>wrote:
>>
>>> I just did a fresh install of RHEL 6.6.  I installed Spacewalk
>client
>>2.6
>>> onto the server.  All is good with the exception of OSAD.  Whenever
>I
>>try
>>> to start it using services, I get the following error:
>>>
>>>
>>> *# service osad start*
>>>
>>> *Starting osad: 2017-02-15 09:41:40 rhn_log.log_error: Error
>>connecting to
>>> jabber server: Unable to connect to the host and port specified. See
>>> https://access.redhat.com/solutions/327903
>Log in to Your Red Hat Account - Red Hat Customer
>Portal<https://access.redhat.com/solutions/327903>
>access.redhat.com
>Log In. Your Red Hat account gives you access to your profile,
>preferences, and services, depending on your status.
>
>
>
>>> <https://access.redhat.com/solutions/327903> for more information. *
>Log in to Your Red Hat Account - Red Hat Customer
>Portal<https://access.redhat.com/solutions/327903>
>access.redhat.com
>Log In. Your Red Hat account gives you access to your profile,
>preferences, and services, depending on your status.
>
>
>
>>>
>>> *Error connecting to jabber server: Unable to connect to the host
>and
>>port
>>> specified. See https://access.redhat.com/solutions/327903
>Log in to Your Red Hat Account - Red Hat Customer
>Portal<https://access.redhat.com/solutions/327903>
>access.redhat.com
>Log In. Your Red Hat account gives you access to y

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

[Robert Paschedag]

Am 15. Februar 2017 17:49:22 MEZ schrieb Konstantin Raskoshnyi 
:
>Can you do a telnet to port 5222 from client to spacewalk?
>On Wed, Feb 15, 2017 at 8:07 AM Daryl Rose 
>wrote:
>
>> I just did a fresh install of RHEL 6.6.  I installed Spacewalk client
>2.6
>> onto the server.  All is good with the exception of OSAD.  Whenever I
>try
>> to start it using services, I get the following error:
>>
>>
>> *# service osad start*
>>
>> *Starting osad: 2017-02-15 09:41:40 rhn_log.log_error: Error
>connecting to
>> jabber server: Unable to connect to the host and port specified. See
>> https://access.redhat.com/solutions/327903
>>  for more information. *
>>
>> *Error connecting to jabber server: Unable to connect to the host and
>port
>> specified. See https://access.redhat.com/solutions/327903
>>  for more information. *
>>
>> *2017-02-15 09:41:40 rhn_log.log_error: Traceback (most recent call
>last):*
>>
>> *  File "/usr/share/rhn/osad/jabber_lib.py", line 266, in
>setup_connection*
>>
>> *c = self._get_jabber_client(js)*
>>
>> *  File "/usr/share/rhn/osad/jabber_lib.py", line 338, in
>> _get_jabber_client*
>>
>> *c.connect()*
>>
>> *  File "/usr/share/rhn/osad/jabber_lib.py", line 612, in connect*
>>
>> *raise socket.error(e)*
>>
>> *error: Unable to connect to the host and port specified*
>>
>>
>> *Traceback (most recent call last):*
>>
>> *  File "/usr/share/rhn/osad/jabber_lib.py", line 266, in
>setup_connection*
>>
>> *c = self._get_jabber_client(js)*
>>
>> *  File "/usr/share/rhn/osad/jabber_lib.py", line 338, in
>> _get_jabber_client*
>>
>> *c.connect()*
>>
>> *  File "/usr/share/rhn/osad/jabber_lib.py", line 612, in connect*
>>
>> *raise socket.error(e)*
>>
>> *error: Unable to connect to the host and port specified*
>>
>>
>> I'm not doing anything different with this install than I've been
>doing
>> with all of my other RHEL servers.  This is an inside network, no
>firewall
>> in between.  I am using fully qualified domain names.  I can telnet
>to port
>> 5222 on the spacewalk server, and I can start osad with -N -v -v -v
>-v and
>> get connected, so there is no issue with the port, or resolving the
>server
>> name.  Could this be something in the 2.6 client and RHEL version
>6.6?
>>
>>
>> Thanks
>>
>>
>> Daryl
>> ___
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list

Hi Daryl,

You get connected when you run with -v -v -v -v but not when you just start the 
service? This does not make sense to me.

Could you please send the part where the connect succeeds from the call with 
very verbose mode?

Regards
Robert

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

Re: [Spacewalk-list] kickstart fails to get packages

[Robert Paschedag]

Am 7. Februar 2017 03:09:41 MEZ schrieb Konstantin Raskoshnyi 
:
>Hi guys, I have rhel 7.2 + sp 2.5, from today sp ks fails retrieve
>repofile, everytime error 500
>
>172.23.9.30 - - [07/Feb/2017:01:55:26 +] "GET
>/ks/dist/child/sl67-spacewalk-repo/sl67/repodata/repomd.xml HTTP/1.1"
>500
>4199
>172.23.9.30 - - [07/Feb/2017:01:55:27 +] "GET
>/ks/dist/child/sl67-updates-repo/sl67/repodata/repomd.xml HTTP/1.1" 500
>4199
>172.23.9.30 - - [07/Feb/2017:01:55:27 +] "GET
>/ks/dist/child/sl67-base-repo/sl67/repodata/repomd.xml HTTP/1.1" 500
>4199
>172.23.9.30 - - [07/Feb/2017:01:55:54 +] "GET
>/ks/dist/child/sl67-base-repo/sl67/repodata/repomd.xml HTTP/1.1" 500
>4199
>172.23.9.30 - - [07/Feb/2017:01:55:56 +] "GET
>/ks/dist/child/sl67-base-repo/sl67/repodata/repomd.xml HTTP/1.1" 500
>4199
>172.23.9.30 - - [07/Feb/2017:01:55:58 +] "GET
>/ks/dist/child/sl67-base-repo/sl67/repodata/repomd.xml HTTP/1.1" 500
>4199
>172.23.9.30 - - [07/Feb/2017:01:56:03 +] "GET
>/ks/dist/child/sl67-base-repo/sl67/repodata/repomd.xml HTTP/1.1" 500
>4199
>
>Any thoughts what it could be? yum on machines work fine.

Did you try to restart the spacewalk services? Maybe one service failed. Just a 
quick test... 


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

Re: [Spacewalk-list] jabberd - router listens only on tcp6

[Robert Paschedag]

Am 7. Februar 2017 00:19:10 MEZ schrieb Konstantin Raskoshnyi 
:
>Hi folks,
>
>I disabled ipv6 on Rhel7 since I had some problems with proxies,
>for some reasons jabberd-router listens only on tcp6 during startup, I
>check config files and didn't find anything suspicious,
>
> 
>  
>
>::
>
>
>5347
>
>
>/etc/jabberd/router-users.xml
>
>
>cfd1bee12672e7f7e6abe34c4aec00f6b5963259
>
>
>
>  
>
>Any thoughts?

The "::" explicitly sets ipv6 here. Try setting it to "0.0.0.0".

Regards
Robert

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

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

Am 9. Januar 2017 22:46:39 MEZ schrieb Daryl Rose :
>I would like to say thank you to Jeremy, Paul, Robert and all who
>helped me with this issue.  After much banging of the head on the wall,
>I finally got this working.
>
>Thank you once again. I really appreciate the help, and again, I
>apology for any angry tones that I may have posted previously.  My
>frustration got the better of me, and I don't want anyone on the list
>thinking that is my normal demeanor.
>
>Daryl
>
>
>
>From: spacewalk-list-boun...@redhat.com
> on behalf of j...@schaubroeck.be
>
>Sent: Thursday, January 5, 2017 4:52 AM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from
>parentchannel
>
>
>Hi Daryl
>
>A few pointers:
>
>*   CA Cert: should be under /etc/rhsm/ca/redhat-uep.pem as your system
>is registered with RHN. (if not, either use "find" or another tool to
>look for it, or use google, you should be able to download it)
>*   SSL Client Cert and SSL Client Key: these are both in the
>entitlement certificates you can download. You can choose to split them
>in two files or just keep them together (both should work iirc)
>
>Add all 3 under Systems -> Kickstart -> GPG and SSL keys (choose SSL as
>type) and give them a clear name. Then you will be able to choose them
>in the dropdown menu for the repo config.
>
>
>Regards,
>
>Jeremy
>
>On 4/01/2017 16:16, Daryl Rose wrote:
>
>Hello Jeremy,
>
>
>Thank you for the information, and sorry for the late reply.  Holidays
>and a heavy work load prevented me from getting back to this topic.
>
>
>Actually, you are the first person to specifically answer some of these
>questions.   I do specifically remember asking the question, more than
>once, what am I missing?  So, I believe the answer to that question is
>the SSL keys.  I don't remember when I setup the original server
>setting up keys, but I must have if it had worked.
>
>
>I've read through the documentation, and I've read the
>subscription-manager man page, but I'm not really sure how to get the
>keys and what to do with them once I do get them.  I am able to
>download the server entitlement from the Red Hat subscription, but I'm
>not sure if that is what I need or not.  Also, I'm not familiar enough
>with certificates and I don't want to start trying commands that I am
>not familiar with and break my current configuration, which I know can
>happen.
>
>
>When I look at the repository page in the WUI, I see three SSL
>settings.
>
>  *   SSL CA Certificate
>  *   SSL Client Certificate
>  *   SSL Client Key
>
>I'm assuming these are what I have to set, correct?  In the drop down,
>there is only a single choice,
>
>  *   RHN-ORG-TRUSTED-SSL-CERT
>
>I tried selecting that in the past, but that did not resolve this
>issue.  Do I have to install the entitlement that I downloaded from Red
>Hat into the RHN-ORG-TRUSTED-SSL-CERT?
>
>If someone can point me in the right direction of how to get the certs,
>and how to add them into Spacewalk without breaking my current
>configuration, I would appreciate it.
>
>Thank you.
>
>Daryl
>
>
>
>From:
>spacewalk-list-boun...@redhat.com
>
>on behalf of j...@schaubroeck.be
>
>Sent: Tuesday, December 20, 2016 10:29 AM
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from
>parentchannel
>
>
>Hi Daryl
>
>At the risk of repeating something someone else has already said,
>here's my thoughts:
>
>Spacewalk-repo-sync and the subscription manager registration are two
>separate things. I don't think anyone doubts that your server is
>registered all fine with RedHat and that all the relevant yum commands
>work. But as far as I know the two are unrelated.
>
>If you want to sync directly with Spacewalk itself (spacewalk-repo-sync
>is that, and it uses the repo config you set within spacewalk) then you
>will have to use the way Paul described:
>
>2) using a the same URL and keys as subscription manager, the URLs for
>the repos and the SSL keys can be retrieved from subscritpion manager
>on a registered host or through access.redhat.com by drilling into the
>subscriptions.
>
>the scheduling and exact options like the URL and if a SSL cert is
>used are configured on each repository through the spacewalk web
>interface. by the way this is the url you were being asked about.
>
>Aka: in your repository configuration in spacewalk you have to enter
>the correct URL, along with an SSL CA Certificate, SSL Client
>Certificate and SSL Client Key. The info where to get these and how to
>use them has been posted on the list a few times.
>
>Now the URL should be fine from what I 

Re: [Spacewalk-list] Cannot retrieve repository metadata (repomd.xml)

[Robert Paschedag]

Am 9. Januar 2017 08:23:13 MEZ schrieb "Jérémie Pradet" 
:
>Before, ask my question, I wish you a good new year.
>
>I have a Spacewalk 2.4, and I use it to download packages and Errata
>from
>redhat.
>For some time, I can't update my Erratas.
>When I run spacewalk-repo-sync. I have the below error message.
>
>/usr/bin/spacewalk-repo-sync --channel rhel-6-server-x64 --type yum
>
>Sync started: Wed Jan  4 13:59:50 2017
>['/usr/bin/spacewalk-repo-sync', '--channel', 'rhel-6-server-x64',
>'--type', 'yum']
>   Repo URL: https://cdn.redhat.com/content/dist/rhel/server/6/6Server/
>x86_64/os
>ERROR: Cannot retrieve repository metadata (repomd.xml) for repository:
>rhel-6-server-x64. Please verify its path and try again
>Sync completed.
>Total time: 0:00:00
>
>
>Would you like help me ?
>
>In the archive mail, I don't find something to fix my issue.
>
>Jérémie

Please look at the threads Daryl Rose started for exactly this error. I'm only 
with my mobile device right now...

Sorry for being vague..

Robert 

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

Re: [Spacewalk-list] spacewalk 2.6 debian jessie [package not found]

[Robert Paschedag]

Am 8. Januar 2017 19:58:11 MEZ schrieb Florin Portase 
:
>Hello, 
>
>I just created a channel for debian 8 [ jessie-main+jessie-updates ] 
>
>So far so good, however,  to certain packages apt-get complains can't
>find them. 
>
>Ex: 
>
> apt-get install openjdk-7-jre 
>
>Err spacewalk://192.168.50.105/ channels:/jessie-updates
>openjdk-7-jre-headless amd64 7u111-2.6.7-2~deb8u1
>  404  Not Found
>Err spacewalk://192.168.50.105/ channels:/jessie-updates openjdk-7-jre
>amd64 7u111-2.6.7-2~deb8u1
>  404  Not Found
>E: Failed to fetch
>spacewalk://192.168.50.105/XMLRPC/GET-REQ/jessie-updates/getPackage/openjdk-7-jre-headless-7u111-2.6.7-2~deb8u1.amd64-deb.deb
> 404  Not Found
>
>E: Failed to fetch
>spacewalk://192.168.50.105/XMLRPC/GET-REQ/jessie-updates/getPackage/openjdk-7-jre-7u111-2.6.7-2~deb8u1.amd64-deb.deb
> 404  Not Found 
>
>And here httpd access log 
>
>192.168.50.16 - - [08/Jan/2017:19:48:22 +0100] "POST /XMLRPC HTTP/1.1"
>200 2005 "-" "rhn.rpclib.py/$Revision$"
>192.168.50.16 - - [08/Jan/2017:19:48:22 +0100] "GET
>//XMLRPC/GET-REQ/jessie-updates/getPackage/openjdk-7-jre-headless-7u111-2.6.7-2~deb8u1.amd64-deb.deb
>HTTP/1.1" 404 - "-" "-"
>192.168.50.16 - - [08/Jan/2017:19:48:22 +0100] "GET
>//XMLRPC/GET-REQ/jessie-updates/getPackage/openjdk-7-jre-7u111-2.6.7-2~deb8u1.amd64-deb.deb
>HTTP/1.1" 404 - "-" 
>
>= 
>
>File located on spacewalk server 
>
>redhat/1/d54/openjdk-7-jre-headless/7u111-2.6.7-2~deb8u1/amd64-deb/d540e4f7c8da546091c349cefb38d970747050f2f00e3a360ddb11466e7df9c6/openjdk-7-jre-headless-7u111-2.6.7-2~deb8u1.amd64-deb.deb
>
>
>redhat/1/3db/openjdk-7-jre/7u111-2.6.7-2~deb8u1/amd64-deb/3db61f01db5861b184385f9bb9e01b251abe912167f51eab4a73aac7e25f24bf/openjdk-7-jre-7u111-2.6.7-2~deb8u1.amd64-deb.deb
>
>
>Also, if I go to jessie-updates channel, can find + download them .
>
>
>I deleted the channel+delete the packages but still same issue, EVERY
>time apt-get complains about the same packages  ? 
>
>Is some other ways to  trace this issue  or anyone faced the same  ?

Please also show us the sync logs, where these files have been downloaded from 
Debian server. 

Robert

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

Re: [Spacewalk-list] spacewalk 2.6 multiple activation keys / register system to epel channel

[Robert Paschedag]

Am 6. Januar 2017 11:07:26 MEZ schrieb Florin Portase 
:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Hello,
>
>So here is my setup::
>
>
>Spacewalk 2.6
>
>Software Channels
>
>centos7.2-base
>|
>\_ centos7.2-updates
>
>centos7.3-base
>|
>\_ centos7.3-updates
>
>
>rhel-7
>|
>\_ epel_rhel7_x86_64
>
>
>So far so good, but here is what I can't figure out what  do I have to
>do::
>
>I want to register a system, let's say for base channel centos7.3-base
>+
>epel7
>
>To reproduce what I have tried:
>
>1. create distrib channel mapping => OS=centos-release Release=7
>ARCH=x86_64 Channel Label=centos-7.3-base
>
>2. create an activation key [ 1-MYORG-key01 ]=>  Base Channel =
>"Spacewalk Default" Child Channels="centos-7.3-updates,
>epel_rhel7_x86_64"
>
>
>But  on my client system [ installed centos 7.3 ] if I do rhnreg_ks
>- --activationkey=1-MYORG-key01
>
>system is registering only on centos7.3-base + centos-7.3-updates; epel
>is completely ignored
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2.0.14 (GNU/Linux)
>
>iQEbBAEBAgAGBQJYb2xeAAoJEEleVOdJlPeKsmoH+Mc8QVp9ORWEDWEg5rDpX/lk
>tKbSWatlB6XtbFPYDbTj6GEgYdjpHYQANhOys18N7Y73DDSuJMyQdc8mr7cJMX3g
>dC10PlOlhjO70C9dir7zwK8umvFyIgUrzChSV3MCGsJjNGMzPRJclnNze0YZwIHa
>vxFzzv4aDFyR+D33NF1Or1vLdrCiavCKvLNHScSc/edwA5JUyZn93hA4ca51l4iH
>ZsoIuRYhmDalSvw03ZxfoGy8Qevx9NHlSFylVP/z3A49Q6yyt4ijsXCAVPjv5ybr
>gITaEXwSNzqB4ZdjKCxd5v1ZIA4/Lh4qOAF1l2aGZIDypgYopW4EqOwZbkMWeg==
>=ujZQ
>-END PGP SIGNATURE-
>
>___
>Spacewalk-list mailing list
>Spacewalk-list@redhat.com
>https://www.redhat.com/mailman/listinfo/spacewalk-list

One system can only have 1 "base" channel at a time. If you want to have epol 
everywhere, you have to create a copy of that epol channel within each base 
channel. All epol channels use the same "repo" of epol to sync from. Spacewalk 
just "links" the packages within the different epol child channels (each 
package is only stored once in disk) 

Robert 

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

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

 go pound sand because I don't have a Satellite subscription.   
>But that was just a feel good ticket anyway.  I know that the URL that
>I am using is accurate, because I can run the "yum repolist", "yum
>update" and "reposync" command and they all work.  There is something
>else that is broke.
>
>
>You and others tell me to look at the logs, however, there is nothing
>in the logs to point me in the direction on what the issue is. I've
>posted the only error that I receive.  Oh, one thing that I have failed
>to mention is that I disabled the schedule a couple of weeks ago when
>this issue first started.  So that takes taskomatic out of the picture.
>I have been using the "spacewalk-repo-sync" command from the command
>line trying to troubleshoot this issue. That is why in all of my
>previous updates I kept specifying spacewalk-repo-sync.  But that is my
>fault for not mentioning that before.
>
>
>With that said, I don't care how many verbose v's I put at the end of
>the command, the only error that I get is the error that I've been
>posting.
>
>
>Here is what I get in the channel log:
>
>2016/12/20 09:12:22 -05:00 Sync of channel started.
>
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.channel_info('rhel-6-server-rpms',)
>2016/12/20 09:12:22 -05:00 Repo URL: 
>2016/12/20 09:12:22 -05:00 Sync of channel completed in 0:00:00.
>
>Here is what I get in the reposync.log:
>2016/12/20 09:12:22 -05:00 Command: ['/usr/bin/spacewalk-repo-sync',
>'--channel', 'rhel-6-server-rpms', '-vvv']
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(136,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(136, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(133,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(133, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(103,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(103, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(122,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(122, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(129,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(129, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(120,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(120, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(121,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(121, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(131,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(131, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(124,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(124, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(138,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(138, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(134,)
>2016/12/20 09:12:22 -05:00 2595 0.0.0.0:
>server/rhnChannel.isCustomChannel(134, 'is a custom channel')
>2016/12/20 09:12:22 -05:00 ======
>2016/12/20 09:12:22 -05:00 | Channel: rhel-6-server-rpms
>2016/12/20 09:12:22 -05:00 ==
>2016/12/20 09:12:22 -05:00 Sync of channel started.
>Please check 'reposync/rhel-6-server-rpms.log' for sync log of this
>channel.
>2016/12/20 09:12:22 -05:00 Sync of channel completed.
>2016/12/20 09:12:22 -05:00 Total time: 0:00:00
>
>Not much information to go on.
>
>Thanks
>
>Daryl
>
>
>
>From:
>spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-boun...@redhat.com>
><spacewalk-list-boun...@redhat.com><mailto:spacewalk-list-boun...@redhat.com>
>on behalf of Robert Paschedag
><robert.pasche...@web.de><mailto:robert.pasche...@web.de>
>Sent: Tuesday, December 20, 2016 9:02 AM
>To: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
>Cc: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
>Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from
>p

Re: [Spacewalk-list] Error when updating SSL certificates

[Robert Paschedag]

Hi Matthew,

 

SQLError: (2292, 'ORA-02292: integrity constraint (SWLKAP01.RHN_CSSSL_CACERTID_FK) violated - child record found\n', 'delete from rhnCryptoKey where id=:rhn_cryptokey_id')

 

Maybe this helps

 

https://www.techonthenet.com/oracle/errors/ora02292.php

 

Regards,

Robert

 

 

Gesendet: Mittwoch, 28. Dezember 2016 um 20:42 Uhr
Von: "Matthew Madey" 
An: "spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] Error when updating SSL certificates


I've recently converted my old SHA-1 certificate to SHA-2 using the directions outlined here: https://access.redhat.com/solutions/10809

 

However, during one of the steps, to import the new cert into the database, I'm getting the below error. Any ideas on how I can rectify this? 
 


# rhn-ssl-dbstore --ca-cert=/root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT

 

ERROR: Cannot insert certificate into DB!

 

Exception reported from spacewalk-qa.ourcompany.com

Time: Wed Dec 28 13:15:15 2016

Exception type 

 

Exception Handler Information

Traceback (most recent call last):

  File "/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/rhn_ssl_dbstore.py", line 84, 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 170, in store_rhnCryptoKey

    "...the traceback: %s" % fetchTraceback()), sys.exc_info()[2])

  File "/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/satCerts.py", line 157, in store_rhnCryptoKey

    verbosity=verbosity)

  File "/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/satCerts.py", line 97, 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 151, in execute

    return self._execute_wrapper(self._execute, *p, **kw)

  File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_cx_Oracle.py", line 133, in _execute_wrapper

    raise_with_tb(sql_base.SQLError(*ret), sys.exc_info()[2])

  File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_cx_Oracle.py", line 113, in _execute_wrapper

    retval = function(*p, **kw)

  File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 205, in _execute

    return self._execute_(args, kwargs)

  File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_cx_Oracle.py", line 167, in _execute_

    self._real_cursor.execute(*(None, ), **params)

CaCertInsertionError: ...the traceback: Exception reported from spacewalk-qa.ourcompany.com

Time: Wed Dec 28 13:15:15 2016

Exception type 

 

Exception Handler Information

Traceback (most recent call last):

  File "/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/satCerts.py", line 157, in store_rhnCryptoKey

    verbosity=verbosity)

  File "/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/satCerts.py", line 97, 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 151, in execute

    return self._execute_wrapper(self._execute, *p, **kw)

  File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_cx_Oracle.py", line 133, in _execute_wrapper

    raise_with_tb(sql_base.SQLError(*ret), sys.exc_info()[2])

  File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_cx_Oracle.py", line 113, in _execute_wrapper

    retval = function(*p, **kw)

  File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 205, in _execute

    return self._execute_(args, kwargs)

  File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_cx_Oracle.py", line 167, in _execute_

    self._real_cursor.execute(*(None, ), **params)

SQLError: (2292, 'ORA-02292: integrity constraint (SWLKAP01.RHN_CSSSL_CACERTID_FK) violated - child record found\n', 'delete from rhnCryptoKey where id=:rhn_cryptokey_id')



___ 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] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

ly error that I get is the error that I've been 
>> posting.
>>
>>
>> Here is what I get in the channel log:
>>
>> 2016/12/20 09:12:22 -05:00 Sync of channel started.
>>
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.channel_info('rhel-6-server-rpms',)
>> 2016/12/20 09:12:22 -05:00 Repo URL: 
>> 2016/12/20 09:12:22 -05:00 Sync of channel completed in 0:00:00.
>>
>> Here is what I get in the reposync.log:
>> 2016/12/20 09:12:22 -05:00 Command: ['/usr/bin/spacewalk-repo-sync', 
>> '--channel', 'rhel-6-server-rpms', '-vvv']
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(136,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(136, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(133,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(133, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(103,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(103, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(122,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(122, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(129,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(129, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(120,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(120, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(121,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(121, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(131,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(131, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(124,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(124, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(138,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(138, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(134,)
>> 2016/12/20 09:12:22 -05:00 2595 0.0.0.0: 
>> server/rhnChannel.isCustomChannel(134, 'is a custom channel')
>> 2016/12/20 09:12:22 -05:00 ==
>> 2016/12/20 09:12:22 -05:00 | Channel: rhel-6-server-rpms
>> 2016/12/20 09:12:22 -05:00 ==
>> 2016/12/20 09:12:22 -05:00 Sync of channel started.
>>Please check 
>> 'reposync/rhel-6-server-rpms.log' for sync log of this channel.
>> 2016/12/20 09:12:22 -05:00 Sync of channel completed.
>> 2016/12/20 09:12:22 -05:00 Total time: 0:00:00
>>
>> Not much information to go on.
>>
>> Thanks
>>
>> Daryl
>>
>>
>
>>
>> *From:* spacewalk-list-boun...@redhat.com 
>> <spacewalk-list-boun...@redhat.com> on behalf of Robert Paschedag 
>> <robert.pasche...@web.de>
>> *Sent:* Tuesday, December 20, 2016 9:02 AM
>> *To:* spacewalk-list@redhat.com
>> *Cc:* spacewalk-list@redhat.com
>> *Subject:* Re: [Spacewalk-list] RHEL 6.x repository not syncing from 
>> parentchannel
>> Hi Daryl,
>> I'm not angryalso frustrated because we all seem to talk about 
>> different things and you seem to focus on an problem, that - in my 
>> opinion - is not of interest yet.
>> The first is to get the synchronisation from RHEL done!
>> Nowin your first post, you wrote, that you did not get updates 
>> from RHEL since several month. This makes me thinkahayou are 
>> downloading "directly" from RHEL. Hence, this is your "master" 
>> spacewalk server. So the "creation" of the metadata of the 
>> "downloaded" packages (that does not work right now) is currently
>useless.
>> The main problem iswhy can't you download the p

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

ocumentation for RHN Satellite 5.x on
access.redhat.com  additionally all of these issues have been
discussed many times on this mailing list and can be found easilly by
a google search




On Mon, Dec 19, 2016 at 2:54 PM, Daryl Rose <darylr...@outlook.com> wrote:
> Robert,
>
>
> Perhaps I don't understand what you're telling me.
>
>
> How do I fix problem 1?  What steps do I have to do to fix problems 1?
>
>
> I know that it's not syncing the remote repository, but the error that I am
> seeing points to problem 2.  To me, problem 2 is what is preventing problem
> 1 from being achieved that is why I am focusing on problem 2.
>
>
> Thanks
>
>
> Daryl
>
>
> 
> From: Robert Paschedag <robert.pasche...@web.de>
> Sent: Monday, December 19, 2016 1:43 PM
>
> To: Daryl Rose; spacewalk-list@redhat.com
> Subject: AW: [Spacewalk-list] RHEL 6.x repository not syncing from
> parentchannel
>
> We are talking about 2 problems.
>
> 1. Your server doesn't sync the remote repository.
> 2. Your server is not creating repository meta data.
>
> You have to fix problem 1 first. If that works, you can think about fixing
> problem 2.
>
> From what you are telling You're trying to fix problem 2. I'm taking
> about problem 1 all the time.
>
> Again... First fix number 1.
>
> Regards
> Robert
>
>
> -- Originalnachricht--
> Von: Daryl Rose
> Datum: Mo., 19. Dez. 2016 20:14
> An: spacewalk-list@redhat.com;
> Cc:
> Betreff:Re: [Spacewalk-list] RHEL 6.x repository not syncing from
> parentchannel
>
> Sorry about the reply.  Normally when I reply, it does go to the group, not
> just to the individual who sent the reply, but for whatever reason, I have
> to specify the mailing list when replying to your emails.
>
>
> The path that the error is referring to is:
>
>
> /var/cache/rhn/reposync/content_dist_rhel_server_6_$releasever_$basearch_os/repomd.xml
>
> or
>
> /var/cache/rhn/reposync/content_dist_rhel_server_6_6Server_x86_64_os_/repomd.xml
>
> As I stated in the past, repomd.xml and additional content is not created
> when spacewalk-repo-sync runs.  I've been able to prove that
> spacewalk-repo-sync creates this directory because I've removed it multiple
> times and the directory is created and a sub-directory called "packages",
> but that is it.  None of the keys are created, and repomd.xml is not
> created.
>
> spacewalk-repo-sync is a python script.  I don't know anything about python
> and I don't know how to trace the script.  I've tried "phthon -m reposync
> --trace spacewalk-repo-sync", but that doesn't work.  I would really like to
> see what is happening when the script tries to execute the reposync module,
> but I get "reposync module doesn't exists".
>
> Maybe if I can see what is going on in the spacewalk-repo-sync script, then
> I can figure out what is causing my issue.
>
> Thanks
>
> Daryl
> 
> From: Robert Paschedag >
> Sent: Monday, December 19, 2016 11:35 AM
> To: Daryl Rose
> Cc: spacewalk-list@redhat.com
> Subject: AW: [Spacewalk-list] RHEL 6.x repository not syncing from
> parentchannel
>
> Please, answer to "all" so the list gets informed, too.
>
> And there is no path mentioned anywhere! Is there no path in the logs that
> the script tries to connect to?
> LikeHTTP://ftp.redhat.com/some/path/repomd.xml
>
> I don't care the name of the repository or path on your local machine
> The download URL is the thing that matters...
>
> Regards
> Robert
>
> -- Originalnachricht--
> Von: Daryl Rose
> Datum: Mo., 19. Dez. 2016 18:11
> An: Robert Paschedag;
> Cc:
> Betreff:Re: [Spacewalk-list] RHEL 6.x repository not syncing from
> parentchannel
>
> I tried both with and without variables.   This is an example of without the
> variables.  Same error:
>
>
> 11:08:18 ERROR: Cannot retrieve repository metadata (repomd.xml) for
> repository: content_dist_rhel_server_6_6Server_x86_64_os_. Please verify its
> path and try again
>
>
> [root reposync]# ls -l
> drwxr-xr-x. 3 root root 4096 Dec 19 11:08
> content_dist_rhel_server_6_6Server_x86_64_os_
>
> Daryl
>
> 
> From: Robert Paschedag>
> Sent: Monday, December 19, 2016 10:08 AM
> To: Daryl Rose; spacewalk-list@redhat.com
> Subject: AW: [Spacewalk-list] RHEL 6.x repository not syncing from
> parentchannel
>
> Daryl,
>
> I don't think, that you can use the URL that is used by "yum" within
> spacewalk. Just because of these variables in it! I think this is why you
> get the "

Re: [Spacewalk-list] spacewalk-repo-sync - no checksum found - openSUSE Leap 42.2

[Robert Paschedag]

Maybe the metadata at the vendor is currently broken? Had this once on one older repo from Novell for a day. Then they fixed it.Someone else syncing this repo?Robert Am 20.12.2016 12:54 schrieb Patrick Sachs :Hi,



the openSUSE Leap 42.2 repositories don't sync packages anymore.



12:18:02 ==

12:18:02 | Channel: opensuse_leap42_2-x86_64-updates

12:18:02 ==

12:18:02 Sync of channel started.

12:18:02 Repo URL: http://download.opensuse.org/update/leap/42.2/oss/

12:18:03 Packages in repo:  1295

12:19:04 No new packages to sync.

12:19:04 Repo http://download.opensuse.org/update/leap/42.2/oss/ has 128 errata.

12:19:05 No checksum found for gnuchess-6.2.1-5.1.i586. Skipping Package

12:19:05 No checksum found for gnuchess-6.2.1-5.1.src. Skipping Package

12:19:05 No checksum found for gnuchess-debuginfo-6.2.1-5.1.i586. Skipping Package

12:19:05 No checksum found for gnuchess-debugsource-6.2.1-5.1.i586. Skipping Package

12:19:05 No checksum found for gnuchess-debuginfo-6.2.1-5.1.x86_64. Skipping Package

12:19:05 No checksum found for gnuchess-debugsource-6.2.1-5.1.x86_64. Skipping Package

12:19:05 No checksum found for ktorrent-5.0.1-3.1.src. Skipping Package

12:19:05 No checksum found for ktorrent-debuginfo-5.0.1-3.1.x86_64. Skipping Package

12:19:05 No checksum found for ktorrent-debugsource-5.0.1-3.1.x86_64. Skipping Package

12:19:05 No checksum found for clamav-database-201611210004-6.1.src. Skipping Package

12:19:05 No checksum found for hylafax+-5.5.8-7.1.i586. Skipping Package







Any ideas what could be wrong?



Best regards



Patrick



___

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] Sorry for breaking conversion threads...

[Robert Paschedag]

I have been told, that some of my answers broke the conversion threads. I'm sorry for that. This must have been caused by one of the mail clients I use on my smartphone. Hope, things will get better. Regards Robert ___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

We are talking about 2 problems. 
1. Your server doesn't sync the remote repository.2. Your server is not 
creating repository meta data. 
You have to fix problem 1 first. If that works, you can think about fixing 
problem 2.
From what you are telling You're trying to fix problem 2. I'm taking about 
problem 1 all the time. 
Again... First fix number 1.
Regards Robert 

-- Originalnachricht--Von: Daryl RoseDatum: Mo., 19. Dez. 2016 20:14An: 
spacewalk-list@redhat.com;Cc: Betreff:Re: [Spacewalk-list] RHEL 6.x repository 
not syncing from parentchannel
Sorry about the reply.  Normally when I reply, it does go to the group, not 
just to the individual who sent the reply, but for whatever reason, I have to 
specify the mailing list when replying to your emails.
The path that the error is referring to is:
/var/cache/rhn/reposync/content_dist_rhel_server_6_$releasever_$basearch_os/repomd.xml
or 
/var/cache/rhn/reposync/content_dist_rhel_server_6_6Server_x86_64_os_/repomd.xml

As I stated in the past, repomd.xml and additional content is not created when 
spacewalk-repo-sync runs.  I've been able to prove that spacewalk-repo-sync 
creates this directory because I've removed it multiple times and the directory 
is created and a sub-directory called "packages", but that is it.  None of the 
keys are created, and repomd.xml is not created.  

spacewalk-repo-sync is a python script.  I don't know anything about python and 
I don't know how to trace the script.  I've tried "phthon -m reposync --trace 
spacewalk-repo-sync", but that doesn't work.  I would really like to see what 
is happening when the script tries to execute the reposync module, but I get 
"reposync module doesn't exists".   
Maybe if I can see what is going on in the spacewalk-repo-sync script, then I 
can figure out what is causing my issue.
Thanks
DarylFrom: Robert Paschedag >
Sent: Monday, December 19, 2016 11:35 AM
To: Daryl Rose
Cc: spacewalk-list@redhat.com
Subject: AW: [Spacewalk-list] RHEL 6.x repository not syncing from 
parentchannel Please, answer to "all" so the list gets informed, too.
And there is no path mentioned anywhere! Is there no path in the logs that the 
script tries to connect to? LikeHTTP://ftp.redhat.com/some/path/repomd.xml
I don't care the name of the repository or path on your local machine The 
download URL is the thing that matters...
Regards Robert
-- Originalnachricht--Von: Daryl Rose Datum: Mo., 19. Dez. 2016 
18:11An: Robert Paschedag;Cc: Betreff:Re: [Spacewalk-list] RHEL 6.x repository 
not syncing from parentchannel
I tried both with and without variables.   This is an example of without the 
variables.  Same error:
11:08:18 ERROR: Cannot retrieve repository metadata (repomd.xml) for 
repository: content_dist_rhel_server_6_6Server_x86_64_os_. Please verify its 
path and try again

[root reposync]# ls -ldrwxr-xr-x. 3 root root     4096 Dec 19 11:08 
content_dist_rhel_server_6_6Server_x86_64_os_
Daryl

From: Robert Paschedag>
Sent: Monday, December 19, 2016 10:08 AM
To: Daryl Rose; spacewalk-list@redhat.com
Subject: AW: [Spacewalk-list] RHEL 6.x repository not syncing from 
parentchannel Daryl,
I don't think, that you can use the URL that is used by "yum" within spacewalk. 
Just because of these variables in it! I think this is why you get the "invalid 
path" errors. So just print also the paths within your logs just before the 
error occurs to verify. Then... Try to use the "resolved" URL within spacewalk. 
Regards Robert 

-- Originalnachricht--Von: Daryl RoseDatum: Mo., 19. Dez. 2016 16:20An: 
spacewalk-list@redhat.com;Cc: Betreff:Re: [Spacewalk-list] RHEL 6.x repository 
not syncing from parentchannel
Robert,
The URL came from the /etc/yum.repos.d/redhat.repo.redhat.repo, which is 
created when registering to Red Hat.   The path in question is created when I 
run the spacewalk-repo-sync command.  I've removed that particular path several 
times, modified the URL and every time I run the spacewalk-repo-sync command, 
the directory in question get recreated.
I do know that there is a difference between the original reposync directory 
and the new reposync directory.
This is the content of the reposync directory on the original server:
[root]# cd /var/cache/rhn/reposync
[root reposync]# ls -ltotal 104drwxr-xr-x. 3 root root 4096 Oct 12 11:18 
centos-7-extradrwxr-xr-x. 3 root root 4096 Nov  8 21:00 
centos-7-updaedrwxr-xr-x. 3 root root 4096 Aug 24 12:10 
centos_7_channeldrwxr-xr-x. 3 root root 4096 Aug 29 13:10 
centos_7_plusdrwxr-xr-x. 3 root root 4096 Dec  9 14:03 
rhel-6-server-rpmsdrwxr-xr-x. 3 root root 4096 Aug 23 18:00 
sles11-sp3-pooldrwxr-xr-x. 3 root root 4096 Aug 23 19:00 
sles11-sp3-pool-x86drwxr-xr-x. 3 root root 4096 Nov  8 18:01 
sles11-sp3-updatedrwxr-xr-x. 3 root root 4096 Dec  8 19:00 
sles11-sp3-update-pool-x86drwxr-xr-x. 3 root root 4096 Aug 23 20:00 
sles11-sp4-pooldrwxr-xr-x. 3 root ro

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

Please, answer to "all" so the list gets informed, too.
And there is no path mentioned anywhere! Is there no path in the logs that the 
script tries to connect to? Like HTTP://ftp.redhat.com/some/path/repomd.xml
I don't care the name of the repository or path on your local machine The 
download URL is the thing that matters...
Regards Robert
-- Originalnachricht--Von: Daryl Rose Datum: Mo., 19. Dez. 2016 
18:11An: Robert Paschedag;Cc: Betreff:Re: [Spacewalk-list] RHEL 6.x repository 
not syncing from parentchannel
I tried both with and without variables.   This is an example of without the 
variables.  Same error:
11:08:18 ERROR: Cannot retrieve repository metadata (repomd.xml) for 
repository: content_dist_rhel_server_6_6Server_x86_64_os_. Please verify its 
path and try again

[root reposync]# ls -ldrwxr-xr-x. 3 root root     4096 Dec 19 11:08 
content_dist_rhel_server_6_6Server_x86_64_os_
Daryl

From: Robert Paschedag >
Sent: Monday, December 19, 2016 10:08 AM
To: Daryl Rose; spacewalk-list@redhat.com
Subject: AW: [Spacewalk-list] RHEL 6.x repository not syncing from 
parentchannel Daryl,
I don't think, that you can use the URL that is used by "yum" within spacewalk. 
Just because of these variables in it! I think this is why you get the "invalid 
path" errors. So just print also the paths within your logs just before the 
error occurs to verify. Then... Try to use the "resolved" URL within spacewalk. 
Regards Robert 

-- Originalnachricht--Von: Daryl RoseDatum: Mo., 19. Dez. 2016 16:20An: 
spacewalk-list@redhat.com;Cc: Betreff:Re: [Spacewalk-list] RHEL 6.x repository 
not syncing from parentchannel
Robert,
The URL came from the /etc/yum.repos.d/redhat.repo.redhat.repo, which is 
created when registering to Red Hat.   The path in question is created when I 
run the spacewalk-repo-sync command.  I've removed that particular path several 
times, modified the URL and every time I run the spacewalk-repo-sync command, 
the directory in question get recreated.
I do know that there is a difference between the original reposync directory 
and the new reposync directory.
This is the content of the reposync directory on the original server:
[root]# cd /var/cache/rhn/reposync
[root reposync]# ls -ltotal 104drwxr-xr-x. 3 root root 4096 Oct 12 11:18 
centos-7-extradrwxr-xr-x. 3 root root 4096 Nov  8 21:00 
centos-7-updaedrwxr-xr-x. 3 root root 4096 Aug 24 12:10 
centos_7_channeldrwxr-xr-x. 3 root root 4096 Aug 29 13:10 
centos_7_plusdrwxr-xr-x. 3 root root 4096 Dec  9 14:03 
rhel-6-server-rpmsdrwxr-xr-x. 3 root root 4096 Aug 23 18:00 
sles11-sp3-pooldrwxr-xr-x. 3 root root 4096 Aug 23 19:00 
sles11-sp3-pool-x86drwxr-xr-x. 3 root root 4096 Nov  8 18:01 
sles11-sp3-updatedrwxr-xr-x. 3 root root 4096 Dec  8 19:00 
sles11-sp3-update-pool-x86drwxr-xr-x. 3 root root 4096 Aug 23 20:00 
sles11-sp4-pooldrwxr-xr-x. 3 root root 4096 Nov  8 20:00 sles11-sp4-update

This is the contents of the reposync directory on the new server: 
[root]# cd /var/cache/rhn/reposync
[root reposync]# ls -ltotal 71328drwxr-xr-x. 3 root root     4096 Dec 18 17:00 
centos_7_centosplus_x86_64_drwxr-xr-x. 3 root root     4096 Dec 18 18:00 
centos_7_extras_x86_64_drwxr-xr-x. 3 root root     4096 Dec 18 17:30 
centos_7_os_x86_64_drwxr-xr-x. 3 root root     4096 Dec 18 18:30 
centos_7_updates_x86_64_drwxr-xr-x. 3 root root     4096 Dec 15 15:38 
content_dist_rhel_server_6_$releasever_$basearch_osdrwxr-xr-x. 3 root root     
4096 Dec 18 20:30 repo_$RCE_SLES11-SP3-Pool_sle-11-i586drwxr-xr-x. 3 root root  
   4096 Dec 18 19:30 repo_$RCE_SLES11-SP3-Pool_sle-11-x86_64drwxr-xr-x. 3 root 
root     4096 Dec 18 21:00 repo_$RCE_SLES11-SP3-Updates_sle-11-i586drwxr-xr-x. 
3 root root     4096 Dec 18 20:00 
repo_$RCE_SLES11-SP3-Updates_sle-11-x86_64drwxr-xr-x. 3 root root     4096 Dec 
18 21:30 repo_$RCE_SLES11-SP4-Pool_sle-11-x86_64drwxr-xr-x. 3 root root     
4096 Dec 18 22:00 repo_$RCE_SLES11-SP4-Updates_sle-11-x86_64
Notice the difference in the sub-directories?  The original server was SW v2.5, 
the new server is SW v2.6.  I'm assuming that the spacewalk-repo-sync command 
changed the way the sub-directories were created.  However these are created 
shouldn't make any difference, because they all work, except the Red Hat repo.  
The path is correct.  The issue is that repomd.xml and additional content is 
not created when the sub-directory 
"content_dist_rhel_server_6_$releasever_$basearch_os" is created, and I have no 
idea how the contents is created.  
The error message saying to check the path is not correct. The path is correct, 
its just the contents is not there.
Daryl
From: spacewalk-list-boun...@redhat.com> on behalf of Robert Paschedag>
Sent: Friday, December 16, 2016 9:37 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from 
parentchannel It says... The path is wrong. So what did you put into the URL 
line?


Am 16.12.20

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

Daryl,
I don't think, that you can use the URL that is used by "yum" within spacewalk. 
Just because of these variables in it! I think this is why you get the "invalid 
path" errors. So just print also the paths within your logs just before the 
error occurs to verify. Then... Try to use the "resolved" URL within spacewalk. 
Regards Robert 

-- Originalnachricht--Von: Daryl RoseDatum: Mo., 19. Dez. 2016 16:20An: 
spacewalk-list@redhat.com;Cc: Betreff:Re: [Spacewalk-list] RHEL 6.x repository 
not syncing from parentchannel
Robert,
The URL came from the /etc/yum.repos.d/redhat.repo. redhat.repo, which is 
created when registering to Red Hat.   The path in question is created when I 
run the spacewalk-repo-sync command.  I've removed that particular path several 
times, modified the URL and every time I run the spacewalk-repo-sync command, 
the directory in question get recreated.
I do know that there is a difference between the original reposync directory 
and the new reposync directory.
This is the content of the reposync directory on the original server:
[root]# cd /var/cache/rhn/reposync
[root reposync]# ls -ltotal 104drwxr-xr-x. 3 root root 4096 Oct 12 11:18 
centos-7-extradrwxr-xr-x. 3 root root 4096 Nov  8 21:00 
centos-7-updaedrwxr-xr-x. 3 root root 4096 Aug 24 12:10 
centos_7_channeldrwxr-xr-x. 3 root root 4096 Aug 29 13:10 
centos_7_plusdrwxr-xr-x. 3 root root 4096 Dec  9 14:03 
rhel-6-server-rpmsdrwxr-xr-x. 3 root root 4096 Aug 23 18:00 
sles11-sp3-pooldrwxr-xr-x. 3 root root 4096 Aug 23 19:00 
sles11-sp3-pool-x86drwxr-xr-x. 3 root root 4096 Nov  8 18:01 
sles11-sp3-updatedrwxr-xr-x. 3 root root 4096 Dec  8 19:00 
sles11-sp3-update-pool-x86drwxr-xr-x. 3 root root 4096 Aug 23 20:00 
sles11-sp4-pooldrwxr-xr-x. 3 root root 4096 Nov  8 20:00 sles11-sp4-update

This is the contents of the reposync directory on the new server: 
[root]# cd /var/cache/rhn/reposync
[root reposync]# ls -ltotal 71328drwxr-xr-x. 3 root root     4096 Dec 18 17:00 
centos_7_centosplus_x86_64_drwxr-xr-x. 3 root root     4096 Dec 18 18:00 
centos_7_extras_x86_64_drwxr-xr-x. 3 root root     4096 Dec 18 17:30 
centos_7_os_x86_64_drwxr-xr-x. 3 root root     4096 Dec 18 18:30 
centos_7_updates_x86_64_drwxr-xr-x. 3 root root     4096 Dec 15 15:38 
content_dist_rhel_server_6_$releasever_$basearch_osdrwxr-xr-x. 3 root root     
4096 Dec 18 20:30 repo_$RCE_SLES11-SP3-Pool_sle-11-i586drwxr-xr-x. 3 root root  
   4096 Dec 18 19:30 repo_$RCE_SLES11-SP3-Pool_sle-11-x86_64drwxr-xr-x. 3 root 
root     4096 Dec 18 21:00 repo_$RCE_SLES11-SP3-Updates_sle-11-i586drwxr-xr-x. 
3 root root     4096 Dec 18 20:00 
repo_$RCE_SLES11-SP3-Updates_sle-11-x86_64drwxr-xr-x. 3 root root     4096 Dec 
18 21:30 repo_$RCE_SLES11-SP4-Pool_sle-11-x86_64drwxr-xr-x. 3 root root     
4096 Dec 18 22:00 repo_$RCE_SLES11-SP4-Updates_sle-11-x86_64
Notice the difference in the sub-directories?  The original server was SW v2.5, 
the new server is SW v2.6.  I'm assuming that the spacewalk-repo-sync command 
changed the way the sub-directories were created.  However these are created 
shouldn't make any difference, because they all work, except the Red Hat repo.  
The path is correct.  The issue is that repomd.xml and additional content is 
not created when the sub-directory 
"content_dist_rhel_server_6_$releasever_$basearch_os" is created, and I have no 
idea how the contents is created.  
The error message saying to check the path is not correct. The path is correct, 
its just the contents is not there.
Daryl
From: spacewalk-list-boun...@redhat.com > on behalf of Robert Paschedag >
Sent: Friday, December 16, 2016 9:37 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from 
parentchannel It says... The path is wrong. So what did you put into the URL 
line?


Am 16.12.2016 15:50 schrieb Daryl Rose >:
So, today I decided to create a new RHEL 6 channel and repo and then run the 
"spacewalk-repo-sync" command and see if I can't get this repo to populate with 
packages from Red Hat.  The same erroroccurred.

ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: 
content_dist_rhel_server_6_6Server_x86_64_os_. Please verify its path and try 
again

This tells me that there isn't anything corrupt.  I'm really think that I 
missed something in the configuration or setup of the new server. 
When I setup the original server, v2.3, I'm thinking there were someadditional 
steps that I had to do once I registered the server to Red Hat.  I've been 
reviewing the installation instructions, but I don't see anything extra that I 
missed. In the SW, v2.6, installation instructions, all I see is to make sure 
that the server is properly registered to theappropriate channel:

Red Hat Optional Server (Red Hat Enterprise Linux)
When using Red Hat Enterprise Linux 6 or 7, make sure you are subscribed to the 
appropriate Red Hat Optional Server channel:
Red Hat 

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

It says... The path is wrong. So what did you put into the URL line?Am 16.12.2016 15:50 schrieb Daryl Rose <darylr...@outlook.com>:






So, today I decided to create a new RHEL 6 channel and repo and then run the "spacewalk-repo-sync" command and see if I can't get this repo to populate with packages from Red Hat.  The same error
occurred.



ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: content_dist_rhel_server_6_6Server_x86_64_os_. Please verify its path and try again



This tells me that there isn't anything corrupt.  I'm really think that I missed something in the configuration or setup of the new server. 


When I setup the original server, v2.3, I'm thinking there were some
additional steps that I had to do once I registered the server to Red Hat.  I've been reviewing the installation instructions, but I don't see anything extra that I missed. In the SW, v2.6,
 installation instructions, all I see is to make sure that the server is properly registered to the
appropriate channel:





Red Hat Optional Server (Red Hat Enterprise Linux)


When using Red Hat Enterprise Linux 6 or 7, make sure you are subscribed to the appropriate Red Hat Optional Server channel:


Red Hat Optional Server 6 , OR
Red Hat Optional Server 7




The server is properly registered and entitled.  I can run a yum repolist and see the repository.  I can issue the subscription-manager command and see that the server is subscribed and I can see what repos are enabled.  But for some reason, that is not
 getting passed onto the Spacewalk repo.


I tried opening a ticket with Red Hat just so I could verify that everything was registered correctly, but since I don't have a satellite subscription, they closed the ticket without even answering my question.


I've run out of idea's.  If someone can give me more suggestions, I'm willing to listen.


Thanks


Daryl






From: spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Robert Paschedag <robert.paschedag@web.de>
Sent: Friday, December 16, 2016 12:44 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel
 


Oh... Just saw that the checksum error occurs when run on a "client"..






Am 15.12.2016 22:48 schrieb Daryl Rose <darylrose@outlook.com>:



One more thought


What would happen if I were to delete the current RHEL channel and repository and recreate them?  What will happen to all of the packages and clients currently registered to the channel/repo?  I know that the packages will become orphan, but can I put them
 back into the new repo, or do I just have to remove them and re-download them from Red Hat?  How about the registered clients?   Do I have to re-register them, or if I keep the same activation key, the same channel/repo names, will they just pickup the change?


Thanks


Daryl




From: spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Thursday, December 15, 2016 2:59 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel
 



Hello Chris,


Thank you for the following steps.  I think this resolved this immanent issue, but the issue of not being able to sync from the parent Red Hat repository is still an issue.  


Do you know how the contents of ./cache/rhn/reposync are created?  As a work around, I copied the contents of
reposync from the original server to the new server, and I'm able to sync from the Red Hat repository, but that is not a long term solution.  


I thought that perhaps I had found a solution.  Yum can access the repository just fine so I copied the contents from
/var/cache/yum/x86_64/6Server/rhel-6-server-rpms to the reposync directory.  It started off just fine, but eventually failing due to not being able to find some keys.  Actually the keys were generated, but they were of zero length and that won't work.


It seems to be obvious that there is something else wrong with my installation, I just don't know what it is. If you, or anyone else have any thoughts are suggestion, I'm willing to take a look and give it a try.


Thank you.


Daryl



From: spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Snyder, Chris <Chris.Snyder@csra.com>
Sent: Wednesday, December 14, 2016 7:07 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel
 




The “metadata ….” Error indicates that your yum cache (provided by the Spacewalk server) is out of with what is actually available through the Spacewalk package database.  This can be because
 taskomatic isn’t running or there’s a problem somewhere.  Check your logs under 

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

behalf of Daryl Rose <darylrose@outlook.com>
Sent: Friday, December 9, 2016 2:56 PM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 




So,  I resurrected the old server from the grave and copied the contents of "/var/cach/rhn/reposync/rhel-6-server-rpms" to "/var/cach/rhn/reposync/content_dist_rhel_server_6_$releasever_$basearch_os"
 and ran a sync.  The sync worked.
 
The sync worked, but it caused a new error.  A team member registered a Red Hat server just after I made these changes.  The server registered, but  with the following error:
 
Bad id for repo: logstash 5.x, byte =   8
 
I'm guessing that something within the data that I copied over does not align with the repository on SW?  
 
Another thing that I noticed is that the directory structure in the old reposync directory is different than the new server.  For example:
 
OLD:
/var/cache/rhn/reposync/centos-7-extra




/centos-7-server-rpms
/centos-7-updae
/centos_7_channel
/centos_7_plus
 





NEW: 


/var/cache/rhn/reposync/centos_7_centosplus_x86_64_







/centos_7_extras_x86_64_



/centos_7_os_x86_64_



/centos_7_updates_x86_64_



 






Is that a SW v2.3 vs. v2.6 change?  



 



Thanks



 



Daryl


 







From:

spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Thursday, December 8, 2016 10:32 AM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 




More questions:
 
When I run "spacewalk-repo-sync --channel=rhel-6-server-rpms",  I get the error:
 
ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: content_dist_rhel_server_6_$releasever_$basearch_os. Please verify its path and try again


What creates the content in "/var/cache/rhn/reposync/content_dist_rhel_server_6_$releasever_$basearch_os"?



 



All of the other channels that I created all have "cachecookie, packages, primary.xml.gz, primary.xml.gz.sqlite, repomd.xml and updateinfo.xml.gz".  



 



There must be a process that creates this content, but what, I'm not sure.  How can I manually create this content?



 



Thanks



 



Daryl



 







From:

spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Thursday, December 8, 2016 9:26 AM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 




Quick update.
 
Poking around on Red Hat I found a doc that suggested that I look at the  name in /etc/sysconfig/network and ensure that the hostname is FQDN and then run "spacewalk-hostname-rename".   Host name
 was not FQDN, so I renamed it, but because I use a signed cert, will running spacewalk-hostname-rename cause a problem with that cert?  
 
Thanks
 
Daryl

 







From:

spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Thursday, December 8, 2016 8:55 AM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 




Robert,
 
Yes, the server is registered and has an active subscription with Red Hat.  As a matter of fact, I just now re-registered to make sure that all is good.   I can see from the command line subscription
 manager that the server is subscribed, and I confirmed that it is entitled.  
 
I use a "signed" cert so I'm wondering if the signed cert has something to do with this?  However, I found a troubleshooting document on Red Hat that verifies that I am entitled and using the
 certificate provided by Red Hat to communicate back to them.  


 



Thank you



 



Daryl








From:

spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Robert Paschedag <robert.paschedag@web.de>
Sent: Wednesday, December 7, 2016 11:48 PM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 






I think you should check your entitlements. But I also don't know, how you could "manually" connect to the repo (with username/password or token inline in URL).

Is your server listed as entitled within your RedHat account?








Von:
Daryl Rose
Gesendet:
‎06.‎12.‎2016 17:26
An:
spacewalk-list@redhat.com
Betreff:
Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel


I decided to try the sync from the command line.  This time I received an error:
 
ERROR: Cannot retrieve

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

 <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Friday, December 9, 2016 2:56 PM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 




So,  I resurrected the old server from the grave and copied the contents of "/var/cach/rhn/reposync/rhel-6-server-rpms" to "/var/cach/rhn/reposync/content_dist_rhel_server_6_$releasever_$basearch_os"
 and ran a sync.  The sync worked.
 
The sync worked, but it caused a new error.  A team member registered a Red Hat server just after I made these changes.  The server registered, but  with the following error:
 
Bad id for repo: logstash 5.x, byte =   8
 
I'm guessing that something within the data that I copied over does not align with the repository on SW?  
 
Another thing that I noticed is that the directory structure in the old reposync directory is different than the new server.  For example:
 
OLD:
/var/cache/rhn/reposync/centos-7-extra




/centos-7-server-rpms
/centos-7-updae
/centos_7_channel
/centos_7_plus
 





NEW: 


/var/cache/rhn/reposync/centos_7_centosplus_x86_64_







/centos_7_extras_x86_64_



/centos_7_os_x86_64_



/centos_7_updates_x86_64_



 






Is that a SW v2.3 vs. v2.6 change?  



 



Thanks



 



Daryl


 







From:

spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Thursday, December 8, 2016 10:32 AM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 




More questions:
 
When I run "spacewalk-repo-sync --channel=rhel-6-server-rpms",  I get the error:
 
ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: content_dist_rhel_server_6_$releasever_$basearch_os. Please verify its path and try again


What creates the content in "/var/cache/rhn/reposync/content_dist_rhel_server_6_$releasever_$basearch_os"?



 



All of the other channels that I created all have "cachecookie, packages, primary.xml.gz, primary.xml.gz.sqlite, repomd.xml and updateinfo.xml.gz".  



 



There must be a process that creates this content, but what, I'm not sure.  How can I manually create this content?



 



Thanks



 



Daryl



 







From:

spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Thursday, December 8, 2016 9:26 AM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 




Quick update.
 
Poking around on Red Hat I found a doc that suggested that I look at the  name in /etc/sysconfig/network and ensure that the hostname is FQDN and then run "spacewalk-hostname-rename".   Host name
 was not FQDN, so I renamed it, but because I use a signed cert, will running spacewalk-hostname-rename cause a problem with that cert?  
 
Thanks
 
Daryl

 







From:

spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Thursday, December 8, 2016 8:55 AM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 




Robert,
 
Yes, the server is registered and has an active subscription with Red Hat.  As a matter of fact, I just now re-registered to make sure that all is good.   I can see from the command line subscription
 manager that the server is subscribed, and I confirmed that it is entitled.  
 
I use a "signed" cert so I'm wondering if the signed cert has something to do with this?  However, I found a troubleshooting document on Red Hat that verifies that I am entitled and using the
 certificate provided by Red Hat to communicate back to them.  


 



Thank you



 



Daryl








From:

spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Robert Paschedag <robert.paschedag@web.de>
Sent: Wednesday, December 7, 2016 11:48 PM
To: 
spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



 






I think you should check your entitlements. But I also don't know, how you could "manually" connect to the repo (with username/password or token inline in URL).

Is your server listed as entitled within your RedHat account?








Von:
Daryl Rose
Gesendet:
‎06.‎12.‎2016 17:26
An:
spacewalk-list@redhat.com
Betreff:
Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel


I decided to try the sync from the command line.  This time I

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

ith this?  However, I found a troubleshooting document on Red Hat that verifies that I am entitled and using the certificate provided by Red Hat to communicate back to them.  


Thank you


Daryl


From: spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Robert Paschedag <robert.paschedag@web.de>
Sent: Wednesday, December 7, 2016 11:48 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel
 



I think you should check your entitlements. But I also don't know, how you could "manually" connect to the repo (with username/password or token inline in URL).

Is your server listed as entitled within your RedHat account?




Von:
Daryl Rose
Gesendet:
‎06.‎12.‎2016 17:26
An:
spacewalk-list@redhat.com
Betreff:
Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel



I decided to try the sync from the command line.  This time I received an error:


ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: content_dist_rhel_server_6_6Server_x86_64_os_. Please verify its path and try again



The path came out of the redhat.repo file that came from Red Hat when I registered the server.  Its the same path that was used on the previous server.  


Any suggestions?


Thank you.


Daryl



From: spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> on behalf of Daryl Rose <darylrose@outlook.com>
Sent: Monday, December 5, 2016 3:00 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] RHEL 6.x repository not syncing from parent channel
 



I just realized that the last Red Hat errata for RHEL 6.x is from August.  I looked at the sync logs and it doesn't appear that anything is syncing at all from the RHEL channel.  


I just recently migrated to a physical server.  I successfully registered the server and attached an entitlement to the server.  If I run "yum update" on the server, it lists latest updates from the RHEL channel.  


This is what I see in the reposync log:



2016/12/05 14:49:42 -05:00 Command: ['/usr/bin/spacewalk-repo-sync', '--channel', 'rhel-6-server-rpms', '--type', 'yum']
2016/12/05 14:49:42 -05:00 Sync of channel started.
2016/12/05 14:49:42 -05:00 Repo URL: https:
2016/12/05 14:49:42 -05:00 Sync of channel completed in 0:00:00.


If I haven't received any syncs since August, then this broke long before I migrated to the physical server.


Any thoughts?


Daryl



























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

Re: [Spacewalk-list] RHEL 6.x repository not syncing fromparentchannel

[Robert Paschedag]

Don't run this rename command unless you know what you are doing with it.

If you run it, you "might" break your communication to the clients.

- Ursprüngliche Nachricht -
Von: "Daryl Rose" <darylr...@outlook.com>
Gesendet: ‎08.‎12.‎2016 16:39
An: "spacewalk-list@redhat.com" <spacewalk-list@redhat.com>
Betreff: Re: [Spacewalk-list] RHEL 6.x repository not syncing fromparentchannel

Quick update.


Poking around on Red Hat I found a doc that suggested that I look at the  name 
in /etc/sysconfig/network and ensure that the hostname is FQDN and then run 
"spacewalk-hostname-rename".   Host name was not FQDN, so I renamed it, but 
because I use a signed cert, will running spacewalk-hostname-rename cause a 
problem with that cert?  


Thanks


Daryl






From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> on 
behalf of Daryl Rose <darylr...@outlook.com>
Sent: Thursday, December 8, 2016 8:55 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from 
parentchannel 
 
Robert,


Yes, the server is registered and has an active subscription with Red Hat.  As 
a matter of fact, I just now re-registered to make sure that all is good.   I 
can see from the command line subscription manager that the server is 
subscribed, and I confirmed that it is entitled.  


I use a "signed" cert so I'm wondering if the signed cert has something to do 
with this?  However, I found a troubleshooting document on Red Hat that 
verifies that I am entitled and using the certificate provided by Red Hat to 
communicate back to them.  


Thank you


Daryl



From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> on 
behalf of Robert Paschedag <robert.pasche...@web.de>
Sent: Wednesday, December 7, 2016 11:48 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] RHEL 6.x repository not syncing from 
parentchannel 
 
I think you should check your entitlements. But I also don't know, how you 
could "manually" connect to the repo (with username/password or token inline in 
URL).

Is your server listed as entitled within your RedHat account?



Von: Daryl Rose
Gesendet: ‎06.‎12.‎2016 17:26
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel


I decided to try the sync from the command line.  This time I received an error:


ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: 
content_dist_rhel_server_6_6Server_x86_64_os_. Please verify its path and try 
again



The path came out of the redhat.repo file that came from Red Hat when I 
registered the server.  Its the same path that was used on the previous server. 
  


Any suggestions?


Thank you.


Daryl





From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> on 
behalf of Daryl Rose <darylr...@outlook.com>
Sent: Monday, December 5, 2016 3:00 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] RHEL 6.x repository not syncing from parent channel 
 
I just realized that the last Red Hat errata for RHEL 6.x is from August.  I 
looked at the sync logs and it doesn't appear that anything is syncing at all 
from the RHEL channel.  


I just recently migrated to a physical server.  I successfully registered the 
server and attached an entitlement to the server.  If I run "yum update" on the 
server, it lists latest updates from the RHEL channel.  


This is what I see in the reposync log:


2016/12/05 14:49:42 -05:00 Command: ['/usr/bin/spacewalk-repo-sync', 
'--channel', 'rhel-6-server-rpms', '--type', 'yum']
2016/12/05 14:49:42 -05:00 Sync of channel started.
2016/12/05 14:49:42 -05:00 Repo URL: https:
2016/12/05 14:49:42 -05:00 Sync of channel completed in 0:00:00.


If I haven't received any syncs since August, then this broke long before I 
migrated to the physical server.


Any thoughts?


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

Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

[Robert Paschedag]

I think you should check your entitlements. But I also don't know, how you 
could "manually" connect to the repo (with username/password or token inline in 
URL).

Is your server listed as entitled within your RedHat account?


- Ursprüngliche Nachricht -
Von: "Daryl Rose" 
Gesendet: ‎06.‎12.‎2016 17:26
An: "spacewalk-list@redhat.com" 
Betreff: Re: [Spacewalk-list] RHEL 6.x repository not syncing from parentchannel

I decided to try the sync from the command line.  This time I received an error:


ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: 
content_dist_rhel_server_6_6Server_x86_64_os_. Please verify its path and try 
again



The path came out of the redhat.repo file that came from Red Hat when I 
registered the server.  Its the same path that was used on the previous server. 
  


Any suggestions?


Thank you.


Daryl





From: spacewalk-list-boun...@redhat.com  on 
behalf of Daryl Rose 
Sent: Monday, December 5, 2016 3:00 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] RHEL 6.x repository not syncing from parent channel 
 
I just realized that the last Red Hat errata for RHEL 6.x is from August.  I 
looked at the sync logs and it doesn't appear that anything is syncing at all 
from the RHEL channel.  


I just recently migrated to a physical server.  I successfully registered the 
server and attached an entitlement to the server.  If I run "yum update" on the 
server, it lists latest updates from the RHEL channel.  


This is what I see in the reposync log:


2016/12/05 14:49:42 -05:00 Command: ['/usr/bin/spacewalk-repo-sync', 
'--channel', 'rhel-6-server-rpms', '--type', 'yum']
2016/12/05 14:49:42 -05:00 Sync of channel started.
2016/12/05 14:49:42 -05:00 Repo URL: https:
2016/12/05 14:49:42 -05:00 Sync of channel completed in 0:00:00.


If I haven't received any syncs since August, then this broke long before I 
migrated to the physical server.


Any thoughts?


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

Re: [Spacewalk-list] Spacewalk proxy

[Robert Paschedag]

 

I'm honestly not sure, but I would think, that the client should contact the proxy and the proxy itself should contact the server and forward the answer back to the client.

 

I don't see the proxy connecting to the server. The proxy is contacting "localhost.localdomain"! This is the proxy itself, unless you are doing really ugly things within /etc/hosts

 

But as I said, 'cause I'm not using a proxy, I'm not sure, how the setup should look like. I would really check the proxy setup, so that it really contacts the server.

 

How is the log from the server looking?

 

 

 


Gesendet: Freitag, 25. November 2016 um 09:51 Uhr
Von: "Oucema Bellagha" 
An: "Spacewalk-list@redhat.com" 
Betreff: [Spacewalk-list] Spacewalk proxy




 

Hi there,

 

I have and architecture composed by:

 

Spacewalk server : jabberd + osa-dipatcher

Spacewalk proxy : jabberd  + osad : is this configuration correct or I need osa-dipatcher + jabberd here ?

Scpacewalk client : osad

 

The problem is when I had the configuration of Spacewalk server + Scpacewalk client the updates are done instantly, now by adding the SW proxy the updates takes more than 3 hours to be applied and this need to be fixed.

 

On the client: 

 

/usr/sbin/osad -N -v -v -v -v

2016-11-23 10:11:32 osad._setup_config: Updating configuration

2016-11-23 10:11:32 jabber_lib.setup_connection: Connecting to proxy.local.labs

2016-11-23 10:11:32 jabber_lib._get_jabber_client:

2016-11-23 10:11:32 jabber_lib._get_jabber_client: Connecting to proxy.ins.local.labs

2016-11-23 10:11:32 jabber_lib.__init__:

2016-11-23 10:11:32 jabber_lib.__init__:

2016-11-23 10:11:32 jabber_lib.check_cert: Loading cert 

2016-11-23 10:11:32 jabber_lib.connect:

2016-11-23 10:11:32 jabber_lib.process: 300

2016-11-23 10:11:32 jabber_lib.process: None

2016-11-23 10:11:32 jabber_lib.connect: Preparing for TLS handshake

2016-11-23 10:11:32 jabber_lib.process: None

2016-11-23 10:11:32 jabber_lib.process: None

2016-11-23 10:11:32 jabber_lib.setup_connection: Connected to jabber server proxy.local.labs

2016-11-23 10:11:32 osad_client.start: osad-7f23444dfa 3156c10b5381e50aaff4 osad

2016-11-23 10:11:32 jabber_lib.auth: osad-7f23444dfa 3156c10b5381e50aaff4 osad 1

2016-11-23 10:11:32 jabber_lib.auth: Sending auth request osad-7f23444dfa

2016-11-23 10:11:32 jabber_lib.process: 59.938011

2016-11-23 10:11:32 jabber_lib.dispatch: Unhandled stanza osad-7f23444dfa

2016-11-23 10:11:32 jabber_lib.auth: Auth response osad-7f23444dfa

2016-11-23 10:11:32 jabber_lib.auth: Sending auth info osad-7f23444dfaosadacc9759e941389a797d038587f9d764a32d3ad02

2016-11-23 10:11:32 jabber_lib.process: 299.93801

2016-11-23 10:11:32 jabber_lib.dispatch: Unhandled stanza 

2016-11-23 10:11:32 jabber_lib.auth: Authenticated

2016-11-23 10:11:32 jabber_lib.register_callback: > iq None None None None

2016-11-23 10:11:32 jabber_lib.process: None

2016-11-23 10:11:32 jabber_lib._roster_callback: Updating the roster 

2016-11-23 10:11:32 jabber_lib.register_callback: > presence None None None None

2016-11-23 10:11:32 jabber_lib.register_callback: > message None None None None

2016-11-23 10:11:32 jabber_lib.register_callback: > error None None None None

2016-11-23 10:11:32 osad.fix_connection: Time drift 1

2016-11-23 10:11:32 osad.fix_connection: Client name 03ebd72b35dbb13d

2016-11-23 10:11:32 osad.fix_connection: Shared key fa1e1673d57f8b1c830939e5f0f8b88b3fa9b57a

2016-11-23 10:11:32 jabber_lib.subscribe_to_presence: Subscribed to {}

2016-11-23 10:11:32 jabber_lib.subscribe_to_presence: Subscribed both {}

2016-11-23 10:11:32 jabber_lib.subscribe_to_presence: Subscribed none {'rhn-dispatcher-sat@localhost.localdomain': {'ask': u'subscribe', 'jid': 'rhn-dispatcher-sat@localhost.localdomain', 'subscription': u'none'}}

2016-11-23 10:11:32 jabber_lib.subscribe_to_presence: Subscribed from {}

2016-11-23 10:11:32 jabber_lib.subscribe_to_presence: Subscribed none + ask=subscribe

2016-11-23 10:11:32 jabber_lib.send_presence: None None

2016-11-23 10:11:32 jabber_lib.process_forever:

2016-11-23 10:11:32 jabber_lib.process: 180

 
On the proxy:

 

 

 

2016-11-23 10:14:31 osad._setup_config: Updating configuration

2016-11-23 10:14:31 jabber_lib.setup_connection: Connecting to localhost.localdomain

2016-11-23 10:14:31 jabber_lib._get_jabber_client:

2016-11-23 10:14:31 jabber_lib._get_jabber_client: Connecting to localhost.localdomain

2016-11-23 10:14:31 jabber_lib.__init__:

2016-11-23 10:14:31 jabber_lib.__init__:

2016-11-23 10:14:31 jabber_lib.check_cert: Loading cert 

2016-11-23 10:14:31 jabber_lib.connect:

2016-11-23 10:14:31 jabber_lib.process: 300

2016-11-23 10:14:31 jabber_lib.process: None

2016-11-23 10:14:31 jabber_lib.connect: Preparing for TLS handshake

2016-11-23 10:14:31 jabber_lib.process: None

2016-11-23 10:14:31 jabber_lib.process: None

2016-11-23 10:14:31 jabber_lib.setup_connection: Connected to jabber server 

Re: [Spacewalk-list] Spacewalk scheduling problem

[Robert Paschedag]

You are not using osad, that would run the job instantly. rhnsd default 
interval is 240 minutes. Can be set to minimum of 60 in /etc/sysconfig/rhn/rhnsd

Am 16.11.2016 16:49 schrieb Oucema Bellagha :
>
> Hi folks,
>
>
> I implemented a test environment  for Spacewalk [spacewalk server + Spacewalk 
> proxy], everything is working good; I added new channel for updates and added 
> the client to the server and so on, but the problem is when I schedule any 
> event (update, install or whatever) the server deploy it on the client with a 
> delay between 2 and ~5 hours.
>
>
> Example: 
>
> Package Install/Upgrade scheduled by SuperAdm
> 11/15/16 4:30:00 PM CET
> 0
> 0
> 1
> 1
>
> The deployment of updates is done at 7:22 PM, so there's a delay of 2.52 
> hours.
>
>
> The time between servers is synchronized so it can't be an ntpd problem from 
> my perspectives. 
>
>
> Do you have any ideas about this ? or any possible ways to track the problem 
> in the right way ?
>
>
> Cheers,
>
>
> Oucema Bellagha
>
> DevOps Engineer specialized in Cloud Computing and IT infrastructures 

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

Re: [Spacewalk-list] Package is not available for installation, again

[Robert Paschedag]

All systems are subscribing the same channel that packages have been pushed to?

Am 16.11.2016 11:01 schrieb Artem Pastukhov :
>
> Hi all!
> I'm truing to make CI/CD system with spacewalk 2.5
>
> There is three seps
> make rpm
> push it to spacewalk with rhnpush
> Schedule to install it to group of hosts with schedulePackageInstall API call
> And i have troubles with last step. Sometime approximately 10% of cases i'm 
> getting  Package %packageName is not available for installation. I get 
> %packagename by calling listLatestAvailablePackage method.
>
> If I reschedule same job in a few minutes, I will get a successful result in 
> 90% of cases.
>
> Is there any way to get 100% ?
>
> -- 
>
> С уважением,
>
> АРТЕМ ПАСТУХОВ, 
>
> Системный администратор
>
> +7 (916) 597-56-74 | +7 (800) 555-46-68 | #переходиналекта 
>
>

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

Re: [Spacewalk-list] Manage automatic updates of errata updates

[Robert Paschedag]

I really meant the API to find errata and apply

http://www.spacewalkproject.org/documentation/api/2.4/handlers/SystemHandler.html#getUnscheduledErrata
http://www.spacewalkproject.org/documentation/api/2.4/handlers/SystemHandler.html#scheduleApplyErrata

Regards,
Robert


> Gesendet: Donnerstag, 10. November 2016 um 13:53 Uhr
> Von: "Grund Anders" <anders.gr...@softronic.se>
> An: "spacewalk-list@redhat.com" <spacewalk-list@redhat.com>
> Betreff: Re: [Spacewalk-list] Manage automatic updates of errata updates
>
> Well the errata is not a problem, I'm using CEFS https://cefs.steve-meier.de/ 
>  for that.
> 
> I had hope for an easy way to schedule the real packet updates in the Gui, or 
> what options is available ?
> 
> I have looked at spacewalk-clone-by-date cmd, but it clones the channels.
> What about the repos, you have to add repos to the cloned channels then i 
> guess ?
> 
> Would be convenient to use something like clone-by-date in the gui, so you 
> get some tracability and be able to schedule it once o month.
> 
> Pretty difficult to find any documentation on the concrete steps  necessary 
> to get this working.
> 
> How do you do at your site ?
> /Anders
> 
> 
> 
> 
> -Ursprungligt meddelande-
> Från: Robert Paschedag [mailto:robert.pasche...@web.de] 
> Skickat: den 9 november 2016 12:40
> Till: Grund Anders <anders.gr...@softronic.se>
> Kopia: spacewalk-list@redhat.com
> Ämne: Re: [Spacewalk-list] Manage automatic updates of errata updates
> 
> Sure.. But you have to use the API to find erratas for a system and apply 
> them and setup a cron job to do it.
> 
> Am 09.11.2016 09:17 schrieb Grund Anders <anders.gr...@softronic.se>:
> >
> > Hello,
> >
> >  
> >
> > Is it possible to schedule automatic updates  for errata in Spacewalk ?
> >
> > e.g like once or twice a month
> >
> >  
> >
> > Regards
> >
> > /Anders
> >
> >  
> >
> >  
> >
> > -
> >
> > Softronic AB
> >
> > Ringvägen 100, 118 60 Stockholm
> >
> > Växel: +46 8 51 90 90 000
> >
> > Mobil: +46 70 881 31 07
> > E-post: anders.gr...@softronic.se
> >
> > -
> >
> >  
> 
> ___
> 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] Manage automatic updates of errata updates

[Robert Paschedag]

Sure.. But you have to use the API to find erratas for a system and apply them 
and setup a cron job to do it.

Am 09.11.2016 09:17 schrieb Grund Anders :
>
> Hello,
>
>  
>
> Is it possible to schedule automatic updates  for errata in Spacewalk ?
>
> e.g like once or twice a month
>
>  
>
> Regards
>
> /Anders
>
>  
>
>  
>
> -
>
> Softronic AB
>
> Ringvägen 100, 118 60 Stockholm
>
> Växel: +46 8 51 90 90 000
>
> Mobil: +46 70 881 31 07
> E-post: anders.gr...@softronic.se
>
> -
>
>  

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

Re: [Spacewalk-list] Schedule kernel upgrade result in kernel panic

[Robert Paschedag]

I also never had problems with SLES or Debian systems.

Robert
Am 16.09.2016 13:48 schrieb Thomas Foster <thomas.foste...@gmail.com>:
>
> I've seen that happened when yum install couldn't write to /boot (either 
> because of security rules in place..cis comes to mind).
>
>
> On Sep 16, 2016 7:37 AM, "Robert Paschedag" <robert.pasche...@web.de> wrote:
>>
>> I don't think, that rhnsd is causing this. Seems more related to yum.
>>
>> Am 16.09.2016 08:52 schrieb Lionel Caignec <caig...@cines.fr>:
>> >
>> > Perhaps this is a bug of the rhnsd agent for Rhel7 which is timing out 
>> > during kernel update process (which is long).
>> > Is it a config file which can defer between Rhel7 and Rhel6?
>> >
>> > - Mail original -
>> > De: "Lionel Caignec" <caig...@cines.fr>
>> > À: "spacewalk-list" <spacewalk-list@redhat.com>
>> > Envoyé: Vendredi 16 Septembre 2016 08:43:32
>> > Objet: Re: [Spacewalk-list] Schedule kernel upgrade result in kernel panic
>> >
>> > Ok thank you i understand now why initramfs missing, i will look in "yum 
>> > debug" log if it exists.
>> >
>> > - Mail original -
>> > De: "William H. ten Bensel" <whten...@up.com>
>> > À: "spacewalk-list" <spacewalk-list@redhat.com>
>> > Envoyé: Jeudi 15 Septembre 2016 21:09:37
>> > Objet: Re: [Spacewalk-list] Schedule kernel upgrade result in kernel panic
>> >
>> > - Schedule a kernel update from Web GUI, let spacewalk agent do it's job 
>> > and get kernel update (/boot/initramfs missing)
>> >
>> > Just saw something similar today.
>> > Issue: Timed out (+2 hours) in the middle of the yum upgrade process.
>> > Solution: Reboot to previous kernel, run yum-complete-transaction, and 
>> > reinstall the new kernel rpms.
>> >
>> > - Thanks and good luck
>> >
>> >
>> > From: Lionel Caignec <caig...@cines.fr>
>> > To: spacewalk-list <spacewalk-list@redhat.com>
>> > Date: 09/15/2016 04:34 AM
>> > Subject: Re: [Spacewalk-list] Schedule kernel upgrade result in kernel 
>> > panic
>> > Sent by: spacewalk-list-boun...@redhat.com
>> >
>> >
>> > This email originated from outside of the company. Please use discretion 
>> > if opening attachments or clicking on links.
>> >
>> > Hi,
>> >
>> > i'm still stuck, i cannot schedule a kernel update from spacewalk (web 
>> > gui) to my CentOS 7 client, because at reboot my server go into "kernel 
>> > panic"
>> >
>> > I don't understand the difference between this 2 way of doing :
>> > - Schedule a kernel update from Web GUI, let spacewalk agent do it's job 
>> > and get kernel update (/boot/initramfs missing)
>> > - Schedule a kernel update from Web GUI, launch on client "rhn_chek" --> 
>> > reboot with no problem on the newest kernel.
>> >
>> > All kernel version give this result, my spacewalk is in version 2.5, but i 
>> > already have this bug in 2.4.
>> >
>> > How can i get debug log from spacewalk agent, perhaps there is something 
>> > interisting in.
>> >
>> > Thank for helping
>> >
>> > --
>> > Lionel
>> >
>> > - Mail original -
>> > De: "Lionel Caignec" <caig...@cines.fr>
>> > À: "spacewalk-list" <spacewalk-list@redhat.com>
>> > Envoyé: Mardi 23 Août 2016 11:43:12
>> > Objet: Re: [Spacewalk-list] Schedule kernel errata upgrade result in 
>> > kernel panic
>> >
>> > Hi,
>> >
>> > i use the webUI to schedule update. It's not related to one specific 
>> > update, but all kernel update (it's a bug i've for months now.). When a 
>> > new kernel is released i schedule update and reboot --> Result in "kernel 
>> > panic".
>> >
>> > All my clients os are Centos 7 and RedHat 7.
>> >
>> > Lionel.
>> >
>> > - Mail original -
>> > De: "Tomas Lestach" <tlest...@redhat.com>
>> > À: "spacewalk-list" <spacewalk-list@redhat.com>
>> > Envoyé: Mardi 23 Août 2016 11:16:52
>> > Objet: Re: [Spacewalk-list] Schedule kernel errata upgrade result in 
>> > kernel panic
>> >
>> > Hello, please, help me understand your problem.
>> > Yo

Re: [Spacewalk-list] Schedule kernel upgrade result in kernel panic

[Robert Paschedag]

I don't think, that rhnsd is causing this. Seems more related to yum.

Am 16.09.2016 08:52 schrieb Lionel Caignec :
>
> Perhaps this is a bug of the rhnsd agent for Rhel7 which is timing out during 
> kernel update process (which is long).
> Is it a config file which can defer between Rhel7 and Rhel6?
>
> - Mail original -
> De: "Lionel Caignec" 
> À: "spacewalk-list" 
> Envoyé: Vendredi 16 Septembre 2016 08:43:32
> Objet: Re: [Spacewalk-list] Schedule kernel upgrade result in kernel panic
>
> Ok thank you i understand now why initramfs missing, i will look in "yum 
> debug" log if it exists.
>
> - Mail original -
> De: "William H. ten Bensel" 
> À: "spacewalk-list" 
> Envoyé: Jeudi 15 Septembre 2016 21:09:37
> Objet: Re: [Spacewalk-list] Schedule kernel upgrade result in kernel panic
>
> - Schedule a kernel update from Web GUI, let spacewalk agent do it's job and 
> get kernel update (/boot/initramfs missing)
>
> Just saw something similar today. 
> Issue: Timed out (+2 hours) in the middle of the yum upgrade process. 
> Solution: Reboot to previous kernel, run yum-complete-transaction, and 
> reinstall the new kernel rpms. 
>
> - Thanks and good luck 
>
>
> From: Lionel Caignec  
> To: spacewalk-list  
> Date: 09/15/2016 04:34 AM 
> Subject: Re: [Spacewalk-list] Schedule kernel upgrade result in kernel panic 
> Sent by: spacewalk-list-boun...@redhat.com 
>
>
> This email originated from outside of the company. Please use discretion if 
> opening attachments or clicking on links.
>
> Hi,
>
> i'm still stuck, i cannot schedule a kernel update from spacewalk (web gui) 
> to my CentOS 7 client, because at reboot my server go into "kernel panic"
>
> I don't understand the difference between this 2 way of doing : 
> - Schedule a kernel update from Web GUI, let spacewalk agent do it's job and 
> get kernel update (/boot/initramfs missing) 
> - Schedule a kernel update from Web GUI, launch on client "rhn_chek" --> 
> reboot with no problem on the newest kernel.
>
> All kernel version give this result, my spacewalk is in version 2.5, but i 
> already have this bug in 2.4.
>
> How can i get debug log from spacewalk agent, perhaps there is something 
> interisting in. 
>
> Thank for helping
>
> -- 
> Lionel
>
> - Mail original - 
> De: "Lionel Caignec"  
> À: "spacewalk-list"  
> Envoyé: Mardi 23 Août 2016 11:43:12 
> Objet: Re: [Spacewalk-list] Schedule kernel errata upgrade result in kernel 
> panic
>
> Hi,
>
> i use the webUI to schedule update. It's not related to one specific update, 
> but all kernel update (it's a bug i've for months now.). When a new kernel is 
> released i schedule update and reboot --> Result in "kernel panic".
>
> All my clients os are Centos 7 and RedHat 7.
>
> Lionel.
>
> - Mail original - 
> De: "Tomas Lestach"  
> À: "spacewalk-list"  
> Envoyé: Mardi 23 Août 2016 11:16:52 
> Objet: Re: [Spacewalk-list] Schedule kernel errata upgrade result in kernel 
> panic
>
> Hello, please, help me understand your problem. 
> You write: 
> * if you "schedule a kernel errata update at reboot", there's an issue 
> with initramfs, grub.cfg ... 
> * if you "schedule upgrade with gui", everything's ok
>
> Does it mean the 1st case isn't via WebUI? Is it via API?
>
> Can you be more specific? What OS do you use on the client, what erratum 
> are you scheduling for update? What way? ... 
>
> Thanks, 
> -- 
> Tomas Lestach 
> Red Hat Satellite Engineering 
>
> On 08/23/2016 10:54 AM, Lionel Caignec wrote: 
> > Hi, 
> > 
> > i've a annoying bug with spacewalk. When i schedule a kernel errata update 
> > at reboot my server is going into kernel panic. 
> > 
> > After some time i've found that initramfs was not generated during update 
> > phase. Moreover in grub.cfg the line "initrd ..." is missing. 
> > If i boot with an old kernel and i launch "yum reinstall kernel" server 
> > will boot without problem on new kernel. 
> > 
> > 
> > But if i schedule upgrade with gui, and then use "rhn_check -vvv" on my 
> > server there is no problem. 
> > 
> > Someone could help me? What do i missing? 
> > 
> > 
> > Thanks, 
> > 
> > -- 
> > Lionel Caignec 
> > 
> > Centre Informatique National de l' Enseignement Supérieur 
> > 950 rue de Saint Priest 
> > 34097 MONTPELLIER Cedex 5 
> > Tel : (33) 04 67 14 14 14 
> > Fax : (33)04 67 52 37 63 
> > http://www.cines.fr 
> > 
> > ___ 
> > Spacewalk-list mailing list 
> > Spacewalk-list@redhat.com 
> > https://www.redhat.com/mailman/listinfo/spacewalk-list 
> > 
> >
>
> ___ 
> Spacewalk-list mailing list 
> Spacewalk-list@redhat.com 
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> 

Re: [Spacewalk-list] Schedule kernel upgrade result in kernel panic

[Robert Paschedag]

Only know this when using SLES you can look in /var/log/zypper/history as this 
is just RPMs that are updated. I don't know if there is anything similar with 
yum.The rebuild of the initramfs should be triggered from the post install 
scripts within the RPM. There should be no difference.

Regards
Robert

Am 15.09.2016 11:21 schrieb Lionel Caignec :
>
> Hi,
>
> i'm still stuck, i cannot schedule a kernel update from spacewalk (web gui) 
> to my CentOS 7 client, because at reboot my server go into "kernel panic"
>
> I don't understand the difference between this 2 way of doing : 
> - Schedule a kernel update from Web GUI, let spacewalk agent do it's job and 
> get kernel update (/boot/initramfs missing)
> - Schedule a kernel update from Web GUI, launch on client "rhn_chek" --> 
> reboot with no problem on the newest kernel.
>
> All kernel version give this result, my spacewalk is in version 2.5, but i 
> already have this bug in 2.4.
>
> How can i get debug log from spacewalk agent, perhaps there is something 
> interisting in.
>
> Thank for helping
>
> --
> Lionel
>
> - Mail original -
> De: "Lionel Caignec" 
> À: "spacewalk-list" 
> Envoyé: Mardi 23 Août 2016 11:43:12
> Objet: Re: [Spacewalk-list] Schedule kernel errata upgrade result in kernel 
> panic
>
> Hi,
>
> i use the webUI to schedule update. It's not related to one specific update, 
> but all kernel update (it's a bug i've for months now.). When a new kernel is 
> released i schedule update and reboot --> Result in "kernel panic".
>
> All my clients os are Centos 7 and RedHat 7.
>
> Lionel.
>
> - Mail original -
> De: "Tomas Lestach" 
> À: "spacewalk-list" 
> Envoyé: Mardi 23 Août 2016 11:16:52
> Objet: Re: [Spacewalk-list] Schedule kernel errata upgrade result in kernel 
> panic
>
> Hello, please, help me understand your problem.
> You write:
> * if you "schedule a kernel errata update at reboot", there's an issue 
> with initramfs, grub.cfg ...
> * if you "schedule upgrade with gui", everything's ok
>
> Does it mean the 1st case isn't via WebUI? Is it via API?
>
> Can you be more specific? What OS do you use on the client, what erratum 
> are you scheduling for update? What way? ...
>
> Thanks,
> --
> Tomas Lestach
> Red Hat Satellite Engineering
>
> On 08/23/2016 10:54 AM, Lionel Caignec wrote:
> > Hi,
> >
> > i've a annoying bug with spacewalk. When i schedule a kernel errata update 
> > at reboot my server is going into kernel panic.
> >
> > After some time i've found that initramfs was not generated during update 
> > phase. Moreover in grub.cfg the line "initrd ..." is missing.
> > If i boot with an old kernel and i launch "yum reinstall kernel" server 
> > will boot without problem on new kernel.
> >
> >
> > But if i schedule upgrade with gui, and then use "rhn_check -vvv" on my 
> > server there is no problem.
> >
> > Someone could help me? What do i missing?
> >
> >
> > Thanks,
> >
> > --
> > Lionel Caignec
> >
> > Centre Informatique National de l' Enseignement Supérieur
> > 950 rue de Saint Priest
> > 34097 MONTPELLIER Cedex 5
> > Tel : (33) 04 67 14 14 14
> > Fax : (33)04 67 52 37 63
> > http://www.cines.fr
> >
> > ___
> > Spacewalk-list mailing list
> > Spacewalk-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> >
> >
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

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

Re: [Spacewalk-list] Errata not synced anymore

[Robert Paschedag]

Maybe the ids have changed. I don't know. I'm also not syncing red hat repos so 
u cannot check this.

Robert
Am 08.09.2016 1:22 nachm. schrieb Morten Middelthon <m...@lastfriday.com>:
>
> Hi, 
>
> the other host, prdrhelsync, is just running reposync and createrepo_c. On 
> that server I have located the XML file containing updateinfo, in my case: 
>
> repodata/397ba6897f0627591714d5ade324ba110f6c4b5610a855a058733e7fda329ef6-updateinfo.xml.gz
>  
>
> I’ve extracted the file, and found the errata for 2014:1850, which points to 
> an old update for virt-who. As far as I can tell there is nothing wrong with 
> the XML formatting. I’m guessing the error message I’m getting is generated 
> by python (ERROR: invalid literal for int(): RHBA-2014:1850), when python 
> expects a variable to be an INT, and instead gets a string, or something 
> similar? 
>
>    type="bugfix" > 
>     RHBA-2014:1850 
>      
>     virt-who bug fix update 
>     0 
>     Copyright 2014 Red Hat Inc 
>     The virt-who package provides an agent that collects 
> information about virtual 
> guests present in the system and reports them to the subscription manager. 
>
> This update fixes the following bug: 
>
> * Prior to this update, the virt-who agent failed to read the list of virtual 
> guests provided by the VDSM daemon. As a consequence, when in VDSM mode, 
> virt-who was not able to send updates about virtual guests to the 
> Subscription 
> Asset Manager (SAM) and Red Hat Satellite. With this update, virt-who reads 
> the 
> list of guests when in VDSM mode correctly, and reports to SAM and Satellite 
> as 
> expected. (BZ#1158441) 
>
> Users of virt-who are advised to upgrade to this updated package, which fixes 
> this bug. 
>     Before applying this update, make sure all previously 
> released errata 
> relevant to your system have been applied. 
>
> This update is available via the Red Hat Network. Details on how to 
> use the Red Hat Network to apply this update are available at 
> https://access.redhat.com/articles/11258 
>     An updated virt-who package that fixes one bug is now 
> available for Red Hat 
> Enterprise Linux 7. 
>     2 
>      
>      
>      href="https://rhn.redhat.com/errata/RHBA-2014-1850.html; type="self" 
> id="RHBA-2014:1850" title="RHBA-2014:1850" /> 
>      href="https://bugzilla.redhat.com/show_bug.cgi?id=1158441; type="bugzilla" 
> id="RHBA-2014:1850" title="virt-who can't work in the VDSM mode" /> 
>      href="http://www.redhat.com/security/updates/classification/#normal; 
> type="other" id="classification" title="normal" /> 
>      
>      
>      
>     rhel-7-server-rpms__7Server__x86_64 
>      name="virt-who" epoch="0" version="0.8" release="15.el7_0" arch="noarch" > 
>         virt-who-0.8-15.el7_0.noarch.rpm 
>      >7d540e0323ccf847dbe8cb84c688a12378fe9f690e0d4b699756dbaa09484886 
>      
>      
>      
>      
>
>
> Morten A. Middelthon 
> Last Friday 
> System Administration and Development 
> +47 907 83 708 
> m...@lastfriday.com 
>
>
>
>
> > On 08 Sep 2016, at 12:45, Robert Paschedag <robert.pasche...@web.de> wrote: 
> > 
> > Is the other server also a SW server? 
> > 
> > Looks like a problem within the XML and the definition for that patch. 
> > 
> > Look into the repomd.xml, look for the file referenced with "updateinfo" 
> > and extract that file and search for the definition for that specific patch 
> > 
> > Regards 
> > Robert 
> > Am 08.09.2016 11:59 vorm. schrieb Morten Middelthon <m...@lastfriday.com>: 
> >> 
> >> Hi, 
> >> 
> >> I’m running an older version of Spacewalk (v2.2), because of RHEL5, which 
> >> a few weeks ago stopped syncing errata for RHEL 6 and RHEL 7 software 
> >> channels. When running reposync on the Spacewalk server I get the 
> >> following error: 
> >> 
> >> /usr/bin/spacewalk-repo-sync -t yum -c lyse-rhel7-x86_64 
> >> 
> >>  Channel label: lyse-rhel7-x86_64  
> >> Repo URL: http://prdrhelsync.lyse.no/mrepo/rhel-7-server-rpms/ 
> >> Packages in repo:  4662 
> >> No new packages to sync. 
> >> Repo http://prdrhelsyn

Re: [Spacewalk-list] Errata not synced anymore

[Robert Paschedag]

Is the other server also a SW server?

Looks like a problem within the XML and the definition for that patch.

Look into the repomd.xml, look for the file referenced with "updateinfo" and 
extract that file and search for the definition for that specific patch

Regards
Robert
Am 08.09.2016 11:59 vorm. schrieb Morten Middelthon :
>
> Hi,
>
> I’m running an older version of Spacewalk (v2.2), because of RHEL5, which a 
> few weeks ago stopped syncing errata for RHEL 6 and RHEL 7 software channels. 
> When running reposync on the Spacewalk server I get the following error:
>
> /usr/bin/spacewalk-repo-sync -t yum -c lyse-rhel7-x86_64
>
>  Channel label: lyse-rhel7-x86_64 
> Repo URL: http://prdrhelsync.lyse.no/mrepo/rhel-7-server-rpms/
> Packages in repo:  4662
> No new packages to sync.
> Repo http://prdrhelsync.lyse.no/mrepo/rhel-7-server-rpms/ has comps file 
> 4219364520953b7f57714c2f39ad9323f4c10ecfe7a34f2b711c650010b2d825-comps.xml.gz.
> Repo http://prdrhelsync.lyse.no/mrepo/rhel-7-server-rpms/ has 1269 errata.
> 5 errata skipped because of empty package list.
> ERROR: invalid literal for int(): RHBA-2014:1850
> Sync completed.
> Total time: 0:06:20
>
> In this case prdrhelsync.lyse.no is another host running RHEL7 with reposync 
> and createrepo_c to sync RPMs and errata from Red Hat. I get no error 
> messages when running reposync or createrepo_c
>
> Morten A. Middelthon
> Last Friday
> System Administration and Development
> +47 907 83 708
> m...@lastfriday.com
>
>
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

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

Re: [Spacewalk-list] No errata for CentOS 7?

[Robert Paschedag]

There are errata available. I also tested download of centos 7 and I have a lot 
of errata in there. Most of them within the EPEL repo.

Regards
Robert
Am 29.08.2016 19:32 schrieb Daryl Rose :
>
> I am testing CentOS 7.  I just added a channel and repositories, both the 
> primary repo and the update repo.   I added a test server to the channel and 
> I'll I see is 739 Packages that need to be updated.  There is no Errata 
> available.  RHEL and SLES both have errata in the update repository.  I 
> assumed that CentOS would as well.
>
>
> Thanks.
>
>
> Daryl

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

Re: [Spacewalk-list] Ongoing jabberd/osad issues.

[Robert Paschedag]

Did you ever look into /var/log/messages ?

Am 19.08.2016 14:34 schrieb Daryl Rose <darylr...@outlook.com>:
>
> Basically you're doing everything that I've been doing with the exception of 
> the db_recover command.  I was not familiar with that command.
>
>
> How can I tell if the clients are self registering or not?
>
>
> Thank you.
>
>
> Daryl
>
>
>
> ____
> From: Robert Paschedag <robert.pasche...@web.de>
> Sent: Friday, August 19, 2016 3:42 AM
> To: Daryl Rose
> Cc: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] Ongoing jabberd/osad issues.
>  
> Now I had also a problem with the database. Just wanted to check, which
> logfiles of the jabber db are not needed anymore as stated in
> http://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/transapp/logfile.html
> Berkeley DB Reference Guide: Log file removal
> web.stanford.edu
> Log file removal. The fourth component of the infrastructure, log file 
> removal, concerns the ongoing disk consumption of the database log files.
>
>
>
> Just running "db_archive" killed my jabber db. Andfixing it with
>
> db_recover -v or
> db_recover -c
>
> within /var/lib/jabber/db
>
> did not work.
>
> So I was also in the situation to "clean" the database.
>
> 1. Stop jabberd (/etc/init.d/jabberd stop)
> 2. Stop osa-dispatcher (/etc/init.d/osa-dispatcher stop)
> 3. Remove contents of /var/lib/jabber/db (rm -f /var/lib/jabber/db/*)
> 4. Start jabber (/etc/init.d/jabberd start)
> 5. Start osa-dispatcher (/etc/init.d/osa-dispatcher start)
>
> I thought, I should restart the osad client everywherebut nothe
> clients are just re-registering themeselves automatically. Of course, I
> have to check this on every client but what I have checked so far is
> looking good.
>
> Regards
> Robert
>
>
> Am 18.08.2016 um 09:30 schrieb Robert Paschedag:
> > Hi Daryl,
> > 
> > as long as there are no error messages within the logs that there seems to 
> > be an error with the jabber db, I wouldn't do anything with the db.
> > 
> > As I earlier wrote, I only had to repair the db once within about 3 1/2 
> > years.
> > 
> > So, what I would do now is to really delete the jabber db (back it up... 
> > just in case) to start up with a"clean " install. If the clients (that 
> > already have authentication information) do not re-register automatically, 
> > you should go to the client, stop osad, remove 
> > /etc/sysconfig/rhn/osad-auth.conf and start osad again. The client should 
> > then register and you should see the status on the web GUI as "online". If 
> > not, check the /var/log/rhn/osad.log on the client  (if I remember correct 
> > right now) and osa-dispatcher logs in the server.
> > 
> > I also wrote, that my spacewalk servers are NOT clients of themselves. I 
> > don't think, that should be a problem but just for " testing " you should 
> > deactivate osad "client" on the spacewalk server.
> > 
> > Start with one test server.
> > 
> > Good luck.
> > 
> > Regards
> > Robert
> > Am 17.08.2016 20:43 schrieb Daryl Rose <darylr...@outlook.com>:
> >>
> >> I've posted here issues that I've had with jabberd and osad, as have 
> >> others.  But I haven't gotten things resolved, so I am posting additional 
> >> information.
> >>
> >>
> >> I put SW into production about a year ago.  After a period of time, I 
> >> noticed issues with the WUI and servers not reporting correctly and other 
> >> issues.  Google searches show that I need to shutdown spacewalk and remove 
> >> all the contents in /var/lib/jabberd/db.   This seemed to work, but after 
> >> a few months, I realized that osad was no longer communicating with 
> >> osa-dispatcher.   
> >>
> >>
> >> I started doing some additional research and learned that was not a good 
> >> way to resolve this issue.  According to the official Spacewalk 
> >> documentation, I should create a checkpoint and then clean up log files 
> >> keeping the database and auth database files.   
> >>
> >>
> >> https://fedorahosted.org/spacewalk/wiki/JabberDatabase
> >>
> >> JabberDatabase – spacewalk - Fedora Hosted
> >> fedorahosted.org
> >> Jabber Database. Spacewalk utilizes Jabber to facilitate communications 
> >> between the server and the clients for osa-dispatcher/osad. The Jabber 
> >> program uses the ...
> >> These are the steps

Re: [Spacewalk-list] Ongoing jabberd/osad issues.

[Robert Paschedag]

Now I had also a problem with the database. Just wanted to check, which
logfiles of the jabber db are not needed anymore as stated in
http://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/transapp/logfile.html

Just running "db_archive" killed my jabber db. Andfixing it with

db_recover -v or
db_recover -c

within /var/lib/jabber/db

did not work.

So I was also in the situation to "clean" the database.

1. Stop jabberd (/etc/init.d/jabberd stop)
2. Stop osa-dispatcher (/etc/init.d/osa-dispatcher stop)
3. Remove contents of /var/lib/jabber/db (rm -f /var/lib/jabber/db/*)
4. Start jabber (/etc/init.d/jabberd start)
5. Start osa-dispatcher (/etc/init.d/osa-dispatcher start)

I thought, I should restart the osad client everywherebut nothe
clients are just re-registering themeselves automatically. Of course, I
have to check this on every client but what I have checked so far is
looking good.

Regards
Robert


Am 18.08.2016 um 09:30 schrieb Robert Paschedag:
> Hi Daryl,
> 
> as long as there are no error messages within the logs that there seems to be 
> an error with the jabber db, I wouldn't do anything with the db.
> 
> As I earlier wrote, I only had to repair the db once within about 3 1/2 years.
> 
> So, what I would do now is to really delete the jabber db (back it up... just 
> in case) to start up with a"clean " install. If the clients (that already 
> have authentication information) do not re-register automatically, you should 
> go to the client, stop osad, remove /etc/sysconfig/rhn/osad-auth.conf and 
> start osad again. The client should then register and you should see the 
> status on the web GUI as "online". If not, check the /var/log/rhn/osad.log on 
> the client  (if I remember correct right now) and osa-dispatcher logs in the 
> server.
> 
> I also wrote, that my spacewalk servers are NOT clients of themselves. I 
> don't think, that should be a problem but just for " testing " you should 
> deactivate osad "client" on the spacewalk server.
> 
> Start with one test server.
> 
> Good luck.
> 
> Regards
> Robert
> Am 17.08.2016 20:43 schrieb Daryl Rose <darylr...@outlook.com>:
>>
>> I've posted here issues that I've had with jabberd and osad, as have others. 
>>  But I haven't gotten things resolved, so I am posting additional 
>> information.
>>
>>
>> I put SW into production about a year ago.  After a period of time, I 
>> noticed issues with the WUI and servers not reporting correctly and other 
>> issues.  Google searches show that I need to shutdown spacewalk and remove 
>> all the contents in /var/lib/jabberd/db.   This seemed to work, but after a 
>> few months, I realized that osad was no longer communicating with 
>> osa-dispatcher.   
>>
>>
>> I started doing some additional research and learned that was not a good way 
>> to resolve this issue.  According to the official Spacewalk documentation, I 
>> should create a checkpoint and then clean up log files keeping the database 
>> and auth database files.   
>>
>>
>> https://fedorahosted.org/spacewalk/wiki/JabberDatabase
>>
>> JabberDatabase – spacewalk - Fedora Hosted
>> fedorahosted.org
>> Jabber Database. Spacewalk utilizes Jabber to facilitate communications 
>> between the server and the clients for osa-dispatcher/osad. The Jabber 
>> program uses the ...
>> These are the steps that I followed:
>>
>>
>> /usr/bin/db_checkpoint -1 -h /var/lib/jabberd/db/ ## mark logs for deletion
>> /usr/bin/db_archive -d -h /var/lib/jabberd/db/  ## delete logs
>> service jabberd restart
>>
>> However, this also causes problems with jabberd and osad.  If I use the 
>> commands as the documentation instructs, then osa-dispatcher will start, but 
>> die, and I get errors in the log that there is an invalid password. 
>>
>>
>> So to help explain my issue, I ran a test and tried to capture everything 
>> that I could and I'll post it here.
>>
>>
>> 1. Listing of /var/lib/jabberd/db
>>
>> [root@ db]# ls 
>> __db.001  __db.006log.04  log.09  log.14  
>> log.19  log.24  sm.db
>> __db.002  authreg.db  log.05  log.10  log.15  
>> log.20  log.25
>> __db.003  log.01  log.06  log.11  log.16  
>> log.21  log.26
>> __db.004  log.02  log.07  log.12  log.17  
>> log.22  log.27
>> __db.005  log.03  log.08  log.13  log.18  
>> log.23  log.0

Re: [Spacewalk-list] Ongoing jabberd/osad issues.

[Robert Paschedag]

Hi Daryl,

as long as there are no error messages within the logs that there seems to be 
an error with the jabber db, I wouldn't do anything with the db.

As I earlier wrote, I only had to repair the db once within about 3 1/2 years.

So, what I would do now is to really delete the jabber db (back it up... just 
in case) to start up with a"clean " install. If the clients (that already have 
authentication information) do not re-register automatically, you should go to 
the client, stop osad, remove /etc/sysconfig/rhn/osad-auth.conf and start osad 
again. The client should then register and you should see the status on the web 
GUI as "online". If not, check the /var/log/rhn/osad.log on the client  (if I 
remember correct right now) and osa-dispatcher logs in the server.

I also wrote, that my spacewalk servers are NOT clients of themselves. I don't 
think, that should be a problem but just for " testing " you should deactivate 
osad "client" on the spacewalk server.

Start with one test server.

Good luck.

Regards
Robert
Am 17.08.2016 20:43 schrieb Daryl Rose :
>
> I've posted here issues that I've had with jabberd and osad, as have others.  
> But I haven't gotten things resolved, so I am posting additional information.
>
>
> I put SW into production about a year ago.  After a period of time, I noticed 
> issues with the WUI and servers not reporting correctly and other issues.  
> Google searches show that I need to shutdown spacewalk and remove all the 
> contents in /var/lib/jabberd/db.   This seemed to work, but after a few 
> months, I realized that osad was no longer communicating with osa-dispatcher. 
>   
>
>
> I started doing some additional research and learned that was not a good way 
> to resolve this issue.  According to the official Spacewalk documentation, I 
> should create a checkpoint and then clean up log files keeping the database 
> and auth database files.   
>
>
> https://fedorahosted.org/spacewalk/wiki/JabberDatabase
>
> JabberDatabase – spacewalk - Fedora Hosted
> fedorahosted.org
> Jabber Database. Spacewalk utilizes Jabber to facilitate communications 
> between the server and the clients for osa-dispatcher/osad. The Jabber 
> program uses the ...
> These are the steps that I followed:
>
>
> /usr/bin/db_checkpoint -1 -h /var/lib/jabberd/db/ ## mark logs for deletion
> /usr/bin/db_archive -d -h /var/lib/jabberd/db/  ## delete logs
> service jabberd restart
>
> However, this also causes problems with jabberd and osad.  If I use the 
> commands as the documentation instructs, then osa-dispatcher will start, but 
> die, and I get errors in the log that there is an invalid password. 
>
>
> So to help explain my issue, I ran a test and tried to capture everything 
> that I could and I'll post it here.
>
>
> 1. Listing of /var/lib/jabberd/db
>
> [root@ db]# ls 
> __db.001  __db.006        log.04  log.09  log.14  
> log.19  log.24  sm.db
> __db.002  authreg.db      log.05  log.10  log.15  
> log.20  log.25
> __db.003  log.01  log.06  log.11  log.16  
> log.21  log.26
> __db.004  log.02  log.07  log.12  log.17  
> log.22  log.27
> __db.005  log.03  log.08  log.13  log.18  
> log.23  log.28
>
> 2. Spacewalk Server Status
>
> [root@ db]# spacewalk-service status
> postmaster (pid  1175) is running...
> router (pid 21431) is running...
> sm (pid 21441) is running...
> c2s (pid 21451) is running...
> s2s (pid 21461) is running...
> tomcat6 (pid 1304) is running...                           [  OK  ]
> httpd (pid  1385) is running...
> osa-dispatcher (pid  21479) is running...
> rhn-search is running (1441).
> cobblerd (pid 1491) is running...
> RHN Taskomatic is running (1515).
>
> 3.  Most recent log file entry:
>
> 2016/08/17 07:44:13 -05:00 21476 0.0.0.0: osad/jabber_lib.__init__
> 2016/08/17 07:44:13 -05:00 21476 0.0.0.0: 
> osad/jabber_lib.setup_connection('Connected to jabber server', 
> '.com')
> 2016/08/17 07:44:13 -05:00 21476 0.0.0.0: 
> osad/osa_dispatcher.fix_connection('Upstream notification server started on 
> port', 1290)
> 2016/08/17 07:44:14 -05:00 21476 0.0.0.0: osad/jabber_lib.process_forever
>
> 4.  Ran the commands as instructed in the jabberd documentation.
>
> /usr/bin/db_checkpoint -1 -h /var/lib/jabberd/db/ ## mark logs for deletion
> /usr/bin/db_archive -d -h /var/lib/jabberd/db/  ## delete logs
> service jabberd restart
>
> 5.  Log file entry:
>
> 2016/08/17 13:28:19 -05:00 21476 0.0.0.0: osad/jabber_lib.main('ERROR', 
> 'Traceback (most recent call last):\n  File 
> "/usr/share/rhn/osad/jabber_lib.py", line 121, in main\n    
> self.process_forever(c)\n  File "/usr/share/rhn/osad/jabber_lib.py", line 
> 179, in process_forever\n    self.process_once(client)\n  File 
> "/usr/share/rhn/osad/osa_dispatcher.py", line 187, 

Re: [Spacewalk-list] 2.5: rhn_regks fails on proxy target

[Robert Paschedag]

Looks like a lookup problem. "Name or service not known"

Regards
Robert
Am 17.08.2016 08:01 schrieb "Ernst, Patrick" :
>
> Hi all,
>
>  
>
> I've set up a spacewalk proxy (2.5) that's successfully registered as client 
> and proxy to the master spacewalk server (2.5).
>
> When I try to register a new client to the proxy rhn_regks fails with 
> "Internal Server Error". I’ve double checked the firewall rules according to 
> the documentation and the proxy can initiate at 5269 to the master and the 
> master can initiate at 443, 4545, 5222 and 5269 to the proxy.  
>
>  
>
> The related debug output from the httpd error log follows:
>
>  
>
> [Wed Aug 17 07:46:00.913924 2016] [:error] [pid 687] Spacewalk 687 2016/08/17 
> 07:46:00 +02:00: ('Socket error', gaierror(-2, 'Name or service not known'))
>
> [Wed Aug 17 07:46:00.914645 2016] [:error] [pid 687] Exception reported from 
> hmb1s01256.business.jungheinrich.com
>
> [Wed Aug 17 07:46:00.914665 2016] [:error] [pid 687] Time: Wed Aug 17 
> 07:46:00 2016
>
> [Wed Aug 17 07:46:00.914668 2016] [:error] [pid 687] Exception type  'socket.gaierror'>
>
> [Wed Aug 17 07:46:00.914670 2016] [:error] [pid 687]
>
> [Wed Aug 17 07:46:00.914672 2016] [:error] [pid 687] Exception Handler 
> Information
>
> [Wed Aug 17 07:46:00.914674 2016] [:error] [pid 687] Traceback (most recent 
> call last):
>
> [Wed Aug 17 07:46:00.914677 2016] [:error] [pid 687]   File 
> "/usr/share/rhn/proxy/rhnProxyAuth.py", line 248, in login
>
> [Wed Aug 17 07:46:00.914690 2016] [:error] [pid 687] token = 
> server.proxy.login(self.__systemid)
>
> [Wed Aug 17 07:46:00.914696 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/rpclib.py", line 662, in __call__
>
> [Wed Aug 17 07:46:00.914759 2016] [:error] [pid 687] return 
> self._send(self._name, args)
>
> [Wed Aug 17 07:46:00.914762 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/rpclib.py", line 394, in _request
>
> [Wed Aug 17 07:46:00.914764 2016] [:error] [pid 687] self._handler, 
> request, verbose=self._verbose)
>
> [Wed Aug 17 07:46:00.914766 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/transports.py", line 177, in request
>
> [Wed Aug 17 07:46:00.914768 2016] [:error] [pid 687] headers, fd = 
> req.send_http(host, handler)
>
> [Wed Aug 17 07:46:00.914769 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/transports.py", line 730, in send_http
>
> [Wed Aug 17 07:46:00.914771 2016] [:error] [pid 687] 
> self._connection.connect()
>
> [Wed Aug 17 07:46:00.914773 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/connections.py", line 174, in connect
>
> [Wed Aug 17 07:46:00.914775 2016] [:error] [pid 687] socket.AF_UNSPEC, 
> socket.SOCK_STREAM)
>
> [Wed Aug 17 07:46:00.914776 2016] [:error] [pid 687] gaierror: [Errno -2] 
> Name or service not known
>
> [Wed Aug 17 07:46:00.914780 2016] [:error] [pid 687]
>
> [Wed Aug 17 07:46:00.914929 2016] [:error] [pid 687] Exception reported from 
> SpacewalkProxyServer
>
> [Wed Aug 17 07:46:00.914950 2016] [:error] [pid 687] Time: Wed Aug 17 
> 07:46:00 2016
>
> [Wed Aug 17 07:46:00.914960 2016] [:error] [pid 687] Exception type  'socket.gaierror'>
>
> [Wed Aug 17 07:46:00.914984 2016] [:error] [pid 687]
>
> [Wed Aug 17 07:46:00.914987 2016] [:error] [pid 687] Exception Handler 
> Information
>
> [Wed Aug 17 07:46:00.914989 2016] [:error] [pid 687] Traceback (most recent 
> call last):
>
> [Wed Aug 17 07:46:00.914991 2016] [:error] [pid 687]   File 
> "/usr/share/rhn/proxy/rhnProxyAuth.py", line 248, in login
>
> [Wed Aug 17 07:46:00.914993 2016] [:error] [pid 687]     token = 
> server.proxy.login(self.__systemid)
>
> [Wed Aug 17 07:46:00.915008 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/rpclib.py", line 662, in __call__
>
> [Wed Aug 17 07:46:00.915030 2016] [:error] [pid 687] return 
> self._send(self._name, args)
>
> [Wed Aug 17 07:46:00.915062 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/rpclib.py", line 394, in _request
>
> [Wed Aug 17 07:46:00.915073 2016] [:error] [pid 687] self._handler, 
> request, verbose=self._verbose)
>
> [Wed Aug 17 07:46:00.915081 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/transports.py", line 177, in request
>
> [Wed Aug 17 07:46:00.915110 2016] [:error] [pid 687] headers, fd = 
> req.send_http(host, handler)
>
> [Wed Aug 17 07:46:00.915113 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/transports.py", line 730, in send_http
>
> [Wed Aug 17 07:46:00.915122 2016] [:error] [pid 687] 
> self._connection.connect()
>
> [Wed Aug 17 07:46:00.915140 2016] [:error] [pid 687]   File 
> "/usr/lib/python2.7/site-packages/rhn/connections.py", line 174, in connect
>
> [Wed Aug 17 07:46:00.915171 2016] [:error] [pid 687] socket.AF_UNSPEC, 
> socket.SOCK_STREAM)
>
> [Wed Aug 17 

Re: [Spacewalk-list] channels for SuSE - in spacewalk

[Robert Paschedag]

You get SLES 11 updates from Novell. SLES12 from SuSE.

Regards
Robert
Am 08.08.2016 17:58 schrieb Bernd Helber <be...@helber-it-services.com>:
>
> Dear Jinesh, 
>
> there are no URLS, like we had it in the Past. 
> You have to register a System at 
>
> SuSE Customer Center, select all Repo's you're in need of. 
>
> SuSE Customer Center will generate URLS you have to use. 
>
>
> At example 
>
> spacecmd {SSM:0}> repo_details sles12-sdk 
> Repository Label:   sles12-sdk 
> Repository URL: 
> https://updates.suse.com/SUSE/Products/SLE-SDK/12/x86_64/productveryyylngtookenwithweirdsigns
>  
> Repository Type:    yum 
>
>
> Then create your Software Channels. 
> Create your Repos and attach the Repos to the Software Channel. 
>
>
> Kind regards. 
>
> Am 08.08.16 um 16:11 schrieb Daryl Rose: 
> > Jineesh, 
> > 
> > 
> > This is correct. You have to have properly licensed servers to be able 
> > to access the repositories. 
> > 
> > 
> > The reason why I am using SW is because I have both RHEL and SLES 
> > servers in my environment.  I evaluated purchasing Red Hat Satellite 
> > server and SuSE Package Management Server.  However, I cannot afford 
> > purchasing both products and licenses all of my systems, so I opted for 
> > Spacewalk.  Spacewalk is the upstream development for both platforms and 
> > I can have a single pain of glass for both environments.  
> > 
> > 
> > I could make either RH Satellite or SuSE Management Server work for 
> > both, but I would have to setup a PULP server to proxy the packages from 
> > one environment to the other.  I tested that scenario, and it was a 
> > major pain.  Going the SW direction seems to be the best option.  I 
> > registered my SW server with Red Hat, and then a couple of servers with 
> > SuSE, who's sole purpose is to access the repositories.   I now am able 
> > to manage both RHEL and SLES environments from a single SW server.  Very 
> > easy and works great.  But again, you need to license and register 
> > servers with SuSE to access the repositories. 
> > 
> > 
> > Daryl 
> > 
> > 
> > 
> > 
> >  
> > *From:* spacewalk-list-boun...@redhat.com 
> > <spacewalk-list-boun...@redhat.com> on behalf of Robert Paschedag 
> > <robert.pasche...@web.de> 
> > *Sent:* Sunday, August 7, 2016 11:34 PM 
> > *To:* jineesh.kot...@accenture.com 
> > *Cc:* spacewalk-list@redhat.com 
> > *Subject:* Re: [Spacewalk-list] channels for SuSE - in spacewalk 
> >  
> > You can find the URL links within your Novell account settings. 
> > 
> > Put your credentials directly into the URL 
> > 
> > Regards 
> > Robert 
> > Am 05.08.2016 15:41 schrieb jineesh.kot...@accenture.com: 
> >> 
> >> Hi Daryl, 
> >> 
> >>  
> >> 
> >> Thanks for the details. 
> >> 
> >>  
> >> 
> >> Could you please let us know what is the repository URL for SUSE11  SP3 
> >> and where you put the credentials in URL link. 
> >> 
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 
> >> Thanks & Regards, 
> >> 
> >> Jineesh K 
> >> 
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 
> >> From: spacewalk-list-boun...@redhat.com 
> >> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Daryl Rose 
> >> Sent: Thursday, August 04, 2016 1:18 AM 
> >> To: spacewalk-list@redhat.com 
> >> Subject: Re: [Spacewalk-list] channels for SuSE - in spacewalk 
> >> 
> >>  
> >> 
> >> Jineesh, 
> >> 
> >>  
> >> 
> >> In order to get SLES repositories setup in Spacewalk, you need to first 
> >> register one server per service pack with SuSE.  For example, I have 
> >> servers that are on both SLES 11 SP3 and SLES 11 SP4.  I built two servers 
> >> specifically just to register to SuSE.  One was registered to the SLES 11 
> >> SP3 SuSE repository and the other 
> > was registered to the SLES 11 SP4 
> >> 
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 
> >> After I built those server and registered them with SuSE, I opened yast 
> >> and copied the Repository URL.  I used that string, along with 

Re: [Spacewalk-list] channels for SuSE - in spacewalk

[Robert Paschedag]

Strip the /rpm/x86_64 from the URL. Should run then.

Regards
Robert
Am 08.08.2016 19:01 schrieb jineesh.kot...@accenture.com:
>
> Hi Daryl,
>
>  
>
> I have created the channel with the URL retrieved from the yast with username 
> and password. The syncing is failing with below message in logs,
>
>  
>
> Sync started: Mon Aug  8 17:44:44 2016
>
> ['/usr/bin/spacewalk-repo-sync', '--channel', 'suse11sp3channel', '--type', 
> 'yum']
>
> Repo URL: 
> https://username:passw...@nu.novell.com/repo/$RCE/SLES11-SP3-Updates/sle-11-x86_64/rpm/x86_64/
>
> ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: 
> suse11sp3channel. Please verify its path and try again
>
> Sync completed.
>
> Total time: 0:01:00
>
>  
>
>  
>
> But we could see the its getting connected with wget command,
>
>  
>
> wget https:// username:password 
> @nu.novell.com/repo/$RCE/SLES11-SP3-Updates/sle-11-x86_64/rpm/x86_64/ConsoleKit-0.2.10-64.2_64.69.1.x86_64.drpm
>
> --2016-08-08 17:48:12--  
> https://938a729642a8403eb436797eb9027703:*password*@nu.novell.com/repo//SLES11-SP3-Updates/sle-11-x86_64/rpm/x86_64/ConsoleKit-0.2.10-64.2_64.69.1.x86_64.drpm
>
> Resolving nu.novell.com... 68.232.34.212
>
> Connecting to nu.novell.com|68.232.34.212|:443... connected.
>
>  
>
>  
>
> Thanks & Regards,
>
> Jineesh K
>
>  
>
>  
>
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Daryl Rose
> Sent: Monday, August 08, 2016 9:25 PM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] channels for SuSE - in spacewalk
>
>  
>
> The URL will be found in the "Configured Software Repositories" in YAST.  
> Open up YAST find "Software Repositories" under the "Software" section.  (I 
> personally uses yast2, and pull the GUI back to my desktop using X windows.)
>
>  
>
> In YAST you'll see the URL string(s) for the various repositories.  Click the 
> "Edit" button for the specific URL that you want. From the edit screen you 
> need:
>
> Server Name
> Directory on Server
>
> To construct the Repository URL within SW you need the credentials from the 
> registered server, which can be found in 
> /etc/zypp/credentials.d/NCCcredentials.  
>
>  
>
> Example of the URL:
>
>  
>
> https://:@<Server Name>/
>
>  
>
> Copy/paste all information that you collected into the Repository URL of the 
> SLES Channel, and then run the sync. 
>
>  
>
> Hopefully this answered your question.
>
>  
>
> Daryl
>
>  
>
>  
>
> 
>
> From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> 
> on behalf of jineesh.kot...@accenture.com <jineesh.kot...@accenture.com>
> Sent: Monday, August 8, 2016 9:16 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] channels for SuSE - in spacewalk
>
>  
>
> Hi Daryl,
>
>  
>
> Thanks for the details.
>
>  
>
> We have the License for SuSE servers. What I am requesting here is, what is 
> the URL and where I have to put the credentials while creating the channels 
> for SuSE in SW.
>
>  
>
>  
>
> Thanks & Regards,
>
> Jineesh K
>
>  
>
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Daryl Rose
> Sent: Monday, August 08, 2016 7:42 PM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] channels for SuSE - in spacewalk
>
>  
>
> Jineesh,
>
>  
>
> This is correct. You have to have properly licensed servers to be able to 
> access the repositories.
>
>  
>
> The reason why I am using SW is because I have both RHEL and SLES servers in 
> my environment.  I evaluated purchasing Red Hat Satellite server and SuSE 
> Package Management Server.  However, I cannot afford purchasing both products 
> and licenses all of my systems, so I opted for Spacewalk.  Spacewalk is the 
> upstream development for both platforms and I can have a single pain of glass 
> for both environments.  
>
>  
>
> I could make either RH Satellite or SuSE Management Server work for both, but 
> I would have to setup a PULP server to proxy the packages from one 
> environment to the other.  I tested that scenario, and it was a major pain.  
> Going the SW direction seems to be the best option.  I registered my SW 
> server with Red Hat, and then a couple of servers with SuSE, who's sole 
> purpose is to access the repositories.   I now am able to manage both RHEL 
> and SLES environments from a single SW se

Re: [Spacewalk-list] channels for SuSE - in spacewalk

[Robert Paschedag]

You can find the URL links within your Novell account settings.

Put your credentials directly into the URL

Regards
Robert
Am 05.08.2016 15:41 schrieb jineesh.kot...@accenture.com:
>
> Hi Daryl,
>
>  
>
> Thanks for the details.
>
>  
>
> Could you please let us know what is the repository URL for SUSE11  SP3 and 
> where you put the credentials in URL link.
>
>  
>
>  
>
>  
>
>  
>
> Thanks & Regards,
>
> Jineesh K
>
>  
>
>  
>
>  
>
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Daryl Rose
> Sent: Thursday, August 04, 2016 1:18 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] channels for SuSE - in spacewalk
>
>  
>
> Jineesh,
>
>  
>
> In order to get SLES repositories setup in Spacewalk, you need to first 
> register one server per service pack with SuSE.  For example, I have servers 
> that are on both SLES 11 SP3 and SLES 11 SP4.  I built two servers 
> specifically just to register to SuSE.  One was registered to the SLES 11 SP3 
> SuSE repository and the other was registered to the SLES 11 SP4
>
>  
>
>  
>
>  
>
>  
>
>  
>
> After I built those server and registered them with SuSE, I opened yast and 
> copied the Repository URL.  I used that string, along with the registered 
> credentials in the "Repository URL" of the Repository Details page in 
> Spacewalk.   The credentials can be found in 
> /etc/zypp/credentials.d/NCCcredentials of the server that you would register 
> with SuSE.
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> From: spacewalk-list-boun...@redhat.com  
> on behalf of jineesh.kot...@accenture.com 
> Sent: Wednesday, August 3, 2016 2:17 PM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] channels for SuSE - in spacewalk
>
>  
>
> Hi Daryl,
>
>  
>
> It would be helpful, if you could share the details.
>
>  
>
>  
>
> Thanks & Regards,
>
> Jineesh K
>
>  
>
>  
>
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Daryl Rose
> Sent: Tuesday, August 02, 2016 7:36 PM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] channels for SuSE - in spacewalk
>
>  
>
> Jineesh,
>
>  
>
> I was wondering if you were able to get SLES 11 channel setup?  I 
> successfully setup SLES 11 and am in the process of moving all of my servers 
> from SCC to my Spacewalk environment.
>
>  
>
> If you need further assistance, please let me know.
>
>  
>
> Daryl
>
>  
>
> 
>
> From: spacewalk-list-boun...@redhat.com  
> on behalf of jineesh.kot...@accenture.com 
> Sent: Thursday, June 2, 2016 8:19 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] channels for SuSE - in spacewalk
>
>  
>
> Hi,
>
>  
>
> Anybody knows the steps to create channel for Enterprise SuSE 11 boxes
>
>  
>
>  
>
> Thanks & Regards,
>
> Jineesh K
>
>  
>
>  
>
> From: Kotayi, Jineesh 
> Sent: Monday, May 30, 2016 7:47 PM
> To: 'spacewalk-list@redhat.com' 
> Subject: [Spacewalk-list] channels for SuSE - in spacewalk
>
>  
>
>  
>
> Hi,
>
>  
>
> We have installed spacewalk setup in our environment and created channels for 
> Redhat and CentOS.
>
>  
>
> We have to create channels for SuSE 11 boxes as well. Could you please help 
> us to share the documents to create the channels for SuSE as we are unable to 
> find any forum
>
>  
>
>  
>
> Thanks & Regards,
>
> Jineesh K
>
>  
>
> 
>
>
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise confidential information. If you have received it 
> in error, please notify the sender immediately and delete the original. Any 
> other use of the e-mail by you is prohibited. Where allowed by local law, 
> electronic communications with Accenture and its affiliates, including e-mail 
> and instant messaging (including content), may be scanned by our systems for 
> the purposes of information security and assessment of internal compliance 
> with Accenture policy. 
> __
>
> www.accenture.com

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

Re: [Spacewalk-list] osad/jabber - Invalid password errors

[Robert Paschedag]

 

Hi Daryl,

 

please, just to be sure. Tell, in which logfile you find the error and past the error you get. You say, that you have the problem with osa-dispatcher? This is on the server.

 

So what do you get, when you restart the spacewalk services "spacewalk-service restart"? Does the osa-dispatcher start correctly?

 

Regards,

Robert


Gesendet: Mittwoch, 03. August 2016 um 21:06 Uhr
Von: "Daryl Rose" <darylr...@outlook.com>
An: "spacewalk-list@redhat.com" <spacewalk-list@redhat.com>
Betreff: Re: [Spacewalk-list] osad/jabber - Invalid password errors




I just realized that I've been saying that I am having an issue with osad, when I should be saying that I am having an issue with osa-dispatcher.

 

It just suddenly occurred to me that osad is the process that runs on the client, while osa-dispatcher is running on the server.  This what is causing my "Invalid Password" error.

 

Thank you.

 

Daryl
 



From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> on behalf of Daryl Rose <darylr...@outlook.com>
Sent: Wednesday, August 3, 2016 1:26 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] osad/jabber - Invalid password errors

 




No, the host name has not changed.

 

Daryl
 



From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> on behalf of Konstantin Raskoshnyi <konra...@gmail.com>
Sent: Wednesday, August 3, 2016 1:00 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] osad/jabber - Invalid password errors

 



Did you change the hostname manually? Usually that's the problem.

 
On Wed, Aug 3, 2016 at 10:37 AM, Daryl Rose  <darylr...@outlook.com> wrote:




Thank you for the information.  However, I am confused by a few things.

 

The error that I am seeing is on the spacewalk server itself, not on the clients.  isn't /etc/sysconfig/rhn/osad-auth.conf only on the clients?    OSAD is failing to start on the server with the invalid password error.  Do I need to remove and recreate the osad-auth.conf file on all of the clients?

 

Thank you.

 

Daryl

 
 




From: Dimitri Yioulos <dyiou...@netatlantic.com>
Sent: Wednesday, August 3, 2016 10:54 AM
To: spacewalk-list@redhat.com; Daryl Rose
Subject: RE: [Spacewalk-list] osad/jabber - Invalid password errors

 



Robert is correct.  I've had similar issues with osad, and so created a simple Ansible playbook to delete osad-auth.conf against all of my nodes.  If you're running Ansible, here it is:

---

- hosts: all
  gather_facts: false
  become: yes

  tasks:
    - name: stop osad
  command: /sbin/service osad stop
    - name: remove osad auth file
  command: /bin/rm -f /etc/sysconfig/rhn/osad-auth.conf
    - name: start osad
  command: /sbin/service osad start

Dimitri

-Original Message-
From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Robert Paschedag
Sent: Wednesday, August 03, 2016 11:14 AM
To: Daryl Rose <darylr...@outlook.com>
Cc: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] osad/jabber - Invalid password errors

You should have configuration files for osad in /etc/sysconfig/rhn. An osad.conf and osad-auth.conf.

I think, if you remove the osad-auth.conf file and restart osad, it should re-register. I think!

Regards
Robert
Am 03.08.2016 15:38 schrieb Daryl Rose <darylr...@outlook.com>:
>
> HmmmWonder how that happened?  I didn't press send, at least not that I'm aware of.
>
>
> Anyway, before I was rudely interrupted by my email client, I was
> asking if there is a password in the jabberd database or authreg.db file that could be an issue?  Since I am no longer completely clearing out the database files, perhaps something got stuck at some point?  Would clearing out the database files rest the password?
>
>
> But again, I'm wondering what the invalid password is?  What is osad 
> logging into?
>
>
> Thank you.
>
>
> Daryl
>
>
>
>
> 
> From: spacewalk-list-boun...@redhat.com
> <spacewalk-list-boun...@redhat.com> on behalf of Daryl Rose
> <darylr...@outlook.com>
> Sent: Wednesday, August 3, 2016 8:15 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] osad/jabber - Invalid password errors
>  
>
> I have some additional information that I think that I should share.
>
>
> Because of specific issues experienced with SW, I used to completely remove jabberd database and log files.  I used to stop SW, cd to /var/lib/jabberd/db and remove the entire contents then restart SW.  But, I started experience problems with OSAD not picking up packages, and after so research, I learned that the way that I used to do things was not a good idea.
>
>
> I think that it was a posting here that told me by removing at database files and

Re: [Spacewalk-list] osad/jabber - Invalid password errors

[Robert Paschedag]

You should have configuration files for osad in /etc/sysconfig/rhn. An 
osad.conf and osad-auth.conf.

I think, if you remove the osad-auth.conf file and restart osad, it should 
re-register. I think!

Regards
Robert
Am 03.08.2016 15:38 schrieb Daryl Rose <darylr...@outlook.com>:
>
> HmmmWonder how that happened?  I didn't press send, at least not that I'm 
> aware of.
>
>
> Anyway, before I was rudely interrupted by my email client, I was asking if 
> there is a password in the jabberd database or authreg.db file that could be 
> an issue?  Since I am no longer completely clearing out the database files, 
> perhaps something got stuck at some point?  Would clearing out the database 
> files rest the password? 
>
>
> But again, I'm wondering what the invalid password is?  What is osad logging 
> into?  
>
>
> Thank you.
>
>
> Daryl
>
>
>
>
> 
> From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> 
> on behalf of Daryl Rose <darylr...@outlook.com>
> Sent: Wednesday, August 3, 2016 8:15 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] osad/jabber - Invalid password errors
>  
>
> I have some additional information that I think that I should share. 
>
>
> Because of specific issues experienced with SW, I used to completely remove 
> jabberd database and log files.  I used to stop SW, cd to /var/lib/jabberd/db 
> and remove the entire contents then restart SW.  But, I started experience 
> problems with OSAD not picking up packages, and after so research, I learned 
> that the way that I used to do things was not a good idea.
>
>
> I think that it was a posting here that told me by removing at database files 
> and the authreg.db it was causing the clients from losing connection with the 
> SW server.  In the SW documentation, I learned that its better to delete only 
> the logs that are not required.  These are the steps that I now use:
>
>
> /usr/bin/db_checkpoint -1 -h /var/lib/jabberd/db/ ## mark logs for deletion
> /usr/bin/db_archive -d -h /var/lib/jabberd/db/  ## delete logs
> /usr/sbin/spacewalk-service restart  ## stop/start spacewalk
>
> I have this setup in a crontab that runs on a daily schedule.  I set this up 
> about two months ago.  
>
>
> I'm not sure when the invalid password issue started.  But it was some point 
> after implementing these steps that the invalid password issue started.  Is 
> there a password
>
>
>  
>
>
>
> 
> From: Robert Paschedag <robert.pasche...@web.de>
> Sent: Tuesday, August 2, 2016 11:47 PM
> To: Daryl Rose
> Cc: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] osad/jabber - Invalid password errors
>  
> Hi Daryl,
>
> the password fire jabber is stored in /etc/sysconfig/rhn/osad.auth, if I 
> remember right.
>
> The other thing is not enough permissions to delete the PID file.
>
> Are you running osad as a non-root user?
>
> Regards
> Robert
> Am 02.08.2016 16:24 schrieb Daryl Rose <darylr...@outlook.com>:
> >
> > OSAD has not been working, and I finally had a moment to look into it.  The 
> > osa-dispatcher.log has the following error:
> >
> >
> > 2016/08/02 08:38:25 -05:00 25556 0.0.0.0: 
> > osad/jabber_lib.setup_connection('Connected to jabber server', 
> > '')
> > 2016/08/02 08:38:25 -05:00 25556 0.0.0.0: osad/jabber_lib.register('ERROR', 
> > 'Invalid password')
> >
> > What password would be invalid?  I am using a customized certificate, and 
> > its still valid for another two years. I can register servers just fine.  I 
> > can use rhn_check to retrieve updates, so I'm sure that the certificate is 
> > fine. 
> >
> >
> > There is another error that I see:
> >
> >
> > 2016/08/01 09:36:22 -05:00 1552 0.0.0.0: osad/jabber_lib.main('ERROR', 
> > 'Traceback (most recent call last):\n  File 
> > "/usr/share/rhn/osad/jabber_lib.py", line 119, in main\n    c = 
> > self.setup_connection(no_fork=no_fork)\n  File 
> > "/usr/share/rhn/osad/jabber_lib.py", line 283, in setup_connection\n    
> > self.push_to_background()\n  File "/usr/share/rhn/osad/jabber_lib.py", line 
> > 213, in push_to_background\n    os.unlink(pid_file)\nOSError: [Errno 13] 
> > Permission denied: \'/var/run/osa-dispatcher.pid\'\n')
> >
> > Anyone have any suggestions?
> >
> > Thank you 
> >
> > Daryl
> >
> >
> >

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

Re: [Spacewalk-list] osad/jabber - Invalid password errors

[Robert Paschedag]

Osad is logging into jabber. The client into the server. Just as rhnsd.

Am 03.08.2016 15:38 schrieb Daryl Rose <darylr...@outlook.com>:
>
> HmmmWonder how that happened?  I didn't press send, at least not that I'm 
> aware of.
>
>
> Anyway, before I was rudely interrupted by my email client, I was asking if 
> there is a password in the jabberd database or authreg.db file that could be 
> an issue?  Since I am no longer completely clearing out the database files, 
> perhaps something got stuck at some point?  Would clearing out the database 
> files rest the password? 
>
>
> But again, I'm wondering what the invalid password is?  What is osad logging 
> into?  
>
>
> Thank you.
>
>
> Daryl
>
>
>
>
> 
> From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> 
> on behalf of Daryl Rose <darylr...@outlook.com>
> Sent: Wednesday, August 3, 2016 8:15 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] osad/jabber - Invalid password errors
>  
>
> I have some additional information that I think that I should share. 
>
>
> Because of specific issues experienced with SW, I used to completely remove 
> jabberd database and log files.  I used to stop SW, cd to /var/lib/jabberd/db 
> and remove the entire contents then restart SW.  But, I started experience 
> problems with OSAD not picking up packages, and after so research, I learned 
> that the way that I used to do things was not a good idea.
>
>
> I think that it was a posting here that told me by removing at database files 
> and the authreg.db it was causing the clients from losing connection with the 
> SW server.  In the SW documentation, I learned that its better to delete only 
> the logs that are not required.  These are the steps that I now use:
>
>
> /usr/bin/db_checkpoint -1 -h /var/lib/jabberd/db/ ## mark logs for deletion
> /usr/bin/db_archive -d -h /var/lib/jabberd/db/  ## delete logs
> /usr/sbin/spacewalk-service restart  ## stop/start spacewalk
>
> I have this setup in a crontab that runs on a daily schedule.  I set this up 
> about two months ago.  
>
>
> I'm not sure when the invalid password issue started.  But it was some point 
> after implementing these steps that the invalid password issue started.  Is 
> there a password
>
>
>  
>
>
>
> 
> From: Robert Paschedag <robert.pasche...@web.de>
> Sent: Tuesday, August 2, 2016 11:47 PM
> To: Daryl Rose
> Cc: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] osad/jabber - Invalid password errors
>  
> Hi Daryl,
>
> the password fire jabber is stored in /etc/sysconfig/rhn/osad.auth, if I 
> remember right.
>
> The other thing is not enough permissions to delete the PID file.
>
> Are you running osad as a non-root user?
>
> Regards
> Robert
> Am 02.08.2016 16:24 schrieb Daryl Rose <darylr...@outlook.com>:
> >
> > OSAD has not been working, and I finally had a moment to look into it.  The 
> > osa-dispatcher.log has the following error:
> >
> >
> > 2016/08/02 08:38:25 -05:00 25556 0.0.0.0: 
> > osad/jabber_lib.setup_connection('Connected to jabber server', 
> > '')
> > 2016/08/02 08:38:25 -05:00 25556 0.0.0.0: osad/jabber_lib.register('ERROR', 
> > 'Invalid password')
> >
> > What password would be invalid?  I am using a customized certificate, and 
> > its still valid for another two years. I can register servers just fine.  I 
> > can use rhn_check to retrieve updates, so I'm sure that the certificate is 
> > fine. 
> >
> >
> > There is another error that I see:
> >
> >
> > 2016/08/01 09:36:22 -05:00 1552 0.0.0.0: osad/jabber_lib.main('ERROR', 
> > 'Traceback (most recent call last):\n  File 
> > "/usr/share/rhn/osad/jabber_lib.py", line 119, in main\n    c = 
> > self.setup_connection(no_fork=no_fork)\n  File 
> > "/usr/share/rhn/osad/jabber_lib.py", line 283, in setup_connection\n    
> > self.push_to_background()\n  File "/usr/share/rhn/osad/jabber_lib.py", line 
> > 213, in push_to_background\n    os.unlink(pid_file)\nOSError: [Errno 13] 
> > Permission denied: \'/var/run/osa-dispatcher.pid\'\n')
> >
> > Anyone have any suggestions?
> >
> > Thank you 
> >
> > Daryl
> >
> >
> >

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

Re: [Spacewalk-list] osad/jabber - Invalid password errors

[Robert Paschedag]

Hi Daryl,

the password fire jabber is stored in /etc/sysconfig/rhn/osad.auth, if I 
remember right.

The other thing is not enough permissions to delete the PID file.

Are you running osad as a non-root user?

Regards
Robert
Am 02.08.2016 16:24 schrieb Daryl Rose :
>
> OSAD has not been working, and I finally had a moment to look into it.  The 
> osa-dispatcher.log has the following error:
>
>
> 2016/08/02 08:38:25 -05:00 25556 0.0.0.0: 
> osad/jabber_lib.setup_connection('Connected to jabber server', 
> '')
> 2016/08/02 08:38:25 -05:00 25556 0.0.0.0: osad/jabber_lib.register('ERROR', 
> 'Invalid password')
>
> What password would be invalid?  I am using a customized certificate, and its 
> still valid for another two years. I can register servers just fine.  I can 
> use rhn_check to retrieve updates, so I'm sure that the certificate is fine. 
>
>
> There is another error that I see:
>
>
> 2016/08/01 09:36:22 -05:00 1552 0.0.0.0: osad/jabber_lib.main('ERROR', 
> 'Traceback (most recent call last):\n  File 
> "/usr/share/rhn/osad/jabber_lib.py", line 119, in main\n    c = 
> self.setup_connection(no_fork=no_fork)\n  File 
> "/usr/share/rhn/osad/jabber_lib.py", line 283, in setup_connection\n    
> self.push_to_background()\n  File "/usr/share/rhn/osad/jabber_lib.py", line 
> 213, in push_to_background\n    os.unlink(pid_file)\nOSError: [Errno 13] 
> Permission denied: \'/var/run/osa-dispatcher.pid\'\n')
>
> Anyone have any suggestions?
>
> Thank you 
>
> Daryl
>
>
>

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

Re: [Spacewalk-list] SpaceWalk and Ubuntu support

[Robert Paschedag]

Hey Tony,

Did you try one of the nightlies to check, if this bug has been closed?

I wasn't able to check it yet.

Regards
Robert
Am 28.07.2016 16:54 schrieb "Coffman, Anthony J" :
>
> I’m using it with a handful of 14.04 systems and it’s a little painful until 
> you figure out the requirements.  I used the excellent information from this 
> blog which covers the topic in great detail.
>
>  
>
> http://www.devops-blog.net/category/spacewalk
>
>  
>
> And this PPA with a critical patch applied.
>
> https://launchpad.net/~aaronr/+archive/ubuntu/spacewalk
>
>  
>
> There was a Spacewalk bug that was recently closed that is very important to 
> be aware of if you do decide to proceed.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1226329
>
> https://github.com/spacewalkproject/spacewalk/pull/399
>
>  
>
> Regards,
>
> --Tony
>
>  
>
>  
>
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Zeal Vora
> Sent: Thursday, July 28, 2016 3:25 AM
> To: spacewalk-list@redhat.com
> Subject: [Spacewalk-list] SpaceWalk and Ubuntu support
>
>  
>
> Hi
>
>  
>
>  
>
> We use SpaceWalk for patching the CentOS based servers and it works great.
>
>  
>
> However we have heard there are many issues with SpaceWalk as far as patching 
> Ubuntu based machines are concerned. 
>
>  
>
> Is it ideal to use SpaceWalk for patch management when we have Ubuntu 14.04  
> LTS based machines ? If anyone is using them, your suggestions will be 
> greatly appreciated. 
>
>  
>
>  
>
> Cheers!
>
> Zeal 

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

Re: [Spacewalk-list] CentOS 7 yum transaction aborted status incorrectly reported by Spacewalk 2.4

[Robert Paschedag]

Because rpm returned exit code 0 (no error), everything is OK. Also, as stated, 
the package is already installed. Nothing to argue with.

Regards
Robert
Am 18.07.2016 4:30 nachm. schrieb "Coffman, Anthony J" 
:
>
> I patched around 20 CentOS 7 systems yesterday.
>
>  
>
> Spacewalk reported all of the scheduled actions completed.
>
>  
>
> 5 of them experienced a yum aborted condition resulting in duplicate packages 
> and a little mess to cleanup.  For those 5 systems, Spacewalk recorded the 
> transaction as “Completed” (green) but in the action details recorded 
> “Requested packages already installed (code 0)”.  So I think there may be a 
> condition when yum aborts that isn’t correctly trapped and reported by 
> Spacewalk 2.4
>
>  
>
> yum history shows the transaction aborted but I don’t yet know why.  I’ve 
> been all over the systems logs but I haven’t found the reason for the 
> transaction aborted yet.
>
>  
>
> I haven’t found a common denominator between these 5 as all 20 systems are 
> very similar setups.
>
>  
>
> Has anybody else seen something similar on 7.x?
>
>  
>
> Regards,
>
> --Tony
>
>  
>
>  

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

Re: [Spacewalk-list] Spacewalk with CNAME DNS record

[Robert Paschedag]

Just change the hostname to the cname while you're configuring spacewalk. Then 
later you can just set the real hostname to what it should be.Am 26.05.2016 
11:00 schrieb Rick van der Linde :
>
> Hi,
>
>  
>
> Part of choices made on my side I would like to configure spacewalk to cname 
> spacewalk.domain.com, however the hostname differs and is something like 
> hostXXX.domain.com.
>
>  
>
> Somehow spacewalk seems to need to work with the hostname FQDN or IP, but I 
> want it to work with cname spacewalk.domain.com that points to A record 
> hostXXX.domain.com. 
>
>  
>
> Is this feasable and how?
>
>  
>
> Thanks in advance,
>
>  
>
>
> Rick

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

Re: [Spacewalk-list] Spacewalk with CNAME DNS record

[Robert Paschedag]

That's no problem. I'm also running our spacewalk servers with cname aliases.

Regards
Robert
Am 26.05.2016 11:00 schrieb Rick van der Linde :
>
> Hi,
>
>  
>
> Part of choices made on my side I would like to configure spacewalk to cname 
> spacewalk.domain.com, however the hostname differs and is something like 
> hostXXX.domain.com.
>
>  
>
> Somehow spacewalk seems to need to work with the hostname FQDN or IP, but I 
> want it to work with cname spacewalk.domain.com that points to A record 
> hostXXX.domain.com. 
>
>  
>
> Is this feasable and how?
>
>  
>
> Thanks in advance,
>
>  
>
>
> Rick

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

Re: [Spacewalk-list] Spacewalk redundancy

[Robert Paschedag]

Lose control?! OK... You're unable to run commands or install patches via 
spacewalk. That's right. You either have a good backup of your server or you 
have to re-register all clients to the new server.

RobertAm 25.05.2016 22:28 schrieb Konstantin Raskoshnyi :
>
> Hello everyone,
> As I see all systems rely on sp server in fact. 
> In case of emergency and if sp is dead you'll lose control over your boxes 
> and have to install a new instance of sp and re-register machines.
>
> Any solutions in this case?
>
> Thanks 

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

Re: [Spacewalk-list] Antwort: Re: rhnpush fails with uninformative error msg

[Robert Paschedag]

Right now, I have no more ideas :-(
Maybe you should start tcpdump for further investigation.
Regards
Robert

Am 25.05.2016 12:01 schrieb Lachlan Musicman <data...@gmail.com>:The command we are using (I'm not at work and don't have access to the servers atm, so this may not be 100% correct) isrhnpush --server localhost -u admin --channel slurm_16_05_rc2 *rpm --nosig    How would be make it https?That is the same command on both machines (the one that works, the one that doesn't).Also, I've tried --server=https://localhost--server=http://localhost--server=http://--server=https://--server=http://--server=https://Although admittedly I've not personally tried those combinations since last Friday. CheersL.--The most dangerous phrase in the language is, "We've always done it this way."- Grace Hopper
On 25 May 2016 at 19:50, Robert Paschedag <robert.paschedag@web.de> wrote:Are you trying to push to http or https?
If you are using http, maybe the problem is a redirect to https. Because you get the 302 codes.
Regards
Robert

Am 25.05.2016 10:42 schrieb Lachlan Musicman <datakid@gmail.com>:Yes and yes and yes. I've run the command at least 10 times a day on each server. They both have the same user and pw. I've passed the pw on the CLI via -p and I've typed it in. I've confirmed it's correct via the strace. L.--The most dangerous phrase in the language is, "We've always done it this way."- Grace Hopper
On 25 May 2016 at 18:37, Robert Paschedag <robert.paschedag@web.de> wrote:So the command line looks the same on both systems... both systems are configured the same way?

Stupid question, but credentials are OK?

Robert
Am 25.05.2016 08:32 schrieb Lachlan Musicman <datakid@gmail.com>:
>
> Thanks for answering Robert, I appreciate it. I think that those log msgs were me casting about wildly for *anything*. I don't think they point to the problem.
>
> The one thing that I see that stands out more than anything else, is the lines
>
>  - - [20/May/2016:13:58:00 +1000] "GET /rhn/errors/500.jsp HTTP/1.1" 302 -
>  - - [20/May/2016:13:58:00 +1000] "POST /rhn/errors/500.jsp HTTP/1.1" 302 -
>  - - [20/May/2016:13:58:00 +1000] "POST /rhn/Login.do?url_bounce=/rhn/errors/500.jsp_method=POST HTTP/1.1" 200 5967
>
> These are seen on the server that isn't accepting rhnpush, in /var/log/tomcat/localhost_access_.txt
>
> I do not see these on the working server, at all.
>
> Today I did some straces - on each server - and while it's verbose and hard to pick apart, it looks like the error is similar to the above. ie, that the two straces appear very similar until just after the password is entered, and then the server that wont import files looks like this. Note that the post returns HTTP code 302:
>
> sendto(3, "POST /APP HTTP/1.1\r\nHost: localh"..., 581, 0, NULL, 0) = 581
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "H", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "T", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "T", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "P", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "/", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "1", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, ".", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "1", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, " ", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "3", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "0", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "2", 1, 0, NULL, NULL)  = 1
>
>
>
> On the working server it looks like this. Note that it returns HTTP cod

Re: [Spacewalk-list] Antwort: Re: rhnpush fails with uninformative error msg

[Robert Paschedag]

Are you trying to push to http or https?
If you are using http, maybe the problem is a redirect to https. Because you get the 302 codes.
Regards
Robert

Am 25.05.2016 10:42 schrieb Lachlan Musicman <data...@gmail.com>:Yes and yes and yes. I've run the command at least 10 times a day on each server. They both have the same user and pw. I've passed the pw on the CLI via -p and I've typed it in. I've confirmed it's correct via the strace. L.--The most dangerous phrase in the language is, "We've always done it this way."- Grace Hopper
On 25 May 2016 at 18:37, Robert Paschedag <robert.paschedag@web.de> wrote:So the command line looks the same on both systems... both systems are configured the same way?

Stupid question, but credentials are OK?

Robert
Am 25.05.2016 08:32 schrieb Lachlan Musicman <datakid@gmail.com>:
>
> Thanks for answering Robert, I appreciate it. I think that those log msgs were me casting about wildly for *anything*. I don't think they point to the problem.
>
> The one thing that I see that stands out more than anything else, is the lines
>
>  - - [20/May/2016:13:58:00 +1000] "GET /rhn/errors/500.jsp HTTP/1.1" 302 -
>  - - [20/May/2016:13:58:00 +1000] "POST /rhn/errors/500.jsp HTTP/1.1" 302 -
>  - - [20/May/2016:13:58:00 +1000] "POST /rhn/Login.do?url_bounce=/rhn/errors/500.jsp_method=POST HTTP/1.1" 200 5967
>
> These are seen on the server that isn't accepting rhnpush, in /var/log/tomcat/localhost_access_.txt
>
> I do not see these on the working server, at all.
>
> Today I did some straces - on each server - and while it's verbose and hard to pick apart, it looks like the error is similar to the above. ie, that the two straces appear very similar until just after the password is entered, and then the server that wont import files looks like this. Note that the post returns HTTP code 302:
>
> sendto(3, "POST /APP HTTP/1.1\r\nHost: localh"..., 581, 0, NULL, 0) = 581
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "H", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "T", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "T", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "P", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "/", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "1", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, ".", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "1", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, " ", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "3", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "0", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[254525]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "2", 1, 0, NULL, NULL)  = 1
>
>
>
> On the working server it looks like this. Note that it returns HTTP code 200:
>
>
> sendto(3, "POST /APP HTTP/1.1\r\nHost: localh"..., 586, 0, NULL, 0) = 586
> poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "H", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "T", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "T", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "P", 1, 0, NULL, NULL)  = 1
> poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "/", 1, 0, NULL, NULL)  = 1

Re: [Spacewalk-list] Antwort: Re: rhnpush fails with uninformative error msg

[Robert Paschedag]

; poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, 
> revents=POLLIN}])
> recvfrom(3, " ", 1, 0, NULL, NULL)  = 1 
> poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, 
> revents=POLLIN}])
> recvfrom(3, "2", 1, 0, NULL, NULL)  = 1 
> poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, 
> revents=POLLIN}])
> recvfrom(3, "0", 1, 0, NULL, NULL)  = 1 
> poll([{fd=3<socket:[964921]>, events=POLLIN}], 1, 12) = 1 ([{fd=3, 
> revents=POLLIN}])
> recvfrom(3, "0", 1, 0, NULL, NULL)  = 1 
>
>
>
> Why is that? The configurations are as identical as possible. Idiot checked 
> for me by two others.
>
>
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this way."
>
> - Grace Hopper
>
> On 24 May 2016 at 00:25, <paschedag.netlut...@swr.de> wrote:
>>
>> The library looks the same to me, but the URL is different. 
>>
>> Regards, 
>> Robert 
>>
>> Mit freundlichen Grüßen 
>>
>> Robert Paschedag 
>> Netlution GmbH 
>> Landteilstr. 33 
>> 68163 Mannheim 
>>
>> im Auftrag des 
>> SWR 
>> Südwestrundfunk 
>> Informations- und Kommunikationssysteme 
>> 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:        Lachlan Musicman <data...@gmail.com> 
>> An:        spacewalk-list@redhat.com 
>> Datum:        23.05.2016 04:53 
>> Betreff:        Re: [Spacewalk-list] rhnpush fails with uninformative error 
>> msg 
>> Gesendet von:        spacewalk-list-boun...@redhat.com 
>> 
>>
>>
>>
>> Ignore that, I've got dispatcher working again. That wasn't the problem 
>> apparently.
>>
>> On the working server, when I successfully import via rhnpush, I see this in 
>> /var/log/httpd/access_log:
>>
>> 112.12.4.12 - - [23/May/2016:11:39:33 +1000] "POST /XMLRPC HTTP/1.1" 200 
>> 11932 "-" "rhn.rpclib.py/2.5.77-1.el7"
>>
>> When I do it on the server that doesn't work, I get this:
>>
>> 10.124.28.172 - - [23/May/2016:12:31:58 +1000] "POST /APP HTTP/1.1" 302 - 
>> "-" "rhn.rpclib.py/2.5.77-1.el7"
>>
>> So I'm getting a different HTTP codes in my apache server for this 
>> rhn.rpclib.py
>>
>> L. 
>>
>> --
>> The most dangerous phrase in the language is, "We've always done it this 
>> way."
>>
>> - Grace Hopper 
>>
>> On 23 May 2016 at 10:53, Lachlan Musicman <data...@gmail.com> wrote: 
>> Hmm. It looks like my osa-dispatcher isn't starting. Where are the 
>> osa-dispatcher config files?
>>
>> cheers 
>> L. 
>>
>> --
>> The most dangerous phrase in the language is, "We've always done it this 
>> way."
>>
>> - Grace Hopper 
>>
>> On 23 May 2016 at 10:29, Lachlan Musicman <data...@gmail.com> wrote: 
>> No one has seen this error before? No one can even give me pointers on where 
>> to start looking for a solution?
>>
>> It almost certainly seems to be a tomcat issue - that either the rhnpush 
>> isn't getting through a proxy (??! wtf) or it is an is failing on the other 
>> side of the proxy because some other reason? 
>>
>> I've check the tomcat conf on both servers - they are the same (as 
>> necessary). The rhn is set up as identically as possible, the server OS is 
>> the same revision...I don't understand. The only discernable difference is 
>> that one is a VMWare VM and one is a stand alone installation.
>>
>> Cheers
>>
>> L. 
>>
>> --
>> The most dangerous phrase in the language is, "We've always done it this 
>> way."
>>
>> - Grace Hopper 
>>
>> On 20 May 2016 at 16:32, Lachlan Musicman <data...@gmail.com> wrote: 
>> In centos 7.2, using 
>>
>> [root@vmpr-res-utils 16.05-rc2]# yum whatprovides rhnpush
>>
>> rhnpush-5.5.89-1.el7.noarch : Package uploader for the Spacewalk or Red Hat 
>> Satellite Server
>> Repo    : spacewalk
>>
>> rhnpush-5.5.89-1.el7.noarch : Package uploader for the Spacewalk or Red Hat 
>> Satellite Server
>> Repo    : @spacewalk
>>
>>
>> [root@vmpr-res-utils 16.05-rc2]# rhnpush --serve

Re: [Spacewalk-list] OSAD not picking up updates

[Robert Paschedag]

I really don't understand, why many people have problems using osad.

In our production environment (500+ server), this is working. The only problem 
I have is "load" when you want to do something on many servers. Then, 
performance is going down.

But I don't know, what's the difference in mine and your setups. I register 
server to spacewalk, enable all remote actions and install osad. Done!

You're all using SSL with osad, right? You all have enabled remote controls? 
(rhn-action-control --enable-all)

My only problem I ever had was somebody cloned a VM (already registered) and 
did not remove the osad-auth file so both systems logged into jabber server 
with the same "credentials" kicking out.

Regards
Robert
Am 13.05.2016 19:18 schrieb "Sorensen, Paul - (p)" :
>
> Is that the only piece OSAD on the client does?  I’ve also spent several 
> months trying to get OSAD working consistently, with little luck.   Seems 
> like a cron job is the better route all around – consistent, reliable, simple.
>
>  
>
> What about “rhncfg-client get” – do you not manage configuration files as 
> well? 
>
>  
>
> There is a mention of replacing OSAD here:  
> https://fedorahosted.org/spacewalk/wiki/BrainBox
>
>  
>
>  
>
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Matt Moldvan
> Sent: Friday, May 13, 2016 9:14 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] OSAD not picking up updates
>
>  
>
> I'm with Maxime... I spent months trying to get OSAD to work properly, and we 
> recently had a major issue with some network equipment that lead to many OSAD 
> clients going offline.  Personally I'm just about done with it and ready to 
> implement a cron job to do rhn_check every 5 minutes...
>
>  
>
> On Fri, May 13, 2016 at 10:44 AM Maxime VEROONE  
> wrote:
>>
>> We have personally chosen to restart both the whole jabberd/osa-dispatcher 
>> stack and the osad clients every morning.
>> We banged our heads way too much trying to figure out why osad clients 
>> randomly loose communications with the server without any log/alert/crash
>>
>> Maxime VEROONE
>> Capensis SARL
>> Lille, France
>>
>> De : spacewalk-list-boun...@redhat.com 
>> [mailto:spacewalk-list-boun...@redhat.com] De la part de Matthew Madey
>> Envoyé : vendredi 13 mai 2016 16:27
>> À : spacewalk-list@redhat.com
>> Objet : Re: [Spacewalk-list] OSAD not picking up updates
>>
>> Are there any errors in /var/log/rhn/osa-dispatcher.log? Also try running 
>> the below command on your clients
>> rm -f /etc/sysconfig/rhn/osad-auth.conf;   service osad restart
>> If you are running a host firewall or have firewalls in place on your 
>> network, ensure port 5222 is open between clients and your Spacewalk server
>> On May 13, 2016 8:44 AM, "Daryl Rose"  wrote:
>> OSAD is not picking up scheduled updates.    To the best of my knowledge, 
>> everything is running and I don't see any errors on the server or on the 
>> clients.  osad is running on the client, osa-dispatcher as well as the 
>> jabberd processes are running on the server.   The packages will be picked 
>> up and applied by rhnsd, but I have to wait for it to check in.   I would 
>> like to have the packages picked up immediately via osad.
>>
>> BTW, I'm using SW version 2.3.
>>
>> Any thoughts on why osad isn't picking up packages?
>>
>> Thanks
>>
>> Daryl
>>
>> ___
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>>
>> ___
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list

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

Re: [Spacewalk-list] File deployment error

[Robert Paschedag]

rhn-action-control --enable-all

Am 25.04.2016 21:05 schrieb Konstantin Raskoshnyi :
>
> Hi guys.
> Trying to automatically deploy files thorough configuration, but it shows me 
> this error
> Local permission not set for action type configfiles.deploy
>
> All packages are installed, also I can run remote commands.
>
> For example I want to create a file /root/test.txt - from conf this command 
> doesn't work
>
> But if I do the same from machine remote command - it works
>
> Thanks

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

Re: [Spacewalk-list] Unable to install packages through activation key

[Robert Paschedag]

Can you install packages from the repository via apt-get on the client?

The packages you want to install must be in one of the channels the client 
subscribes.

Regards
Robert
Am 17.04.2016 17:48 schrieb Georg Bernold :
>
> Hi everyone!
>
>  
>
> I am currently trying to get my Raspberry Pi 3 running with spacewalk. When I 
> add packages to the activation key, and activate my Pi (which works), none of 
> the packages get installed and the event “package install” fails.
>
> I tried to add a package, which exists in my channels and one which does not 
> exist. But I do not see an error message. Has anyone an idea where I can find 
> a log regarding this issue? I must know why the action has failed. The 
> following components are installed on my client:
>
> ​http://packages.debian.org/sid/apt-transport-spacewalk
>
> ​http://packages.debian.org/sid/python-rhn
>
> ​http://packages.debian.org/sid/python-ethtool
>
> ​http://packages.debian.org/sid/rhnsd
>
> ​http://packages.debian.org/sid/rhn-client-tools
>
> I have NOT installed rhnpush and osad.
>
>  
>
> Any suggestions?
>
>  
>
> Kind Regards,
>
> Georg

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

Re: [Spacewalk-list] Search feature not working

[Robert Paschedag]

Is there a maximum number of connections reached while trying to access the 
external database?

Regards
Robert
Am 31.03.2016 19:24 schrieb Jagga Soorma :
>
> Hi Guys,
>
> Anyone able to help with this?  
>
> Thanks!
>
> On Tue, Mar 29, 2016 at 11:55 AM, Jagga Soorma  wrote:
>>
>> Hi Guys,
>>
>> I need to search for a package on spacewalk and I was getting a unable to 
>> connect to service error message so I manually started the rhn-search 
>> service which seemed to have died.  Now when I search it does not come up 
>> with any packages and I see the following message in my 
>> rhn_search_daemon.log:
>>
>> (I am using a external postgres db and have been using spacewalk for awhile 
>> now without any issues, just haven't searched for a package)
>>
>> --
>> INFO   | jvm 1    | 2016/03/29 11:52:54 | Mar 29, 2016 11:52:54 AM 
>> com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask run
>> INFO   | jvm 1    | 2016/03/29 11:52:54 | WARNING: 
>> com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@4dc756a8 -- 
>> Acquisition Attempt Failed!!! Clearing pending acquires. While trying to 
>> acquire a needed new resource, we failed to succeed more than the maximum 
>> number of allowed acquisition attempts (30). Last acquisition attempt 
>> exception: 
>> INFO   | jvm 1    | 2016/03/29 11:52:54 | org.postgresql.util.PSQLException: 
>> Connection refused. Check that the hostname and port are correct and that 
>> the postmaster is accepting TCP/IP connections.
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:215)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:64)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:144)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:29)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:21)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.jdbc3g.Jdbc3gConnection.(Jdbc3gConnection.java:24)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.Driver.makeConnection(Driver.java:410)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.Driver.connect(Driver.java:280)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:134)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:182)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:148)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> com.mchange.v2.async.ThreadPerTaskAsynchronousRunner$TaskThread.run(ThreadPerTaskAsynchronousRunner.java:255)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 | Caused by: 
>> java.net.ConnectException: Connection refused
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> java.net.PlainSocketImpl.socketConnect(Native Method)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> java.net.Socket.connect(Socket.java:579)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.core.PGStream.(PGStream.java:61)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     at 
>> org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:109)
>> INFO   | jvm 1    | 2016/03/29 11:52:54 |     ... 14 more
>> INFO   | jvm 1    | 2016/03/29 11:52:54 | 
>> --
>>
>> I see the correct entries for my postgres db in /etc/rhn/rhn.conf.  Am I 
>> missing something else that needs to be checked or 

Re: [Spacewalk-list] spacewalk syncs sometimes don't work

[Robert Paschedag]

Do you use a self singed certificate?

Try using only http protocol or deploy the root CA to the spacewalk server.

Regards
Robert
Am 28.03.2016 15:52 schrieb Elizabeth Jones :
>
> I am having some trouble getting my syncs to work.  The urls that I'm 
> connecting to are good, but spacewalk often returns this:
>
> Sync started: Mon Mar 28 08:44:15 2016
>
> ['/usr/bin/spacewalk-repo-sync', '--channel', 'my-rhel6', '--type', 'yum']
>
> Repo URL: https://lnxpulp01.mycompany.com/pulp/repos/rhel-6-server/
>
> ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: 
> my-rhel6. Please verify its path and try again
>
> Repo URL: https://lnxpulp01.mycompany/pulp/repos/my-6server/
>
> ERROR: Cannot retrieve repository metadata (repomd.xml) for repository: 
> my-rhel6. Please verify its path and try again
>
> Sync completed.
>
> Total time: 0:00:00
>
> I know this url is good, and I have synced to it in the past.  However, it 
> can be a little slow to respond back with files.  Is there a way to increase 
> the timeout so that the sync has enough time to successfully connect and get 
> the xml file?
>
>
> thanks,
>
> EJ

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

Re: [Spacewalk-list] rhnpush and passwords...

[Robert Paschedag]

Don't supply the -p option. You will be prompted then.

Regards
Robert
Am 21.03.2016 00:19 schrieb Lachlan Musicman :
>
> Hi,
>
> Admittedly I'm new to the rpm-based distro, but it seems odd to me that you 
> would have to explicitly have a password in a command. Specifically, rhnpush.
>
>
> For eg:
>
> rhnpush --server localhost -u admin -p --channel software-channel *.rpm
>
> doesn't work. 
>
> rhnpush --server localhost -u admin -p MyBigSecretDisplayedInHistory 
> --channel software-channel *.rpm
>
> does.
>
> Surely it's simple enough to prompt if -p flag is seen, rather than fail on 
> missing password?
>
> Am I missing something here?
>
> L.
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this way."
>
> - Grace Hopper

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

Re: [Spacewalk-list] Injecting Kernel module into kickstart?

[Robert Paschedag]

Hi,

I would just take the exact kernel version of the "installer" kernel and 
compile the Cisco module on another server (maybe virtualbox) for that kernel. 
Then modify the "installer" initrd.

Unpack, put module in modules path (/lib/modules/...), run depmod on that path 
and repack the initrd.

Regards
Robert
Am 16.03.2016 03:41 schrieb Lachlan Musicman :
>
> Hola,
>
> I can't get Kickstart to install on my server(s).
>
> I've successfully kickstarted an OS in virtualbox on my laptop, so I know 
> that everything else is working.
>
> The problem is that the servers need a specific driver (snic - a Cisco 
> storage driver) to see their storage.
>
> How can I get the snic driver into the iso created when I run:
>
> $ cobbler buildiso
>
> I don't want it stand alone - I still want it to be a net install. But to 
> recognise the hard ware on which the OS should be installed, the new driver 
> needs to be in the kernel on the cobbler generated.iso...
>
> Any ideas?
>
> cheers
> L.
>
>
>
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this way."
>
> - Grace Hopper

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

Re: [Spacewalk-list] wsgi apache error on proxy

[Robert Paschedag]

Am 18.03.2016 um 12:38 schrieb Jan Hutař:
> On 2016-03-16 14:25 -0400, Slava Bendersky wrote:
>>   Hello Everyone,
>>   On of the spacewalk proxy apache report error and I can't find what
>>   actual issue. Any help thank you.
>>   [Wed Mar 16 14:09:57 2016] [error] \tSERVER_SOFTWARE: Apache/2.2.15
>>   (Oracle)
>>   [Wed Mar 16 14:09:57 2016] [error] \tSSL_TLS_SNI: myhost.org
>>   [Wed Mar 16 14:09:57 2016] [error] \tUser-Agent:
>>   rhn.rpclib.py/2.5.72-1.el6
>>   [Wed Mar 16 14:09:57 2016] [error] \tX-Libcurl-Empty-Header-Workaround:
>>   *
>>   [Wed Mar 16 14:09:57 2016] [error] \tX-RHN-Auth:
>>   1TbeR557SRN8n/oLhSMWPyNP5lo8Cum76ors/eGC5tc=
>>   [Wed Mar 16 14:09:57 2016] [error] \tX-RHN-Auth-Expire-Offset: 3600.0
>>   [Wed Mar 16 14:09:57 2016] [error] \tX-RHN-Auth-Server-Time:
>>   1458151677.32
>>   [Wed Mar 16 14:09:57 2016] [error] \tX-RHN-Auth-User-Id:
>>   [Wed Mar 16 14:09:57 2016] [error] \tX-RHN-Server-Id: 110021
>>   [Wed Mar 16 14:09:57 2016] [error] \tX-RHN-Transport-Capability:
>>   follow-redirects=3
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_ssl.is_https: >   ssl_is_https of mod_wsgi.Adapter object at 0x7f0ae7af5a80>
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_ssl.var_lookup: >   method ssl_var_lookup of mod_wsgi.Adapter object at 0x7f0ae7af5a80>
>>   [Wed Mar 16 14:09:57 2016] [error]
>>   \tmod_wsgi.application_group:myhost.org|/xmlrpc
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.callable_object:
>>   application
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.handler_script:
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.input_chunked: 0
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.listener_host:
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.listener_port: 443
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.process_group:
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.request_handler:
>>   wsgi-script
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.script_reloading: 1
>>   [Wed Mar 16 14:09:57 2016] [error] \tmod_wsgi.version: (3, 2)
>>   [Wed Mar 16 14:09:57 2016] [error] \twsgi.errors: >   at 0x7f0ae7ac4fb0>
>>   [Wed Mar 16 14:09:57 2016] [error] \twsgi.file_wrapper: >   method file_wrapper of mod_wsgi.Adapter object at 0x7f0ae7af5a80>
>>   [Wed Mar 16 14:09:57 2016] [error] \twsgi.input: >   object at 0x7f0ae6179b20>
>>   [Wed Mar 16 14:09:57 2016] [error] \twsgi.multiprocess: True
>>   [Wed Mar 16 14:09:57 2016] [error] \twsgi.multithread: False
>>   [Wed Mar 16 14:09:57 2016] [error] \twsgi.run_once: False
>>   [Wed Mar 16 14:09:57 2016] [error] \twsgi.url_scheme: https
>>   [Wed Mar 16 14:09:57 2016] [error] \twsgi.version: (1, 1)
>>   [Wed Mar 16 14:09:57 2016] [error]
>>   [Wed Mar 16 14:09:57 2016] [error] Exception Handler Information
>>   [Wed Mar 16 14:09:57 2016] [error] Traceback (most recent call last):
>>   [Wed Mar 16 14:09:57 2016] [error] File
>>   "/usr/share/rhn/proxy/rhnShared.py", line 210, in _serverCommo
>>   [Wed Mar 16 14:09:57 2016] [error] status, headers, bodyFd =
>>   self._proxy2server()
>>   [Wed Mar 16 14:09:57 2016] [error] File
>>   "/usr/share/rhn/proxy/rhnShared.py", line 385, in _proxy2server
>>   [Wed Mar 16 14:09:57 2016] [error] response =
>>   http_connection.getresponse()
>>   [Wed Mar 16 14:09:57 2016] [error] File
>>   "/usr/lib/python2.6/site-packages/rhn/connections.py", line 93, in
>>   getresponse
>>   [Wed Mar 16 14:09:57 2016] [error] response.begin()
>>   [Wed Mar 16 14:09:57 2016] [error] File
>>   "/usr/lib64/python2.6/httplib.py", line 404, in begin
>>   [Wed Mar 16 14:09:57 2016] [error] version, status, reason =
>>   self._read_status()
>>   [Wed Mar 16 14:09:57 2016] [error] File
>>   "/usr/lib64/python2.6/httplib.py", line 360, in _read_status
>>   [Wed Mar 16 14:09:57 2016] [error] line = self.fp.readline(_MAXLINE +
>>   1)
>>   [Wed Mar 16 14:09:57 2016] [error] File
>>   "/usr/lib64/python2.6/socket.py", line 479, in readline
>>   [Wed Mar 16 14:09:57 2016] [error] data =
>>   self._sock.recv(self._rbufsize)
>>   [Wed Mar 16 14:09:57 2016] [error] timeout: timed out
>>   [Wed Mar 16 14:09:57 2016] [error]
>>   [Wed Mar 16 14:11:47 2016] [error] [client 172.16.101.102] mod_wsgi
>>   (pid=2739): Exception occurred processing WSGI script
>>   '/usr/share/rhn/wsgi/xmlrpc.py'.
>>   [Wed Mar 16 14:11:47 2016] [error] [client 172.16.101.102] IOError:
>>   failed to write data
> 
> Hello.
> 
> Who is 172.16.101.102 - your Spacewalk, or some client or the Spacewalk
> Proxy?
> 
> What is the Spacewalk Proxy and Spacewalk version?
> 
> Which action triggers this traceback?
> 
> Regards,
> Jan
> 
But there is a "tirmeout" error. Is this now a permanent error?

Regads
Robert

> 
> 

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

Re: [Spacewalk-list] Cannot get Spacewalk to start after upgrade from 2.3 to Spacewalk 2.4

[Robert Paschedag]

Did you update the database schema after the upgrade to 2.4?

You seem to have a problem with your database.

Regards
Robert
Am 12.03.2016 08:41 schrieb "Steward, Dan (US - Hermitage)" 
:
>
> Attached is a copy of the error that I receive when I startup Spacewalk:
>
>  
>
>  
>
>  
>
>  
>
>  
>
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Stuart Green
> Sent: Tuesday, March 8, 2016 8:38 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] Cannot get Spacewalk to start after upgrade 
> from 2.3 to Spacewalk 2.4
>
>  
>
> https://fedorahosted.org/spacewalk/wiki/HowToUpgrade
>
>  
>
> 2.3 > 2.4 is documented above, ensure you've followed all the steps and 
> report back :)
>
>  
>
> On 8 March 2016 at 14:19, Steward, Dan (US - Hermitage) 
>  wrote:
>>
>> Hi All,
>> I recently upgraded Spacewalk from 2.3 to 2.4. Now the Spacewalk service 
>> starts but jabberd process fails along with the osa-dispatcher service.
>>
>> Does anyone have any recommendations or advice on how to get these 2 
>> processes started? Also if you have a documented process on upgrading from 
>> 2.3 to 2.4.
>>
>> Thanks,
>> Dan
>>
>>
>>
>> This message (including any attachments) contains confidential information 
>> intended for a specific individual and purpose, and is protected by law. If 
>> you are not the intended recipient, you should delete this message and any 
>> disclosure, copying, or distribution of this message, or the taking of any 
>> action based on it, by you is strictly prohibited.
>>
>> v.E.1
>>
>>
>>
>> ___
>> 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] Problem with activation key and kickstart

[Robert Paschedag]

Hi Damien,

I think the first key is a generated key special for this kickstarted system. 
Just as if you would like to "reactivate" a client. But I did not yet use koan 
so I actually don't really know.

Regards
Robert
Am 25.02.2016 23:32 schrieb Damien Daco :
>
> Hi list :)
>
> I've got a small problem with my activation key when kickstarting virtual 
> machines.
>
> My key, and only key, is called "1-centos6-x64". I only have that key, and 
> it's universal.
>
> However, when I provision VMs with koan, the clients automatically register 
> to spacewalk, but they aren't properly registered to my channels/repositories.
>
> When I check my kickstart file, I see something strange, there are actually 
> TWO keys!
>
> key=1-cb1705dc1caf00069d949e2cb25c88aa,1-centos6-x64
>
>
> Where is this long key coming from? I can't find any mention of this key when 
> checking the webgui.
>
>
> When I manually register the clients with the following command:
>
> rhnreg_ks --serverUrl=https://space.intra.lab/XMLRPC 
> --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT 
> --activationkey=1-centos6-x64
>
> ...they finally get the proper repos... but this is tedious, I wish I could 
> understand what's wrong with the weird key in my kickstart file.
>
> Any ideas?
>
> Cheers
>

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

Re: [Spacewalk-list] RHNSD interval, splay time?

[Robert Paschedag]

You assume, that every server started rhnsd at the same time... Or on the same 
minute within an hour. As long as you don't start or restart rhnsd via cron, 
this shouldn't happen.

If you're using osad, and schedule a task for all servers to start "as soon as 
possible", you'll might get in trouble.

Regards
Robert
Am 25.02.2016 19:45 schrieb Marcin Figura :
>
> Hello,
>
>    I am trying to understand better how rhnsd works and since I have plans to 
> connect about thousand clients. With current 200 clients all have interval 
> set to 60 minutes which is recommended minimal pooling time.  
>  
>   So when I schedule a task not all clients contact spacewalk server at the 
> same time which is good but that makes me believe there must be a splay time 
> set for each client. If there was no splay time, all clients will connect at 
> every full hour , for example 1:00, 2:00, 3:00 ... 
>
>    Any assistance with few questions below very appreciated:  
> How its being determined when client should check with spacewalk server? Is 
> it the time since first registration of the client with the server and then 
> every 60 minutes? 
> What if the interval is set to 30 minutes? Why its not recommended?
>
>
>
>
> Mintel Group Limited | 333 West Wacker Drive Suite 1100 | Chicago, Illinois 
> USA 60606
>
> Contact details for our other offices can be found at 
> http://www.mintel.com/office-locations.
>
> This email and any attachments may include content that is confidential, 
> privileged 
>  or otherwise protected under applicable law. Unauthorized disclosure, 
> copying, distribution 
>  or use of the contents is prohibited and may be unlawful. If you have 
> received this email in error,
>  including without appropriate authorization, then please reply to the sender 
> about the error 
>  and delete this email and any attachments.
>
>

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

Re: [Spacewalk-list] Kickstart URL

[Robert Paschedag]

Hi Emmet,

I think you should be able to specify the URL as kernel option within the 
profile. But this is "installer" specific.

Regards
Robert
Am 24.02.2016 03:02 schrieb Emmett Hogan :
>
> Hi Folks, 
>
> (Hopefully) quick question…  
>
> I have a spacewalk server with 2 interfaces…I want to PXE boot my bare metal 
> builds off of a private network (SW server IP 192.168.67.5) on the 2nd 
> interface.  The DHCP and PXE boot portion is working fine…but my kickstart 
> URL that is passed to the clients contains the real hostname of the SW 
> server…which the new clients cannot get to.  
>
> I would think this isn't such a strange configuration…so someone must know 
> the answer.  I've been testing my google-foo…and failing.  
>
> Anyone have any thoughts?
>
> When I look at my Kickstart Details: Bare Metal Kickstart screen, I see the 
> URL that is used…but I cannot figure out how to change it.
>
> Thanks in advance,
> Emmett
>

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

Re: [Spacewalk-list] Unexpected RPM package type while using rhnpush

[Robert Paschedag]

Hi Zeal,

Isn't the URL .../XMLRPC at the end?

Regards
Robert
Am 24.02.2016 02:01 schrieb Zeal Vora :
>
> Hi
>
> Whenever I use rhnpush, it says :-
>
> Unable to load package /tmp/packages/epel-release-7-5.noarch.rpm : Unexpected 
> RPM package type
>
> I tried with different RPM's and for all it says the same thing.
>
>
> The command :-
>
> rhnpush -v --server=https://172.20.10.15/APP -c myanime --source 
> /tmp/packages/epel-release-7-5.noarch.rpm 
> Connecting to https://172.20.10.15/APP
>
> Any help will be appreciated !
>
>

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

Re: [Spacewalk-list] Integrating Space Walk with Configuration Management

[Robert Paschedag]

Hi,

Why don't you just create some "postinstall" script to your image deployment to 
do that?

In Suse, you can do this within autoyast.

Regards
Robert
Am 22.02.2016 02:21 schrieb Zeal Vora :
>
> Hi
>
> We generally use Ansible for many things including Server Hardening and Linux 
> Hardening rules.
>
> I was wondering, if is use SpaceWalk for Deployments via PXE, doing a Laptop 
> Hardening ( Linux hardening ) does not seem to be possible.
>
> We then need to run Ansible to deploy the Linux Hardening rules on those new 
> machines.
>
> Is there any optimal way where whenever a new machine is provisioned , after 
> PXE, Space Walk can automatically run the Linux Hardening Rules via Ansible !
>
> If there is any better solution, any suggestions would be appreciated ! 
>
>
> Regards,
> Zeal

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

Re: [Spacewalk-list] spacewalk upgrade for client

[Robert Paschedag]

Just re-register to new server with

rhnreg_ks --force --activationkey= 
--serverUrl=https://

Regards
Robert
Am 02.02.2016 23:09 schrieb Benjamin Fernandis :
>
> Hi,
>
> In previous we are using spacewalk version 2.3. Now we created new server 
> which has latest version 2.4 . What would be best way to upgrade clients to 
> connect with new spacewalk server which has 2.4 version.
>
> I am thinking to remove client packages from client machine and setup 2.4 
> repo and install accordingly. Please suggest me if is there any better way 
> for this.
>
> what is best way to use spacewalk for update systems. we thinking to pull 
> updates from spacewalk by running yum update at client end.
>
> do we require to move existing base repo which comes with centos after 
> installation to use spacewalk repo in yum update ?
>
> Thanks
> Ben

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

Re: [Spacewalk-list] Antwort: Re: Errata Cache bunch running forever on Spacewalk 2.4

[Robert Paschedag]

FINISHED 
> > errata-cache _2016-01-12 08:36:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:36:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:35:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:35:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:34:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:36:00 MEZ FINISHED 
> > errata-mailer _2016-01-12 08:33:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:33:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:33:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:33:00 MEZ FINISHED 
> > errata-mailer _2016-01-12 08:32:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:32:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:32:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:32:00 MEZ FINISHED 
> > errata-mailer _2016-01-12 08:31:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:31:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:31:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:31:00 MEZ FINISHED 
> > errata-mailer _2016-01-12 08:30:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:30:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:30:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:30:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:29:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=132> 
> > 2016-01-12 08:29:00 MEZ SKIPPED 
> > 
> > 
> > 
> > And also I noticed that the "errata-mailer" tasks seems to get only 
> > started, when the "errata-cache" tasks finished within one minute. (Just 
> > look above). As soon as the errata-cache tasks runs longer than one 
> > minute, the "errata-mailer" is not started. I'm also not sure, if 
> > something went wrong, while I was shutting down the spacewalk server for 
> > the update. 
> > 
> > This is what it looked before (on spacewalk 2.2). I started the update 
> > on 2016-01-04 abount 08:30. 
> > errata-cache _2016-01-04 10:10:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 10:10:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 10:00:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 10:00:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 09:50:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 09:50:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 09:40:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 09:40:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 09:30:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 09:30:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 09:20:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 09:20:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 09:10:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 09:10:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 09:00:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 09:00:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 08:50:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 08:50:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 08:40:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 08:40:00 MEZ SKIPPED 
> > errata-cache _2016-01-04 08:30:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-05 08:59:59 MEZ INTERRUPTED 
> > errata-mailer _2016-01-04 08:30:00 MEZ _ 
> > <https://spacewalk.swr.ard/rhn/admin/ScheduleDetail.do?schid=7> 
> > 2016-01-04 08:29:57 MEZ INTERRUPTED 
> > errata-mailer _2016-01-04 08:00:00 MEZ _ 
> > <https://spacewal

Re: [Spacewalk-list] Errata Cache bunch running forever on Spacewalk 2.4

[Robert Paschedag]

Can anybody give a hint, in which db table to search for these errata-cache 
tasks, that are started over and over again? I just don't get it myself right 
now . It also looks like that it is always the same prox. 50 servers that this 
occurs.

Regards
Robert
Am 07.01.2016 10:11 vorm. schrieb paschedag.netlut...@swr.de:
>
> Hi all, 
>
> it looks like one (or more?) jobs have been interrupted, while the spacewalk 
> service had shut down for upgrade. I upgraded my spacewalk server from 2.2 -> 
> 2.3 -> 2.4. 
>
> Now it looks like the errata-cache bunch tasks is running forever and the 
> errata notification mail is not started anymore. I think it gets called from 
> errata-cache, when this has finished. 
>
> Errata Cache:
> 2016-01-07 10:00:00 MEZ
> RUNNING
> Errata Notification Mail:
> 2016-01-04 08:30:00 MEZ
> INTERRUPTED
>
>
> When I look into the database, I can see several tasks in the rhntaskqueue 
> but I'm pretty sure, that these tasks do not get cleared correctly, so the 
> task is run for every server over and over again. I'm not sure! This is just 
> my thinking. 
>
> rhnschema=# select * from rhntaskqueue; 
>  org_id |         task_name          | task_data  | priority |           
> earliest 
> +++--+---
>  
>       1 | update_server_errata_cache | 110701 |        0 | 2016-01-07 
> 10:00:45.963006+01 
>       1 | update_server_errata_cache | 110274 |        0 | 2016-01-07 
> 10:00:53.198001+01 
>       1 | update_server_errata_cache | 110527 |        0 | 2016-01-07 
> 10:01:03.768592+01 
>       1 | update_server_errata_cache | 110689 |        0 | 2016-01-07 
> 10:01:56.915296+01 
>       1 | update_server_errata_cache | 110641 |        0 | 2016-01-07 
> 10:02:41.775593+01 
>       1 | update_server_errata_cache | 110687 |        0 | 2016-01-07 
> 10:05:01.471365+01 
>       1 | update_server_errata_cache | 110650 |        0 | 2016-01-07 
> 10:05:26.492405+01 
>       1 | update_server_errata_cache | 110520 |        0 | 2016-01-07 
> 10:06:38.052352+01 
> (8 Zeilen) 
>
> rhnschema=# 
>
> Any help will be appreciated to debug this further. 
>
> Regards, 
> Robert 
>
>
> Mit freundlichen Grüßen 
>
> Robert Paschedag 
> Netlution GmbH 
> Landteilstr. 33 
> 68163 Mannheim 
>
> im Auftrag des 
> SWR 
> Südwestrundfunk 
> Informations- und Kommunikationssysteme 
> Neckarstraße 230 
> 70190 Stuttgart 
>
> Telefon +49 (0)711 /929-12654 oder 
> Telefon +49 (0)711 /929-13714 
> paschedag.netlut...@swr.de 
>
> swr.de 
>

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

Re: [Spacewalk-list] Errata Cache bunch running forever on Spacewalk 2.4

[Robert Paschedag]

Hi again,

just some further information.

Because I already activated debug logging of taskomatic, searching for
server errata cache tasks within the rhn_taskomatic_daemon logfiles with

grep 'Updating errata cache for server' rhn_taskomatic_daemon.log* | awk
'{print $NF; }' | sort | uniq -c

i get

14 [110274]
 14 [110299]
  4 [110504]
 14 [110512]
 14 [110516]
 14 [110517]
 14 [110518]
 14 [110519]
 14 [110520]
 14 [110521]
 14 [110522]
 14 [110523]
 14 [110524]
 14 [110527]
 14 [110528]
 14 [110529]
 14 [110530]
 14 [110531]
 14 [110532]
 14 [110564]
 14 [110570]
 15 [110573]
 15 [110593]
 13 [110639]
 14 [110640]
 15 [110641]
 13 [110642]
 14 [110647]
 13 [110648]
 14 [110649]
 15 [110650]
 14 [110651]
 14 [110652]
  6 [110672]
 15 [110683]
 14 [110684]
 14 [110685]
 14 [110687]
 14 [110688]
 14 [110689]
 14 [110690]
 14 [110691]
 14 [110692]
 14 [110693]
 14 [110694]
 15 [110695]
 14 [110697]
 14 [110698]
  2 [110702]
 14 [110705]
 14 [110710]
  2 [110715]

On this server, there are more than 400 servers registered, so this
looks like, something is "hanging" on these servers and not going any
further (i think).

But right now, I don't know - exactly - where to look for this "error"
or within which DB table to further track this down.

Regards,
Robert

Am 08.01.2016 um 19:31 schrieb Robert Paschedag:
> Can anybody give a hint, in which db table to search for these errata-cache 
> tasks, that are started over and over again? I just don't get it myself right 
> now . It also looks like that it is always the same prox. 50 servers that 
> this occurs.
> 
> Regards
> Robert
> Am 07.01.2016 10:11 vorm. schrieb paschedag.netlut...@swr.de:
>>
>> Hi all, 
>>
>> it looks like one (or more?) jobs have been interrupted, while the spacewalk 
>> service had shut down for upgrade. I upgraded my spacewalk server from 2.2 
>> -> 2.3 -> 2.4. 
>>
>> Now it looks like the errata-cache bunch tasks is running forever and the 
>> errata notification mail is not started anymore. I think it gets called from 
>> errata-cache, when this has finished. 
>>
>> Errata Cache:
>> 2016-01-07 10:00:00 MEZ
>> RUNNING
>> Errata Notification Mail:
>> 2016-01-04 08:30:00 MEZ
>> INTERRUPTED
>>
>>
>> When I look into the database, I can see several tasks in the rhntaskqueue 
>> but I'm pretty sure, that these tasks do not get cleared correctly, so the 
>> task is run for every server over and over again. I'm not sure! This is just 
>> my thinking. 
>>
>> rhnschema=# select * from rhntaskqueue; 
>>  org_id | task_name  | task_data  | priority |   
>> earliest 
>> +++--+---
>>  
>>   1 | update_server_errata_cache | 110701 |0 | 2016-01-07 
>> 10:00:45.963006+01 
>>   1 | update_server_errata_cache | 110274 |0 | 2016-01-07 
>> 10:00:53.198001+01 
>>   1 | update_server_errata_cache | 110527 |0 | 2016-01-07 
>> 10:01:03.768592+01 
>>   1 | update_server_errata_cache | 110689 |0 | 2016-01-07 
>> 10:01:56.915296+01 
>>   1 | update_server_errata_cache | 110641 |0 | 2016-01-07 
>> 10:02:41.775593+01 
>>   1 | update_server_errata_cache | 110687 |0 | 2016-01-07 
>> 10:05:01.471365+01 
>>   1 | update_server_errata_cache | 110650 |    0 | 2016-01-07 
>> 10:05:26.492405+01 
>>   1 | update_server_errata_cache | 110520 |0 | 2016-01-07 
>> 10:06:38.052352+01 
>> (8 Zeilen) 
>>
>> rhnschema=# 
>>
>> Any help will be appreciated to debug this further. 
>>
>> Regards, 
>> Robert 
>>
>>
>> Mit freundlichen Grüßen 
>>
>> Robert Paschedag 
>> Netlution GmbH 
>> Landteilstr. 33 
>> 68163 Mannheim 
>>
>> im Auftrag des 
>> SWR 
>> Südwestrundfunk 
>> Informations- und Kommunikationssysteme 
>> Neckarstraße 230 
>> 70190 Stuttgart 
>>
>> Telefon +49 (0)711 /929-12654 oder 
>> Telefon +49 (0)711 /929-13714 
>> paschedag.netlut...@swr.de 
>>
>> swr.de 
>>
> 
> ___
> 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] Exception Handler on Spacewalk V2.0

[Robert Paschedag]

Hmm... For me, this worked on sles11. There was an update for rhnlib. After that, I got the 'get_server_capability " error. I then upgraded osad, osa-common and the rhncfg packages. But I took these from the opensuse build system.
Regards
Robert
Am 11.12.2015 10:27 vorm. schrieb stefano ciavarella <stefano.ciavare...@gmail.com>:[Fri Dec 11 10:25:56 2015] [error] Exception Handler Information[Fri Dec 11 10:25:56 2015] [error] Traceback (most recent call last):[Fri Dec 11 10:25:56 2015] [error]   File "/usr/lib/python2.6/site-packages/spacewalk/server/apacheRequest.py", line 121, in call_function[Fri Dec 11 10:25:56 2015] [error] func = self.method_ref(method)[Fri Dec 11 10:25:56 2015] [error]   File "/usr/lib/python2.6/site-packages/spacewalk/server/apacheRequest.py", line 432, in method_ref[Fri Dec 11 10:25:56 2015] [error] classname, funcname = string.split(method, '.', 1)[Fri Dec 11 10:25:56 2015] [error] UnknownXML: Invalid request received (method 'get_server_capability' doesn't have a class and function).[Fri Dec 11 10:25:56 2015] [error] [Fri Dec 11 10:25:56 2015] [error] \tmod_wsgi.version: (3, 2)[Fri Dec 11 10:25:56 2015] [error] \twsgi.errors: [Fri Dec 11 10:25:56 2015] [error] \twsgi.file_wrapper: [Fri Dec 11 10:25:56 2015] [error] \twsgi.input: [Fri Dec 11 10:25:56 2015] [error] \twsgi.multiprocess: True[Fri Dec 11 10:25:56 2015] [error] \twsgi.multithread: False[Fri Dec 11 10:25:56 2015] [error] \twsgi.run_once: False[Fri Dec 11 10:25:56 2015] [error] \twsgi.url_scheme: https[Fri Dec 11 10:25:56 2015] [error] \twsgi.version: (1, 1)[Fri Dec 11 10:25:56 2015] [error] Extra information about this error:[Fri Dec 11 10:25:56 2015] [error] Response sent back to the caller:[Fri Dec 11 10:25:56 2015] [error] While running 'get_server_capability': caught[Fri Dec 11 10:25:56 2015] [error]  : Invalid request received (method 'get_server_capability' doesn't have a class and function).I upgraded  osad, rhncfg, rhncfg-actions, same errorrhn-client-tools-2.5.2-1.el6.noarch.rpm rhn-check-2.5.2-1.el6.noarch.rpm rhn-setup-2.5.2-1.el6.noarch.rpm rhncfg-5.10.87-1.el6.noarch.rpm rhncfg-actions-5.10.87-1.el6.noarch.rpm rhncfg-client-5.10.87-1.el6.noarch.rpm rhncfg-management-5.10.87-1.el6.noarch.rpmOn Thu, Dec 10, 2015 at 8:39 PM, stefano ciavarella <stefano.ciavarella@gmail.com> wrote:Thanks Robert for the answer, i get traceback  every minute.
I'll try to upgrade the packages you suggested me, Thanks again Rob
Il 10/Dic/2015 20:10, "Robert Paschedag" <robert.paschedag@web.de> ha scritto:Know that error. Also update osad, rhncfg, rhncfg-actions

You get a traceback every two minutes??

Regards
Robert

Am 10.12.2015 3:20 nachm. schrieb stefano ciavarella <stefano.ciavarella@gmail.com>:
>
> redhat 6.4 x86_64
> Spacewalk V2.0
>
> I tried upgrading the following packages without luck
>
> rhnlib-2.5.77-1.el6.noarch
> osa-common-5.11.63-1.el6.noarch
> osa-dispatcher-5.11.63-1.el6.noarch
> osa-dispatcher-selinux-5.11.63-1.el6.noarch
>
>
> [Thu Dec 10 15:13:57 2015] [error] Exception reported from xxx.local
> [Thu Dec 10 15:13:57 2015] [error] Time: Thu Dec 10 15:13:57 2015
> [Thu Dec 10 15:13:57 2015] [error] Exception type 
> [Thu Dec 10 15:13:57 2015] [error] Exception while handling function get_server_capability
> [Thu Dec 10 15:13:57 2015] [error] Request object information:
> [Thu Dec 10 15:13:57 2015] [error] URI: /XMLRPC
> [Thu Dec 10 15:13:57 2015] [error] Remote Host: 10.233.65.132
> [Thu Dec 10 15:13:57 2015] [error] Server Name: xxx.local:443
> [Thu Dec 10 15:13:57 2015] [error] Headers passed in:
> [Thu Dec 10 15:13:57 2015] [error] \tAccept-Encoding: identity
> [Thu Dec 10 15:13:57 2015] [error] \tCONTENT_LENGTH: 115
> [Thu Dec 10 15:13:57 2015] [error] \tCONTENT_TYPE: text/xml
> [Thu Dec 10 15:13:57 2015] [error] \tDOCUMENT_ROOT: /var/www/html
> [Thu Dec 10 15:13:57 2015] [error] \tGATEWAY_INTERFACE: CGI/1.1
> [Thu Dec 10 15:13:57 2015] [error] \tHTTPS: 1
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_ACCEPT_ENCODING: identity
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_HOST: xxx.local
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_USER_AGENT: rhn.rpclib.py/2.5.77-1.el6
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_X_CLIENT_VERSION: 1
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_X_INFO: RPC Processor (C) Red Hat, Inc (version 2.5.77-1.el6)
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_X_RHN_TRANSPORT_CAPABILITY: follow-redirects=3
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_X_TRANSPORT_INFO: Extended Capabilities Transport (C) Red Hat, Inc (version 2.5.77-1.el6)
> [Thu Dec 10 15:13:57 2015] [error] \tHost: xxx.local
> [Thu Dec 10 15:13:57 2015] [error] \tPATH_INFO:
> [Thu Dec 10 15:13:57 2015] [error] \tQUERY_STRING:
> [Thu Dec 10 15:13:57 2015] [error] \tREMOTE_ADDR: 10.x.x.x
> [Thu Dec 

Re: [Spacewalk-list] Exception Handler on Spacewalk V2.0

[Robert Paschedag]

Know that error. Also update osad, rhncfg, rhncfg-actions

You get a traceback every two minutes??

Regards
Robert

Am 10.12.2015 3:20 nachm. schrieb stefano ciavarella 
:
>
> redhat 6.4 x86_64 
> Spacewalk V2.0
>
> I tried upgrading the following packages without luck
>
> rhnlib-2.5.77-1.el6.noarch
> osa-common-5.11.63-1.el6.noarch
> osa-dispatcher-5.11.63-1.el6.noarch
> osa-dispatcher-selinux-5.11.63-1.el6.noarch
>
>
> [Thu Dec 10 15:13:57 2015] [error] Exception reported from xxx.local
> [Thu Dec 10 15:13:57 2015] [error] Time: Thu Dec 10 15:13:57 2015
> [Thu Dec 10 15:13:57 2015] [error] Exception type  'spacewalk.server.apacheRequest.UnknownXML'>
> [Thu Dec 10 15:13:57 2015] [error] Exception while handling function 
> get_server_capability
> [Thu Dec 10 15:13:57 2015] [error] Request object information:
> [Thu Dec 10 15:13:57 2015] [error] URI: /XMLRPC
> [Thu Dec 10 15:13:57 2015] [error] Remote Host: 10.233.65.132
> [Thu Dec 10 15:13:57 2015] [error] Server Name: xxx.local:443
> [Thu Dec 10 15:13:57 2015] [error] Headers passed in:
> [Thu Dec 10 15:13:57 2015] [error] \tAccept-Encoding: identity
> [Thu Dec 10 15:13:57 2015] [error] \tCONTENT_LENGTH: 115
> [Thu Dec 10 15:13:57 2015] [error] \tCONTENT_TYPE: text/xml
> [Thu Dec 10 15:13:57 2015] [error] \tDOCUMENT_ROOT: /var/www/html
> [Thu Dec 10 15:13:57 2015] [error] \tGATEWAY_INTERFACE: CGI/1.1
> [Thu Dec 10 15:13:57 2015] [error] \tHTTPS: 1
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_ACCEPT_ENCODING: identity
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_HOST: xxx.local
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_USER_AGENT: 
> rhn.rpclib.py/2.5.77-1.el6
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_X_CLIENT_VERSION: 1
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_X_INFO: RPC Processor (C) Red Hat, 
> Inc (version 2.5.77-1.el6)
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_X_RHN_TRANSPORT_CAPABILITY: 
> follow-redirects=3
> [Thu Dec 10 15:13:57 2015] [error] \tHTTP_X_TRANSPORT_INFO: Extended 
> Capabilities Transport (C) Red Hat, Inc (version 2.5.77-1.el6)
> [Thu Dec 10 15:13:57 2015] [error] \tHost: xxx.local
> [Thu Dec 10 15:13:57 2015] [error] \tPATH_INFO: 
> [Thu Dec 10 15:13:57 2015] [error] \tQUERY_STRING: 
> [Thu Dec 10 15:13:57 2015] [error] \tREMOTE_ADDR: 10.x.x.x
> [Thu Dec 10 15:13:57 2015] [error] \tREMOTE_PORT: 54840
> [Thu Dec 10 15:13:57 2015] [error] \tREQUEST_METHOD: POST
> [Thu Dec 10 15:13:57 2015] [error] \tREQUEST_URI: /XMLRPC
> [Thu Dec 10 15:13:57 2015] [error] \tSCRIPT_FILENAME: 
> /usr/share/rhn/wsgi/xmlrpc.py
> [Thu Dec 10 15:13:57 2015] [error] \tSCRIPT_NAME: /XMLRPC
> [Thu Dec 10 15:13:57 2015] [error] \tSCRIPT_URI: https://xxx.local/XMLRPC
> [Thu Dec 10 15:13:57 2015] [error] \tSCRIPT_URL: /XMLRPC
> [Thu Dec 10 15:13:57 2015] [error] \tSERVER_ADDR: 10.x.x.x
> [Thu Dec 10 15:13:57 2015] [error] \tSERVER_ADMIN: root@localhost
> [Thu Dec 10 15:13:57 2015] [error] \tSERVER_NAME: xxx.local
> [Thu Dec 10 15:13:57 2015] [error] \tSERVER_PORT: 443
> [Thu Dec 10 15:13:57 2015] [error] \tSERVER_PROTOCOL: HTTP/1.1
> [Thu Dec 10 15:13:57 2015] [error] \tSERVER_SIGNATURE: Apache Server 
> at xxx.local Port 443
> [Thu Dec 10 15:13:57 2015] [error] 
> [Thu Dec 10 15:13:57 2015] [error] \tSERVER_SOFTWARE: Apache
> [Thu Dec 10 15:13:57 2015] [error] \tUser-Agent: rhn.rpclib.py/2.5.77-1.el6
> [Thu Dec 10 15:13:57 2015] [error] \tX-Client-Version: 1
> [Thu Dec 10 15:13:57 2015] [error] \tX-Info: RPC Processor (C) Red Hat, Inc 
> (version 2.5.77-1.el6)
> [Thu Dec 10 15:13:57 2015] [error] \tX-RHN-Transport-Capability: 
> follow-redirects=3
> [Thu Dec 10 15:13:57 2015] [error] \tX-Transport-Info: Extended Capabilities 
> Transport (C) Red Hat, Inc (version 2.5.77-1.el6)
> [Thu Dec 10 15:13:57 2015] [error] \tmod_ssl.is_https:  ssl_is_https of mod_wsgi.Adapter object at 0x7f223c685918>
> [Thu Dec 10 15:13:57 2015] [error] \tmod_ssl.var_lookup:  ssl_var_lookup of mod_wsgi.Adapter object at 0x7f223c685918>
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.application_group: 
> xxx.local|/xmlrpc
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.callable_object: application
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.handler_script: 
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.input_chunked: 0
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.listener_host: 
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.listener_port: 443
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.process_group: 
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.request_handler: wsgi-script
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.script_reloading: 1
> [Thu Dec 10 15:13:57 2015] [error] \tmod_wsgi.version: (3, 2)
> [Thu Dec 10 15:13:57 2015] [error] \twsgi.errors:  0x7f225551aab0>
> [Thu Dec 10 15:13:57 2015] [error] \twsgi.file_wrapper:  file_wrapper of mod_wsgi.Adapter object at 0x7f223c685918>
> [Thu Dec 10 15:13:57 2015] [error] \twsgi.input:  0x7f225537a770>
> [Thu Dec 10 15:13:57 2015] [error] \twsgi.multiprocess: True
> [Thu Dec 10 

Re: [Spacewalk-list] Check "task queue" for client on server within database? SOLVED!

[Robert Paschedag]

Already solved it

Regards
Robert

Am 09.12.2015 5:08 nachm. schrieb Jan Dobes <jdo...@redhat.com>:
>
> On 8.12.2015 10:23 paschedag.netlut...@swr.de wrote: 
> > Hi everyone, 
> > 
> > I just noticed, that several of my clients are not picking up remote 
> > commands from the server. Although all "remote commands" are allowed on 
> > the client, scheduling a task stays in "pending" state forever. 
> > 
> > On the client, nothing gets logged anymore. It looks, like the client 
> > does not "find" anything to do in its queue on the server. When I debug 
> > the "rhn_check" command, this code here fails 
> > 
> > action = self.server.queue.get(up2dateAuth.getSystemId(), 
> >   94 ACTION_VERSION, status_report) 
> >   95 
> >   96 return action 
> > 
> > "action" is emtpy every time now. 
> > 
> > Any help will be appreciated. 
> > 
> > Regards, 
> > Robert 
> > 
> > 
> > Mit freundlichen Grüßen 
> > 
> > Robert Paschedag 
> > Netlution GmbH 
> > Landteilstr. 33 
> > 68163 Mannheim 
> > 
> > im Auftrag des 
> > SWR 
> > Südwestrundfunk 
> > Informations- und Kommunikationssysteme 
> > Neckarstraße 230 
> > 70190 Stuttgart 
> > 
> > Telefon +49 (0)711 /929-12654 oder 
> > Telefon +49 (0)711 /929-13714 
> > paschedag.netlut...@swr.de 
> > 
> > swr.de 
> > 
>
> Hello, 
>
> try to run rhn_check -vvv to display more output. Also check what's 
> happening on server side in /var/log/rhn/rhn_server_xmlrpc.log . 
>
> Regards, 
> -- 
> Jan Dobes 
> Satellite 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

Re: [Spacewalk-list] Check "task queue" for client on server within database?

[Robert Paschedag]

So... finally... after long digging... I found my error.

Situation:

Nearly all clients stopped picking up tasks from spacewalk at the same time.

Problem was an error within the database because of a suddenly read only 
filesystem. All problematic clients had an "open" task, that was in status 
"picked up", but the client had nothing to return anymore.

And all the "new" tasks had not been picked up, because within the handler 
"queue.get", the handler returns without doing anything if there is still an 
"open" task for the client.

So the solution was to change the status of the "open" task within the database.

I put all tasks to "fail" (status code 3) with

"update rhnServerActions set status = 3, completed_time = CURRENT_TIMESTAMP 
where status = 1;"

Database is PostgreSQL

After that, all clients picked up the "remaining" tasks and the server nearly 
broke down ;-)

Regards
Robert
Am 08.12.2015 10:23 schrieb paschedag.netlut...@swr.de:
>
> Hi everyone, 
>
> I just noticed, that several of my clients are not picking up remote commands 
> from the server. Although all "remote commands" are allowed on the client, 
> scheduling a task stays in "pending" state forever. 
>
> On the client, nothing gets logged anymore. It looks, like the client does 
> not "find" anything to do in its queue on the server. When I debug the 
> "rhn_check" command, this code here fails 
>
>             action = self.server.queue.get(up2dateAuth.getSystemId(), 
>  94                     ACTION_VERSION, status_report) 
>  95 
>  96                 return action 
>
> "action" is emtpy every time now. 
>
> Any help will be appreciated. 
>
> Regards, 
> Robert 
>
>
> Mit freundlichen Grüßen 
>
> Robert Paschedag 
> Netlution GmbH 
> Landteilstr. 33 
> 68163 Mannheim 
>
> im Auftrag des 
> SWR 
> Südwestrundfunk 
> Informations- und Kommunikationssysteme 
> Neckarstraße 230 
> 70190 Stuttgart 
>
> Telefon +49 (0)711 /929-12654 oder 
> Telefon +49 (0)711 /929-13714 
> paschedag.netlut...@swr.de 
>
> swr.de 
>

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

Re: [Spacewalk-list] Check "task queue" for client on server within database?

[Robert Paschedag]

You misunderstand...

The filesystem was read-only... I had to reboot the spacewalk server then. 
Afterwards... everything was read write again.

Robert
Am 09.12.2015 1:24 vorm. schrieb Paul Robert Marino <prmari...@gmail.com>:
>
> were there any DBI related errors in the logs?
>
> On Tue, Dec 8, 2015 at 7:23 PM, Paul Robert Marino <prmari...@gmail.com> 
> wrote:
> > Wait I am confused by this bug report, how can you update a read only 
> > database?
> > You should have gotten an error from the database when it could not
> > write to the journal.
> > Now PostgreSQL would have probably allowed you to keep reading as long
> > as the queries fit within the memory boundaries, but you wouldn't be
> > able to update the statuses in that case.
> > now if the journal was on a different files system than the data, for
> > example you have spacewalk in a separate table space. I have seen
> > instances where PostgreSQL will commit to the journal but will fail to
> > update the data. In those cases you need to fix the file system and
> > then restart the PosgresSQL service to force a journal recovery, then
> > you would have to bounce the spacewalk services to get them to
> > reconnect.
> >
> >
> >
> >
> >
> > On Tue, Dec 8, 2015 at 3:41 PM, Robert Paschedag
> > <robert.pasche...@web.de> wrote:
> >> So... finally... after long digging... I found my error.
> >>
> >> Situation:
> >>
> >> Nearly all clients stopped picking up tasks from spacewalk at the same 
> >> time.
> >>
> >> Problem was an error within the database because of a suddenly read only 
> >> filesystem. All problematic clients had an "open" task, that was in status 
> >> "picked up", but the client had nothing to return anymore.
> >>
> >> And all the "new" tasks had not been picked up, because within the handler 
> >> "queue.get", the handler returns without doing anything if there is still 
> >> an "open" task for the client.
> >>
> >> So the solution was to change the status of the "open" task within the 
> >> database.
> >>
> >> I put all tasks to "fail" (status code 3) with
> >>
> >> "update rhnServerActions set status = 3, completed_time = 
> >> CURRENT_TIMESTAMP where status = 1;"
> >>
> >> Database is PostgreSQL
> >>
> >> After that, all clients picked up the "remaining" tasks and the server 
> >> nearly broke down ;-)
> >>
> >> Regards
> >> Robert
> >> Am 08.12.2015 10:23 schrieb paschedag.netlut...@swr.de:
> >>>
> >>> Hi everyone,
> >>>
> >>> I just noticed, that several of my clients are not picking up remote 
> >>> commands from the server. Although all "remote commands" are allowed on 
> >>> the client, scheduling a task stays in "pending" state forever.
> >>>
> >>> On the client, nothing gets logged anymore. It looks, like the client 
> >>> does not "find" anything to do in its queue on the server. When I debug 
> >>> the "rhn_check" command, this code here fails
> >>>
> >>> action = self.server.queue.get(up2dateAuth.getSystemId(),
> >>>  94 ACTION_VERSION, status_report)
> >>>  95
> >>>  96 return action
> >>>
> >>> "action" is emtpy every time now.
> >>>
> >>> Any help will be appreciated.
> >>>
> >>> Regards,
> >>> Robert
> >>>
> >>>
> >>> Mit freundlichen Grüßen
> >>>
> >>> Robert Paschedag
> >>> Netlution GmbH
> >>> Landteilstr. 33
> >>> 68163 Mannheim
> >>>
> >>> im Auftrag des
> >>> SWR
> >>> Südwestrundfunk
> >>> Informations- und Kommunikationssysteme
> >>> Neckarstraße 230
> >>> 70190 Stuttgart
> >>>
> >>> Telefon +49 (0)711 /929-12654 oder
> >>> Telefon +49 (0)711 /929-13714
> >>> paschedag.netlut...@swr.de
> >>>
> >>> swr.de
> >>>
> >>
> >> ___
> >> Spacewalk-list mailing list
> >> Spacewalk-list@redhat.com
> >> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

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

[Spacewalk-list] Fwd: Aw: Re: Install new package to ubuntu client

[Robert Paschedag]

Again... List not in cc. :-(
-- Weitergeleitete Nachricht --Von: Robert Paschedag <robert.pasche...@web.de>Datum: 07.12.2015 12:02 nachm.Betreff: Aw: Re: [Spacewalk-list] Install new package to ubuntu clientAn: Tevfik Ceydeliler <tevfik.ceydeli...@astron.yasar.com.tr>Cc: I think, I fix won't come that soon :-(

 

To work around, I did

 

1. deactivate the schedule for the main channel (we use debian)

 

2. Go to /var/cache/rhn/repodata/

 

There are 2 files: Packages and Packages.gz

 

Edit Packages and add the header

 

Multi-Arch: allowed

 

to the package section "Package: python", "Package: python2.7" and "Package: python3"

 

Example:

 

...

 

Package: python
Version: 2.7.9-1
Architecture: amd64
Maintainer: Matthias Klose <doko@debian.org>
Installed-Size: 680
Provides: python-ctypes, python-email, python-importlib, python-profiler, python-wsgiref
Depends: python2.7 (>= 2.7.9-1~), libpython-stdlib (=2.7.9-1)
Conflicts: python-central (<< 0.5.5)
Replaces: python-dev (<< 2.6.5-2)
Suggests: python-doc (= 2.7.9-1), python-tk (>=2.7.9-1~)
Pre-Depends: python-minimal (= 2.7.9-1)
Breaks: update-manager-core (<< 0.200.5-2)
Multi-Arch: allowed
Filename: XMLRPC/GET-REQ/jessie_main/getPackage/python-2.7.9-1.amd64-deb.deb
Size: 151042

 


...

 

3. Recreate the zipped version with

 

gzip -c Packages > Packages.gz

 

4. Go to you clients and "apt-get update". You maybe have to clean the old lists before on the client

 

For me, this works pretty wellright now.

 

Regards,

Robert

 


Gesendet: Montag, 07. Dezember 2015 um 07:12 Uhr
Von: "Tevfik Ceydeliler" <tevfik.ceydeliler@astron.yasar.com.tr>
An: "Robert Paschedag" <robert.paschedag@web.de>
Betreff: Re: [Spacewalk-list] Install new package to ubuntu client


I need description step by step :(
or waiting fix.
regards..
 
On 12/04/2015 06:12 PM, Robert Paschedag wrote:


For me right now... because the Python packages are in the unchanging main channel. I deactivated the sync schedule for that channel and added the missing header myself.

Regards
Robert

Am 04.12.2015 4:21 nachm. schrieb Tevfik Ceydeliler <tevfik.ceydeliler@astron.yasar.com.tr>:



ANy action or workaround about this issue?

On 12/04/2015 02:06 PM, Robert Paschedag wrote:



Look's like this..



https://bugzilla.redhat.com/show_bug.cgi?id=1243387



Regard

Robert

Am 04.12.2015 12:40 schrieb Tevfik Ceydeliler <tevfik.ceydeliler@astron.yasar.com.tr>:




Hi,

I have ubuntu 14.04 client and need to install some packages.

When I try to install package I get some errors:

###

root@spaceclient:/# apt-get update

Apt-Spacewalk: Updating sources.list

Ign spacewalk://spacewalk.yasar.net channels: InRelease

Ign spacewalk://spacewalk.yasar.net channels: Release.gpg

Ign spacewalk://spacewalk.yasar.net channels: Release

Ign spacewalk://spacewalk.yasar.net channels:/main amd64 Packages/DiffIndex

Ign spacewalk://spacewalk.yasar.net channels:/main i386 Packages/DiffIndex

Get:1 spacewalk://spacewalk.yasar.net channels:/main amd64 Packages [2.022 kB]

Get:2 spacewalk://spacewalk.yasar.net channels:/main i386 Packages [2.022 kB]

Ign spacewalk://spacewalk.yasar.net channels:/main Translation-en_US

Ign spacewalk://spacewalk.yasar.net channels:/main Translation-en

Fetched 4.044 kB in 1s (3.819 kB/s)

Reading package lists... Done

root@spaceclient:/# 

root@spaceclient:/# 

root@spaceclient:/# 

root@spaceclient:/#

root@spaceclient:/# apt-get install mysql-client

Reading package lists... Done

Building dependency tree   

Reading state information... Done

You might want to run 'apt-get -f install' to correct these:

The following packages have unmet dependencies:

 apt-xapian-index : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not installable

 dh-python : Depends: python3:any (>= 3.3.2-2~) but it is not installable

 landscape-common : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not installable

 language-selector-common : Depends: python3:any (>= 3.3.2-2~) but it is not installable

 lsb-release : Depends: python3:any (>= 3.3.2-2~) but it is not installable

 mysql-client : Depends: mysql-client-5.5 but it is not going to be installed

 python-apt : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not installable

 python-chardet : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not installable

 python-configobj : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not installable

 python-dbus : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not installable

 python-

Re: [Spacewalk-list] Install new package to ubuntu client

[Robert Paschedag]

Look's like this..

https://bugzilla.redhat.com/show_bug.cgi?id=1243387

Regard
Robert
Am 04.12.2015 12:40 schrieb Tevfik Ceydeliler 
:
>
> Hi,
> I have ubuntu 14.04 client and need to install some packages.
> When I try to install package I get some errors:
> ###
> root@spaceclient:/# apt-get update
> Apt-Spacewalk: Updating sources.list
> Ign spacewalk://spacewalk.yasar.net channels: InRelease
> Ign spacewalk://spacewalk.yasar.net channels: Release.gpg
> Ign spacewalk://spacewalk.yasar.net channels: Release
> Ign spacewalk://spacewalk.yasar.net channels:/main amd64 Packages/DiffIndex
> Ign spacewalk://spacewalk.yasar.net channels:/main i386 Packages/DiffIndex
> Get:1 spacewalk://spacewalk.yasar.net channels:/main amd64 Packages [2.022 kB]
> Get:2 spacewalk://spacewalk.yasar.net channels:/main i386 Packages [2.022 kB]
> Ign spacewalk://spacewalk.yasar.net channels:/main Translation-en_US
> Ign spacewalk://spacewalk.yasar.net channels:/main Translation-en
> Fetched 4.044 kB in 1s (3.819 kB/s)
> Reading package lists... Done
> root@spaceclient:/# 
> root@spaceclient:/# 
> root@spaceclient:/# 
> root@spaceclient:/#
> root@spaceclient:/# apt-get install mysql-client
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> You might want to run 'apt-get -f install' to correct these:
> The following packages have unmet dependencies:
>  apt-xapian-index : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  dh-python : Depends: python3:any (>= 3.3.2-2~) but it is not installable
>  landscape-common : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  language-selector-common : Depends: python3:any (>= 3.3.2-2~) but it is not 
> installable
>  lsb-release : Depends: python3:any (>= 3.3.2-2~) but it is not installable
>  mysql-client : Depends: mysql-client-5.5 but it is not going to be installed
>  python-apt : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-chardet : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-configobj : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-dbus : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-debian : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-gi : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not installable
>  python-gobject-2 : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-libxml2 : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-newt : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-openssl : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-pkg-resources : Depends: python:any (>= 2.7) but it is not installable
>     Depends: python:any (< 2.8) but it is not installable
>  python-requests : Depends: python:any (< 2.8) but it is not installable
>    Depends: python:any (>= 2.7.5-5~) but it is not installable
>  python-serial : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-six : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-twisted-core : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-urllib3 : Depends: python:any (>= 2.7.5-5~) but it is not installable
>   Depends: python:any (< 2.8) but it is not installable
>  python-xapian : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
> installable
>  python-zope.interface : Depends: python:any (>= 2.7.1-0ubuntu2) but it is 
> not installable
>  python3-apport : Depends: python3:any (>= 3.3.2-2~) but it is not installable
>  python3-commandnotfound : Depends: python3:any (>= 3.3.2-2~) but it is not 
> installable
>  python3-distupgrade : Depends: python3:any (>= 3.3.2-2~) but it is not 
> installable
>  python3-problem-report : Depends: python3:any (>= 3.3.2-2~) but it is not 
> installable
>  python3-software-properties : Depends: python3:any (>= 3.3.2-2~) but it is 
> not installable
>  python3-update-manager : Depends: python3:any (>= 3.3.2-2~) but it is not 
> installable
>  software-properties-common : Depends: python3:any (>= 3.3.2-2~) but it is 
> not installable
>  ubuntu-release-upgrader-core : Depends: python3:any (>= 3.2~) but it is not 
> installable
>  ufw : Depends: python3:any (>= 3.3.2-2~) but it is not installable
>  update-manager-core : Depends: python3:any (>= 3.2~) but it is not 
> installable
>  update-notifier-common : Depends: python3:any but it is not installable
> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify 
> a solution).
> 

[Spacewalk-list] Fwd: Re: Install new package to ubuntu client

[Robert Paschedag]

Forgot the list...-- Weitergeleitete Nachricht --
Von: Robert Paschedag <robert.pasche...@web.de>
Datum: 04.12.2015 5:12 nachm.
Betreff: Re: [Spacewalk-list] Install new package to ubuntu client
An: Tevfik Ceydeliler <tevfik.ceydeli...@astron.yasar.com.tr>
Cc: 

> For me right now... because the Python packages are in the unchanging main 
> channel. I deactivated the sync schedule for that channel and added the 
> missing header myself.
>
> Regards
> Robert
>
> Am 04.12.2015 4:21 nachm. schrieb Tevfik Ceydeliler 
> <tevfik.ceydeli...@astron.yasar.com.tr>:
>>
>> ANy action or workaround about this issue?
>>
>> On 12/04/2015 02:06 PM, Robert Paschedag wrote:
>>>
>>> Look's like this..
>>>
>>>
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1243387
>>>
>>>
>>>
>>> Regard
>>>
>>> Robert
>>>
>>> Am 04.12.2015 12:40 schrieb Tevfik Ceydeliler 
>>> <tevfik.ceydeli...@astron.yasar.com.tr>:
>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I have ubuntu 14.04 client and need to install some packages.
>>>>
>>>> When I try to install package I get some errors:
>>>>
>>>> ###
>>>>
>>>> root@spaceclient:/# apt-get update
>>>>
>>>> Apt-Spacewalk: Updating sources.list
>>>>
>>>> Ign spacewalk://spacewalk.yasar.net channels: InRelease
>>>>
>>>> Ign spacewalk://spacewalk.yasar.net channels: Release.gpg
>>>>
>>>> Ign spacewalk://spacewalk.yasar.net channels: Release
>>>>
>>>> Ign spacewalk://spacewalk.yasar.net channels:/main amd64 Packages/DiffIndex
>>>>
>>>> Ign spacewalk://spacewalk.yasar.net channels:/main i386 Packages/DiffIndex
>>>>
>>>> Get:1 spacewalk://spacewalk.yasar.net channels:/main amd64 Packages [2.022 
>>>> kB]
>>>>
>>>> Get:2 spacewalk://spacewalk.yasar.net channels:/main i386 Packages [2.022 
>>>> kB]
>>>>
>>>> Ign spacewalk://spacewalk.yasar.net channels:/main Translation-en_US
>>>>
>>>> Ign spacewalk://spacewalk.yasar.net channels:/main Translation-en
>>>>
>>>> Fetched 4.044 kB in 1s (3.819 kB/s)
>>>>
>>>> Reading package lists... Done
>>>>
>>>> root@spaceclient:/# 
>>>>
>>>> root@spaceclient:/# 
>>>>
>>>> root@spaceclient:/# 
>>>>
>>>> root@spaceclient:/#
>>>>
>>>> root@spaceclient:/# apt-get install mysql-client
>>>>
>>>> Reading package lists... Done
>>>>
>>>> Building dependency tree   
>>>>
>>>> Reading state information... Done
>>>>
>>>> You might want to run 'apt-get -f install' to correct these:
>>>>
>>>> The following packages have unmet dependencies:
>>>>
>>>>  apt-xapian-index : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
>>>> installable
>>>>
>>>>  dh-python : Depends: python3:any (>= 3.3.2-2~) but it is not installable
>>>>
>>>>  landscape-common : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
>>>> installable
>>>>
>>>>  language-selector-common : Depends: python3:any (>= 3.3.2-2~) but it is 
>>>> not installable
>>>>
>>>>  lsb-release : Depends: python3:any (>= 3.3.2-2~) but it is not installable
>>>>
>>>>  mysql-client : Depends: mysql-client-5.5 but it is not going to be 
>>>> installed
>>>>
>>>>  python-apt : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
>>>> installable
>>>>
>>>>  python-chardet : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
>>>> installable
>>>>
>>>>  python-configobj : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
>>>> installable
>>>>
>>>>  python-dbus : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
>>>> installable
>>>>
>>>>  python-debian : Depends: python:any (>= 2.7.1-0ubuntu2) but it is not 
>>>> installable
>>>>
>>>>  python-gi : Depends: python:any (>= 2.7.1-0ubuntu2) but it 

Re: [Spacewalk-list] Delay in deploying configuration in a new 7.2 client

[Robert Paschedag]

Sounds like osad is not running and rhnsd is using its default refresh time of 
240 minutes.

Regards
Robert
Am 03.12.2015 9:51 vorm. schrieb Morgan Marodin :
>
> Hi everyone.
>
> I've installed a new linux physical client with RHEL like distribution, 
> version 7.2.
> I've configured it to use my Spacewalk installation, version 2.2.
>
> All is ok updating the system, but I'm having some delay problem deploying 
> configuration.
> For example I've scheduled an immediate deploy yesterday at 4:16 pm, but my 
> client had received it at 7:42 pm.
>
> Other clients do not have this problem.
> The only difference is that they are virtual systems, not physical ...
>
> Clocks are syncronized ... so what could be the problem?
>
> Please let me know, thanks.
> Morgan

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

Re: [Spacewalk-list] Upgrading SLES 11 SP3 to SP4 results in broken systemid-Files

[Robert Paschedag]

I'm pretty sure, I already tried to upgrade from SP3 to SP4 without a problem 
and I'm also pretty sure, that I was able to do further installations after 
that.

But that was on spacewalk 2.2. I'll test this tomorrow with my new spacewalk 
2.4 server.

Regards
Robert
Am 30.11.2015 1:08 nachm. schrieb "Lichtinger, Bernhard" 
:
>
> Hello, 
>
> Upgrading our SLES 11 SP3 Machines to SP4 we stumbled over an annoying bug: 
>
> We have spacewalk-2.3 on CentOS6 and our SLES clients use the client packages 
> from suse open build service. 
>
> To upgrade a Machine, we change in SW the base-channel and child-channels 
> from SP3 to SP4, then run "zypper up zypper; zypper dup", which works fine. 
> But then the next time we call zypper or rhn_check or some other tool, which 
> talks to the SW-Server it fails to do so, because the client certificate is 
> wrong. 
>
> What happens: 
> Everytime the rhn-client-tools talk to the SW server the function 
> "maybeUpdateVersion" in up2date_client/up2dateAuth.py checks if the system's 
> os-release is newer than the os-releas which is recorded in the client 
> certificate (/etc/sysconfig/rhn/systemid). 
> On SLES os-release changes with every service pack. Therefore 
> "maybeUpdateVersion" requests a new certificate from the SW server. 
> The old systemid-File is copied to systemid.save and the new certificate is 
> stored as systemid. 
> But now the client tries to use this new certificate, but it does not work, 
> because the checksum within the certificate does not match the checksum the 
> SW server is expecting: 
>
> rhn_server_xmlrpc.log: 
> 2015/11/27 15:29:43 +02:00 27113 CLIENT_IP: 
> xmlrpc/up2date.listChannels(110119,) 
> 2015/11/27 15:29:44 +02:00 21394 CLIENT_IP: 
> xmlrpc/up2date.listChannels(110119,) 
> 2015/11/27 15:29:44 +02:00 21413 CLIENT_IP: 
> xmlrpc/registration.upgrade_version(110119, '11.4') 
> 2015/11/27 15:29:44 +02:00 21387 CLIENT_IP: xmlrpc/up2date.login(110119,) 
> 2015/11/27 15:29:44 +02:00 21411 CLIENT_IP: 
> rhnServer/server_certificate.__validate_checksum('ERROR', 'Checksum check 
> failed: 47401415cf887beab0e590ad07fbb6ae != 
> 6abe16dcad7c7fe65b75a053cfade1de905832d74f0342d3f8132c41a25f63cc' [...] 
>
> On the client a diff between old and new certificate shows: 
> diff systemid.old systemid.new 
> 22c22 
> < 3902bcae3cabf243bd50afb108ee58a0 
> --- 
> > 6abe16dcad7c7fe65b75a053cfade1de905832d74f0342d3f8132c41a25f63cc
> >  
> 34c34 
> < x86_64 
> --- 
> > x86_64-redhat-linux 
> 38c38 
> < 11.3 
> --- 
> > 11.4 
>
> The strange thing is, the server expects neither the old checksum nor the new 
> checksum. 
>
> When I revert the client certificate to the old version, it starts over 
> again: For one time e.g. a "zypper lr" works, and then the client requests 
> again a new certificate and it is broken again. 
>
> My workaround is to generate a reactivationkey after the SP upgrade and to 
> reregister the client machine with it. (rhnreg_ks --force 
> --activationkey=...) 
>
> I suspect there is a bug on the server side: 
> One hint is the fact, that the server still expects a md5 checksum instead of 
> a sha-256 checksum. 
> And I think it must be in the area of migrating from md5 to sha256 checksums, 
> called by "spacewalk/backend/server/handlers/xmlrpc/registration.py": 
> upgrade_version() 
> Before the introduction of sha256 checksums it worked. I found an older SLES 
> client, which was upgraded from 11.2 to 11.3 in Q3/2013, here everything was 
> still working well (everything with md5): 
> diff systemid systemid.save 
> 22c22 
> < 513e830b5aa37f50d0f1c3fdc6312415 
> --- 
> > 6c4bebef36330a62466c00bcaf994be7 
> 34c34 
> < x86_64-redhat-linux 
> --- 
> > x86_64 
> 38c38 
> < 11.3 
> --- 
> > 11.2 
>
>
> Regards, 
> Bernhard
> ___ 
> 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