[Spacewalk-list] comps.xml

[William Clark]

My Spacewalk installation has a set of base channels based on upstream official 
centos channels.

I first mirror the upstream channels to a local webserver and then from 
Spacewalk I have channels that point to this local repo and update nightly.

The problem I am seeing is that while I do have comps.xml in the local 
webserver repository this does not seem to translate over to my Spacewalk 
channels.  I need this data for doing groupinstall etc.

Does anyone know how I can get this comps.xml data over into spacewalk?

Regards,

William Clark




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

Re: [Spacewalk-list] spacewalk-common-channels infinite looping

[Boyd, Robert]

I reworked some of the debug output and now it's actually doing something that 
looks more or less rational.I'm not sure what the problem was, but it 
appears that I may have made a small but significant error in indent level at 
some point when inserting the debug output statements.

I must say - it would be very nice if code like this routine was well 
commented.  It seems that if it's going to be looked at in an open-source 
community there should be more elaborate comments that explain the design of 
the program.   The code is easy to read, but it not self documenting.

From: spacewalk-list-boun...@redhat.com 
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Boyd, Robert
Sent: Thursday, September 20, 2012 4:48 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] spacewalk-common-channels infinite looping

I am trying to use spacewalk-common-channels to create all of the channel 
structures for CentOS 4, 5 and 6 and I'm running into a problem right away.   
It appears that the  program is going into an infinite loop processing the 
channel info.   If I tell it to list the available channels I get some nice 
output.   When I tell it to create the channels for CentOS5  it goes away and 
never comes back.I added some additional print to take advantage of the 
verbose option and was able to see that it was looping forever over what 
appears to be the same data.

I only know enough python to hack around a little bit, so I'm not sure how to 
debug this thing.   There really isn't very much built in diagnostic output to 
be able to see what it's trying to do.   I'll be happy to throw several debug 
statements in once I have some better understanding of how the code is 
structured.

Anyone on the list familiar with the code enough to give me some pointers?

Thanks,


Robert Boyd
Senior Systems Engineer
Phone: 919-645-2972
Mobile: 919-306-4681
Peoplefluent
434 Fayetteville Street
Raleigh, NC  27601

robert.b...@peoplefluent.com

[cid:image001.png@01CD9751.E71412D0]



This email message is for the sole use of the intended recipient(s) and may 
contain confidential information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.

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

[Spacewalk-list] spacewalk-common-channels infinite looping

[Boyd, Robert]

I am trying to use spacewalk-common-channels to create all of the channel 
structures for CentOS 4, 5 and 6 and I'm running into a problem right away.   
It appears that the  program is going into an infinite loop processing the 
channel info.   If I tell it to list the available channels I get some nice 
output.   When I tell it to create the channels for CentOS5  it goes away and 
never comes back.I added some additional print to take advantage of the 
verbose option and was able to see that it was looping forever over what 
appears to be the same data.

I only know enough python to hack around a little bit, so I'm not sure how to 
debug this thing.   There really isn't very much built in diagnostic output to 
be able to see what it's trying to do.   I'll be happy to throw several debug 
statements in once I have some better understanding of how the code is 
structured.

Anyone on the list familiar with the code enough to give me some pointers?

Thanks,


Robert Boyd
Senior Systems Engineer
Phone: 919-645-2972
Mobile: 919-306-4681
Peoplefluent
434 Fayetteville Street
Raleigh, NC  27601

robert.b...@peoplefluent.com

[cid:image001.png@01CD974F.93FC2BC0]



This email message is for the sole use of the intended recipient(s) and may 
contain confidential information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.

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

Re: [Spacewalk-list] Error on Overview Page after OpenSCAP Scan

[Kenny Van Alstyne]

>This is fixed since
>
>commit 87ec31f8e9964367a88345e485c0b2b809ca20f9
>Author: Simon Lukasik 
>Date:   Thu Mar 1 13:07:05 2012 +0100
>
>OpenSCAP integration  -- Show results for system on web.
>
>It will be part of Spacewalk 1.8, together with much more scap features.
>
>I am sorry for troubles,
>
>--
>Simon Lukasik

Hm... is there a good way to backport those changes to my Spacewalk?
I was thinking about compiling those new classes and wedging them into
my rhn.jar, but I worry about the side effects of that.  Any idea when
Spacewalk 1.8 will be out?

Thanks,
Kenny

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

Re: [Spacewalk-list] Error on Overview Page after OpenSCAP Scan

[Simon Lukasik]

On 09/20/2012 05:12 PM, Kenny Van Alstyne wrote:
> Greetings all -- I'm wondering if anyone knows a fix for the below
> error when browsing to the overview page on Spacewalk 1.7 after
> running an XCCDF OpenSCAP Scan:

This is fixed since

commit 87ec31f8e9964367a88345e485c0b2b809ca20f9
Author: Simon Lukasik 
Date:   Thu Mar 1 13:07:05 2012 +0100

OpenSCAP integration  -- Show results for system on web.

It will be part of Spacewalk 1.8, together with much more scap features.

I am sorry for troubles,

-- 
Simon Lukasik

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

Re: [Spacewalk-list] Massive problems with slow updates on rhnServerAction

[Jonathan Scott]

- Forgot about ulimit, not sure why... I deal with Oracle almost daily.
I've adjusted my ulimit nofile setting (both soft and hard):

# ulimit -a | grep files
open files  (-n) 4096

# ulimit -aH | grep files
open files  (-n) 65000

- There is a /var/lib/pgsql/data/base/pgsql_tmp/ folder, but it is empty at
the moment; I will keep an eye on it.

- I have the keepalive changed at the sysctl level as every time I do so on
the postgresql side, I cannot do so much as cancel a scheduled task without
the app going 503 on me. Neither sysctl or postgresql.conf changes appear
to help in this case, regardless of what I set them to.

Thanks again for your time and assistance with this frustrating issue o'
mine,
Jonathan

On Thu, Sep 20, 2012 at 2:09 PM, Paul Robert Marino wrote:

> well thats one part of it but also
> ulimit -n
> which can be set persistently with a nofile entry in
> /etc/security/limits.conf or equivalent file in
> /etc/security/limits.d/
>
> there is also one more thing do you have a
> /var/lib/pgsql/data/base/pgsql_tmp/ directory and does it contain
> files. the existence of that directory indicates there was a query
> that required more memory than it was allowed to use.
>
>
> I suspect you may have a query thats timing out and the space walk
> kills the connection uncleanly and leaves behind artifact connections.
> or possibly you may be reaching a file handle limit on one of the
> spacewalk processes and keep in mind an network socket is counted as a
> file.
>
>
>
> also in the postgresql.conf look at the section about TCP keepalive
>
>
> "
> # - TCP Keepalives -
> # see "man 7 tcp" for details
>
> #tcp_keepalives_idle = 0# TCP_KEEPIDLE, in seconds;
> # 0 selects the system default
> #tcp_keepalives_interval = 0# TCP_KEEPINTVL, in seconds;
> # 0 selects the system default
> #tcp_keepalives_count = 0   # TCP_KEEPCNT;
> # 0 selects the system default
> "
>
> note all of these have have a value greater than 1
> setting these flags should cull any connections from clients that are
> no longer there.
>
> On Thu, Sep 20, 2012 at 1:42 PM, Jonathan Scott  wrote:
> > By this, do you mean the "fs.file-max" kernel parameter? If so, no I have
> > not; I am still at the default.
> >
> > - Jonathan
> >
> >
> > On Thu, Sep 20, 2012 at 1:12 PM, Paul Robert Marino  >
> > wrote:
> >>
> >> Also did either of you tune the max open file limit
> >>
> >> On Sep 20, 2012 1:08 PM, "Paul Robert Marino" 
> wrote:
> >>>
> >>> I think I may have some idea on what may be causing this but I haven't
> >>> had time to look. At it yet. Did eitherof you tune the sort memory or
> >>> working memory in your postgres.conf
> >>>
> >>> On Sep 20, 2012 10:20 AM, "Patrick Hurrelmann"
> >>>  wrote:
> 
>  On 20.09.2012 16:04, Jonathan Scott wrote:
>  > Paul,
>  >
>  > This is reading like the exact same issue you and I discussed
> on-list
>  > a
>  > few weeks ago. I had closed out that thread as resolved, but the
> issue
>  > has since creeped its way back up. Patrick breaks it down well, I
> too
>  > just get a pile up of "idle in transaction" db connections which do
>  > not
>  > clear with any configuration change I have made (tcp timeout, idle
>  > timeout and connection limit adjustments in postgresql.conf); a
>  > restart
>  > of all associated services gives me about 3-5 days before the app
>  > becomes unresponsive.
>  >
>  > Patrick, may I ask how are you loading your errata?
>  >
>  > - Jonathan
> 
>  As a short update: I missed one node that had osad still running. Osad
>  was disabled there as well. I no longer have any update queries
> waiting.
>  There are still some idle transactions, but the number is way lower
> now.
>  I have the strong feeling that this is all connected osad and push to
>  clients. Anyone else?
> 
>  But back to your question. I'm running David Nutter's centos-errata.py
>  on a nightly basis directly after a spacewalk restart.
> 
>  Regards
>  Patrick
> 
>  --
>  Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg
> 
>  HRB 178831, Amtsgericht München
>  Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
> 
>  ___
>  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

Re: [Spacewalk-list] Massive problems with slow updates on rhnServerAction

[Paul Robert Marino]

well thats one part of it but also
ulimit -n
which can be set persistently with a nofile entry in
/etc/security/limits.conf or equivalent file in
/etc/security/limits.d/

there is also one more thing do you have a
/var/lib/pgsql/data/base/pgsql_tmp/ directory and does it contain
files. the existence of that directory indicates there was a query
that required more memory than it was allowed to use.


I suspect you may have a query thats timing out and the space walk
kills the connection uncleanly and leaves behind artifact connections.
or possibly you may be reaching a file handle limit on one of the
spacewalk processes and keep in mind an network socket is counted as a
file.



also in the postgresql.conf look at the section about TCP keepalive


"
# - TCP Keepalives -
# see "man 7 tcp" for details

#tcp_keepalives_idle = 0# TCP_KEEPIDLE, in seconds;
# 0 selects the system default
#tcp_keepalives_interval = 0# TCP_KEEPINTVL, in seconds;
# 0 selects the system default
#tcp_keepalives_count = 0   # TCP_KEEPCNT;
# 0 selects the system default
"

note all of these have have a value greater than 1
setting these flags should cull any connections from clients that are
no longer there.

On Thu, Sep 20, 2012 at 1:42 PM, Jonathan Scott  wrote:
> By this, do you mean the "fs.file-max" kernel parameter? If so, no I have
> not; I am still at the default.
>
> - Jonathan
>
>
> On Thu, Sep 20, 2012 at 1:12 PM, Paul Robert Marino 
> wrote:
>>
>> Also did either of you tune the max open file limit
>>
>> On Sep 20, 2012 1:08 PM, "Paul Robert Marino"  wrote:
>>>
>>> I think I may have some idea on what may be causing this but I haven't
>>> had time to look. At it yet. Did eitherof you tune the sort memory or
>>> working memory in your postgres.conf
>>>
>>> On Sep 20, 2012 10:20 AM, "Patrick Hurrelmann"
>>>  wrote:

 On 20.09.2012 16:04, Jonathan Scott wrote:
 > Paul,
 >
 > This is reading like the exact same issue you and I discussed on-list
 > a
 > few weeks ago. I had closed out that thread as resolved, but the issue
 > has since creeped its way back up. Patrick breaks it down well, I too
 > just get a pile up of "idle in transaction" db connections which do
 > not
 > clear with any configuration change I have made (tcp timeout, idle
 > timeout and connection limit adjustments in postgresql.conf); a
 > restart
 > of all associated services gives me about 3-5 days before the app
 > becomes unresponsive.
 >
 > Patrick, may I ask how are you loading your errata?
 >
 > - Jonathan

 As a short update: I missed one node that had osad still running. Osad
 was disabled there as well. I no longer have any update queries waiting.
 There are still some idle transactions, but the number is way lower now.
 I have the strong feeling that this is all connected osad and push to
 clients. Anyone else?

 But back to your question. I'm running David Nutter's centos-errata.py
 on a nightly basis directly after a spacewalk restart.

 Regards
 Patrick

 --
 Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg

 HRB 178831, Amtsgericht München
 Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

 ___
 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] Massive problems with slow updates on rhnServerAction

[Jonathan Scott]

I run mine in a VM and as a means of troubleshooting the issue recently
increased the system RAM allocation. After doing so I re-ran pgtune as I
did during the initial install, but did not do any manual change to sort or
working memory configuration (I'm very new to postgresql).

- Jonathan

On Thu, Sep 20, 2012 at 1:08 PM, Paul Robert Marino wrote:

> I think I may have some idea on what may be causing this but I haven't had
> time to look. At it yet. Did eitherof you tune the sort memory or working
> memory in your postgres.conf
> On Sep 20, 2012 10:20 AM, "Patrick Hurrelmann" <
> patrick.hurrelm...@lobster.de> wrote:
>
>> On 20.09.2012 16:04, Jonathan Scott wrote:
>> > Paul,
>> >
>> > This is reading like the exact same issue you and I discussed on-list a
>> > few weeks ago. I had closed out that thread as resolved, but the issue
>> > has since creeped its way back up. Patrick breaks it down well, I too
>> > just get a pile up of "idle in transaction" db connections which do not
>> > clear with any configuration change I have made (tcp timeout, idle
>> > timeout and connection limit adjustments in postgresql.conf); a restart
>> > of all associated services gives me about 3-5 days before the app
>> > becomes unresponsive.
>> >
>> > Patrick, may I ask how are you loading your errata?
>> >
>> > - Jonathan
>>
>> As a short update: I missed one node that had osad still running. Osad
>> was disabled there as well. I no longer have any update queries waiting.
>> There are still some idle transactions, but the number is way lower now.
>> I have the strong feeling that this is all connected osad and push to
>> clients. Anyone else?
>>
>> But back to your question. I'm running David Nutter's centos-errata.py
>> on a nightly basis directly after a spacewalk restart.
>>
>> Regards
>> Patrick
>>
>> --
>> Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg
>>
>> HRB 178831, Amtsgericht München
>> Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
>>
>> ___
>> 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] Massive problems with slow updates on rhnServerAction

[Jonathan Scott]

By this, do you mean the "fs.file-max" kernel parameter? If so, no I have
not; I am still at the default.

- Jonathan

On Thu, Sep 20, 2012 at 1:12 PM, Paul Robert Marino wrote:

> Also did either of you tune the max open file limit
> On Sep 20, 2012 1:08 PM, "Paul Robert Marino"  wrote:
>
>> I think I may have some idea on what may be causing this but I haven't
>> had time to look. At it yet. Did eitherof you tune the sort memory or
>> working memory in your postgres.conf
>> On Sep 20, 2012 10:20 AM, "Patrick Hurrelmann" <
>> patrick.hurrelm...@lobster.de> wrote:
>>
>>> On 20.09.2012 16:04, Jonathan Scott wrote:
>>> > Paul,
>>> >
>>> > This is reading like the exact same issue you and I discussed on-list a
>>> > few weeks ago. I had closed out that thread as resolved, but the issue
>>> > has since creeped its way back up. Patrick breaks it down well, I too
>>> > just get a pile up of "idle in transaction" db connections which do not
>>> > clear with any configuration change I have made (tcp timeout, idle
>>> > timeout and connection limit adjustments in postgresql.conf); a restart
>>> > of all associated services gives me about 3-5 days before the app
>>> > becomes unresponsive.
>>> >
>>> > Patrick, may I ask how are you loading your errata?
>>> >
>>> > - Jonathan
>>>
>>> As a short update: I missed one node that had osad still running. Osad
>>> was disabled there as well. I no longer have any update queries waiting.
>>> There are still some idle transactions, but the number is way lower now.
>>> I have the strong feeling that this is all connected osad and push to
>>> clients. Anyone else?
>>>
>>> But back to your question. I'm running David Nutter's centos-errata.py
>>> on a nightly basis directly after a spacewalk restart.
>>>
>>> Regards
>>> Patrick
>>>
>>> --
>>> Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg
>>>
>>> HRB 178831, Amtsgericht München
>>> Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
>>>
>>> ___
>>> 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] Massive problems with slow updates on rhnServerAction

[Paul Robert Marino]

Also did either of you tune the max open file limit
On Sep 20, 2012 1:08 PM, "Paul Robert Marino"  wrote:

> I think I may have some idea on what may be causing this but I haven't had
> time to look. At it yet. Did eitherof you tune the sort memory or working
> memory in your postgres.conf
> On Sep 20, 2012 10:20 AM, "Patrick Hurrelmann" <
> patrick.hurrelm...@lobster.de> wrote:
>
>> On 20.09.2012 16:04, Jonathan Scott wrote:
>> > Paul,
>> >
>> > This is reading like the exact same issue you and I discussed on-list a
>> > few weeks ago. I had closed out that thread as resolved, but the issue
>> > has since creeped its way back up. Patrick breaks it down well, I too
>> > just get a pile up of "idle in transaction" db connections which do not
>> > clear with any configuration change I have made (tcp timeout, idle
>> > timeout and connection limit adjustments in postgresql.conf); a restart
>> > of all associated services gives me about 3-5 days before the app
>> > becomes unresponsive.
>> >
>> > Patrick, may I ask how are you loading your errata?
>> >
>> > - Jonathan
>>
>> As a short update: I missed one node that had osad still running. Osad
>> was disabled there as well. I no longer have any update queries waiting.
>> There are still some idle transactions, but the number is way lower now.
>> I have the strong feeling that this is all connected osad and push to
>> clients. Anyone else?
>>
>> But back to your question. I'm running David Nutter's centos-errata.py
>> on a nightly basis directly after a spacewalk restart.
>>
>> Regards
>> Patrick
>>
>> --
>> Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg
>>
>> HRB 178831, Amtsgericht München
>> Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
>>
>> ___
>> 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] Massive problems with slow updates on rhnServerAction

[Paul Robert Marino]

I think I may have some idea on what may be causing this but I haven't had
time to look. At it yet. Did eitherof you tune the sort memory or working
memory in your postgres.conf
On Sep 20, 2012 10:20 AM, "Patrick Hurrelmann" <
patrick.hurrelm...@lobster.de> wrote:

> On 20.09.2012 16:04, Jonathan Scott wrote:
> > Paul,
> >
> > This is reading like the exact same issue you and I discussed on-list a
> > few weeks ago. I had closed out that thread as resolved, but the issue
> > has since creeped its way back up. Patrick breaks it down well, I too
> > just get a pile up of "idle in transaction" db connections which do not
> > clear with any configuration change I have made (tcp timeout, idle
> > timeout and connection limit adjustments in postgresql.conf); a restart
> > of all associated services gives me about 3-5 days before the app
> > becomes unresponsive.
> >
> > Patrick, may I ask how are you loading your errata?
> >
> > - Jonathan
>
> As a short update: I missed one node that had osad still running. Osad
> was disabled there as well. I no longer have any update queries waiting.
> There are still some idle transactions, but the number is way lower now.
> I have the strong feeling that this is all connected osad and push to
> clients. Anyone else?
>
> But back to your question. I'm running David Nutter's centos-errata.py
> on a nightly basis directly after a spacewalk restart.
>
> Regards
> Patrick
>
> --
> Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg
>
> HRB 178831, Amtsgericht München
> Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk with Oracle Linux

[Gerhardus Geldenhuis]

Hi Prakash,
The latter managing OEL clients with spacewalk.

Regards

On 20 September 2012 15:37, Velayutham, Prakash <
prakash.velayut...@cchmc.org> wrote:

> Are you asking about running Spacewalk server in OEL, or how to manage OEL
> clients with Spacewalk?
>
> Prakash
>
> On Sep 20, 2012, at 10:30 AM, Gerhardus Geldenhuis wrote:
>
> > Hi
> >
> > Was curious if anyone has successfully used Spacewalk with Oracle Linux.
> The company that I am working for has decided not just to get in bed with
> the devil but be joined at the hip. The Oracle tools at the moment does not
> seem up to job to provision and manage Oracle Linux machines. I am
> interested in anyone's experience good or bad. If it is of a sensitive
> nature than please feel free to email me offline.
> >
> > The changes that Oracle makes seems small enough so should be
> theoretically possible. I have not yet done my own testing and will do so
> in due course.
> >
> > Regards
> > --
> > Gerhardus Geldenhuis
> > ___
> > 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
>



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

Re: [Spacewalk-list] Spacewalk with Oracle Linux

[Martin Eggen]

As OEL is more or less a rewrapped RHEL distribution it should be fairly 
straight-forward to create a OEL channel (using mrepo to mirror from 
http://public-yum.oracle.com/, although I'm not sure how they publish their 
erratas).
As far as I can see from the list archives this has been done (with some minor 
issues regarding how OEL identifies release versions).

Martin

From: spacewalk-list-boun...@redhat.com 
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Gerhardus Geldenhuis
Sent: Thursday, September 20, 2012 4:31 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Spacewalk with Oracle Linux

Hi

Was curious if anyone has successfully used Spacewalk with Oracle Linux. The 
company that I am working for has decided not just to get in bed with the devil 
but be joined at the hip. The Oracle tools at the moment does not seem up to 
job to provision and manage Oracle Linux machines. I am interested in anyone's 
experience good or bad. If it is of a sensitive nature than please feel free to 
email me offline.

The changes that Oracle makes seems small enough so should be theoretically 
possible. I have not yet done my own testing and will do so in due course.

Regards
--
Gerhardus Geldenhuis

This email originates from Steria AS, Biskop Gunnerus' gate 14a, N-0051 OSLO, 
http://www.steria.no. This email and any attachments may contain 
confidential/intellectual property/copyright information and is only for the 
use of the addressee(s). You are prohibited from copying, forwarding, 
disclosing, saving or otherwise using it in any way if you are not the 
addressee(s) or responsible for delivery. If you receive this email by mistake, 
please advise the sender and cancel it immediately. Steria may monitor the 
content of emails within its network to ensure compliance with its policies and 
procedures. Any email is susceptible to alteration and its integrity cannot be 
assured. Steria shall not be liable if the message is altered, modified, 
falsified, or even edited.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk with Oracle Linux

[Velayutham, Prakash]

Are you asking about running Spacewalk server in OEL, or how to manage OEL 
clients with Spacewalk?

Prakash

On Sep 20, 2012, at 10:30 AM, Gerhardus Geldenhuis wrote:

> Hi
> 
> Was curious if anyone has successfully used Spacewalk with Oracle Linux. The 
> company that I am working for has decided not just to get in bed with the 
> devil but be joined at the hip. The Oracle tools at the moment does not seem 
> up to job to provision and manage Oracle Linux machines. I am interested in 
> anyone's experience good or bad. If it is of a sensitive nature than please 
> feel free to email me offline.
> 
> The changes that Oracle makes seems small enough so should be theoretically 
> possible. I have not yet done my own testing and will do so in due course.
> 
> Regards
> -- 
> Gerhardus Geldenhuis
> ___
> 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] Spacewalk with Oracle Linux

[Gerhardus Geldenhuis]

Hi

Was curious if anyone has successfully used Spacewalk with Oracle Linux.
The company that I am working for has decided not just to get in bed with
the devil but be joined at the hip. The Oracle tools at the moment does not
seem up to job to provision and manage Oracle Linux machines. I am
interested in anyone's experience good or bad. If it is of a sensitive
nature than please feel free to email me offline.

The changes that Oracle makes seems small enough so should be theoretically
possible. I have not yet done my own testing and will do so in due course.

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

Re: [Spacewalk-list] Massive problems with slow updates on rhnServerAction

[Patrick Hurrelmann]

On 20.09.2012 16:04, Jonathan Scott wrote:
> Paul,
> 
> This is reading like the exact same issue you and I discussed on-list a
> few weeks ago. I had closed out that thread as resolved, but the issue
> has since creeped its way back up. Patrick breaks it down well, I too
> just get a pile up of "idle in transaction" db connections which do not
> clear with any configuration change I have made (tcp timeout, idle
> timeout and connection limit adjustments in postgresql.conf); a restart
> of all associated services gives me about 3-5 days before the app
> becomes unresponsive.
> 
> Patrick, may I ask how are you loading your errata?
> 
> - Jonathan

As a short update: I missed one node that had osad still running. Osad
was disabled there as well. I no longer have any update queries waiting.
There are still some idle transactions, but the number is way lower now.
I have the strong feeling that this is all connected osad and push to
clients. Anyone else?

But back to your question. I'm running David Nutter's centos-errata.py
on a nightly basis directly after a spacewalk restart.

Regards
Patrick

-- 
Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg

HRB 178831, Amtsgericht München
Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

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

Re: [Spacewalk-list] Massive problems with slow updates on rhnServerAction

[Jonathan Scott]

Paul,

This is reading like the exact same issue you and I discussed on-list a few
weeks ago. I had closed out that thread as resolved, but the issue has
since creeped its way back up. Patrick breaks it down well, I too just get
a pile up of "idle in transaction" db connections which do not clear with
any configuration change I have made (tcp timeout, idle timeout and
connection limit adjustments in postgresql.conf); a restart of all
associated services gives me about 3-5 days before the app becomes
unresponsive.

Patrick, may I ask how are you loading your errata?

- Jonathan

On Thu, Sep 20, 2012 at 2:45 AM, Patrick Hurrelmann <
patrick.hurrelm...@lobster.de> wrote:

> Hi,
>
> On 19.09.2012 20:13, Paul Robert Marino wrote:
> > run a full vacuum analyze on the database.
> > once it completes you should be in better shape
>
> Thanks for that suggestion, but been there, done that. This is one of
> the frist steps for postgres related performance issues ;) Right now I
> disabled osad on most local systems and I'm in much better shape now.
> Right now it only has 40 connections open an one hanging "update
> rhnServerAction". Wonder if this really happens due to the use of push
> to the clients?
>
> > and if the count still keeps going up consider utilizing pgpool.
> > pgpool if configured correctly will really just reuse the stale idle
> > connections.
>
> Good idea actually. I will consider this. But it won't help for "Idle in
> transaction", right?
>
> Thanks,
> Patrick
>
> --
> Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg
>
> HRB 178831, Amtsgericht München
> Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
>
> ___
> 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