Re: [Spacewalk-list] Deploy a root password change

[Andy Ingham]

My suggestion would be *ansible*Š

>From a post I sent back in April, the following has worked quite well for
us:


Changing root passwords across the plant via ansible:

Create a pseudo-random salt to use for the password hashing:
 [root@HOSTXYZ ~]# python
 >>> import os
 >>> os.urandom(32).encode('base_64')
 '+Ks4YQAwuHLotW6PX/+9Tzf0B8HQmF43Kr/NpLcyJDE=\n'

The output of the step above provides the INPUT for the next set of
commands (see right AFTER "$1$" below)
Create a hash of the new password using python's crypt function (see
also 
http://mjanja.co.ke/2013/01/generate-salted-shadow-hashes-using-python-crypt
/ ).  E.g.:
 >>> import crypt
 >>> 
crypt.crypt("mysupertoughpassword",'$1$+Ks4YQAwuHLotW6PX/+9Tzf0B8HQmF43Kr/N
pLcyJDE=\n')
 '$1$+Ks4YQAw$l0aKYjp7tZinnU25B.KfN0'
 >>> quit()

The output of the step above allows for the needed INPUT to ansible
below:
 ansible HOSTS_LISTED_HERE -m user -a 'name=root
password=$1$+Ks4YQAw$l0aKYjp7tZinnU25B.KfN0' -K --sudo


From:   on behalf of J Epperson

Reply-To:  "Spacewalk-list@redhat.com" 
Date:  Tuesday, August 25, 2015 at 8:57 PM
To:  "Spacewalk-list@redhat.com" 
Subject:  Re: [Spacewalk-list] Deploy a root password change

I've always done this with "usermod -p", using the crypted password string.
But that's probably not actually any more secure than echoing to "passwd
--stdin".

 

 
On 2015-08-25 16:50, Steve Meier wrote:
> Hello,
> 
> using sed on your /etc/shadow is a very harsh way to do it. On Red Hat
> the passwd command supports the --stdin parameter which is much cleaner
> 
> echo supersecret | passwd --stdin root
> 
> Run this as a remote action and you are good.
> 
> Alternatively, you can create a dummy RPM where this is a %post action
> and deploy this RPM. This should work as well and the version of that
> dummy RPM will actually give you a hint on which of your rotated
> passwords
> it is.
> 
> Kind regards,
>Steve
> 
> Am 2015-08-25 22:24, schrieb Justin Edmands:
>> You change the root pw on one machine, grab the /etc/shadow entry, and sed
>> replace the root line in the shadow file into a remote command to whatever
>> systems you need to change.
>>> On Aug 25, 2015, at 4:13 PM, Franky Van Liedekerke 
>>> wrote: On Tue, 25 Aug 2015 19:45:06 + "Armstrong, Kenneth Lawrence
>>> (SYSADMIN)"  wrote:
 Is there a way to deploy a root password change to a group of servers in
 Satellite 5.6? I imagine something like this might be possible in Satellite
 6.x, but we don¹t have that deployed yet.
>>> Since spacewalk only has the root-pwd there for kickstart I don't think that
>>> is possible. I don't know if this helps, but: loop through your servers, do
>>> sudo and: echo "root:newpass"|chpasswd I know, it is not the config-method
>>> you're looking for (puppet, ansible), but sometimes the simplest things are
>>> sufficient too ... Franky ___
>>> 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.comhttps://www.redhat.com/mailman/listinfo/spacewalk-lis>
t




smime.p7s
Description: S/MIME cryptographic signature
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] FW: Why am I seeing THIS: "Running external rewrite maps without defining a RewriteLock is DANGEROUS!"

[Andy Ingham]

I don't recall seeing any responses to this question.  Anyone have any
insights / information?

TIA,
Andy

From:  Andy Ingham 
Reply-To:  "spacewalk-list@redhat.com" 
Date:  Thursday, February 19, 2015 at 5:08 PM
To:  "spacewalk-list@redhat.com" 
Subject:  [Spacewalk-list] Why am I seeing THIS: "Running external rewrite
maps without defining a RewriteLock is DANGEROUS!"

Every time apache restarts on my spacewalk server (SW 2.2).

E.g.

[Sun Feb 15 03:34:34 2015] [warn] mod_rewrite: Running external rewrite maps
without defining a RewriteLock is DANGEROUS!


Is this something specific to how I've tweaked http (although I don't recall
doing so!) or is this something everyone sees?

If the former, is there a quick fix?

If the latter, should we all be concerned?

;)

Andy






smime.p7s
Description: S/MIME cryptographic signature
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Config management questions

[Andy Ingham]

Will --

Your use cases seem similar to what we've implemented here.  That is, the
versioning isn't as full-featured as something like git, but serves the
purpose well of validating that key files haven't changed across the plant
(I've got a daily script that leverages the spacewalk API to flag the
files that are no longer in spec.)

You are also correct that it isn't close to the power of puppet, but
certainly is much lighter-weight and quicker to deploy (again, for a
specific use-case).

On the subject of root passwords:  is it important to your organization to
have DIFFERENT root passwords for each of your servers?  (Yes, I'm
serious!)  If you disallow remote root login (which you should!), and
leverage "sudo" for elevating privileges (with users' using their OWN
password), the root passwords are never really used / exposed.  In such a
case, it's much easier to manage if they are all the same.

(Which leads me back to ansible...)  If having them the same makes you (or
your bosses) insist on CHANGING those passwords more frequently, I'd
suggest using ansible to do so.  It's worked GREAT for us here.  (It's a
fast enough process that you could change your root passwords once a
MONTH, if that's what would make folks happy.)

Changing root passwords across the plant via ansible:

Create a pseudo-random salt to use for the password hashing:
 [root@HOSTXYZ ~]# python
 >>> import os
 >>> os.urandom(32).encode('base_64')
 '+Ks4YQAwuHLotW6PX/+9Tzf0B8HQmF43Kr/NpLcyJDE=\n'

The output of the step above provides the INPUT for the next set of
commands (see right AFTER "$1$" below)
 
Create a hash of the new password using python's crypt function (see
also 
http://mjanja.co.ke/2013/01/generate-salted-shadow-hashes-using-python-cryp
t/ ).  E.g.:
 >>> import crypt
 >>> 
crypt.crypt("mysupertoughpassword",'$1$+Ks4YQAwuHLotW6PX/+9Tzf0B8HQmF43Kr/N
pLcyJDE=\n')
 '$1$+Ks4YQAw$l0aKYjp7tZinnU25B.KfN0'
 >>> quit()

The output of the step above allows for the needed INPUT to ansible
below:
 ansible HOSTS_LISTED_HERE -m user -a 'name=root
password=$1$+Ks4YQAw$l0aKYjp7tZinnU25B.KfN0' -K --sudo



Just some thoughts...


Andy

On 4/27/15, 12:02 PM, "Will Beldman"  wrote:

I'm trying to do a better job in my organization managing changes to
configuration files.

Most of our authentication and authorization I'd like to defer to LDAP so
I 
figured monitoring some local user management config files would be a good
start (eg. /etc/passwd, /etc/shadow, /etc/group). My idea was that if a
sysadmin tried to add a local user, Spacewalk could alert me to the change
because it would no longer match my centrally manged files.

However, I've already realized that I have a problem with my /etc/shadow
file 
because the hash associated with the root password will obviously be
different 
for every machine so I cannot manage it centrally.

I tried to use macros like so:
=
root:{| rhn.system.custom_info(root_hash) |}::0:9:7:::
...
=
and this works but I've realized that this means I am loading the root
password hash onto every system as a custom info value which is probably
not a 
good idea security-wise. If my Spacewalk server were compromised, the
/etc/shadow file for every system is also compromised.

Is there any ability to do things like ignore certain lines or put in
regex 
wildcards so I can just say "put whatever you want in here"? Or is there a
feature request for this?


Also, can I get some idea, philosophically, on how to leverage config
management in Spacewalk to it's potential. I think I really need to put up
a 
config management server (Puppet/Chef/etc) to do what I really want, but
in 
the interim, I was hoping to get some ideas on common uses for config
management in Spacewalk.

___
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] Yum client reports no update, But Spacewalk GUI reports that there are

[Andy Ingham]

Due to these sorts of nagging issues (especially when they proliferate across 
SCORES of servers), I finally set up a standard daily cron task (pushed out via 
the SW configuration management!) that does these actions daily on all clients:

/usr/bin/yum clean all
/usr/bin/yum makecache
/usr/sbin/rhn-profile-sync
/sbin/service osad restart

I find it handy to run that script "by hand" at times also.  A sledgehammer 
approach, perhaps, but one with very little downside AFAIK.

I'd say that that has eliminated 90% of the nagging one-off problems with 
connectivity (osad) and failed updates.

FWIW.

If you have root privileges to the spacewalk SERVER (which you presumably do), 
you may find that recreating the repodata for the affected channel may help.

cd /var/cache/rhn/repodata/
remove the affected channel's directory tree
then run (in spacecmd) the "softwarechannel_regenerateyumcache" command against 
that channel
new repodata should then shortly re-appear
(At which point, I've found that I may need to run the cron script (above) by 
hand on the client.)

Andy

Andy Ingham, MS, CISSP
IT Infrastructure
Fuqua School of Business
Duke University


From: , Robert 
mailto:robert.b...@peoplefluent.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Friday, April 17, 2015 at 1:03 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] Yum client reports no update, But Spacewalk GUI 
reports that there are

This problem continues.  The master clearly sees that a number of packages need 
updating.  For some reason on the client these packages are not being seen.  I 
attempted scheduling updates from Spacewalk GUI.  Then ran rhn_check on the 
client.   Then I see this result on the master:

Summary:

Package Install scheduled by 

Details:

This action will be executed after 04/17/15 12:58:53 PM EDT.

This action's status is: Failed.
The client picked up this action on 04/17/15 12:59:09 PM EDT.
The client completed this action on 04/17/15 12:59:15 PM EDT.
Client execution returned "Error while executing packages action: empty 
transaction [[6]]" (code -1)
Packages Scheduled:
· xorg-x11-server-common-1.15.0-26.el6_6
· libipa_hbac-python-1.11.6-30.el6_6.4
· cyrus-sasl-2.1.23-15.el6_6.2
· scl-utils-20120927-27.el6_6
· kernel-2.6.32-504.12.2.el6
· sssd-1.11.6-30.el6_6.4
· dhcp-common-4.1.1-43.P1.el6_6.1:12
· busybox-1.15.1-21.el6_6:1
· nss-softokn-freebl-3.14.3-22.el6_6
· tzdata-2015b-1.el6
· kpartx-0.4.9-80.el6_6.3
· openssl-1.0.1e-30.el6_6.8
· samba-winbind-3.6.23-14.el6_6:0
· samba-winbind-clients-3.6.23-14.el6_6:0
· ntp-4.2.6p5-3.el6_6
· krb5-libs-1.10.3-37.el6_6
· sssd-krb5-common-1.11.6-30.el6_6.4
· perf-2.6.32-504.12.2.el6
· flac-1.2.1-7.el6_6
· krb5-workstation-1.10.3-37.el6_6
· freetype-2.3.11-15.el6_6.1
· cyrus-sasl-lib-2.1.23-15.el6_6.2
· unzip-6.0-2.el6_6
· dhclient-4.1.1-43.P1.el6_6.1:12
· augeas-libs-1.0.0-7.el6_6.1
· samba4-libs-4.0.0-66.el6_6.rc4:0
· samba-common-3.6.23-14.el6_6:0
· tzdata-java-2015b-1.el6
· sssd-client-1.11.6-30.el6_6.4
· dracut-004-356.el6_6.1
· curl-7.19.7-40.el6_6.4
· cyrus-sasl-plain-2.1.23-15.el6_6.2
· libsss_idmap-1.11.6-30.el6_6.4
· libcurl-7.19.7-40.el6_6.4
· sssd-proxy-1.11.6-30.el6_6.4
· libipa_hbac-1.11.6-30.el6_6.4
· openssl-devel-1.0.1e-30.el6_6.8
· krb5-devel-1.10.3-37.el6_6
· libssh2-1.4.2-1.el6_6.1
· nss-softokn-3.14.3-22.el6_6
· sssd-common-1.11.6-30.el6_6.4
· python-sssdconfig-1.11.6-30.el6_6.4
· shadow-utils-4.1.4.2-19.el6_6.1:2
· sssd-ipa-1.11.6-30.el6_6.4
· xorg-x11-server-Xorg-1.15.0-26.el6_6
· alsa-utils-1.0.22-9.el6_6
· sssd-krb5-1.11.6-30.el6_6.4
· kexec-tools-2.0.0-280.el6_6.2
· ruby-1.8.7.374-4.el6_6
· kernel-headers-2.6.32-504.12.2.el6
· sssd-ad-1.11.6-30.el6_6.4
· kernel-firmware-2.6.32-504.12.2.el6
· gdbm-1.8.0-38.el6
· openjpeg-libs-1.3-11.el6
· gdbm-devel-1.8.0-38.el6
· tcsh-6.17-25.el6_6
· sssd-ldap-1.11.6-30.el6_6.4
· dracut-kernel-004-356.el6_6.1
· nss-softokn-freebl-3.14.3-22.el6_6
· ruby-libs-1.8.7.374-4.el6_6
· cyrus-sasl-gssapi-2.1.23-15.el6_6.2
· sssd-common-pac-1.11.6-30.el6_6.4

Time:

04/17/15 12:58:53 PM EDT


Reschedule:

This history event was caused by a failed scheduled action.
If you have corrected the problem, you may reschedule the action b



Robert Boyd
Sr. Systems Eng

[Spacewalk-list] Why am I seeing THIS: "Running external rewrite maps without defining a RewriteLock is DANGEROUS!"

[Andy Ingham]

Every time apache restarts on my spacewalk server (SW 2.2).

E.g.

[Sun Feb 15 03:34:34 2015] [warn] mod_rewrite: Running external rewrite maps 
without defining a RewriteLock is DANGEROUS!


Is this something specific to how I've tweaked http (although I don't recall 
doing so!) or is this something everyone sees?

If the former, is there a quick fix?

If the latter, should we all be concerned?

;)

Andy


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

Re: [Spacewalk-list] list of systems by uptime?

[Andy Ingham]

I shouldn't say the output is "ordered".  The difference is simply in which set 
of values is at the beginning of each output line (which makes it easy to 
re-order within your favorite text editor).

Andy

From: Andy Ingham mailto:andy.ing...@duke.edu>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Wednesday, February 4, 2015 at 8:38 AM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] list of systems by uptime?

Matthew --

I've been using the following python script to output last reboots across my 
plant, ordered either by running kernel version OR by last boot time (toggled 
by commenting/uncommenting near the end of the script).  Note that it pulls 
login credentials from a separate file named "creds.py"

Is this helpful?

Andy




#!/usr/bin/python


from __future__ import print_function

import xmlrpclib

import re

import datetime

from datetime import date

from datetime import timedelta

import os

import smtplib

from email.mime.text import MIMEText

from creds import SATELLITE_LOGIN, SATELLITE_PASSWORD


SATELLITE_URL = "https://[YOUR_FQDN_HERE]/rpc/api";


client = xmlrpclib.Server(SATELLITE_URL, verbose=0)


key = client.auth.login(SATELLITE_LOGIN, SATELLITE_PASSWORD)


today = date.today()

yesterday = today - timedelta(days=1)


list = client.system.list_systems(key)

for system in list:

lastboot = client.system.get_details(key,system.get('id'))

currKern = 
client.system.get_running_kernel(key,system.get('id'))

matchObj = re.search(".*\'last_boot\'\: \mailto:mrine...@apptio.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Tuesday, February 3, 2015 at 4:46 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: [Spacewalk-list] list of systems by uptime?

Is there a way to get the uptime or last reboot time of a system, or all 
systems through the API?

I saw via google this was discussed before on the list but I couldn't not find 
a definitive answer if it was ever implemented.

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

Re: [Spacewalk-list] list of systems by uptime?

[Andy Ingham]

Matthew --

I've been using the following python script to output last reboots across my 
plant, ordered either by running kernel version OR by last boot time (toggled 
by commenting/uncommenting near the end of the script).  Note that it pulls 
login credentials from a separate file named "creds.py"

Is this helpful?

Andy




#!/usr/bin/python


from __future__ import print_function

import xmlrpclib

import re

import datetime

from datetime import date

from datetime import timedelta

import os

import smtplib

from email.mime.text import MIMEText

from creds import SATELLITE_LOGIN, SATELLITE_PASSWORD


SATELLITE_URL = "https://[YOUR_FQDN_HERE]/rpc/api";


client = xmlrpclib.Server(SATELLITE_URL, verbose=0)


key = client.auth.login(SATELLITE_LOGIN, SATELLITE_PASSWORD)


today = date.today()

yesterday = today - timedelta(days=1)


list = client.system.list_systems(key)

for system in list:

lastboot = client.system.get_details(key,system.get('id'))

currKern = 
client.system.get_running_kernel(key,system.get('id'))

matchObj = re.search(".*\'last_boot\'\: \mailto:mrine...@apptio.com>>
Reply-To: "spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Date: Tuesday, February 3, 2015 at 4:46 PM
To: "spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Subject: [Spacewalk-list] list of systems by uptime?

Is there a way to get the uptime or last reboot time of a system, or all 
systems through the API?

I saw via google this was discussed before on the list but I couldn't not find 
a definitive answer if it was ever implemented.

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

Re: [Spacewalk-list] Interesting OSAD Problem

[Andy Ingham]

To close the circle, so to speak, be aware that selinux-policy-3.7.19-260 fixes 
this issue.

Once you've got that package updated, then, don't forget to go back and REMOVE 
the previously implemented workaround.

Do so with: semanage permissive -d osad_t

Verify via: semanage permissive -l

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

Andy

From: Andy Ingham mailto:andy.ing...@duke.edu>>
Date: Tuesday, December 2, 2014 at 1:56 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] Interesting OSAD Problem

Jon --

This topic came up about a month ago.

The quick and dirty workaround until this gets fixed:

semanage permissive -a osad_t

The background is at:  http://osdir.com/ml/spacewalk-list/2014-11/msg00090.html

Andy


From: , Jonathan - 0443 - MITLL 
mailto:jrgle...@ll.mit.edu>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Tuesday, December 2, 2014 at 1:39 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] Interesting OSAD Problem

Actually it's somewhat a permissions problem Disabling selinux and 
restarting now lets the service start correctly.  Looks like I need to 
investigate what selinux is unhappy about.

From:spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-boun...@redhat.com>
 [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Glennie, Jonathan - 
0443 - MITLL
Sent: Tuesday, December 02, 2014 1:28 PM
To: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
Subject: [Spacewalk-list] Interesting OSAD Problem

Hello All-

I'm having an interesting osad problem... osa-dispatcher starts fine on the 
server, but from a client, attempting to do a "service osad start" generates 
the "Unable to connect to jabber servers" log messages.  However, if I manually 
launch osad from the command line, either by running "osad _N -v -v -v -v" or 
simply typing "osad", everything launches just fine... I see the connection on 
the server side and I can successfully ping/push commands to it from the GUI.

What could be causing he difference in behavior?  I've checked and no matter 
what way the service is launched, it runs as root so I wouldn't think it's a 
permissions issue... Thanks for any help.

-Jon

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

Re: [Spacewalk-list] Interesting OSAD Problem

[Andy Ingham]

Jon --

This topic came up about a month ago.

The quick and dirty workaround until this gets fixed:

semanage permissive -a osad_t

The background is at:  http://osdir.com/ml/spacewalk-list/2014-11/msg00090.html

Andy


From: , Jonathan - 0443 - MITLL 
mailto:jrgle...@ll.mit.edu>>
Reply-To: "spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Date: Tuesday, December 2, 2014 at 1:39 PM
To: "spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] Interesting OSAD Problem

Actually it's somewhat a permissions problem Disabling selinux and 
restarting now lets the service start correctly.  Looks like I need to 
investigate what selinux is unhappy about.

From: 
spacewalk-list-boun...@redhat.com 
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Glennie, Jonathan - 
0443 - MITLL
Sent: Tuesday, December 02, 2014 1:28 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Interesting OSAD Problem

Hello All-

I'm having an interesting osad problem... osa-dispatcher starts fine on the 
server, but from a client, attempting to do a "service osad start" generates 
the "Unable to connect to jabber servers" log messages.  However, if I manually 
launch osad from the command line, either by running "osad _N -v -v -v -v" or 
simply typing "osad", everything launches just fine... I see the connection on 
the server side and I can successfully ping/push commands to it from the GUI.

What could be causing he difference in behavior?  I've checked and no matter 
what way the service is launched, it runs as root so I wouldn't think it's a 
permissions issue... Thanks for any help.

-Jon

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

Re: [Spacewalk-list] CentOS 6.6 upgrade breaks osad on SW 2.1 clients that have SELinux in enforcing mode

[Andy Ingham]

Scratch that last post.  :)

I think I'm mistaken, and the setting WILL persist across reboots ...

Andy

From: Andy Ingham mailto:andy.ing...@duke.edu>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Thursday, November 13, 2014 at 1:38 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] CentOS 6.6 upgrade breaks osad on SW 2.1 clients 
that have SELinux in enforcing mode

This is a fine workaround EXCEPT be aware that it does NOT persist across 
reboots.

That is, you'll have to re-run the command after every reboot.  (I'm hoping 
someone can indicate that I'm wrong on this, but I don't see a "persistent" 
option for that command).

Andy

From: ndegz mailto:nnd...@gmail.com>>
Reply-To: "nndegz+l...@gmail.com<mailto:nndegz+l...@gmail.com>" 
mailto:nndegz+l...@gmail.com>>, 
"spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Friday, November 7, 2014 at 3:18 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] CentOS 6.6 upgrade breaks osad on SW 2.1 clients 
that have SELinux in enforcing mode

Ran into the same issue and found this blog post
Short tip: osad: Unable to connect to the host and port specified (EL6.6 + 
EL7)<http://blog.christian-stankowic.de/?p=6341&lang=en>

semanage permissive -a osad_t




On Thu, Nov 6, 2014 at 12:59 PM, Kevin Sandy 
mailto:ke...@digitallotus.com>> wrote:
I've been seeing this as well.  Clients are on CentOS 6.6 with Spacewalk 2.2.  
I've had to put SELinux in permissive mode for now.


-- kevin



On Nov 6, 2014, at 12:48 PM, Andy Ingham 
mailto:andy.ing...@duke.edu>> wrote:

Ever since updating from CentOS 6.5 > 6.6, my servers (which are all at
spacewalk client version 2.1) are showing:


+
SELinux is preventing /usr/bin/python from name_connect access on the
tcp_socket .

*  Plugin catchall (100. confidence) suggests
***

If you believe that python should be allowed name_connect access on the
tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep osad /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
+





And FWIW, attempting to mitigate by adding a local policy (as the above
notice instructs) ALSO FAILS:

[root@HOSTNAME local_policy]# semodule -i osad.pp
libsepol.print_missing_requirements: osad's global requirements were not
met: type/attribute osad_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or
directory).
semodule:  Failed!





Is this a known issue?


Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University






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


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com<mailto: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 6.6 upgrade breaks osad on SW 2.1 clients that have SELinux in enforcing mode

[Andy Ingham]

This is a fine workaround EXCEPT be aware that it does NOT persist across 
reboots.

That is, you'll have to re-run the command after every reboot.  (I'm hoping 
someone can indicate that I'm wrong on this, but I don't see a "persistent" 
option for that command).

Andy

From: ndegz mailto:nnd...@gmail.com>>
Reply-To: "nndegz+l...@gmail.com<mailto:nndegz+l...@gmail.com>" 
mailto:nndegz+l...@gmail.com>>, 
"spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Friday, November 7, 2014 at 3:18 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] CentOS 6.6 upgrade breaks osad on SW 2.1 clients 
that have SELinux in enforcing mode

Ran into the same issue and found this blog post
Short tip: osad: Unable to connect to the host and port specified (EL6.6 + 
EL7)<http://blog.christian-stankowic.de/?p=6341&lang=en>

semanage permissive -a osad_t




On Thu, Nov 6, 2014 at 12:59 PM, Kevin Sandy 
mailto:ke...@digitallotus.com>> wrote:
I've been seeing this as well.  Clients are on CentOS 6.6 with Spacewalk 2.2.  
I've had to put SELinux in permissive mode for now.


-- kevin



On Nov 6, 2014, at 12:48 PM, Andy Ingham 
mailto:andy.ing...@duke.edu>> wrote:

Ever since updating from CentOS 6.5 > 6.6, my servers (which are all at
spacewalk client version 2.1) are showing:


+
SELinux is preventing /usr/bin/python from name_connect access on the
tcp_socket .

*  Plugin catchall (100. confidence) suggests
***

If you believe that python should be allowed name_connect access on the
tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep osad /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
+





And FWIW, attempting to mitigate by adding a local policy (as the above
notice instructs) ALSO FAILS:

[root@HOSTNAME local_policy]# semodule -i osad.pp
libsepol.print_missing_requirements: osad's global requirements were not
met: type/attribute osad_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or
directory).
semodule:  Failed!





Is this a known issue?


Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University






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


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com<mailto: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] CentOS 6.6 upgrade breaks osad on SW 2.1 clients that have SELinux in enforcing mode

[Andy Ingham]

Ever since updating from CentOS 6.5 > 6.6, my servers (which are all at
spacewalk client version 2.1) are showing:


+
SELinux is preventing /usr/bin/python from name_connect access on the
tcp_socket .

*  Plugin catchall (100. confidence) suggests
***

If you believe that python should be allowed name_connect access on the
tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep osad /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
+





And FWIW, attempting to mitigate by adding a local policy (as the above
notice instructs) ALSO FAILS:

[root@HOSTNAME local_policy]# semodule -i osad.pp
libsepol.print_missing_requirements: osad's global requirements were not
met: type/attribute osad_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or
directory).
semodule:  Failed!





Is this a known issue?


Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University






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

[Spacewalk-list] new strange startup messages for jabberd

[Andy Ingham]

Ever since updating my spacewalk server to CentOS 6.6, I'm now seeing the
following:

Initializing jabberd processes ...
Starting router: /usr/bin/dirname: extra operand `2>&1'
Try `/usr/bin/dirname --help' for more information.
   [  OK  ]

Starting sm: /usr/bin/dirname: extra operand `2>&1'
Try `/usr/bin/dirname --help' for more information.
   [  OK  ]

Starting c2s: /usr/bin/dirname: extra operand `2>&1'
Try `/usr/bin/dirname --help' for more information.
   [  OK  ]

Starting s2s: /usr/bin/dirname: extra operand `2>&1'
Try `/usr/bin/dirname --help' for more information.
   [  OK  ]

Starting osa-dispatcher:   [  OK  ]




I'm still running SW 2.1, and the processes start up (and stay up), but
I'm curious what the messages are from.

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] Shibboleth protection for spacewalk web interface

[Andy Ingham]

In case sending this on Friday afternoon was a bad idea...

Does anyone know if spacewalk / satellite support Shibboleth
authentication?  (Having looked a little more closely since late last
week, I'm less confident that it will work as easily as I'd envisioned).

Andy


On 10/24/14, 1:50 PM, "Andy Ingham"  wrote:

All --

I'm considering adding Shib authentication to my spacewalk server (to make
it an SP within our Duke campus environment).  I'm hoping it will be a
fairly straightforward setup, but anyone know of any particular gotchas
with Shib/spacewalk(or satellite)?

Best,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




___
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] Shibboleth protection for spacewalk web interface

[Andy Ingham]

All --

I'm considering adding Shib authentication to my spacewalk server (to make
it an SP within our Duke campus environment).  I'm hoping it will be a
fairly straightforward setup, but anyone know of any particular gotchas
with Shib/spacewalk(or satellite)?

Best,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] odd issue after postgres upgrade (from 8.4 > 9.3)

[Andy Ingham]

Yes, this resolves the issue.

Thanks, Stephen!

Andy

On 7/18/14, 10:44 AM, "Stephen Herr"  wrote:

My guess is that your postgresql 9.3 instance is not using the
configuration generated by spacewalk-setup-postgresql. In particular, I
suspect this problem would be fixed by setting "bytea_output = 'escape'"
in postgresql.conf. Try appending the following to postgresql.conf and
restarting the db:

### spacewalk-setup-postgresql modified values
checkpoint_completion_target = 0.7
checkpoint_segments = 8
effective_cache_size = 1152MB
log_line_prefix = '%m '
maintenance_work_mem = 96MB
max_connections = 600
shared_buffers = 384MB
wal_buffers = 4MB
work_mem = 2560kB
bytea_output = 'escape'

-Stephen

On 07/18/2014 10:26 AM, Andy Ingham wrote:
> For the most part, things look good and all functionality seems to be
> happy after my postgres upgrade EXCEPT this one interesting issue:
>
> The running of a "remote command" FUNCTIONS correctly, however, the
>output
> in the webUI when one visits [System name] > Events > History > "Run an
> arbitrary script scheduled by "
>
> no longer shows the command / script that was run, but rather displays a
> hex string like:
> x23212f62696e2f73680a73657276696365206175746f66732072657374617274
>
>
> Likewise, the "output" (whether raw or filtered) displays as hex, rather
> than as something useful / readable.
>
>
>
> Sure seems that the data in the postgres db is now being stored in a new
> format or with a new data type.
>
> Anyone seen anything like this or have ideas about why I'm seeing this?
>
> Best wishes,
> Andy
>
> Andy Ingham
> IT Infrastructure
> Fuqua School of Business
> Duke University
>
>
>
>
> ___
> 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] odd issue after postgres upgrade (from 8.4 > 9.3)

[Andy Ingham]

For the most part, things look good and all functionality seems to be
happy after my postgres upgrade EXCEPT this one interesting issue:

The running of a "remote command" FUNCTIONS correctly, however, the output
in the webUI when one visits [System name] > Events > History > "Run an
arbitrary script scheduled by "

no longer shows the command / script that was run, but rather displays a
hex string like:  
x23212f62696e2f73680a73657276696365206175746f66732072657374617274


Likewise, the "output" (whether raw or filtered) displays as hex, rather
than as something useful / readable.



Sure seems that the data in the postgres db is now being stored in a new
format or with a new data type.

Anyone seen anything like this or have ideas about why I'm seeing this?

Best wishes,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] upgrading postgres (8.4 > 9.x) on the spacewalk server ?

[Andy Ingham]

Paul --

I used a dump file that was output by the script that our DBA wrote to
create nightly backups.

>From that script, it looks like the only pg_dump options used are -O ("Do
not output commands to set ownership of objects to match the original
database") and -v ("verbose")

Andy


On 7/17/14, 4:22 PM, "Paul Robert Marino"  wrote:

huh I'm curious what dump options you used?


On Thu, Jul 17, 2014 at 3:05 PM, Andy Ingham  wrote:
> To close the loop, I *think* I've got things resolved now.
>
> The gotcha was that I had not properly prepped the new (version 9.3)
> database to receive the (8.4) dump file input.
>
> After some trial and error (and dropping and re-creating the db several
> times) and teasing some things out of the online documentation, THIS is
> what worked:
>
> /usr/pgsql-9.3/bin/createdb -O postgres spaceschema
> /usr/pgsql-9.3/bin/createlang plpgsql spaceschema
> /usr/pgsql-9.3/bin/createlang pltclu spaceschema
>
> (THEN, read in the dumpfile:)
> /usr/pgsql-9.3/bin/psql -U spaceuser spaceschema <
> spaceschema_17072014084044.bkup
>
>
>
> Andy
>
>
> PS, this was all a preparatory step for upgrading SW itself from 2.0 to
> 2.1.  That'll have to wait for another day...
>
>
> On 7/17/14, 11:35 AM, "Andy Ingham"  wrote:
>
> I should add that I've got oodles of THIS type of error:
>
> 2014/07/17 11:28:06 -04:00 28281 152.3.160.155:
> rhnSQL/driver_postgresql.check_connection('ERROR', "DATABASE CONNECTION
>TO
> 'spaceschema' LOST", "Exception information: Database instance has no
> attribute 'dbh'")
>
>
> in my rhn_server_xmlrpc.log
>
> I also have THIS in my rhn_taskomatic_daemon.log:
>
> STATUS | wrapper  | 2014/07/17 11:32:11 | Launching a JVM...
> INFO   | jvm 5| 2014/07/17 11:32:11 | Wrapper (Version 3.2.3)
> http://wrapper.tanukisoftware.org
> INFO   | jvm 5| 2014/07/17 11:32:11 |   Copyright 1999-2006 Tanuki
> Software, Inc.  All Rights Reserved.
> INFO   | jvm 5| 2014/07/17 11:32:11 |
> ERROR  | wrapper  | 2014/07/17 11:32:41 | Startup failed: Timed out
> waiting for signal from JVM.
> ERROR  | wrapper  | 2014/07/17 11:32:41 | JVM did not exit on request,
> terminated
> INFO   | wrapper  | 2014/07/17 11:32:41 | JVM exited on its own while
> waiting to kill the application.
> STATUS | wrapper  | 2014/07/17 11:32:41 | JVM exited in response to
>signal
> SIGKILL (9).
> FATAL  | wrapper  | 2014/07/17 11:32:41 | There were 5 failed launches in
> a row, each lasting less than 300 seconds.  Giving up.
> FATAL  | wrapper  | 2014/07/17 11:32:41 |   There may be a configuration
> problem: please check the logs.
> STATUS | wrapper  | 2014/07/17 11:32:41 | <-- Wrapper Stopped
>
>
>
>
> Andy
>
> On 7/17/14, 11:25 AM, "Andy Ingham"  wrote:
>
> So I attempted the postgres 8.4 > 9.3 upgrade this morning (for the local
> db on my SW 2.0 server)
>
> Everything seemed to go pretty smoothly (thanks, Paul for the tips
>below!)
>
> BUT...
>
> The spacewalk instance is unable to connect to the upgraded database.
>
> I have confirmed that the pgsql user / password are valid and allow
> connecting from the local system (via the psql CLIENT)
>
> But yet when I try to start spacewalk, it consistently says:
>
> Starting httpd:[  OK  ]
> Starting osa-dispatcher: Spacewalk 28090 2014/07/17 11:16:43 -04:00:
> ('Error caught:',)
> Spacewalk 28090 2014/07/17 11:16:43 -04:00: ('Traceback (most recent call
> last):\n  File "/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n
> self.setup_config(config)\n  File
>"/usr/share/rhn/osad/osa_dispatcher.py",
> line 112, in setup_config\nrhnSQL.initDB()\n  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
> line 102, in initDB\n__init__DB(backend, host, port, username,
> password, database)\n  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
> line 55, in __init__DB\n__DB.connect()\n  File
> 
>"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresq
>l
> .py", line 174, in connect\nreturn self.connect(reconnect=0)\n  File
> 
>"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresq
>l
> .py", line 163, in connect\npassword=str(self.password))\n  File
> "/usr/lib64/python2.6/site-packages/psycopg2/__init__.py", line 164, in
> connect\nconn = _connect(dsn, connection_factory=connection_factory,
> async=async)\nSQLConnectError: (None, None, \'spaceschema\', \

Re: [Spacewalk-list] upgrading postgres (8.4 > 9.x) on the spacewalk server ?

[Andy Ingham]

To close the loop, I *think* I've got things resolved now.

The gotcha was that I had not properly prepped the new (version 9.3)
database to receive the (8.4) dump file input.

After some trial and error (and dropping and re-creating the db several
times) and teasing some things out of the online documentation, THIS is
what worked:

/usr/pgsql-9.3/bin/createdb -O postgres spaceschema
/usr/pgsql-9.3/bin/createlang plpgsql spaceschema
/usr/pgsql-9.3/bin/createlang pltclu spaceschema

(THEN, read in the dumpfile:)
/usr/pgsql-9.3/bin/psql -U spaceuser spaceschema <
spaceschema_17072014084044.bkup



Andy


PS, this was all a preparatory step for upgrading SW itself from 2.0 to
2.1.  That'll have to wait for another day...


On 7/17/14, 11:35 AM, "Andy Ingham"  wrote:

I should add that I've got oodles of THIS type of error:

2014/07/17 11:28:06 -04:00 28281 152.3.160.155:
rhnSQL/driver_postgresql.check_connection('ERROR', "DATABASE CONNECTION TO
'spaceschema' LOST", "Exception information: Database instance has no
attribute 'dbh'")


in my rhn_server_xmlrpc.log

I also have THIS in my rhn_taskomatic_daemon.log:

STATUS | wrapper  | 2014/07/17 11:32:11 | Launching a JVM...
INFO   | jvm 5| 2014/07/17 11:32:11 | Wrapper (Version 3.2.3)
http://wrapper.tanukisoftware.org
INFO   | jvm 5| 2014/07/17 11:32:11 |   Copyright 1999-2006 Tanuki
Software, Inc.  All Rights Reserved.
INFO   | jvm 5| 2014/07/17 11:32:11 |
ERROR  | wrapper  | 2014/07/17 11:32:41 | Startup failed: Timed out
waiting for signal from JVM.
ERROR  | wrapper  | 2014/07/17 11:32:41 | JVM did not exit on request,
terminated
INFO   | wrapper  | 2014/07/17 11:32:41 | JVM exited on its own while
waiting to kill the application.
STATUS | wrapper  | 2014/07/17 11:32:41 | JVM exited in response to signal
SIGKILL (9).
FATAL  | wrapper  | 2014/07/17 11:32:41 | There were 5 failed launches in
a row, each lasting less than 300 seconds.  Giving up.
FATAL  | wrapper  | 2014/07/17 11:32:41 |   There may be a configuration
problem: please check the logs.
STATUS | wrapper  | 2014/07/17 11:32:41 | <-- Wrapper Stopped




Andy

On 7/17/14, 11:25 AM, "Andy Ingham"  wrote:

So I attempted the postgres 8.4 > 9.3 upgrade this morning (for the local
db on my SW 2.0 server)

Everything seemed to go pretty smoothly (thanks, Paul for the tips below!)

BUT...

The spacewalk instance is unable to connect to the upgraded database.

I have confirmed that the pgsql user / password are valid and allow
connecting from the local system (via the psql CLIENT)

But yet when I try to start spacewalk, it consistently says:

Starting httpd:[  OK  ]
Starting osa-dispatcher: Spacewalk 28090 2014/07/17 11:16:43 -04:00:
('Error caught:',)
Spacewalk 28090 2014/07/17 11:16:43 -04:00: ('Traceback (most recent call
last):\n  File "/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n
self.setup_config(config)\n  File "/usr/share/rhn/osad/osa_dispatcher.py",
line 112, in setup_config\nrhnSQL.initDB()\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
line 102, in initDB\n__init__DB(backend, host, port, username,
password, database)\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
line 55, in __init__DB\n__DB.connect()\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py", line 174, in connect\nreturn self.connect(reconnect=0)\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py", line 163, in connect\npassword=str(self.password))\n  File
"/usr/lib64/python2.6/site-packages/psycopg2/__init__.py", line 164, in
connect\nconn = _connect(dsn, connection_factory=connection_factory,
async=async)\nSQLConnectError: (None, None, \'spaceschema\', \'Attempting
Re-Connect to the database failed\')\n',)



Any particular ideas on what I'm missing?

TIA,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University







On 7/14/14, 5:01 PM, "Paul Robert Marino"  wrote:

I Know of a few gotchas

essentially the database upgrade itself is easy just do a full dump and
reload.
here are the gotchas

1) be sure to follow the steps here
http://www.postgresql.org/docs/9.3/static/upgrading.html including the
file system backup first. If there is a failure in the restore it can
be a nightmare to fix if you didn't make a copy of the database files
before you upgrade.

2) If you are using custom table spaces like I am make sure you make
backup copies of those as well. also recreate them on the new database
 before the restore. I use custom table spaces because I hate putting
entire databases in /var so my journal is in the default location and
my data is on a different partition. 

Re: [Spacewalk-list] upgrading postgres (8.4 > 9.x) on the spacewalk server ?

[Andy Ingham]

I should add that I've got oodles of THIS type of error:

2014/07/17 11:28:06 -04:00 28281 152.3.160.155:
rhnSQL/driver_postgresql.check_connection('ERROR', "DATABASE CONNECTION TO
'spaceschema' LOST", "Exception information: Database instance has no
attribute 'dbh'")


in my rhn_server_xmlrpc.log

I also have THIS in my rhn_taskomatic_daemon.log:

STATUS | wrapper  | 2014/07/17 11:32:11 | Launching a JVM...
INFO   | jvm 5| 2014/07/17 11:32:11 | Wrapper (Version 3.2.3)
http://wrapper.tanukisoftware.org
INFO   | jvm 5| 2014/07/17 11:32:11 |   Copyright 1999-2006 Tanuki
Software, Inc.  All Rights Reserved.
INFO   | jvm 5| 2014/07/17 11:32:11 |
ERROR  | wrapper  | 2014/07/17 11:32:41 | Startup failed: Timed out
waiting for signal from JVM.
ERROR  | wrapper  | 2014/07/17 11:32:41 | JVM did not exit on request,
terminated
INFO   | wrapper  | 2014/07/17 11:32:41 | JVM exited on its own while
waiting to kill the application.
STATUS | wrapper  | 2014/07/17 11:32:41 | JVM exited in response to signal
SIGKILL (9).
FATAL  | wrapper  | 2014/07/17 11:32:41 | There were 5 failed launches in
a row, each lasting less than 300 seconds.  Giving up.
FATAL  | wrapper  | 2014/07/17 11:32:41 |   There may be a configuration
problem: please check the logs.
STATUS | wrapper  | 2014/07/17 11:32:41 | <-- Wrapper Stopped




Andy

On 7/17/14, 11:25 AM, "Andy Ingham"  wrote:

So I attempted the postgres 8.4 > 9.3 upgrade this morning (for the local
db on my SW 2.0 server)

Everything seemed to go pretty smoothly (thanks, Paul for the tips below!)

BUT...

The spacewalk instance is unable to connect to the upgraded database.

I have confirmed that the pgsql user / password are valid and allow
connecting from the local system (via the psql CLIENT)

But yet when I try to start spacewalk, it consistently says:

Starting httpd:[  OK  ]
Starting osa-dispatcher: Spacewalk 28090 2014/07/17 11:16:43 -04:00:
('Error caught:',)
Spacewalk 28090 2014/07/17 11:16:43 -04:00: ('Traceback (most recent call
last):\n  File "/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n
self.setup_config(config)\n  File "/usr/share/rhn/osad/osa_dispatcher.py",
line 112, in setup_config\nrhnSQL.initDB()\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
line 102, in initDB\n__init__DB(backend, host, port, username,
password, database)\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
line 55, in __init__DB\n__DB.connect()\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py", line 174, in connect\nreturn self.connect(reconnect=0)\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py", line 163, in connect\npassword=str(self.password))\n  File
"/usr/lib64/python2.6/site-packages/psycopg2/__init__.py", line 164, in
connect\nconn = _connect(dsn, connection_factory=connection_factory,
async=async)\nSQLConnectError: (None, None, \'spaceschema\', \'Attempting
Re-Connect to the database failed\')\n',)



Any particular ideas on what I'm missing?

TIA,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University







On 7/14/14, 5:01 PM, "Paul Robert Marino"  wrote:

I Know of a few gotchas

essentially the database upgrade itself is easy just do a full dump and
reload.
here are the gotchas

1) be sure to follow the steps here
http://www.postgresql.org/docs/9.3/static/upgrading.html including the
file system backup first. If there is a failure in the restore it can
be a nightmare to fix if you didn't make a copy of the database files
before you upgrade.

2) If you are using custom table spaces like I am make sure you make
backup copies of those as well. also recreate them on the new database
 before the restore. I use custom table spaces because I hate putting
entire databases in /var so my journal is in the default location and
my data is on a different partition. if you intend to use custom table
spaces this is probably the best time to make that change its painful
otherwise.

3) if you are doing this on EL 6 you need to update a symlink for jdbc.
here is the default
"
~]# ls -L /usr/share/java/postgresql-jdbc.jar
lrwxrwxrwx. 1 root root 44 Nov  5  2012
/usr/share/java/postgresql-jdbc.jar ->
/usr/share/java/postgresql-8.4-703.jdbc4.jar
"
you need to make sure you have the correct PostgreSQL 9 jdbc file
installed and /usr/share/java/postgresql-jdbc.jar is pointed to the
one for 9 instead of 8.
This one is critical or you will experience a whole lot of weird
issues and possibly even database corruption especially with
Taskomatic.

3) I haven't had time to track this down yet however I did create a
bug ticket. I found that rhnsea

Re: [Spacewalk-list] upgrading postgres (8.4 > 9.x) on the spacewalk server ?

[Andy Ingham]

So I attempted the postgres 8.4 > 9.3 upgrade this morning (for the local
db on my SW 2.0 server)

Everything seemed to go pretty smoothly (thanks, Paul for the tips below!)

BUT...

The spacewalk instance is unable to connect to the upgraded database.

I have confirmed that the pgsql user / password are valid and allow
connecting from the local system (via the psql CLIENT)

But yet when I try to start spacewalk, it consistently says:

Starting httpd:[  OK  ]
Starting osa-dispatcher: Spacewalk 28090 2014/07/17 11:16:43 -04:00:
('Error caught:',)
Spacewalk 28090 2014/07/17 11:16:43 -04:00: ('Traceback (most recent call
last):\n  File "/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n
self.setup_config(config)\n  File "/usr/share/rhn/osad/osa_dispatcher.py",
line 112, in setup_config\nrhnSQL.initDB()\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
line 102, in initDB\n__init__DB(backend, host, port, username,
password, database)\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
line 55, in __init__DB\n__DB.connect()\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py", line 174, in connect\nreturn self.connect(reconnect=0)\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py", line 163, in connect\npassword=str(self.password))\n  File
"/usr/lib64/python2.6/site-packages/psycopg2/__init__.py", line 164, in
connect\nconn = _connect(dsn, connection_factory=connection_factory,
async=async)\nSQLConnectError: (None, None, \'spaceschema\', \'Attempting
Re-Connect to the database failed\')\n',)



Any particular ideas on what I'm missing?

TIA,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University







On 7/14/14, 5:01 PM, "Paul Robert Marino"  wrote:

I Know of a few gotchas

essentially the database upgrade itself is easy just do a full dump and
reload.
here are the gotchas

1) be sure to follow the steps here
http://www.postgresql.org/docs/9.3/static/upgrading.html including the
file system backup first. If there is a failure in the restore it can
be a nightmare to fix if you didn't make a copy of the database files
before you upgrade.

2) If you are using custom table spaces like I am make sure you make
backup copies of those as well. also recreate them on the new database
 before the restore. I use custom table spaces because I hate putting
entire databases in /var so my journal is in the default location and
my data is on a different partition. if you intend to use custom table
spaces this is probably the best time to make that change its painful
otherwise.

3) if you are doing this on EL 6 you need to update a symlink for jdbc.
here is the default
"
~]# ls -L /usr/share/java/postgresql-jdbc.jar
lrwxrwxrwx. 1 root root 44 Nov  5  2012
/usr/share/java/postgresql-jdbc.jar ->
/usr/share/java/postgresql-8.4-703.jdbc4.jar
"
you need to make sure you have the correct PostgreSQL 9 jdbc file
installed and /usr/share/java/postgresql-jdbc.jar is pointed to the
one for 9 instead of 8.
This one is critical or you will experience a whole lot of weird
issues and possibly even database corruption especially with
Taskomatic.

3) I haven't had time to track this down yet however I did create a
bug ticket. I found that rhnsearchd is still ignoring the IP address
in the configuration and connecting to local host. I do not know if
its due to some remnant someplace left over from upgrades or if it is
a real bug in rhnsearchd itself.




On Mon, Jul 14, 2014 at 11:35 AM, Boyd, Robert
 wrote:
> Andy,
>
> When you do the upgrade I'd like to hear what if any details you
>discover that you have to work through that deviate from the postgres
>docs.  I'd like to make the same upgrade.  I looked at it a few months
>ago and decided to wait a while before tackling it.
>
> Thanks,
>
> Robert Boyd
> Sr. Systems Engineer
> PeopleFluent
> e. robert.b...@peoplefluent.com
>
> Visit: www.peoplefluent.com | Read: Peoplefluent Blog | Follow:
>@peoplefluent | Download: iPad App
>
> -Original Message-
> From: spacewalk-list-boun...@redhat.com
>[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Andy Ingham
> Sent: Monday, July 14, 2014 10:02 AM
> To: spacewalk-list@redhat.com
> Subject: [Spacewalk-list] upgrading postgres (8.4 > 9.x) on the
>spacewalk server ?
>
> Folks --
>
> Any particular gotchas about attempting to upgrade the postgresql server
>for our spacewalk installation?  It's at version 8.4 and we'd like to get
>it into the 9.x series.
>
> I'm assuming it should just be done according to the postg

[Spacewalk-list] upgrading postgres (8.4 > 9.x) on the spacewalk server ?

[Andy Ingham]

Folks --

Any particular gotchas about attempting to upgrade the postgresql server
for our spacewalk installation?  It's at version 8.4 and we'd like to get
it into the 9.x series.

I'm assuming it should just be done according to the postgres docs?

TIA,
Andy


Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] Scheduled jobs picked up but not executing

[Andy Ingham]

Check out the man page for run-actions-control

>>> man rhn-actions-control

Looks like you'd (minimally) need to execute

>>> rhn-actions-control --enable-run

But may also want to enable other sorts of actions.  (We just do an 
"--enable-all" and call it a day).

Andy

From: "hemen.me...@gmail.com<mailto:hemen.me...@gmail.com>" 
mailto:hemen.me...@gmail.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Friday, June 27, 2014 at 3:02 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] Scheduled jobs picked up but not executing

i am not the original poster of this question, but I have the same problem.

When I run "rhn-actions-control --report"
I get:
deploy is disabled
diff is disabled
upload is disabled
mtime_upload is disabled
run is disabled

How do I go about changing that?



On Fri, Jun 27, 2014 at 1:31 PM, Andy Ingham 
mailto:andy.ing...@duke.edu>> wrote:
Chris --

Sounds like the communication between spacewalk and the client is working, but 
perhaps the client isn't "allowed" to execute a command?

What does the output of "rhn-actions-control --report" on an affected client 
show?

Especially, does it show that "run is enabled" ?

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University


From: Chris Balcum 
mailto:cbal...@millennialmedia.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Thursday, June 26, 2014 at 3:03 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: [Spacewalk-list] Scheduled jobs picked up but not executing

Hi all,

Having a funky issue with Spacewalk and scheduling remote commands. On some 
systems (around 40 or so out of over 500) I schedule a command and they get 
picked up, but they don't actually execute. The UI shows them as being picked 
up, but they just... sit there. I've verified that rhnsd and osad is running on 
the client side, and jabberd and osa-dispatcher is running on the server end.

This action will be executed after 6/26/14 2:27:00 PM EDT
This action's status is: Picked Up.
The client picked up this action on 6/26/14 2:28 PM
The client has not yet completed this action.

Any help would be greatly appreciated.

Chris
__
Chris Balcum | Infrastructure Operations Engineer
millennial media
Mobile:  315.530.2911
Email: cbal...@millennialmedia.com<mailto:cbal...@millennialmedia.com>
Web: www.millennialmedia.com<http://www.millennialmedia.com/>

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com<mailto: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] Scheduled jobs picked up but not executing

[Andy Ingham]

Chris --

Sounds like the communication between spacewalk and the client is working, but 
perhaps the client isn't "allowed" to execute a command?

What does the output of "rhn-actions-control --report" on an affected client 
show?

Especially, does it show that "run is enabled" ?

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University


From: Chris Balcum 
mailto:cbal...@millennialmedia.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Thursday, June 26, 2014 at 3:03 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: [Spacewalk-list] Scheduled jobs picked up but not executing

Hi all,

Having a funky issue with Spacewalk and scheduling remote commands. On some 
systems (around 40 or so out of over 500) I schedule a command and they get 
picked up, but they don't actually execute. The UI shows them as being picked 
up, but they just... sit there. I've verified that rhnsd and osad is running on 
the client side, and jabberd and osa-dispatcher is running on the server end.

This action will be executed after 6/26/14 2:27:00 PM EDT
This action's status is: Picked Up.
The client picked up this action on 6/26/14 2:28 PM
The client has not yet completed this action.

Any help would be greatly appreciated.

Chris
__
Chris Balcum | Infrastructure Operations Engineer
millennial media
Mobile:  315.530.2911
Email: cbal...@millennialmedia.com<mailto:cbal...@millennialmedia.com>
Web: www.millennialmedia.com<http://www.millennialmedia.com/>
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] installing package updates

[Andy Ingham]

I've always found the OSAD mechanism to be a bit of a dark art.  But, "yes", 
you should have an SSL cert on each registered host.  Mine is at  
/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT .

Have a look also at your /etc/sysconfig/rhn/osad.conf file.  Especially these 
directives:

proto =
osa_ssl_cert =

And, obviously, remember that you need the osa-dispatcher functioning properly 
on the spacewalk server itself.

That's likely the extent of my ability to help.  Other folks on the list may 
understand the inner workings better.

Andy

From: "hemen.me...@gmail.com<mailto:hemen.me...@gmail.com>" 
mailto:hemen.me...@gmail.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Wednesday, June 4, 2014 at 2:25 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] installing package updates

Andy Inghan: I think I have the OSAD setup wrong, do I need to have an SSL cert 
on every client machine?



On Wed, Jun 4, 2014 at 1:38 PM, Andy Ingham 
mailto:andy.ing...@duke.edu>> wrote:
Do you have OSAD setup / running?

I think that's exactly what you're looking for.

Andy


From: Howard Coles mailto:hco...@dollargeneral.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Wednesday, June 4, 2014 at 1:30 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] installing package updates

Oh, and you can also check the "Automatic Errata Update" option under Edit 
System Details.  :D


See Ya'
Howard Coles Jr.

From:spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-boun...@redhat.com>
 [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of 
hemen.me...@gmail.com<mailto:hemen.me...@gmail.com>
Sent: Wednesday, June 04, 2014 11:28 AM
To: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
Subject: [Spacewalk-list] installing package updates

How do I get my SW server to upgrade the packages on the client machines 
immediately, and not on whatever schedule they are currently on?

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com<mailto: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] installing package updates

[Andy Ingham]

Do you have OSAD setup / running?

I think that's exactly what you're looking for.

Andy


From: Howard Coles mailto:hco...@dollargeneral.com>>
Reply-To: "spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Date: Wednesday, June 4, 2014 at 1:30 PM
To: "spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] installing package updates

Oh, and you can also check the "Automatic Errata Update" option under Edit 
System Details.  :D


See Ya'
Howard Coles Jr.

From: 
spacewalk-list-boun...@redhat.com 
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of 
hemen.me...@gmail.com
Sent: Wednesday, June 04, 2014 11:28 AM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] installing package updates

How do I get my SW server to upgrade the packages on the client machines 
immediately, and not on whatever schedule they are currently on?
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Is there a native function in spacewalk for archiving and then deleting old "actions"

[Andy Ingham]

Brian --

Thanks for the reply and for giving me a head-start on "rolling my own"
solution.

Best wishes,

Andy

On 5/1/14 1:42 PM, "Brian Collins"  wrote:

In Satellite, I've written a script to do that for all the "Show
differences ..." actions.  It takes completed and failed actions, moves
them to archived actions, then deletes them from archived actions.

It can easily be adjusted to purge a wider range of actions, and probably
to accommodate the age of the items.

It archives/purges 500 items at a time until they are all done.

Including it as a .txt, but it's written in Python.


> -Original Message-
> From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-
> boun...@redhat.com] On Behalf Of Paul Robert Marino
> Sent: Thursday, May 01, 2014 1:02 PM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] Is there a native function in spacewalk for
> archiving and then deleting old "actions"
> 
> As far as I know no there isn't but it may be possible to use the
> API's to do that.
> 
> On Thu, May 1, 2014 at 12:33 PM, Andy Ingham 
>wrote:
> > The process of manually "archiving" old actions and then deleting them
> > (via the GUI) is very tedious.
> >
> > Is there a built-in way to have then cycle from "completed" (at least)
>to
> > "archived" when they reach X days/weeks/months old.  Similarly, is
>there a
> > native way of having archived actions older than X months "deleted"?
> >
> > Just want to make sure I'm not missing an easy way to do this before
> > trying to roll something on my own.
> >
> > Thanks!
> >
> > Andy
> >
> > Andy Ingham
> > IT Infrastructure
> > Fuqua School of Business
> > Duke University
> >
> >
> >
> >
> > ___
> > 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] Is there a native function in spacewalk for archiving and then deleting old "actions"

[Andy Ingham]

The process of manually "archiving" old actions and then deleting them
(via the GUI) is very tedious.

Is there a built-in way to have then cycle from "completed" (at least) to
"archived" when they reach X days/weeks/months old.  Similarly, is there a
native way of having archived actions older than X months "deleted"?

Just want to make sure I'm not missing an easy way to do this before
trying to roll something on my own.

Thanks!

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] after installation of 3rd party SSL certificate, now getting (intermittent) errors!

[Andy Ingham]

Helpful spacewalk list --

I'm still looking for an answer to this.  Any ideas?

The problem:
* I can no longer successfully get configuration comparisons for my 72 servers 
(either "manually" via the GUI or scheduled daily through taskomatic) [ever 
since I installed new third-party certificates and changed various settings to 
use https instead of http]

The symptoms:
* The following type of error is spewed to rhn_server_xmlrpc.log (starting 
about 3 minutes after the job "starts"):
2014/04/28 23:43:49 -04:00 13820 XYZ.XYZ.XYZ.XYZ: 
rhnSQL/driver_postgresql.check_connection('ERROR', "DATABASE CONNECTION TO 
'XX' LOST", "Exception information: Database instance has no attribute 
'dbh'")

* A "few" (up to 10ish) systems SUCCEED each time; the rest (~62) fail.  
Sometimes I get a 500 server error from the GUI.

The questions:
* Are there postgres tuning steps that are needed? (and why did this happen all 
of a sudden after years of no issues?)
* What other logs should I be looking at?

I'm running spacewalk 2.0 (NOT 2.1) with, obviously, a postgres backend


TIA!
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University



From: Andy Ingham mailto:andy.ing...@duke.edu>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Friday, April 25, 2014 9:30 AM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] after installation of 3rd party SSL certificate, 
now getting (intermittent) errors!

Thanks, Paul, for your message.

I did update the CA cert on the hosts (and edited their configurations to point 
to it).  The package events work GREAT across the servers!

The real trouble is with, for example, the "compare-configs-default" task (via 
the built-in Task Engine).

Anyone have any ideas why this is now wedged?  (Some configuration file that 
needs a new pointer to the new cert, or where a password is wrong, for example?)

TIA,
Andy

PS, I'm not sure I agree with your assessment of the heartbleed vulnerability, 
but that's a discussion for another time and/or place.  ;)

From: Paul Robert Marino mailto:prmari...@gmail.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Thursday, April 24, 2014 7:16 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] after installation of 3rd party SSL certificate, 
now getting (intermittent) errors!

Did you deploy the CA cert from the third party signer to the hosts as in place 
of the one initially deployed by spacewalk or update the 
/etc/sysconfig/rhn/up2date file to point to the stock copy form the 3rd party 
vendor deployed by the rpm included in the distro.

Also heartbleed effected a smaller number of certs than most people think 
essentially if the cert was generated prior to the poisonous patch its safe. 
Its only new certs generated by versions after the poisonous patch and or 
systems that haven't updated the openssl libraries since which are vulnerable.
The vast majority of production systems are reasonably safe. Further more I 
wouldn't worry about it that much unless your traffic goes over a public 
network. Essentially if someone has the access to utilize it in your internal 
network you have a much bigger problem.

To be clear if you are vulnerable its a huge problem especially if you deal 
with ecommerce, web based financial information, or data that can be used for 
identity theaft. But you have really look at and understand the problem before 
you should panic and replace all your certs.


-- Sent from my HP Pre3


On Apr 24, 2014 14:19, Andy Ingham 
mailto:andy.ing...@duke.edu>> wrote:

Ever since we switched from a self-signed to a third-party SSL certificate
two days ago (thank you, Heartbleed!), I've seen intermittent issues.

The most obvious error: the daily 11:00 PM "compare-configs-default" task
(which has always run successfully for all 70+ servers), now is failing
for 98% (but not ALL!) hosts. The event message when it fails is: "This
action has been picked up multiple times without a successful transaction;
this action is now failed for this system."

The osa-dispatcher.log and rhn_server_xmlrpc.log show LOTS of entries like
rhnSQL/driver_postgresql.check_connection('ERROR', "DATABASE CONNECTION
TO 'spaceschema' LOST", "Exception information: Database instance has no
attribute 'dbh'")
clustered around the time of the scheduled run

I've done full restarts of post

Re: [Spacewalk-list] after installation of 3rd party SSL certificate, now getting (intermittent) errors!

[Andy Ingham]

Thanks, Paul, for your message.

I did update the CA cert on the hosts (and edited their configurations to point 
to it).  The package events work GREAT across the servers!

The real trouble is with, for example, the "compare-configs-default" task (via 
the built-in Task Engine).

Anyone have any ideas why this is now wedged?  (Some configuration file that 
needs a new pointer to the new cert, or where a password is wrong, for example?)

TIA,
Andy

PS, I'm not sure I agree with your assessment of the heartbleed vulnerability, 
but that's a discussion for another time and/or place.  ;)

From: Paul Robert Marino mailto:prmari...@gmail.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Thursday, April 24, 2014 7:16 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] after installation of 3rd party SSL certificate, 
now getting (intermittent) errors!

Did you deploy the CA cert from the third party signer to the hosts as in place 
of the one initially deployed by spacewalk or update the 
/etc/sysconfig/rhn/up2date file to point to the stock copy form the 3rd party 
vendor deployed by the rpm included in the distro.

Also heartbleed effected a smaller number of certs than most people think 
essentially if the cert was generated prior to the poisonous patch its safe. 
Its only new certs generated by versions after the poisonous patch and or 
systems that haven't updated the openssl libraries since which are vulnerable.
The vast majority of production systems are reasonably safe. Further more I 
wouldn't worry about it that much unless your traffic goes over a public 
network. Essentially if someone has the access to utilize it in your internal 
network you have a much bigger problem.

To be clear if you are vulnerable its a huge problem especially if you deal 
with ecommerce, web based financial information, or data that can be used for 
identity theaft. But you have really look at and understand the problem before 
you should panic and replace all your certs.


-- Sent from my HP Pre3


On Apr 24, 2014 14:19, Andy Ingham 
mailto:andy.ing...@duke.edu>> wrote:

Ever since we switched from a self-signed to a third-party SSL certificate
two days ago (thank you, Heartbleed!), I've seen intermittent issues.

The most obvious error: the daily 11:00 PM "compare-configs-default" task
(which has always run successfully for all 70+ servers), now is failing
for 98% (but not ALL!) hosts. The event message when it fails is: "This
action has been picked up multiple times without a successful transaction;
this action is now failed for this system."

The osa-dispatcher.log and rhn_server_xmlrpc.log show LOTS of entries like
rhnSQL/driver_postgresql.check_connection('ERROR', "DATABASE CONNECTION
TO 'spaceschema' LOST", "Exception information: Database instance has no
attribute 'dbh'")
clustered around the time of the scheduled run

I've done full restarts of postgres and spacewalk (and even a full reboot
for good measure).

Is there some reason that a cert change would lead to problems with
postgres connections, or is the error above a red herring?

Any ideas of where to look next?

TIA,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




___
Spacewalk-list mailing list
Spacewalk-list@redhat.com<mailto: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] after installation of 3rd party SSL certificate, now getting (intermittent) errors!

[Andy Ingham]

Ever since we switched from a self-signed to a third-party SSL certificate
two days ago (thank you, Heartbleed!), I've seen intermittent issues.

The most obvious error:  the daily 11:00 PM "compare-configs-default" task
(which has always run successfully for all 70+ servers), now is failing
for 98% (but not ALL!) hosts.  The event message when it fails is:  "This
action has been picked up multiple times without a successful transaction;
this action is now failed for this system."

The osa-dispatcher.log and rhn_server_xmlrpc.log show LOTS of entries like
  rhnSQL/driver_postgresql.check_connection('ERROR', "DATABASE CONNECTION
TO 'spaceschema' LOST", "Exception information: Database instance has no
attribute 'dbh'")
clustered around the time of the scheduled run

I've done full restarts of postgres and spacewalk (and even a full reboot
for good measure).

Is there some reason that a cert change would lead to problems with
postgres connections, or is the error above a red herring?

Any ideas of where to look next?

TIA,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] Problems with System Set Manager

[Andy Ingham]

Daniel --

I've not noticed that particular problem, but I've similarly noticed some
issues with SSM in spacewalk 2.0.

MY issue is that I will define systems for SSM, go to the package update
function, schedule ALL systems (in the SSM subset) to do all available
updates.  They get scheduled and executed, with spacewalk reporting that
"all succeeded".  When I navigate back to the SSM, though, I find that
there are systems that still have outdated packages!  Near as I can tell,
it seems to be based upon different OS versions, meaning that, for
instance, all the CentOS *6* hosts will be fully updated, but the CentOS
*5* servers within the SSM subset don't actually get their updates.

Solution is to simply schedule and execute the bulk update again, but I
don't recall this hiccup previous to version 2.0

Andy

On 3/19/14 5:37 AM, "Daniel Souvignier"
 wrote:

Hello,

I've got a problem with the System Set Manager. Neither package installs
nor package removals will work, only updates and script commands. If I
install or remove from a single system via spacewalk web interface, it
works just fine. I'm using stable spacewalk 2.0. What can be causing
this? If I try to remove a package, the message is always "package xy
could not be found", but why? Does it matter if I select systems which
already have the package removed alongside with systems which need to
have this package removed? Thanks!the SS

Regards,
Daniel

-- 

Daniel Souvignier
Fachinformatiker Systemintegration in Ausbildung
Lehrstuhl für integrierte Analogschaltungen
RWTH Aachen
Sommerfeldstraße 24 (Walther-Schottky-Haus)
52074 Aachen
Raum 24C 313
Tel.:0241/80-27771
www.ias.rwth-aachen.de




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

[Spacewalk-list] Problem kickstarting using a Software Package Profile

[Andy Ingham]

I'm using Spacewalk 2.0 (NOT 2.1) and have just begun creating kickstart
profiles for provisioning

I've worked out most bugs, but am stuck on something similar to what was
reported about a year ago ===>

(See 
https://www.redhat.com/archives/spacewalk-list/2013-April/msg00103.html )


Namely, when I configure the KS profile to include a package profile to
use (Software > Package Profiles), the sync-ing of packages always fails
as part of the KS.  If I immediately turn around and MANUALLY run the
package sync, it works fine.

The newly provisioned system IS getting proper channel subscriptions (for
the packages it needs to sync) AND is also getting the proper GPG keys for
the packages in those channels.

Attempts to add a "pre" script as described at the URL above have been
unsuccessful, although I do suspect the issue is related to the proper
repos not being available at the point in time when they are actually
needed.

Any ideas?

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University







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

[Spacewalk-list] [SOLVED] Re: switching from local repository to spacewalk-based repository -- errors

[Andy Ingham]

[FINALLY SOLVED]

The problem was nothing more than having an EXCLUDE statement in
/etc/yum/pluginconf.d/rhnplugin.conf

Changing:

[main]
enabled = 1
gpgcheck = 1
exclude=*postgresql*


To:
[main]
enabled = 1
gpgcheck = 1


And restarting rhnsd (for good measure) led to success.

FYI!

Andy

On 3/7/14 3:07 PM, "Andy Ingham"  wrote:

Michael --

I've tried all of the things you mention as well as re-registering the
client to the spacewalk server, to no avail.

I suspect that my only option at this point is to completely uninstall
postgres via yum and then reinstall it via spacewalk.

Not exactly the smooth transition I'd been hoping for as the precedent for
my other postgres servers.

Thanks for the ideas!

Andy

On 3/7/14 4:02 AM, "Michael Mraka"  wrote:

Andy Ingham wrote:
% Michael --
% 
% Here's what is returned by yum on the machine (note no indication of
% packages available for upgrade):
% 
% Installed Packages
% postgresql91.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% postgresql91-contrib.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% postgresql91-devel.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% postgresql91-libs.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% postgresql91-server.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% 
% So essentially seeking the 9.1.9-1PGDG >> 9.1.12-1PGDG updates that
% spacewalk says are available (as mentioned below).
% 
% FWIW, I'm running SW 2.0 with all SW client packages updated.
% 
% TIA for any possible insight!

Well, I have no idea what's the problem. I'd try:
- run yum clean all and yum update on the client to see whether it can
  see updates,
- also after scheduling updates you can also run rhn_check -vvv to see
  more detailed debug messages,
- check /var/cache/rhn/repodata/pgdg91/primary.xml.gz on server which
  version of postgresql91 is in,
and
- check last repo generation date in channel detail in webUI
- and maybe check taskomatic log.

Regards,

--
Michael Mráka
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


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

Re: [Spacewalk-list] switching from local repository to spacewalk-based repository -- errors

[Andy Ingham]

Michael --

I've tried all of the things you mention as well as re-registering the
client to the spacewalk server, to no avail.

I suspect that my only option at this point is to completely uninstall
postgres via yum and then reinstall it via spacewalk.

Not exactly the smooth transition I'd been hoping for as the precedent for
my other postgres servers.

Thanks for the ideas!

Andy

On 3/7/14 4:02 AM, "Michael Mraka"  wrote:

Andy Ingham wrote:
% Michael --
% 
% Here's what is returned by yum on the machine (note no indication of
% packages available for upgrade):
% 
% Installed Packages
% postgresql91.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% postgresql91-contrib.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% postgresql91-devel.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% postgresql91-libs.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% postgresql91-server.x86_64
% 9.1.9-1PGDG.rhel6   @pgdg91
% 
% So essentially seeking the 9.1.9-1PGDG >> 9.1.12-1PGDG updates that
% spacewalk says are available (as mentioned below).
% 
% FWIW, I'm running SW 2.0 with all SW client packages updated.
% 
% TIA for any possible insight!

Well, I have no idea what's the problem. I'd try:
- run yum clean all and yum update on the client to see whether it can
  see updates,
- also after scheduling updates you can also run rhn_check -vvv to see
  more detailed debug messages,
- check /var/cache/rhn/repodata/pgdg91/primary.xml.gz on server which
  version of postgresql91 is in,
and
- check last repo generation date in channel detail in webUI
- and maybe check taskomatic log.

Regards,

--
Michael Mráka
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] switching from local repository to spacewalk-based repository -- errors

[Andy Ingham]

Michael --

Here's what is returned by yum on the machine (note no indication of
packages available for upgrade):

Installed Packages
postgresql91.x86_64
9.1.9-1PGDG.rhel6   @pgdg91
postgresql91-contrib.x86_64
9.1.9-1PGDG.rhel6   @pgdg91
postgresql91-devel.x86_64
9.1.9-1PGDG.rhel6   @pgdg91
postgresql91-libs.x86_64
9.1.9-1PGDG.rhel6   @pgdg91
postgresql91-server.x86_64
9.1.9-1PGDG.rhel6   @pgdg91


So essentially seeking the 9.1.9-1PGDG >> 9.1.12-1PGDG updates that
spacewalk says are available (as mentioned below).

FWIW, I'm running SW 2.0 with all SW client packages updated.

TIA for any possible insight!

Andy


On 3/4/14 8:10 AM, "Michael Mraka"  wrote:

Andy Ingham wrote:
% I'm trying to switch a system from using a locally-defined repo (for
% postgres91) to using a newly created spacewalk-based repo instead.
% 
% Spacewalk indicates that there are package updates to be applied, but
% continues to fail every time I try to actually apply them.  (See below)
% 
% I've tried clearing yum caches and restarting various services.
% 
% Any ideas?  What's the magic solution to this?

Hi Andy,

What's the version of old packages you are trying to update?

% Andy
% 
% This action's status is: Failed.
% The client picked up this action on 03/ 3/14 8:52:15 AM EST.
% The client completed this action on 03/ 3/14 8:52:16 AM EST.
% Client execution returned "Error while executing packages action: empty
% transaction [[6]]" (code -1)
% Packages Scheduled:
% 
% * postgresql91-9.1.12-1PGDG.rhel6
% * postgresql91-server-9.1.12-1PGDG.rhel6
% * postgresql91-libs-9.1.12-1PGDG.rhel6
% * postgresql91-contrib-9.1.12-1PGDG.rhel6
% * postgresql91-devel-9.1.12-1PGDG.rhel6

Regards,

--
Michael Mráka
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

[Spacewalk-list] switching from local repository to spacewalk-based repository -- errors

[Andy Ingham]

I'm trying to switch a system from using a locally-defined repo (for
postgres91) to using a newly created spacewalk-based repo instead.

Spacewalk indicates that there are package updates to be applied, but
continues to fail every time I try to actually apply them.  (See below)

I've tried clearing yum caches and restarting various services.

Any ideas?  What's the magic solution to this?

Andy



This action's status is: Failed.
The client picked up this action on 03/ 3/14 8:52:15 AM EST.
The client completed this action on 03/ 3/14 8:52:16 AM EST.
Client execution returned "Error while executing packages action: empty
transaction [[6]]" (code -1)
Packages Scheduled:

* postgresql91-9.1.12-1PGDG.rhel6
* postgresql91-server-9.1.12-1PGDG.rhel6
* postgresql91-libs-9.1.12-1PGDG.rhel6
* postgresql91-contrib-9.1.12-1PGDG.rhel6
* postgresql91-devel-9.1.12-1PGDG.rhel6


Time:03/ 3/14 8:52:03 AM EST


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

Re: [Spacewalk-list] unable to cancel pending actions!

[Andy Ingham]

Thanks, Grant, for all the info!

I think my proposed remedy should be "good enough" for this go 'round.

In case anyone needs to use the kludged workaround I mentioned, be aware
that the "package actions" part of the events will STILL RUN (not
immediately, with OSAD down, but within the interval set within the given
clients' /etc/sysconfig/rhn/rhnsd files).

The saving grace is that the REBOOT (via a linked command) will FAIL,
since the action is currently not allowed on the box.

If you're ok with the package action happening but just not the reboot (as
I am), this remedy should suffice.

Andy

On 2/25/14 10:08 AM, "Grant Gainey"  wrote:

Hey Andy,

- Original Message -
> Grant --
> 
> Thanks for the offer.  I am testing a workaround of "breaking" OSAD
> connectivity and disabling actions on the client end until the point when
> it is "ok" for the action to get picked up and executed.

Yeah, that'll get you past the problem.

> I'm game for the pgsql option if my testing doesn't work, though.

Here's my current work. Any multi-lingual SQL experts out there care to
vet that the Postgresql below accomplishes the same goal as the Oracle SQL
below? I know that the Postgresql "works", in that it is syntactically
correct - but since I have no data in the broken state, I haven't seen it
actually *work*, as in fix the problem.

What we're trying to accomplish is to recursively find and remove all
rhnServerActions, that belong to rhnActions, that have *other* rhnActions
as their prerequisites, where the prerequisite rhnAction has NO
rhnServerActions.  Whew.  In other words, the action at the head of the
chain has been cancelled, but the followon actions didn't get to hear
about the cancellation.

Andy - you could change the pgres from "delete from" to "select * from",
and peek at the results. If they look like the ones that are giving you
heartburn, *then* run as a delete.

Also, db-backup strongly recommended (as always when doing db-surgery...)

ORACLE
===
delete from rhnserveraction rsa
 where rsa.action_id in (
   select a.id
 from rhnaction a
start with a.id in (
   select a1.id
 from rhnaction a1
where a1.prerequisite is null
  and not exists (
select 1 from rhnserveraction sa where sa.action_id = a1.id
  )
)
connect by prior a.id = a.prerequisite
 );
===

POSTGRESQL: (8.4)
===
delete from rhnserveraction rsa
 where rsa.action_id in (
   with recursive rq as (
 select id, prerequisite
 from   rhnaction
 where  id in (
   select a.id 
 from rhnaction a
where a.prerequisite is null
  and not exists (
select 1 from rhnserveraction sa where sa.action_id = a.id
  )
 )
 union all
 select a1.id, a1.prerequisite
 from   rhnaction a1
 join rq on a1.id = rq.prerequisite
   )
   select id
   from rq
);
===
 
G


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

Re: [Spacewalk-list] unable to cancel pending actions!

[Andy Ingham]

Grant --

Thanks for the offer.  I am testing a workaround of "breaking" OSAD
connectivity and disabling actions on the client end until the point when
it is "ok" for the action to get picked up and executed.

I'm game for the pgsql option if my testing doesn't work, though.

Best,
Andy

On 2/25/14 9:39 AM, "Grant Gainey"  wrote:

Hey Andy,

There's a fix that keeps you from getting into this state in the next
version of SW. Unfortunately, the fix won't help once you're already
broken.

I have some Oracle SQL that will fix this, but it'll take me a bit to
translate to pgres - the Oracle code uses START WITH ...CONNECT BY, which
I have to convert to a Postgresql WITH RECURSIVE, which is kind of
exciting.

Assuming I can pull it together - are you comfortable running direct SQL
against your SW's postgres?

G

- Original Message -
> I believe the ability to select MULTIPLE systems for a package action and
> link that with an arbitrary script on ALL those selected systems (such as
> a post-update reboot) was new in spacewalk 2.0 (in prior versions, it was
> only possible to link a package action with a remote command on one
>system
> at a time).
> 
> It seems that the problem I'm encountering is directly related to this
>new
> functionality, in that I am unable to CANCEL "linked" actions that were
> set up IN BULK.  (Regardless of whether I try to cancel individual
> actions, individual systems, all events together, via GUI, or via
> spacecmd).
> 
> The reboots need to be cancelled, so I'm guessing I'll have to DELETE the
> systems from spacewalk and re-add them.
> 
> Any other ideas, short of this drastic action?
> 
> Andy
> 
> 
> 
> On 2/24/14 4:45 PM, "Andy Ingham"  wrote:
> 
> Either in the GUI or via spacecmd.
> 
> spacecmd {SSM:0}> schedule_cancel 30953 30741 30740 30739 30738 30737
>30736
> ERROR: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: null
> 
> 
> 
> 
> I've tried restarting both the spacewalk stack AND postgres
> 
> 
> Errors in /var/log/tomcat6/catalina.out seem to indicate it is unhappy
> about the fact that the events are (package updates & arbitrary scripts)
> scheduled together.
> 
> I REALLY need to be able to cancel these events sometime in the next 24
> hours.
> 
> Is there any way to force them to clear?
> 
> 
> I just upgraded to Spacewalk 2.0 (still with a local postgres 8.4
>backend)
> 
> 
> 
> Help!
> 
> Andy
> 
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
> 
> 
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
> 


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

Re: [Spacewalk-list] unable to cancel pending actions!

[Andy Ingham]

I believe the ability to select MULTIPLE systems for a package action and
link that with an arbitrary script on ALL those selected systems (such as
a post-update reboot) was new in spacewalk 2.0 (in prior versions, it was
only possible to link a package action with a remote command on one system
at a time).

It seems that the problem I'm encountering is directly related to this new
functionality, in that I am unable to CANCEL "linked" actions that were
set up IN BULK.  (Regardless of whether I try to cancel individual
actions, individual systems, all events together, via GUI, or via
spacecmd).

The reboots need to be cancelled, so I'm guessing I'll have to DELETE the
systems from spacewalk and re-add them.

Any other ideas, short of this drastic action?

Andy



On 2/24/14 4:45 PM, "Andy Ingham"  wrote:

Either in the GUI or via spacecmd.

spacecmd {SSM:0}> schedule_cancel 30953 30741 30740 30739 30738 30737 30736
ERROR: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: null




I've tried restarting both the spacewalk stack AND postgres


Errors in /var/log/tomcat6/catalina.out seem to indicate it is unhappy
about the fact that the events are (package updates & arbitrary scripts)
scheduled together.

I REALLY need to be able to cancel these events sometime in the next 24
hours.

Is there any way to force them to clear?


I just upgraded to Spacewalk 2.0 (still with a local postgres 8.4 backend)



Help!

Andy


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


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

[Spacewalk-list] unable to cancel pending actions!

[Andy Ingham]

Either in the GUI or via spacecmd.

spacecmd {SSM:0}> schedule_cancel 30953 30741 30740 30739 30738 30737 30736
ERROR: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: null




I've tried restarting both the spacewalk stack AND postgres


Errors in /var/log/tomcat6/catalina.out seem to indicate it is unhappy
about the fact that the events are (package updates & arbitrary scripts)
scheduled together.

I REALLY need to be able to cancel these events sometime in the next 24
hours.

Is there any way to force them to clear?


I just upgraded to Spacewalk 2.0 (still with a local postgres 8.4 backend)



Help!

Andy


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

Re: [Spacewalk-list] timestamps and the spacecmd API

[Andy Ingham]

Jon and Robert --

Thanks for your responses!  I was aware of those modules and have been
going around in circles with them for longer than I'd like to admit.

I guess I was hoping that someone far better at python than me would have
the few lines of code already written that work with comparing the
"completed_date" value from the spacewalk API to some current timestamp.

There appear to be about 100 potential ways of doing this, but I've been
unable to fit the pieces together for a single one of them!  I'll blame
that on my newness to writing python.

If anyone has any code that is working in python against the spacewalk API
and able to evaluate how long ago an event "completed", please let me know?

This has got to be easier than I've made it thus far.

Best wishes,
Andy




On 2/6/14 2:35 PM, "Jon Miller"  wrote:

You can do both with the datetime[1] module in Python.

E.g. 
from datetime import datetime, timedelta
completed_date = datetime.strptime('20131230T23:00:24', '%Y%m%dT%H:%M:%S')
if completed_date > datetime.now() - timedelta(hours=-5):
print 'Need to do something'

The dateutil (python-dateutil RPM) module is also nice about parsing a
variety of string representations of date and times.

-- Jon Miller

[1]: http://docs.python.org/2/library/datetime.html

andy.ing...@duke.edu writes:

> Hello all!
>
> I need to compare the "completed_date" from the listSystemEvents method
> (published at 
> 
>http://www.spacewalkproject.org/documentation/api/1.9/handlers/SystemHandl
>e
> r.html#listSystems ) to the current time (when my python script runs).
>
> The 'completed_date' is returned from the API in ISO8601 format, e.g.:
> 20131230T23:00:24
>
> I'm grabbing the current timestamp via datetime.datetime.now(), which
> returns a format like: 2014-02-06 13:05:47.583122
>
>
>
> Has anyone got python code that compares two timestamps for use with the
> spacewalk API?  (Ultimately, I want to create a conditional that says,
>"if
> the event completed less than X hours ago, do Y")
>
> TIA!
>
>
> Andy
>
> Andy Ingham
> IT Infrastructure
> Fuqua School of Business
> Duke University
>
>
>
>
>
>
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

-- 
Jon Miller

___
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] timestamps and the spacecmd API

[Andy Ingham]

Hello all!

I need to compare the "completed_date" from the listSystemEvents method
(published at 
http://www.spacewalkproject.org/documentation/api/1.9/handlers/SystemHandle
r.html#listSystems ) to the current time (when my python script runs).

The 'completed_date' is returned from the API in ISO8601 format, e.g.:
20131230T23:00:24

I'm grabbing the current timestamp via datetime.datetime.now(), which
returns a format like: 2014-02-06 13:05:47.583122



Has anyone got python code that compares two timestamps for use with the
spacewalk API?  (Ultimately, I want to create a conditional that says, "if
the event completed less than X hours ago, do Y")

TIA!


Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University







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

Re: [Spacewalk-list] SELinux with spacewalk

[Andy Ingham]

Michael --

Thanks for letting me know; I won't spend time trying to untangle it!

Best,
Andy

On 1/24/14 4:59 AM, "Michael Mraka"  wrote:

Andy Ingham wrote:
% One lingering issue is that the Monitoring functionality is not entirely
% happy with SELinux.  I suspect it has something to do with the contexts
% that the processes are running in.

Hi Andy,

There's sad news about SELinux & Monitoring: it isn't 100% finish yet.
So it might work for a simple use cases but don't expect it to work in
any real world environment. :(

For now there's no better advice than setenforce Permissive if you use
monitoring.


Regards,

--
Michael Mráka
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] SELinux with spacewalk

[Andy Ingham]

One lingering issue is that the Monitoring functionality is not entirely
happy with SELinux.  I suspect it has something to do with the contexts
that the processes are running in.

>From my server:

$ ps -aefZ | grep nocpul

unconfined_u:system_r:initrc_t:s0 root   19497 1  0 14:03 pts/0
00:00:00 /usr/bin/perl /usr/bin/gogo.pl --fname=NotifEscalator
--user=nocpulse --hbfile=/var/log/nocpulse/notif-escalator.log
--hbfreq=300 --hbcheck=600 -- /usr/bin/notif-escalator
unconfined_u:system_r:initrc_t:s0 nocpulse 19498 19497  0 14:03 pts/0
00:00:00 /usr/bin/perl /usr/bin/gogo.pl --fname=NotifEscalator
--user=nocpulse --hbfile=/var/log/nocpulse/notif-escalator.log
--hbfreq=300 --hbcheck=600 -- /usr/bin/notif-escalator
unconfined_u:system_r:initrc_t:s0 nocpulse 19499 19498  0 14:03 pts/0
00:00:00 /usr/bin/perl /usr/bin/notif-escalator


>From the documentation at
https://fedorahosted.org/spacewalk/wiki/Features/SELinux (under
"Monitoring" heading):

root:system_r:spacewalk_monitoring_t root 1861  0.0  0.1  14596  1500
pts/2S12:06   0:00 /usr/bin/perl /usr/bin/gogo.pl
--fname=GenerateNotifConfig --us
root:system_r:spacewalk_monitoring_t nocpulse 1862 0.0  0.2 14596 2460
pts/2   S12:06   0:00 /usr/bin/perl /usr/bin/gogo.pl
--fname=GenerateNotifConfig --us
root:system_r:spacewalk_monitoring_t nocpulse 1863 0.0  2.1 107412 20240
pts/2 S12:06   0:00 /usr/bin/perl /usr/bin/generate-config




I'm guessing that my various monitoring processes should be running with
"root:system_r:spacewalk_monitoring_t" instead of
"unconfined_u:system_r:initrc_t:s0".  How do I resolve that?

(I already have the "spacewalk-monitoring-selinux" RPM installed!)


Thanks in advance!

Andy


On 1/23/14 1:00 PM, "Andy Ingham"  wrote:

I've revisited my non-standard /var/satellite setup and have learned a lot
more about SELinux to boot.

I have a few remaining errors to double-check, but believe I'm at the
point where SELinux will work properly with my spacewalk.

Thanks, everyone!

Andy

On 1/16/14 4:29 AM, "Michael Mraka"  wrote:

Andy Ingham wrote:
% Thanks, Michael and Jan, for your responses.
% 
% I currently have SELinux in 'permissive' mode and have been reviewing the
% 'sealert -a audit.log' output periodically.
% 
% Thanks to your confirmation, I'm fairly certain now that the issues I'm
% seeing are related to a non-standard setup I've got with the
% /var/satellite filesystem.

If your data subtree is /somewhere/else instead of standard /var/satellite
use

semanage fcontext -a -e /var/satellite /somewhere/else

to fix it (see man semanage).


% May be one more reason for me to revisit my current (non-standard) setup.
% 
% Andy


Regards,

--
Michael Mráka
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] SELinux with spacewalk

[Andy Ingham]

I've revisited my non-standard /var/satellite setup and have learned a lot
more about SELinux to boot.

I have a few remaining errors to double-check, but believe I'm at the
point where SELinux will work properly with my spacewalk.

Thanks, everyone!

Andy

On 1/16/14 4:29 AM, "Michael Mraka"  wrote:

Andy Ingham wrote:
% Thanks, Michael and Jan, for your responses.
% 
% I currently have SELinux in 'permissive' mode and have been reviewing the
% 'sealert -a audit.log' output periodically.
% 
% Thanks to your confirmation, I'm fairly certain now that the issues I'm
% seeing are related to a non-standard setup I've got with the
% /var/satellite filesystem.

If your data subtree is /somewhere/else instead of standard /var/satellite
use

semanage fcontext -a -e /var/satellite /somewhere/else

to fix it (see man semanage).


% May be one more reason for me to revisit my current (non-standard) setup.
% 
% Andy


Regards,

--
Michael Mráka
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] SELinux with spacewalk

[Andy Ingham]

Thanks, Michael and Jan, for your responses.

I currently have SELinux in 'permissive' mode and have been reviewing the
'sealert -a audit.log' output periodically.

Thanks to your confirmation, I'm fairly certain now that the issues I'm
seeing are related to a non-standard setup I've got with the
/var/satellite filesystem.

May be one more reason for me to revisit my current (non-standard) setup.

Andy

On 1/15/14 1:57 AM, "Jan Pazdziora"  wrote:

On Mon, Jan 13, 2014 at 05:44:14PM +, Andy Ingham wrote:
> Thinking of trying to activate SELinux on my spacewalk server.  The info
> I'm finding on the web is all roughly 3 years old (and multiple spacewalk
> versions behind current).  Is there more recent documentation that I
> failed to find?
> 
> I'm currently running spacewalk 1.9, on CentOS 6.5.
> 
> Using the older documentation, I've got these packages installed:
> 
> spacewalk-selinux
> osa-dispatcher-selinux
> spacewalk-monitoring-selinux
> 
> [ jabberd-selinux  <-- NOT INSTALLED; NO LONGER AVAILABLE / NECESSARY?]
> 
> 
> but but have not done any special tweaking of contexts or local policies.
> 
> Any particular gotchas I should be on the lookout for?

Do you currently have SELinux disabled or permissive?

-- 
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat

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


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

[Spacewalk-list] SELinux with spacewalk

[Andy Ingham]

Thinking of trying to activate SELinux on my spacewalk server.  The info
I'm finding on the web is all roughly 3 years old (and multiple spacewalk
versions behind current).  Is there more recent documentation that I
failed to find?

I'm currently running spacewalk 1.9, on CentOS 6.5.

Using the older documentation, I've got these packages installed:

spacewalk-selinux
osa-dispatcher-selinux
spacewalk-monitoring-selinux

[ jabberd-selinux  <-- NOT INSTALLED; NO LONGER AVAILABLE / NECESSARY?]


but but have not done any special tweaking of contexts or local policies.

Any particular gotchas I should be on the lookout for?

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University















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

Re: [Spacewalk-list] Failed to delete system‏

[Andy Ingham]

Javier --

My vague recollection (from about 15 months ago) was that spacewalk 1.8 had 
issues with cobbler 2.2.x

When I manually downgraded cobbler back to 2.0.x, I was again able to delete 
systems.

(HOWEVER, I seem to recall that that downgrade then BROKE my OSAD 
functionality.)

Silver lining is that at spacewalk version 1.9, everything seems to work fine 
with cobbler 2.2.x

I'm sure others with better memories can fill in more accurate details, but you 
should definitely focus on your cobbler setup.

Andy

From: "Valencia ..." mailto:fjvalenc...@hotmail.com>>
Reply-To: "spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Date: Friday, December 13, 2013 10:19 PM
To: "spacewalk-list@redhat.com" 
mailto:spacewalk-list@redhat.com>>
Subject: [Spacewalk-list] Failed to delete system‏

When trying todelete a system,sends me the following error

"Could not deletethe system profile 111726.Review the Cobbler server."

Anyone who can help me to achieveremove systems that no longer exist?

thanks

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

Re: [Spacewalk-list] OSAD auditing

[Andy Ingham]

I've always just done a super simplistic:

spacecmd system_details *.duke.edu > temp.txt

Followed by a

grep -c offline temp.txt

Followed, if need be, by searching through the temp file to see the actual
hosts.

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University






On 11/18/13 11:17 AM, "Paul Robert Marino"  wrote:

It could be done via the API's

http://www.spacewalkproject.org/documentation/api/1.9/handlers/SystemHandle
r.html#listActiveSystems

http://www.spacewalkproject.org/documentation/api/1.9/handlers/SystemHandle
r.html#listInactiveSystems

http://www.spacewalkproject.org/documentation/api/1.9/handlers/SystemHandle
r.html#getDetails

but I don't know of a tool that does it out of the box.

On Mon, Nov 18, 2013 at 9:29 AM, Coffman, Anthony J
 wrote:
> Is there any easy way to audit for offline OSAD agents at a mass level
> (hundreds of machines)?
>
>
>
> The method I¹ve been using is to schedule a hardware refresh for the
>group
> and then manually going to look at systems that don¹t complete the
>action in
> a short period of time.  Surely , there must be a better way?
>
>
>
> Thanks,
>
> --Tony Coffman
>
>
>
>
> ___
> 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] how do I clear spacewalk's repo-sync cache?

[Andy Ingham]

Robert --

My issue had been that the HTTP proxy cache had stale content (in that
repodata had been updated at archive.linux.duke.edu but was not yet
reflected in the squid cache).

Two options, one or both of which worked for me (I can't remember at this
point):
* Bypass the proxy and go directly to the repo.  (If that is a 
networking
possibility, anyway).
* Force a restart of the squid proxy (as the best (only?) way of forcing
a full cleaning of its cache)

FWIW,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University





On 8/21/13 6:21 PM, "Boyd, Robert"  wrote:

Andy or anyone,

What did you do to clear the problem?  Did it clear up by virtue the stale
mirror(s) eventually catching up?  Or did you change the URL you were
using for the repository?

I found I had the same problem today and changed the URL to point to
dl.fedora.org instead of download.fedora.org and got it to work.   I'm
sure in the long run it would be better to switch it back to the one that
points to the mirrors.


Robert Boyd
Senior Systems Engineer | Peoplefluent
p. 919-645-2972 | c. 919-306-4681
e. robert.b...@peoplefluent.com
Visit: www.peoplefluent.com | Read: Peoplefluent Blog
Follow: @peoplefluent | Download: iPad App





-Original Message-
From: spacewalk-list-boun...@redhat.com
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Andy Ingham
Sent: Monday, April 29, 2013 11:56 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] how do I clear spacewalk's repo-sync cache?

Jan --

That appears to have been the issue.

Many thanks!

Andy


On 4/29/13 11:04 AM, "Jan Pazdziora"  wrote:

...

Is it possible you use a caching HTTP proxy (possibly a transparent
one) that gives you the stale data?

If you do

GET 
'http://archive.linux.duke.edu/pub/epel/6/x86_64/repodata/repomd.xml'
| grep primary.sqlite

do you see the correct content?

--
Jan Pazdziora
Principal Software Engineer, 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] Possible to associate a remote command with a config file deploy (as opposed to a package update)?

[Andy Ingham]

Tomas --

Thanks for confirming that I wasn't missing something.

Best,
Andy


On 8/14/13 5:39 AM, "Tomas Lestach"  wrote:

> I'd like to use spacewalk for version control of (for instance)
> apache
> config files.

Spacewalk just remembers the revisions, as a version control it's very
very limited.

>  Is there a way to associate a remote command (like a
> 'configtest' or a 'reload') immediately AFTER the file gets deployed?
> 
> I'd hoped that there would be an analogous function to the "Add
> Remote
> Command to Package Upgrade" button that is available when scheduling
> package updates to a single server.

No, there isn't.

> 
> Essentially, though, it would be tying the "Remote Command" function
> to
> the "Deploy File" function.
> 
> Is this possible somehow?

Sure, it is. As far I know, we do not have this feature on our scope.
However, somebody from the community might be interested to work on it.


Regards,

--
Tomas Lestach
Red Hat 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

[Spacewalk-list] Possible to associate a remote command with a config file deploy (as opposed to a package update)?

[Andy Ingham]

I'd like to use spacewalk for version control of (for instance) apache
config files.  Is there a way to associate a remote command (like a
'configtest' or a 'reload') immediately AFTER the file gets deployed?

I'd hoped that there would be an analogous function to the "Add Remote
Command to Package Upgrade" button that is available when scheduling
package updates to a single server.

Essentially, though, it would be tying the "Remote Command" function to
the "Deploy File" function.

Is this possible somehow?

Thanks in advance,
Andy


Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University






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

Re: [Spacewalk-list] Anyone using Ansible along side Spacewalk?

[Andy Ingham]

Jon --

Very belatedly, thanks for the script and the pointer to it.  Very nice and 
very helpful!

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University


From: Giovanni Torres mailto:giovtor...@hotmail.com>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Friday, June 7, 2013 8:24 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] Anyone using Ansible along side Spacewalk?

Only just started to use ansible. ill take a look at your script. i was 
thinking of a way to keep the hosts in sync, but havent sat down to write 
anything yet.


From: joneb...@gmail.com<mailto:joneb...@gmail.com>
Date: Wed, 22 May 2013 08:37:17 -0700
To: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
Subject: [Spacewalk-list] Anyone using Ansible along side Spacewalk?

Thought I'd share a potentially helpful tip for other Spacewalk users on the 
list. While I've been happy with Spacewalk, I've also been using Ansible[1] for 
some extra ad-hoc configurations. I wrote a inventory script[2] which uses the 
spacewalk-report package and feeds the server groupings to Ansible that you 
have defined within Spacewalk. Since I name my profile and system groups the 
same, that means I can also now consistently reference that group name in a 
ansible playbook or single command.

-- Jon Miller

[1]: http://ansible.cc/
[2]: 
https://github.com/ansible/ansible/blob/devel/plugins/inventory/spacewalk.py

___ Spacewalk-list mailing list 
Spacewalk-list@redhat.com<mailto: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] how do I clear spacewalk's repo-sync cache?

[Andy Ingham]

Jan --

That appears to have been the issue.

Many thanks!

Andy


On 4/29/13 11:04 AM, "Jan Pazdziora"  wrote:

On Mon, Apr 29, 2013 at 03:00:31PM +0000, Andy Ingham wrote:
> Hello --
> 
> I'm trying to do a repo-sync and it is failing because the
> *-primary.sqlite.bz2 (and other files) changed on the mirror yesterday.
> 
> 
> Even after manually deleting /var/cache/rhn/reposync/epel6-centos6-x86_64
> 
> I continue to get the same error (see below), and spacewalk repopulates
> that cache directory with the OLD references.

Is it possible you use a caching HTTP proxy (possibly a transparent
one) that gives you the stale data?

If you do

GET 
'http://archive.linux.duke.edu/pub/epel/6/x86_64/repodata/repomd.xml'
| grep primary.sqlite

do you see the correct content?

-- 
Jan Pazdziora
Principal Software Engineer, 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

[Spacewalk-list] how do I clear spacewalk's repo-sync cache?

[Andy Ingham]

Hello --

I'm trying to do a repo-sync and it is failing because the
*-primary.sqlite.bz2 (and other files) changed on the mirror yesterday.


Even after manually deleting /var/cache/rhn/reposync/epel6-centos6-x86_64

I continue to get the same error (see below), and spacewalk repopulates
that cache directory with the OLD references.

How do I force a reload of that data?

TIA,

Andy


[root@XYZ /etc/yum.repos.d] $ spacewalk-repo-sync --channel
epel6-centos6-x86_64
Repo URL: http://archive.linux.duke.edu/pub/epel/6/x86_64/
ERROR: failure: 
repodata/6af42b123225b88fa2baabad6337bcf380858146e3154eeccb3d8474c783485d-p
rimary.sqlite.bz2 from epel6-centos6-x86_64: [Errno 256] No more mirrors
to try.



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

Re: [Spacewalk-list] coreutils don't update properly via spacewalk

[Andy Ingham]

Thanks, Jan and Scott, for getting me on the right track.

Very helpful!

Andy


On 4/11/13 1:22 PM, "Scott Worthington" 
wrote:

On 4/11/2013 10:42, Andy Ingham wrote:
> First, let me say that I am very willing to believe that my yum setup is
> sub-optimal for the spacewalk context, and appreciate help optimizing it.
>
> Having said that,
>
> We don't have any non-standard repos, generally, and for the clients I'm
> checking, there aren't any defined that aren't "spacewalk-managed".
>
> For that reason, we haven't set up the sort of "custom" setup that Scott
> describes below.
>
> What continues to confuse me about the issue is that:
>
> (a) when the coreutils packages are in need of updating, GUI-initiated
> updates from spacewalk don't work (but a local yum update does)
>
> (b) when the coreutils packages are NOT in need of updating,
>GUI-initiated
> updates from spacewalk DO work
>
> (Sure makes me think it is something specific to THOSE PACKAGES)
>
>
> I certainly see from that log entry that it is unhappy about the baseurl
> for "CentOS-Base", but my reading of the comments for that file
> (/etc/yum.repos.d/CentOS-Base.repo), indicate that I WANT the baseurl
> commented out:
>
> # The mirror system uses the connecting IP address of the client and the
> # update status of each mirror to pick mirrors that are updated to and
> # geographically close to the client.  You should use this for CentOS
> updates
> # unless you are manually picking other mirrors.
> #
> # If the mirrorlist= does not work for you, as a fall back you can try
>the
> # remarked out baseurl= line instead.
> #
>
>
>
>
> OR:
> Is it the case that for spacewalk-managed clients, there is no need for
> ANYTHING in /etc/yum.repos.d/ UNLESS it is a repo that spacewalk DOESN'T
> manage?
>
>
> Thanks again for help in quelling my confusion.
>
> Andy

Here are two references to previous discussions regarding this issue:

http://www.redhat.com/archives/spacewalk-list/2010-March/msg0.html

http://www.redhat.com/archives/spacewalk-list/2009-December/msg00057.html

You typically disable all foreign yum repositories and allow only
Spacewalk/Satellite as your RPM source.
You do not enable both eternal repos and Spacewalk/Satellite channels at
the same time for the SAME source of repository files.

In a hybird setup where you are using both external repos and
Spacewalk/Satellite channels, you create the directory "mkdir -p
/etc/yum.repos.d/custom", place a symlink from
/etc/yum.repos.d/custom/.repo  back to the file in
/etc/yum.repos.d/.repo since repos rpms place their configs
into /etc/yum.repos.d/ (such as elrepo-release-6-5.elrepo.noarch.rpm
places its repository rpm into /etc/yum.repos.d/).  Finally, alter the
variable "reposdir" in /etc/yum.conf to be
"reposdir=/etc/yum.repos.d/custom/".

Yum updates will then pull from SW/SS and also from enternal repos
without problems (except when you need http_proxy/https_proxy settings
and that's a totally different issue).

Hope that helps.

___
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] coreutils don't update properly via spacewalk

[Andy Ingham]

First, let me say that I am very willing to believe that my yum setup is
sub-optimal for the spacewalk context, and appreciate help optimizing it.

Having said that,

We don't have any non-standard repos, generally, and for the clients I'm
checking, there aren't any defined that aren't "spacewalk-managed".

For that reason, we haven't set up the sort of "custom" setup that Scott
describes below.

What continues to confuse me about the issue is that:

(a) when the coreutils packages are in need of updating, GUI-initiated
updates from spacewalk don't work (but a local yum update does)

(b) when the coreutils packages are NOT in need of updating, GUI-initiated
updates from spacewalk DO work

(Sure makes me think it is something specific to THOSE PACKAGES)


I certainly see from that log entry that it is unhappy about the baseurl
for "CentOS-Base", but my reading of the comments for that file
(/etc/yum.repos.d/CentOS-Base.repo), indicate that I WANT the baseurl
commented out:

# The mirror system uses the connecting IP address of the client and the
# update status of each mirror to pick mirrors that are updated to and
# geographically close to the client.  You should use this for CentOS
updates
# unless you are manually picking other mirrors.
#
# If the mirrorlist= does not work for you, as a fall back you can try the
# remarked out baseurl= line instead.
#




OR:
Is it the case that for spacewalk-managed clients, there is no need for
ANYTHING in /etc/yum.repos.d/ UNLESS it is a repo that spacewalk DOESN'T
manage?


Thanks again for help in quelling my confusion.

Andy






On 4/10/13 3:27 PM, "Scott Worthington" 
wrote:

On 4/10/2013 14:10, Jan Pazdziora wrote:
> On Wed, Apr 10, 2013 at 03:41:50PM +, Andy Ingham wrote:
>> Jan --
>>
>> The following is repeated 4 times at 20 second intervals within that log
>> on a sample host:
>>
>> [Tue Apr  9 09:25:52 2013] up2date
>> Traceback (most recent call last):
>>   File "/usr/sbin/rhn_check", line 385, in __run_action
>> (status, message, data) = CheckCli.__do_call(method, params, kwargs)
>>   File "/usr/sbin/rhn_check", line 377, in __do_call
>> method = getMethod.getMethod(method, "/usr/share/rhn/", "actions")
> [...]
>
>>   File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 662, in
>> _baseurlSetup
>> self.check()
>>   File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 426, in
>> check
>> 'Cannot find a valid baseurl for repo: %s' % self.id
>> : Cannot find a valid baseurl for repo:
>>base
> So, may we assume that your yum is misconfigured and that you have
> something in /etc/yum.repos.d called "base" which does not have the
> baseurl set?
>

Isn't best practice to alter /etc/yum.conf and change variable
"reposdir" to /etc/yum.repos.d/custom/ and then use symlinks from
/etc/yum.repos.d/custom/ back to /etc/yum.repos.d/ for repos outside of
your Spacewalk? (also mkdir /etc/yum.repos.d/custom)

Perhaps that step wasn't performed on clients and, like Jan said, you
are picking up a repo config in /etc/yum.repos.d/.

#cat /etc/yum.conf

[main]
cachedir=/var/cache/yum
reposdir=/etc/yum.repos.d/custom/
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
#bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=ht
tp://bugs.centos.org/bug_report_page.php?category=yum

# Note: yum-RHN-plugin doesn't honor this.
metadata_expire=1h

# Allow only up to 3 kernels to be installed at one time
installonly_limit = 3

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d/custom

___
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] coreutils don't update properly via spacewalk

[Andy Ingham]

Jan --

The following is repeated 4 times at 20 second intervals within that log
on a sample host:

[Tue Apr  9 09:25:52 2013] up2date
Traceback (most recent call last):
  File "/usr/sbin/rhn_check", line 385, in __run_action
(status, message, data) = CheckCli.__do_call(method, params, kwargs)
  File "/usr/sbin/rhn_check", line 377, in __do_call
method = getMethod.getMethod(method, "/usr/share/rhn/", "actions")
  File "/usr/share/rhn/up2date_client/getMethod.py", line 79, in getMethod
actions = __import__(modulename)
  File "/usr/share/rhn/actions/packages.py", line 273, in 
yum_base = YumAction()
  File "/usr/share/rhn/actions/packages.py", line 64, in __init__
self.doTsSetup()
  File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 84, in
doTsSetup
return self._getTs()
  File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 99, in
_getTs
self._getTsInfo(remove_only)
  File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 110, in
_getTsInfo
pkgSack = self.pkgSack
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 887, in

pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 669, in
_getSacks
self.repos.populateSack(which=repos)
  File "/usr/lib/python2.6/site-packages/yum/repos.py", line 279, in
populateSack
self.doSetup()
  File "/usr/lib/python2.6/site-packages/yum/repos.py", line 105, in
doSetup
self.ayum.plugins.run('postreposetup')
  File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 184, in run
func(conduitcls(self, self.base, conf, **kwargs))
  File "/usr/lib/yum-plugins/fastestmirror.py", line 197, in
postreposetup_hook
if downgrade_ftp and _len_non_ftp(repo.urls) == 1:
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 699, in

urls = property(fget=lambda self: self._geturls(),
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 696, in
_geturls
self._baseurlSetup()
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 662, in
_baseurlSetup
self.check()
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 426, in
check
'Cannot find a valid baseurl for repo: %s' % self.id
: Cannot find a valid baseurl for repo: base







On 4/10/13 2:29 AM, "Jan Pazdziora"  wrote:

On Tue, Apr 09, 2013 at 05:37:24PM +, Andy Ingham wrote:
> Jan --
> 
> These are CentOS 6.4 servers (upgraded from 6.3 within the last few
>weeks)
> & they only had a few packages that needed updating today, chief among
> them the "coreutils" and "coreutils-libs" packages.
> 
> Spacewalk server is at version 1.8
> 
> 
> rhn-client-tools is 1.8.26-1.el6 (systematically updated across the plant
> right after the spacewalk server upgrade)
> 
> 
> I'm scheduling updates via the Spacewalk GUI, and they fail with (the
>ever
> present) "Fatal error in Python code occurred [[6]]".

What is in /var/log/up2date on the client when this error shows up in
WebUI?

-- 
Jan Pazdziora
Principal Software Engineer, 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] coreutils don't update properly via spacewalk

[Andy Ingham]

Jan --

These are CentOS 6.4 servers (upgraded from 6.3 within the last few weeks)
& they only had a few packages that needed updating today, chief among
them the "coreutils" and "coreutils-libs" packages.

Spacewalk server is at version 1.8


rhn-client-tools is 1.8.26-1.el6 (systematically updated across the plant
right after the spacewalk server upgrade)


I'm scheduling updates via the Spacewalk GUI, and they fail with (the ever
present) "Fatal error in Python code occurred [[6]]".

As I say, once I update the coreutils and coreutils-libs packages
manually, GUI-initiated updates generally run fine.

Andy







On 4/9/13 12:17 PM, "Jan Pazdziora"  wrote:

On Tue, Apr 09, 2013 at 01:47:15PM +, Andy Ingham wrote:
> Looking for a sanity check here.
> 
> Certain packages won't update properly via spacewalk UNTIL "coreutils" is
> updated on that client.
> 
> The problem is that I'm unable to get the coreutils packages THEMSELVES
>to
> update via spacewalk.
> 
> So, I find myself having to connect to each client individually to "yum
> update coreutils".
> 
> At that point, I'm having success pushing updates to the clients that
> failed previously.
> 
> Of course, given those steps, I've not saved any time since I've already
> had to connect to each client.
> 
> Am I missing something about how to avoid this?

Can you be more specific about the exact OS you're using, Spacewalk
server version, RHN client tools version, as well as the exact
commands you run and the output you get?

-- 
Jan Pazdziora
Principal Software Engineer, 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

[Spacewalk-list] coreutils don't update properly via spacewalk

[Andy Ingham]

Looking for a sanity check here.

Certain packages won't update properly via spacewalk UNTIL "coreutils" is
updated on that client.

The problem is that I'm unable to get the coreutils packages THEMSELVES to
update via spacewalk.

So, I find myself having to connect to each client individually to "yum
update coreutils".

At that point, I'm having success pushing updates to the clients that
failed previously.

Of course, given those steps, I've not saved any time since I've already
had to connect to each client.

Am I missing something about how to avoid this?

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] inability to completely purge orphaned packages

[Andy Ingham]

Thanks, Jan, for the reply.

I eventually got things purged, but unfortunately don't recall exactly how
I did it.

Andy

On 3/22/13 11:37 AM, "Jan Pazdziora"  wrote:

On Fri, Feb 22, 2013 at 02:02:29PM +0000, Andy Ingham wrote:
> Hello again list --
> 
> I'm trying to use rhnpush to add a couple packages to a custom channel.
>I
> initially created a channel, added the packages and then (since I needed
> to define a different parent) deleted the channel, leaving the packages
> orphaned.  I have (1) used the GUI to locate and remove the packages, and
> (2) run the following:  spacewalk-data-fsck -v --remove

Did you verify that they indeed got removed from /var/satellite?

> Despite these attempts, each time I try to re-add the packages to the new
> channel (with correct parentage) I get the following errors:
> 
> [root ~] $ rhnpush --nosig --channel=fuqua-rhnpush-centos5-x86_64
> --server=http://localhost/APP --dir=/opt/installs/rhnpush_stage/x86_64 -v
> Connecting to http://localhost/APP
> 
> Package /opt/installs/rhnpush_stage/x86_64/jdk-7u15-linux-x64.rpm already
> exists on the RHN Server-- Skipping Upload
> Package /opt/installs/rhnpush_stage/x86_64/jdk-6u41-linux-amd64.rpm
> already exists on the RHN Server-- Skipping UploadŠ.

Is it possible that the packages indeed already exist on the server,
just maybe with different signature (signed with beta key or
something)?

-- 
Jan Pazdziora
Principal Software Engineer, 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] trick to doing CentOS 6.3 > 6.4 update via spacewalk?

[Andy Ingham]

Thanks, everyone, for the lively discussion!

I'm still relatively new to spacewalk (less than a year) and have never
set up any channels beyond the default ones I originally created with the

/usr/bin/spacewalk-common-channels

command.  Thanks for the ideas of some things to try.



As for what happens when I kick off a full update (selecting all 290+
packages in the GUI), the action is picked up quickly, rhn_check runs for
a LONG time on the client (~ 2.5 hours) and then the action fails with:

Error while executing packages action: Error Downloading Packages:
tcsh-6.17-24.el6.x86_64: failure: Packages/tcsh-6.17-24.el6.x86_64.rpm
from base: [Errno 256] No more mirrors to try. gawk-3.1.7-10.el6.x86_64:
failure: Packages/gawk-3.1.7-10.el6.x86_64.rpm from base: [Errno 256] No
more mirrors to try. strace-4.5.19-1.17.el6.x86_64: failure:
Packages/strace-4.5.19-1.17.el6.x86_64.rpm from base: [Errno 256] No more
mirrors to try. plymouth-graphics-libs-0.8.3-27.el6.centos.x86_64:
failure: Packages/plymouth-graphics-libs-0.8.3-27.el6.centos.x86_64.rpm
from base: [Errno 256] No more mirrors to try.
krb5-libs-1.10.3-10.el6.x86_64: failure:
Packages/krb5-libs-1.10.3-10.el6.x86_64.rpm from base: [Errno 256] No more
mirrors to try. glibc-2.12-1.107.el6.x86_64: failure:
Packages/glibc-2.12-1.107.el6.x86_64.rpm from base: [Errno 256] No more
mirrors to try. cifs-utils-4.8.1-18.el6.x86_64: failure:
Packages/cifs-utils-4.8.1-18.el6.x86_64.rpm from base: [Errno 256] No more
mirrors to try. mtdev-1.1.2-5





Andy



On 3/12/13 4:08 AM, "Jan Pazdziora"  wrote:

On Mon, Mar 11, 2013 at 07:02:50PM +0000, Andy Ingham wrote:
> Friendly list --
> 
> Now that CentOS 6.4 is available, I have 40+ servers that I'd like to
> update from 6.3 > 6.4.
> 
> I just finished bringing all the (spacewalk-managed) servers up to date
> with osad, rhn-check, rhn-client-tools, rhn-setup, rhnlib, etc.  (I'm at
> version 1.8 still.)
> 
> Scheduling the update via spacewalk results in a failure, though.

Is the failure manifested somehow, perhaps by an error message which
could help the audience help you to figure out what is wrong?

-- 
Jan Pazdziora
Principal Software Engineer, 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

[Spacewalk-list] trick to doing CentOS 6.3 > 6.4 update via spacewalk?

[Andy Ingham]

Friendly list --

Now that CentOS 6.4 is available, I have 40+ servers that I'd like to
update from 6.3 > 6.4.

I just finished bringing all the (spacewalk-managed) servers up to date
with osad, rhn-check, rhn-client-tools, rhn-setup, rhnlib, etc.  (I'm at
version 1.8 still.)

Scheduling the update via spacewalk results in a failure, though.

Does the 6.3 > 6.4 upgrade need to happen via yum from the client?  Or is
there some trick to getting it to take via spacewalk?

TIA,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] Clients show need for updates in GUI, but updates are not needed

[Andy Ingham]

Michael --

Thanks for the response.  I've found that while there is often a way to
coax any given client to be happy with spacewalk, it often takes more
manual intervention than I'd like.

I did a server upgrade to 1.8 yesterday and am taking the opportunity to
visit each client to also upgrade the client repo to 1.8.  I'm fiddling
with a daily cron script on each client that does some steps (such as
rhn-profile-sync and osad restart) that seems to be beneficial.  I remain
unable to find any set of actions, however, (either server-side or
client-side) that can make my group of 65 (primarily CentOS 6) servers
consistently happy.

Andy

On 2/25/13 4:02 AM, "Michael Mraka"  wrote:

Andy Ingham wrote:
% Thanks, Michael.  I've looked at those logs as well and am noticing sql
% connection errors such as:
% 
% /var/log/rhn/osa-dispatcher.log:2013/02/19 09:14:12 -04:00 2452 0.0.0.0:
% osad/jabber_lib.main('ERROR', 'Traceback (most recent call last):\n  File
% "/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n
% self.setup_config(config)\n  File
"/usr/share/rhn/osad/osa_dispatcher.py",
% line 112, in setup_config\nrhnSQL.initDB()\n  File
% "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
% line 124, in initDB\n__init__DB(backend, host, port, username,
% password, database)\n  File
% "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
% line 55, in __init__DB\n__DB.connect()\n  File
% 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
% .py", line 171, in connect\nreturn self.connect(reconnect=0)\n  File
% 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
% .py", line 160, in connect\npassword=self.password)\nSQLConnectError:
% (None, None, \'spaceschema\', \'Attempting Re-Connect to the database
% failed\')\n')

Osa-dispatcher complaining about not been able to connect to database -
it's most likely temporary database outage.

On the other hand osa-dispatcher doesn't come into play when running
yum update or rhn_check. So there should be a different (ISE related)
error.

% Thankfully, it *does* appear that completely deleting and re-registering
% clients does the trick.  I sure wish there was a quicker way to
% consistently flush these errors across a large number of clients, though.
% 
% Andy
% 
% On 2/22/13 3:56 AM, "Michael Mraka"  wrote:
% 
% Andy Ingham wrote:
% % Hello list --
% % 
% % I've got a number of spacewalk clients that indicate in the GUI that
they
% % have critical updates needed, but the updates have been done (and yum
on
% % the client is happy).
% % 
% % I've tried everything I can think of to clear this discrepancy to no
% avail
% % (rhn-profile-sync, restarts of osad and rhnsd, GUI-forced "package
% % verify", spacewalk server restart, re-registration of the client).
% ...
% % 
% %  0, 'name': 'packages.verify'})
% % XMLRPC ProtocolError: 
% 
% Hi Andy,
% 
% there should be more information about Internal Server Error in
% /var/log/httpd/*error_log and/or /var/log/rhn/*.log.

Regards,

--
Michael Mráka
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

[Spacewalk-list] inability to completely purge orphaned packages

[Andy Ingham]

Hello again list --

I'm trying to use rhnpush to add a couple packages to a custom channel.  I
initially created a channel, added the packages and then (since I needed
to define a different parent) deleted the channel, leaving the packages
orphaned.  I have (1) used the GUI to locate and remove the packages, and
(2) run the following:  spacewalk-data-fsck -v --remove



Despite these attempts, each time I try to re-add the packages to the new
channel (with correct parentage) I get the following errors:

[root ~] $ rhnpush --nosig --channel=fuqua-rhnpush-centos5-x86_64
--server=http://localhost/APP --dir=/opt/installs/rhnpush_stage/x86_64 -v
Connecting to http://localhost/APP

Package /opt/installs/rhnpush_stage/x86_64/jdk-7u15-linux-x64.rpm already
exists on the RHN Server-- Skipping Upload
Package /opt/installs/rhnpush_stage/x86_64/jdk-6u41-linux-amd64.rpm
already exists on the RHN Server-- Skipping UploadŠ.



If I add the "--force" option, it gives me this error:

Error Message:
Package Upload Failed
Error Class Code: 55
Error Class Info: 
 The --force rhnpush option is disabled on this server.
 Please contact your Satellite administrator for more help.






Any ideas for how to clear this so that I can PROPERLY add the packages?

Many thanks in advance.

Andy


Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University






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

Re: [Spacewalk-list] Clients show need for updates in GUI, but updates are not needed

[Andy Ingham]

Thanks, Michael.  I've looked at those logs as well and am noticing sql
connection errors such as:

/var/log/rhn/osa-dispatcher.log:2013/02/19 09:14:12 -04:00 2452 0.0.0.0:
osad/jabber_lib.main('ERROR', 'Traceback (most recent call last):\n  File
"/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n
self.setup_config(config)\n  File "/usr/share/rhn/osad/osa_dispatcher.py",
line 112, in setup_config\nrhnSQL.initDB()\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
line 124, in initDB\n__init__DB(backend, host, port, username,
password, database)\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py",
line 55, in __init__DB\n__DB.connect()\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py", line 171, in connect\nreturn self.connect(reconnect=0)\n  File
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py", line 160, in connect\npassword=self.password)\nSQLConnectError:
(None, None, \'spaceschema\', \'Attempting Re-Connect to the database
failed\')\n')



Thankfully, it *does* appear that completely deleting and re-registering
clients does the trick.  I sure wish there was a quicker way to
consistently flush these errors across a large number of clients, though.

Andy

On 2/22/13 3:56 AM, "Michael Mraka"  wrote:

Andy Ingham wrote:
% Hello list --
% 
% I've got a number of spacewalk clients that indicate in the GUI that they
% have critical updates needed, but the updates have been done (and yum on
% the client is happy).
% 
% I've tried everything I can think of to clear this discrepancy to no
avail
% (rhn-profile-sync, restarts of osad and rhnsd, GUI-forced "package
% verify", spacewalk server restart, re-registration of the client).
...
% 
%  0, 'name': 'packages.verify'})
% XMLRPC ProtocolError: 

Hi Andy,

there should be more information about Internal Server Error in
/var/log/httpd/*error_log and/or /var/log/rhn/*.log.

Regards,

--
Michael Mráka
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

[Spacewalk-list] Clients show need for updates in GUI, but updates are not needed

[Andy Ingham]

Hello list --

I've got a number of spacewalk clients that indicate in the GUI that they
have critical updates needed, but the updates have been done (and yum on
the client is happy).

I've tried everything I can think of to clear this discrepancy to no avail
(rhn-profile-sync, restarts of osad and rhnsd, GUI-forced "package
verify", spacewalk server restart, re-registration of the client).

I have some clients WITH THE SAME SETUP that are just fine.  I'm using
spacewalk 1.7.

The only clue I have is the following TRUNCATED output from rhn_check.
Any ideas greatly appreciated!

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




TRUNCATED output from rhn_check on one of the affected clients:



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-c105b9de-4e0fd3a3 to keyring
D: added key gpg-pubkey-0608b895-4bd22942 to keyring
D: added key gpg-pubkey-863a853d-4f55f54d to keyring
D: Using legacy gpg-pubkey(s) from rpmdb
D: opening  db index   /var/lib/rpm/Providename rdonly mode=0x0
D: check_action{'action': "\n\npackages.verify\n\n\n\n\nlibtasn1

'2.el6', '', 'noarch'], ['rubygems', '1.3.7', '1.el6', '', 'noarch'],
['busybox', '1.15.1', '15.el6', '1', 'x86_64']],){'cache_only': None}
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-c105b9de-4e0fd3a3 to keyring
D: added key gpg-pubkey-0608b895-4bd22942 to keyring
D: added key gpg-pubkey-863a853d-4f55f54d 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: fastestmirror, rhnplugin
Config time: 0.038
D: rpcServer: Calling XMLRPC up2date.listChannels
Setting up Package Sacks
Loading mirror speeds from cached hostfile
 * base: centos.mirror.nac.net
 * epel: archive.linux.duke.edu
 * extras: centos.icyboards.com
 * updates: centos.mirror.netriplex.com
pkgsack time: 15.390
rpmdb time: 0.000
Checking for new repos for mirrors
repo time: 0.001
D: Called packages.verify
D: Sending back response(0, 'packages verified', {'verify_info':
[[('libtasn1', '2.3', '3.el6_2.1', '', 'x86_64'), []], [('libproxy-bin',
'0.3.0', '3.el6_3', '', 'x86_64'),



 0, 'name': 'packages.verify'})
XMLRPC ProtocolError: 
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



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

Re: [Spacewalk-list] problemscreating a scratch partition in my kickstart profile

[Andy Ingham]

Looks like the double-dashes on that line are actually single (long) dashes.  
Perhaps they got converted when some text editor was trying to be "helpful".

Just a guess.

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University


From: "J.W. slone" mailto:jslon...@yahoo.com>>
Reply-To: "J.W. slone" mailto:jslon...@yahoo.com>>, 
"spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Monday, November 19, 2012 3:11 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Cc: Jw Slone mailto:jw.sl...@atmel.com>>
Subject: [Spacewalk-list] problemscreating a scratch partition in my kickstart 
profile

part /boot --fstype=ext3 --size=200
part pv.01 --size=1000 --grow
part swap --size=1000   --maxsize=4000
part scratch –size=1000 
–maxsize=2000---when I take this 
partition line line out it works. How is this line wrong
volgroup myvg pv.01
logvol / --vgname=myvg --name=rootvol --size=1000 --grow
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] rhntaskorun issues

[Andy Ingham]

Hello list --

I haven't gotten any responses to my request from last week (below).

I'm also now noticing THESE errors in my Tomcat logs.  Any idea why?

Oct 29, 2012 1:46:22 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesJdbc
SEVERE: A web application registered the JBDC driver [org.postgresql.Driver] 
but failed to unregister it when the web application was stopped. To prevent a 
memory leak, the JDBC Driver has been forcibly unregistered.
Oct 29, 2012 1:46:22 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: A web application appears to have started a thread named [RHN Message 
Dispatcher] but has failed to stop it. This is very likely to create a memory 
leak.
Oct 29, 2012 1:46:22 PM org.apache.catalina.loader.WebappClassLoader 
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type [null] (value 
[com.redhat.rhn.common.hibernate.ConnectionManager$1@13742ad8]) and a value of 
type [null] (value [null]) but failed to remove it when the web application was 
stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.


Thanks,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University



From: Andy Ingham mailto:andy.ing...@duke.edu>>
Date: Wednesday, October 24, 2012 12:16 PM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: Re: [Spacewalk-list] rhntaskorun issues

Folks --

(Beth and I work in the same office)

We believe that we traced the pgsql problem (below) to some iSCSI connection 
issues.  Unfortunately, since we did not have a usable database dump, we ended 
up having to do the following:

from the spaceschema database:

truncate table rhntaskorun;

(this was done *without* the cascade option, so only that table was truncated.)

The good news is that we can now do SELECTS from all tables in the database 
without spectacular postgres crashes.

The bad news is that certain spacewalk functions are now broken (not 
surprisingly, due to the deletion of records above).

Specifically:

* going to https://our.spacewalk.server.edu/rhn/admin/SatSchedules.do results 
in "The scheduling service appears down. Please contact your Satellite 
administrator."

*  osa-dispatcher startup results in:  Starting osa-dispatcher: RHN 2349 
2012/10/24 11:14:23 -04:00: ('Error caught:',)
RHN 2349 2012/10/24 11:14:23 -04:00: ('Traceback (most recent call last):\n  
File "/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n
self.setup_config(config)\n  File "/usr/share/rhn/osad/osa_dispatcher.py", line 
112, in setup_config\nrhnSQL.initDB()\n  File 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py", line 
124, in initDB\n__init__DB(backend, host, port, username, password, 
database)\n  File 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py", line 
55, in __init__DB\n__DB.connect()\n  File 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
 line 171, in connect\nreturn self.connect(reconnect=0)\n  File 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
 line 160, in connect\npassword=self.password)\nSQLConnectError: (None, 
None, \'spaceschema\', \'Attempting Re-Connect to the database failed\')\n',)

* the rhn_taskomatic_daemon.log shows, among other things:  INFO   | jvm 1| 
2012/10/24 11:46:13 | WARNING: java.lang.NoClassDefFoundError: Could not 
initialize class net.sf.cglib.proxy.Enhancer

* the rhn_server_xmlrpc.log shows, among other things:  2012/10/24 11:53:23 
-04:00 6184 10.148.42.65: server/rhnChannel.guess_channels_for_server('ERROR', 
'No available channels for (server, org)', (110031, 1), '6.3', 
'x86_64-redhat-linux')


My questions:
(1)  Any chance that a "stock" set of records might be available somewhere for 
re-populating the rhntaskorun table?

(2) Any advice on the other errors noted above? (Assuming they aren't just red 
herrings).

Many thanks in advance.

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University



From: Elizabeth Good mailto:elizabeth.g...@duke.edu>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Tuesday, October 23, 2012 9:57 AM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: [Spacewalk-list] rhntaskorun issues

Hello,

I’m reposting this in the hopes that someone has run across a similar issue 
with the rhntaskorun table.  Spacewalk is down when I’ve performed the 
following actions.   As far as we can tell it is not a problem with our disks.

We are on spacewalk 1.7, postg

Re: [Spacewalk-list] rhntaskorun issues

[Andy Ingham]

Folks --

(Beth and I work in the same office)

We believe that we traced the pgsql problem (below) to some iSCSI connection 
issues.  Unfortunately, since we did not have a usable database dump, we ended 
up having to do the following:

from the spaceschema database:

truncate table rhntaskorun;

(this was done *without* the cascade option, so only that table was truncated.)

The good news is that we can now do SELECTS from all tables in the database 
without spectacular postgres crashes.

The bad news is that certain spacewalk functions are now broken (not 
surprisingly, due to the deletion of records above).

Specifically:

* going to https://our.spacewalk.server.edu/rhn/admin/SatSchedules.do results 
in "The scheduling service appears down. Please contact your Satellite 
administrator."

*  osa-dispatcher startup results in:  Starting osa-dispatcher: RHN 2349 
2012/10/24 11:14:23 -04:00: ('Error caught:',)
RHN 2349 2012/10/24 11:14:23 -04:00: ('Traceback (most recent call last):\n  
File "/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n
self.setup_config(config)\n  File "/usr/share/rhn/osad/osa_dispatcher.py", line 
112, in setup_config\nrhnSQL.initDB()\n  File 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py", line 
124, in initDB\n__init__DB(backend, host, port, username, password, 
database)\n  File 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py", line 
55, in __init__DB\n__DB.connect()\n  File 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
 line 171, in connect\nreturn self.connect(reconnect=0)\n  File 
"/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
 line 160, in connect\npassword=self.password)\nSQLConnectError: (None, 
None, \'spaceschema\', \'Attempting Re-Connect to the database failed\')\n',)

* the rhn_taskomatic_daemon.log shows, among other things:  INFO   | jvm 1| 
2012/10/24 11:46:13 | WARNING: java.lang.NoClassDefFoundError: Could not 
initialize class net.sf.cglib.proxy.Enhancer

* the rhn_server_xmlrpc.log shows, among other things:  2012/10/24 11:53:23 
-04:00 6184 10.148.42.65: server/rhnChannel.guess_channels_for_server('ERROR', 
'No available channels for (server, org)', (110031, 1), '6.3', 
'x86_64-redhat-linux')


My questions:
(1)  Any chance that a "stock" set of records might be available somewhere for 
re-populating the rhntaskorun table?

(2) Any advice on the other errors noted above? (Assuming they aren't just red 
herrings).

Many thanks in advance.

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University



From: Elizabeth Good mailto:elizabeth.g...@duke.edu>>
Reply-To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Date: Tuesday, October 23, 2012 9:57 AM
To: "spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>" 
mailto:spacewalk-list@redhat.com>>
Subject: [Spacewalk-list] rhntaskorun issues

Hello,

I’m reposting this in the hopes that someone has run across a similar issue 
with the rhntaskorun table.  Spacewalk is down when I’ve performed the 
following actions.   As far as we can tell it is not a problem with our disks.

We are on spacewalk 1.7, postgresql 8.4.13.  We have not been able to get a 
good pg_dump, as the postgresql backup stops at the rhntaskorun table:

pg_dump: Dumping the contents of table "rhntaskorun" failed: PQgetCopyData() 
failed.
pg_dump: Error message from server: pg_dump: The command was: COPY 
public.rhntaskorun (id, template_id, schedule_id, org_id, start_time, end_time, 
std_output_path, std_error_path, status, created, modified) TO stdout;
pg_dump: *** aborted because of error


In addition,  selecting from the rhntaskorun also causes issues.

All the postgresql processes go down when I do the select or run a pg_dump, 
with the exception of the postmaster and logger processes.



Thanks,

Beth

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

Re: [Spacewalk-list] unable to remove systems

[Andy Ingham]

These were, indeed, the settings that needed to be fixed.

Thank you so much!

Andy



On 8/28/12 3:48 AM, "Jan Hutař"  wrote:

Check you have this in /etc/cobbler/settings:

redhat_management_server: ""
redhat_management_permissive: 0

and in /etc/cobbler/modules.conf:

[authentication]
module = authn_spacewalk


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

Re: [Spacewalk-list] unable to remove systems

[Andy Ingham]

Going back a ways, I realize, but I am also unable to DELETE systems via
spacewalk.

I have tried downgrading cobbler and I'm still getting the same "internal
server error" message when I try to delete.  This is the case regardless
of the versions of the files mentioned in the previous post (
/etc/cobbler/settings and /etc/cobbler/modules.conf) or (
/etc/cobbler/settings.rpmsave and /etc/cobbler/modules.conf.rpmsave )

Ultimately, the cobbler functionality is less critical to me than the need
to delete old systems from the inventory.  I've only been approaching from
the cobbler end because of what I've read on the list.

Any help greatly appreciated!


Andy



Some potentially helpful info =>

My /var/log/rhn/rhn_taskomatic_daemon.log file shows:

INFO   | jvm 1| 2012/08/22 16:11:00 | 2012-08-22 16:11:00,074
[DefaultQuartzScheduler_Worker-5] ERROR
com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand - XmlRpcFault
while logging in.  most likely user doesn't have permissions.
INFO   | jvm 1| 2012/08/22 16:11:00 | redstone.xmlrpc.XmlRpcFault:
:'login failed (taskomatic_user)'
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:443)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(C
obblerXMLRPCHelper.java:69)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerL
oginCommand.java:52)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.frontend.integration.IntegrationService.authorize(Integratio
nService.java:114)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(Integra
tionService.java:67)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerCommand.(CobblerComma
nd.java:68)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerDistroSyncCommand.(Co
bblerDistroSyncCommand.java:52)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java
:72)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:80)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:169)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
org.quartz.core.JobRunShell.run(JobRunShell.java:214)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:54
9)
INFO   | jvm 1| 2012/08/22 16:11:00 | 2012-08-22 16:11:00,074
[DefaultQuartzScheduler_Worker-5] ERROR
com.redhat.rhn.taskomatic.task.CobblerSyncTask - RuntimeExceptioneError
trying to sync to cobbler: We had an error trying to login.
INFO   | jvm 1| 2012/08/22 16:11:00 |
com.redhat.rhn.manager.kickstart.cobbler.NoCobblerTokenException: We had
an error trying to login.
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand.login(CobblerL
oginCommand.java:57)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.frontend.integration.IntegrationService.authorize(Integratio
nService.java:114)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.frontend.integration.IntegrationService.getAuthToken(Integra
tionService.java:67)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerCommand.(CobblerComma
nd.java:68)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.manager.kickstart.cobbler.CobblerDistroSyncCommand.(Co
bblerDistroSyncCommand.java:52)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java
:72)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:80)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:169)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
org.quartz.core.JobRunShell.run(JobRunShell.java:214)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:54
9)
INFO   | jvm 1| 2012/08/22 16:11:00 | Caused by:
redstone.xmlrpc.XmlRpcFault: :'login
failed (taskomatic_user)'
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:443)
INFO   | jvm 1| 2012/08/22 16:11:00 |   at
redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
INFO   | jvm 1   

Re: [Spacewalk-list] Error doing updates with Scientific Linux clients

[Andy Ingham]

I believe you're right.  The trick is, where exactly am I supposed to
correct that?

Thanks!

Andy

On 5/15/12 3:04 PM, "Musayev, Ilya"  wrote:

If I'm not mistaken, the release should be 6 and not 6.2

-Original Message-
From: spacewalk-list-boun...@redhat.com
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Andy Ingham
Sent: Tuesday, May 15, 2012 1:47 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Error doing updates with Scientific Linux clients

I've gone around and around on this one.

Trying to do updates to 1.7 server (postgres) with Scientific Linux
clients and I'm constantly encountering:

"Error Message:
Your account does not have access to any channels matching
(release='6.2', arch='x86_64-redhat-linux') Error Class Code: 19 Error
Class Info: Architecture and OS version combination is not supported.
Explanation: 
 An error has occurred while processing your request. If this problem
 persists please enter a bug report at bugzilla.redhat.com.
 If you choose to submit the bug report, please be sure to include
 details of what you were trying to do when this error occurred and
 details on how to reproduce this problem.
"




Is there a known fix for this?  Do I have a configuration problem?

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




___
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] Error doing updates with Scientific Linux clients

[Andy Ingham]

I've gone around and around on this one.

Trying to do updates to 1.7 server (postgres) with Scientific Linux
clients and I'm constantly encountering:

"Error Message:
Your account does not have access to any channels matching
(release='6.2', arch='x86_64-redhat-linux')
Error Class Code: 19
Error Class Info: Architecture and OS version combination is not supported.
Explanation: 
 An error has occurred while processing your request. If this problem
 persists please enter a bug report at bugzilla.redhat.com.
 If you choose to submit the bug report, please be sure to include
 details of what you were trying to do when this error occurred and
 details on how to reproduce this problem.
"




Is there a known fix for this?  Do I have a configuration problem?

Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University




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

Re: [Spacewalk-list] client checks in, but OSAD continues to end up "offline" when package update attempted

[Andy Ingham]

I've since gone to the client and forced a full yum update from the
commandline.

I suspect that the issue had to do with the system being SO FAR out of
date.  Until there are enough new packages to provide something to really
test, I'm uncertain about whether or not a problem still exists with this
system.

Andy

On 5/7/12 7:36 AM, "Jan Pazdziora"  wrote:

On Fri, Apr 13, 2012 at 09:02:50PM +, Andy Ingham wrote:
> CentOS 5 (x86_64) client trying to use a spacewalk 1.7 server
> 
> 
> Within the spacewalk GUI:
> 
> "OSA Status" consistently switches to "offline" shortly after I schedule
>a
> package update

What is the exact information on the WebUI? Including the timestamps ...

-- 
Jan Pazdziora
Principal Software Engineer, 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

[Spacewalk-list] client checks in, but OSAD continues to end up "offline" when package update attempted

[Andy Ingham]

CentOS 5 (x86_64) client trying to use a spacewalk 1.7 server


Within the spacewalk GUI:

"OSA Status" consistently switches to "offline" shortly after I schedule a
package update
   
   


The client, however, is still successfully "checking in" with spacewalk.





Nothing noteworthy in any logs, near as I can tell, but for completeness,
here are some snippets
SERVER-SIDE:
In /var/log/rhn/rhn_server_xmlrpc.log :

2012/04/13 15:19:16 -04:00 8377 10.148.42.119:
xmlrpc/registration.welcome_message('lang: None',)
2012/04/13 15:19:16 -04:00 8380 10.148.42.119:
xmlrpc/registration.register_osad
2012/04/13 15:19:16 -04:00 8379 10.148.42.119:
xmlrpc/registration.register_osad_jid
2012/04/13 15:20:21 -04:00 8375 10.148.42.119:
xmlrpc/queue.get(110007, 2, 'checkins enabled')
2012/04/13 15:20:21 -04:00 8756 10.148.42.119:
xmlrpc/up2date.login(110007,)
2012/04/13 15:20:21 -04:00 8757 10.148.42.119:
xmlrpc/up2date.listChannels(110007,)


In /var/log/rhn/rhn_taskomatic_daemon.log :

INFO   | jvm 1| 2012/04/13 15:45:00 | 2012-04-13 15:45:00,022
[DefaultQuartzScheduler_Worker-6] INFO
com.redhat.rhn.taskomatic.task.SessionCleanup - 4 stale session(s) deleted

CLIENT-SIDE:


In /var/log/up2date:
[Fri Apr 13 15:09:31 2012] up2date Updating package profile
[Fri Apr 13 15:20:21 2012] up2date updateLoginInfo() login info
[Fri Apr 13 15:20:21 2012] up2date logging into up2date server
[Fri Apr 13 15:20:21 2012] up2date successfully retrieved authentication
token from up2date server




Thoughts?
What else do I check?

TIA,
Andy


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

Re: [Spacewalk-list] CentOS 4 repository setup?

[Andy Ingham]

Re-asking this since it would save me a LOT of time:



Is there a way to populate my spacewalk repos with the final (vault)
version of the CentOS 4 files?





Thanks!

Andy



On 3/23/12 9:33 AM, "Andy Ingham"  wrote:

Is there a quick way to tweak the repositories in spacewalk for the
*CentOS 4* channels, so that I can get a final, last set of packages for
that rev (that I can then turn around and apply to a bunch of hosts that
are unfortunately still at CentOS 4).

I am able to manually do this on a GIVEN HOST by changing the "baseurl"
setting within /etc/yum.repos.d/CentOS-Base.repo.  (BTW, I've assumed that
I've needed to do this on a very specific version-by-version basis:  E.g.,

baseurl=http://vault.centos.org/4.9/os/$basearch/

[Note the *4.9* in this case]

I'm hoping to avoid doing this on a host by host basis, so would like to
leverage spacewalk, so...

Can I simply change "Repository URL" for each CentOS 4 repo from its
current (for example)
"http://mirrorlist.centos.org/?release=4&arch=i386&repo=os"; to something
else?  If so, what would that something else BE
("http://vault.centos.org/?release=4&arch=i386&repo=os"; does NOT work).
Relatedly, do I need to be concerned about the 4.7 vs 4.8 vs 4.9, etc
issue?


Thanks for any insight!

Andy


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


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

[Spacewalk-list] CentOS 4 repository setup?

[Andy Ingham]

Is there a quick way to tweak the repositories in spacewalk for the
*CentOS 4* channels, so that I can get a final, last set of packages for
that rev (that I can then turn around and apply to a bunch of hosts that
are unfortunately still at CentOS 4).

I am able to manually do this on a GIVEN HOST by changing the "baseurl"
setting within /etc/yum.repos.d/CentOS-Base.repo.  (BTW, I've assumed that
I've needed to do this on a very specific version-by-version basis:  E.g.,

baseurl=http://vault.centos.org/4.9/os/$basearch/

[Note the *4.9* in this case]

I'm hoping to avoid doing this on a host by host basis, so would like to
leverage spacewalk, so...

Can I simply change "Repository URL" for each CentOS 4 repo from its
current (for example)
"http://mirrorlist.centos.org/?release=4&arch=i386&repo=os"; to something
else?  If so, what would that something else BE
("http://vault.centos.org/?release=4&arch=i386&repo=os"; does NOT work).
Relatedly, do I need to be concerned about the 4.7 vs 4.8 vs 4.9, etc
issue?


Thanks for any insight!

Andy


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

Re: [Spacewalk-list] cannot register CentOS 5 system to my new spacewalk server

[Andy Ingham]

Jan --

Really appreciate the feedback.

I fully expect that there are multiple things wrong with my setup.
However, I'm having a hard time understanding WHY that would be, since I
followed the setup instructions at https://fedorahosted.org/spacewalk/
VERY CAREFULLY.  Twice now.

As I mentioned before, I would find it very helpful if there was explicit
documentation about the "SSL setup".  If the package installs don't put
things where they need to be, and there is not adequate documentation
about what needs to be done manually, I'm just plain stuck.  Which is
where I've been for a while now, and why I'm seeking help from this list.

I'd be the first to admit that I don't know the specifics of what
taskomatic or jabberd are needed for.  All I know is that they are not
working, DESPITE following the setup instructions VERY CAREFULLY.

This is all quite frustrating, since I think spacewalk would be an AWESOME
tool and I'd LOVE to be able to actually use it.

Having said all that, I am more than willing to break the issues down into
manageable pieces and address them one-by-one.

What is the order of priority for troubleshooting the following:
Taskomatic
Jabberd
SSL failures

?

I'm happy to provide WHATEVER data (what I did, what X logfile shows, etc)
you'd find helpful in helping me to troubleshoot.

And I'd REALLY appreciate that help; without it, I've run out of ideas and
time to spend chasing hunches.


Andy


On 3/12/12 11:02 AM, "Jan Pazdziora"  wrote:

On Thu, Mar 08, 2012 at 06:17:01PM +, Andy Ingham wrote:
> Sabuj --
> 
> That's what I've got, so perhaps my problem is less an SSL one than an
> issue with Taskomatic or jabberd (or something else!)

Please, keep the issues separated.

When you run rhnreg_ks, that does not have anything to do with
taskomatic, nor jabberd. When you get
up2date_client.up2dateErrors.SSLCertificateVerifyFailedError, it's
really a SSL issue -- either certificate wrong, or date/time out of
sync.

> See below for the output in my /var/log/rhn/rhn_taskomatic_daemon.log
>file
> upon issuing "/usr/sbin/spacewalk-service start" to start the spacewalk
> service.
> 
> It is complaining about not being able to connect with the Oracle
>backend,
> even though I've got the two files:
> 
>   /usr/lib/oracle/11.2/client64/network/admin/tnsnames.ora
>   and
>   /usr/lib/oracle/11.2/client64/network/admin/sqlnet.ora
> 
> that the
> 
>   sqlplus [db_user]/[db_pass]@[SERVICE_NAME]
> 
> commandline command requires for interactive db access
> 
> What am I missing?

I can imagine taskomatic cannot read that
/usr/lib/oracle/11.2/client64/network/admin/tnsnames.ora file, or it
does not read the file at all -- the tnsnames.ora for use with Instant
Client should really be in /etc.

> Does sw not work with an external Oracle 11g instance?

It does.

-- 
Jan Pazdziora
Principal Software Engineer, 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] cannot register CentOS 5 system to my new spacewalk server

[Andy Ingham]

Yes, I'm able to connect commandline via sqlplus


Anyone else using CentOS 6.x for the sw server to connect to an Oracle 11g
on a separate server?

Andy



On 3/9/12 9:03 AM, "Sabuj Pattanayek"  wrote:

> that the
>
>sqlplus [db_user]/[db_pass]@[SERVICE_NAME]

You're able to connect to it using sqlplus ?

>
> commandline command requires for interactive db access
>
> What am I missing?
>
> Does sw not work with an external Oracle 11g instance?

It should, but I'm still using 1.0 with oracle express. My next
upgrade will be to pgsql.

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


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

Re: [Spacewalk-list] cannot register CentOS 5 system to my new spacewalk server

[Andy Ingham]

FO   | jvm 1| 2012/03/08 12:32:08 |   at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:
880)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
org.quartz.utils.PoolingConnectionProvider.getConnection(PoolingConnectionP
rovider.java:194)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
org.quartz.utils.DBConnectionManager.getConnection(DBConnectionManager.java
:109)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
org.quartz.impl.jdbcjobstore.JobStoreSupport.getConnection(JobStoreSupport.
java:687)
INFO   | jvm 1| 2012/03/08 12:32:08 |   ... 13 more
INFO   | jvm 1| 2012/03/08 12:32:08 | Caused by:
java.sql.SQLException: ORA-12154: TNS:could not resolve the connect
identifier specified
INFO   | jvm 1| 2012/03/08 12:32:08 |
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
oracle.jdbc.driver.T2CConnection.checkError(T2CConnection.java:759)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
oracle.jdbc.driver.T2CConnection.logon(T2CConnection.java:414)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:536)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
oracle.jdbc.driver.T2CConnection.(T2CConnection.java:162)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
oracle.jdbc.driver.T2CDriverExtension.getConnection(T2CDriverExtension.java
:53)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:521)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConn
ectionFactory.java:38)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnec
tionFactory.java:294)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
org.apache.commons.dbcp.BasicDataSource.validateConnectionFactory(BasicData
Source.java:1247)
INFO   | jvm 1| 2012/03/08 12:32:08 |   at
org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.ja
va:1221)
INFO   | jvm 1| 2012/03/08 12:32:08 |   ... 17 more
FATAL  | jvm 1| 2012/03/08 12:32:08 | this.scheduler failed
java.lang.InstantiationException: this.scheduler failed
at 
com.redhat.rhn.taskomatic.core.SchedulerKernel.(SchedulerKernel.java:
137)
at 
com.redhat.rhn.taskomatic.core.TaskomaticDaemon.onStartup(TaskomaticDaemon.
java:98)
at 
com.redhat.rhn.taskomatic.core.BaseDaemon.startupWithOptions(BaseDaemon.jav
a:189)
at com.redhat.rhn.taskomatic.core.BaseDaemon.start(BaseDaemon.java:54)
at 
org.tanukisoftware.wrapper.WrapperManager$11.run(WrapperManager.java:2788)

STATUS | wrapper  | 2012/03/08 12:32:10 | <-- Wrapper Stopped




On 3/8/12 10:10 AM, "Sabuj Pattanayek"  wrote:

Systems -> kickstart -> GPG & SSL Keys . There should be one called
RHN-ORG-TRUSTED-SSL-CERT or similar. The text that's in that entire
thing should be put in a file and specified as the file in the
--sslCACert=/path/to/file.crt argument

On Thu, Mar 8, 2012 at 8:04 AM, Andy Ingham  wrote:
> Sabuj --
>
> Thanks for the info, but what I think I'm struggling with is exactly
>WHICH
> cert and key files, FROM where, concatenated in WHAT WAY and ultimately
> saved in WHICH directory (and on which host).
>
>
> As someone mentioned on the list previously, the info specific to SSL
> files for spacewalk is thin and with numerous files involved (and spread
> across both sw server and sw clients), I am far from confident that I've
> got what I'm supposed to have where I'm supposed to have it.
>
> Is there (client) setup documentation somewhere that I'm missing?
>
> Again, many thanks!
>
> Andy
>
>
> On 3/7/12 4:27 PM, "Sabuj Pattanayek"  wrote:
>
>>An error has occurred:
>>up2date_client.up2dateErrors.SSLCertificateVerifyFailedError
>>See /var/log/up2date for more information
>
> In my kickstart scripts the SSL cert from the server gets put into
> this file and it does this :
>
> cat > /tmp/ssl-key-1 <<'EOF'
> # HUGE SSL KEY HERE #
> .
> .
> .
> cat /tmp/ssl-key-* > /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
> perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i
> /etc/sysconfig/rhn/*
> .
> .
> rhnreg_ks --force --serverUrl=/XMLRPC
> --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
> --activationkey=
>
> ___
> 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] cannot register CentOS 5 system to my new spacewalk server

[Andy Ingham]

Sabuj --

Thanks for the info, but what I think I'm struggling with is exactly WHICH
cert and key files, FROM where, concatenated in WHAT WAY and ultimately
saved in WHICH directory (and on which host).


As someone mentioned on the list previously, the info specific to SSL
files for spacewalk is thin and with numerous files involved (and spread
across both sw server and sw clients), I am far from confident that I've
got what I'm supposed to have where I'm supposed to have it.

Is there (client) setup documentation somewhere that I'm missing?

Again, many thanks!

Andy


On 3/7/12 4:27 PM, "Sabuj Pattanayek"  wrote:

>An error has occurred:
>up2date_client.up2dateErrors.SSLCertificateVerifyFailedError
>See /var/log/up2date for more information

In my kickstart scripts the SSL cert from the server gets put into
this file and it does this :

cat > /tmp/ssl-key-1 <<'EOF'
# HUGE SSL KEY HERE #
.
.
.
cat /tmp/ssl-key-* > /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i
/etc/sysconfig/rhn/*
.
.
rhnreg_ks --force --serverUrl=/XMLRPC
--sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
--activationkey=

___
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] cannot register CentOS 5 system to my new spacewalk server

[Andy Ingham]

Hello --

I've followed the directions as well as I'm able (twice now!) and continue
to see the following errors.

When I run *this* from a CentOS 5 client system:

rhnreg_ks --serverUrl=https://10.148.42.210/XMLRPC
--activationkey=

The result is:

An error has occurred:
up2date_client.up2dateErrors.SSLCertificateVerifyFailedError
See /var/log/up2date for more information


And within /var/log/up2date:

[Wed Mar  7 16:03:27 2012] up2date
Traceback (most recent call last):
  File "/usr/sbin/rhnreg_ks", line 218, in ?
cli.run()
  File "/usr/share/rhn/up2date_client/rhncli.py", line 75, in run
sys.exit(self.main() or 0)
  File "/usr/sbin/rhnreg_ks", line 90, in main
rhnreg.getCaps()
  File "/usr/share/rhn/up2date_client/rhnreg.py", line 239, in getCaps
s.capabilities.validate()
  File "/usr/share/rhn/up2date_client/rhnserver.py", line 159, in
__get_capabilities
self.registration.welcome_message()
  File "/usr/share/rhn/up2date_client/rhnserver.py", line 50, in __call__
return rpcServer.doCall(method, *args, **kwargs)
  File "/usr/share/rhn/up2date_client/rpcServer.py", line 196, in doCall
ret = method(*args, **kwargs)
  File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__
return self.__send(self.__name, args)
  File "/usr/share/rhn/up2date_client/rpcServer.py", line 37, in _request1
ret = self._request(methodname, params)
  File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 381, in
_request
self._handler, request, verbose=self._verbose)
  File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 167, in
request
headers, fd = req.send_http(host, handler)
  File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 700, in
send_http
headers=self.headers)
  File "/usr/lib64/python2.4/httplib.py", line 810, in request
self._send_request(method, url, body, headers)
  File "/usr/lib64/python2.4/httplib.py", line 833, in _send_request
self.endheaders()
  File "/usr/lib64/python2.4/httplib.py", line 804, in endheaders
self._send_output()
  File "/usr/lib64/python2.4/httplib.py", line 685, in _send_output
self.send(msg)
  File "/usr/lib64/python2.4/httplib.py", line 664, in send
self.sock.sendall(str)
  File "/usr/lib/python2.4/site-packages/rhn/SSL.py", line 218, in write
sent = self._connection.send(data)
up2date_client.up2dateErrors.SSLCertificateVerifyFailedError: The SSL
certificate failed verification.



I should note also that when I start up osad on the client (via "service
osad start"), I consistently get:

Starting osad: 2012-03-07 16:06:04 jabber_lib.main: Unable to connect to
jabber servers, sleeping 68 seconds


I've been around and around on the various settings on both sw server end
and on the client end.

Can someone offer guidance?


Thanks,
Andy

Andy Ingham
IT Infrastructure
Fuqua School of Business
Duke University


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