Re: [Spacewalk-list] End of life for Spacewalk project?
On Thu, May 21, 2020 at 12:08 PM Howard Coles wrote: > >From what I'm seeing it just says that Satellite will end on May 31, not > spacewalk. Where did we read that Spacewalk will be done? > Also, is there a consolidated upstream project similar to Satellite 6? > Because from what I can see SuSE and Oracle (for their unbearable Linux) > use Spacewalk or a similar structure, or am I mistaken? > We used to use spacewalk much more than we do now, but it does need to be > caught up in patching. > > > See Ya' > Howard Coles Jr. > > John 3:16! > > -- > *From:* spacewalk-list-boun...@redhat.com < > spacewalk-list-boun...@redhat.com> on behalf of Paul Greene < > paul.greene...@gmail.com> > *Sent:* Thursday, May 21, 2020 10:23 AM > *To:* spacewalk-list@redhat.com > *Subject:* Re: [Spacewalk-list] End of life for Spacewalk project? > > > EXTERNAL MESSAGE: Exercise Caution > What would be the implications of moving to the newer stack? Would it lose > compatibility with previous versions? > > On Thu, May 21, 2020 at 11:16 AM Joe Belliveau > wrote: > > Means we have to either fork it or move on to the newer stack that redhat > uses. > > My plan so far is to start migrating to the newer stack. Sadly the value > of spacewalk is dropping due to cloud usage. And a lack of understanding > what Spacewalk can do. > > > On 5/21/20 11:04 AM, Paul Greene wrote: > > I have 2 spacewalk servers - one running 2.7 and one running 2.9. I was > looking at the Spacewalk homepage yesterday, thinking about updating to > 2.10, and saw that Spacewalk is being discontinued as of May 31, 2020?? > > What does that mean? It won't be available anymore? No new updates after > that date? What does the future hold for Spacewalk after May 31, 2020? > > > > ___ > Spacewalk-list mailing > listSpacewalk-list@redhat.comhttps://www.redhat.com/mailman/listinfo/spacewalk-list > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_spacewalk-2Dlist=DwMFaQ=fEu2bgw3pNXAPCclXAucaUr2IoGZ7yiSSHPvd02mOBQ=snqX7lBGRnBrdAOZ3eplSnu-aBlPXKFvdkM2GFYwyMc=D1vHJKRwCMAdPzkq53bB-3q5TKY6NcK38fRpdhiPpRU=pWonVgHp7JQVN3y8KlacHHJMAG7hdtSry8aNU09xdCs=> > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_spacewalk-2Dlist=DwMFaQ=fEu2bgw3pNXAPCclXAucaUr2IoGZ7yiSSHPvd02mOBQ=snqX7lBGRnBrdAOZ3eplSnu-aBlPXKFvdkM2GFYwyMc=D1vHJKRwCMAdPzkq53bB-3q5TKY6NcK38fRpdhiPpRU=pWonVgHp7JQVN3y8KlacHHJMAG7hdtSry8aNU09xdCs=> > > ___ > 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] End of life for Spacewalk project?
What would be the implications of moving to the newer stack? Would it lose compatibility with previous versions? On Thu, May 21, 2020 at 11:16 AM Joe Belliveau wrote: > Means we have to either fork it or move on to the newer stack that redhat > uses. > > My plan so far is to start migrating to the newer stack. Sadly the value > of spacewalk is dropping due to cloud usage. And a lack of understanding > what Spacewalk can do. > > > On 5/21/20 11:04 AM, Paul Greene wrote: > > I have 2 spacewalk servers - one running 2.7 and one running 2.9. I was > looking at the Spacewalk homepage yesterday, thinking about updating to > 2.10, and saw that Spacewalk is being discontinued as of May 31, 2020?? > > What does that mean? It won't be available anymore? No new updates after > that date? What does the future hold for Spacewalk after May 31, 2020? > > > > ___ > Spacewalk-list mailing > listSpacewalk-list@redhat.comhttps://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] End of life for Spacewalk project?
I have 2 spacewalk servers - one running 2.7 and one running 2.9. I was looking at the Spacewalk homepage yesterday, thinking about updating to 2.10, and saw that Spacewalk is being discontinued as of May 31, 2020?? What does that mean? It won't be available anymore? No new updates after that date? What does the future hold for Spacewalk after May 31, 2020? ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] "Invalid function call attempted (code 6)"
Ok, I thought I'd found the error (but maybe not). The systems that seemed
to be working correctly had their clients installed from a tarball of all
the RPMs needed to install the client. The newer systems that were all
failing got their rhn* packages from our local yum repos. The RPMs from the
tarball, at least most of them, had newer versions than the ones installed
from the yum repos.
So, I built a new system, used the tarballed RPM files to register the
client to the Spacewalk server, and the remote tasks worked correctly. (I
created a task, ran 'rhn_check -' to run the task right away) The new
system had a kernel # 3.10.0-1062.el7.x86_64.
Then I did a yum update, which left me with kernel #
3.10.0-1062.9.1.el7.x86_64.
After the update, the scheduled tasks started failing again but the errors
were different - I was getting back this in the output of rhn_check:
D: Sending back response(1, 'Script failed', {'output': ' ', 'base64enc':
1, 'process_end': '2020-02-14- 17:56:28', 'return _code': 256,
'process_start': '2020-02-14 17:56:28'})
Nothing more about "Invalid function call ."
On Fri, Feb 14, 2020 at 2:23 PM Stefan Bluhm
wrote:
> Hello Paul,
>
> please check that your up2date config file contains the FQDN. Also make
> sure it is the same FQDN that the Spacewalk server is configured fore.
>
> Best wishes,
>
> Stefan
>
> ------
> *Von: *"Paul Greene"
> *An: *spacewalk-list@redhat.com
> *Gesendet: *Freitag, 14. Februar 2020 18:15:17
> *Betreff: *Re: [Spacewalk-list] "Invalid function call attempted (code 6)"
>
> Ezequiel,
> When I run rhn_check -, the only line in there that looks like an
> error message is "couldn't find any keys in /var/lib/rpm/pubkeys/*.key",
> (the pubkey folder doesn't exist)
>
> but then the next line is "loading keyring from rpmdb", so it looks like
> it gets the key from there.
>
> I get those same messages though on both the machines that fail and the
> ones that succeed.
>
> Paul
>
> On Fri, Feb 14, 2020 at 11:51 AM Paul Greene
> wrote:
>
>> What version of 7 are you running? (including kernel #?)
>>
>> On Fri, Feb 14, 2020 at 11:17 AM Ezequiel Sozzi wrote:
>>
>>> Hi Paul,
>>> Versions should not be the problem, I'm managing almost 4000 servers
>>> with spacewalk and 35% are Centos6 while the other 65% are Centos7.
>>> have you tried to perform a rhn_check - from the client? That could
>>> bring you more information.
>>>
>>> BR,
>>>
>>> El vie., 14 de feb. de 2020 a la(s) 13:12, Paul Greene (
>>> paul.greene...@gmail.com) escribió:
>>>
>>>> Ezequiel,
>>>>
>>>> I tried it but it didn't seem to do anything.
>>>> These systems have no connection to the internet - our repositories are
>>>> all internal to the network (one repo for base, one for updates, and one
>>>> for EPEL), and they have all the latest updates anyway, so there was
>>>> nothing to update.
>>>> Not sure where to go with this.
>>>> Just to add to my second post - older versions of CentOS 7 aren't
>>>> having issues, and there's many systems still on CentOS 6 that don't have
>>>> any issues either. So that leads me to believe there's something about the
>>>> differences in OS versions that are the root of the problem.
>>>>
>>>> Paul
>>>>
>>>> On Thu, Feb 13, 2020 at 7:23 PM Ezequiel Sozzi
>>>> wrote:
>>>>
>>>>> Hi Paul,
>>>>> This a more often issue than everybody things, in order to fix this,
>>>>> what we do is to run the next commands on the client side:
>>>>>
>>>>> Disable all the plugins to disable rhnplugin: sed -i
>>>>> 's/plugins=1/plugins=0/g' /etc/yum.conf
>>>>>
>>>>> Disable all the external repositores: yum-config-manager --disable \*
>>>>>
>>>>> Re-enable all the plugins to enable rhnplugin: sed -i
>>>>> 's/plugins=0/plugins=1/g' /etc/yum.conf
>>>>> Update all the packages related to rpm, rhn, and yum: yum update rpm*
>>>>> rhn* yum* -y
>>>>>
>>>>> This fix the issue. At least that's my experience. Hope this helps.
>>>>>
>>>>> BR,
>>>>>
>>>>> Ezequiel
>>>>>
>>>>>
>>>>>
>>>>> El jue., 13 de febrero de 2020 7:26 p. m., Paul Greene <
>>>>> paul.greene...@gmail.com> escribió:
>>>>>
>>>>>> I
Re: [Spacewalk-list] "Invalid function call attempted (code 6)"
Ezequiel, When I run rhn_check -, the only line in there that looks like an error message is "couldn't find any keys in /var/lib/rpm/pubkeys/*.key", (the pubkey folder doesn't exist) but then the next line is "loading keyring from rpmdb", so it looks like it gets the key from there. I get those same messages though on both the machines that fail and the ones that succeed. Paul On Fri, Feb 14, 2020 at 11:51 AM Paul Greene wrote: > What version of 7 are you running? (including kernel #?) > > On Fri, Feb 14, 2020 at 11:17 AM Ezequiel Sozzi wrote: > >> Hi Paul, >> >> Versions should not be the problem, I'm managing almost 4000 servers with >> spacewalk and 35% are Centos6 while the other 65% are Centos7. >> have you tried to perform a rhn_check - from the client? That could >> bring you more information. >> >> BR, >> >> El vie., 14 de feb. de 2020 a la(s) 13:12, Paul Greene ( >> paul.greene...@gmail.com) escribió: >> >>> Ezequiel, >>> >>> I tried it but it didn't seem to do anything. >>> These systems have no connection to the internet - our repositories are >>> all internal to the network (one repo for base, one for updates, and one >>> for EPEL), and they have all the latest updates anyway, so there was >>> nothing to update. >>> Not sure where to go with this. >>> Just to add to my second post - older versions of CentOS 7 aren't having >>> issues, and there's many systems still on CentOS 6 that don't have any >>> issues either. So that leads me to believe there's something about the >>> differences in OS versions that are the root of the problem. >>> >>> Paul >>> >>> On Thu, Feb 13, 2020 at 7:23 PM Ezequiel Sozzi wrote: >>> >>>> Hi Paul, >>>> >>>> This a more often issue than everybody things, in order to fix this, >>>> what we do is to run the next commands on the client side: >>>> >>>> Disable all the plugins to disable rhnplugin: sed -i >>>> 's/plugins=1/plugins=0/g' /etc/yum.conf >>>> >>>> Disable all the external repositores: yum-config-manager --disable \* >>>> >>>> Re-enable all the plugins to enable rhnplugin: sed -i >>>> 's/plugins=0/plugins=1/g' /etc/yum.conf >>>> Update all the packages related to rpm, rhn, and yum: yum update rpm* >>>> rhn* yum* -y >>>> >>>> This fix the issue. At least that's my experience. Hope this helps. >>>> >>>> BR, >>>> >>>> Ezequiel >>>> >>>> >>>> >>>> El jue., 13 de febrero de 2020 7:26 p. m., Paul Greene < >>>> paul.greene...@gmail.com> escribió: >>>> >>>>> I have a spacewalk 2.9 server with CentOS 7 clients. When I run a >>>>> scheduled remote command on 50 systems, usually about half of the systems >>>>> will get marked as "failed" with the error "Invalid function call >>>>> attempted >>>>> (code 6)". >>>>> >>>>> They all have the same configuration, and every line put in the remote >>>>> command will run just fine from a command prompt. If I go into a system >>>>> that has been marked "failed" and manually verify if the command did what >>>>> it was supposed to do, many times it actually did succeed, but was still >>>>> marked "failed". And there are some that did in fact fail. >>>>> >>>>> How can I address this error to get rid of the false "failed" messages? >>>>> >>>>> I looked in /var/log/up2date on the clients that failed and get just >>>>> these messages at the time the scheduled task failed: >>>>> >>>>> up2date updateLoginfo() login info >>>>> up2date logging into up2date server >>>>> up2date successfully retrieved authentication token from up2date server >>>>> ___ >>>>> Spacewalk-list mailing list >>>>> Spacewalk-list@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/spacewalk-list >>>> >>>> ___ >>>> Spacewalk-list mailing list >>>> Spacewalk-list@redhat.com >>>> https://www.redhat.com/mailman/listinfo/spacewalk-list >>> >>> ___ >>> Spacewalk-list mailing list >>> Spacewalk-list@redhat.com >>> https://www.redhat.com/mailman/listinfo/spacewalk-list >> >> ___ >> Spacewalk-list mailing list >> Spacewalk-list@redhat.com >> https://www.redhat.com/mailman/listinfo/spacewalk-list > > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] "Invalid function call attempted (code 6)"
What version of 7 are you running? (including kernel #?) On Fri, Feb 14, 2020 at 11:17 AM Ezequiel Sozzi wrote: > Hi Paul, > > Versions should not be the problem, I'm managing almost 4000 servers with > spacewalk and 35% are Centos6 while the other 65% are Centos7. > have you tried to perform a rhn_check - from the client? That could > bring you more information. > > BR, > > El vie., 14 de feb. de 2020 a la(s) 13:12, Paul Greene ( > paul.greene...@gmail.com) escribió: > >> Ezequiel, >> >> I tried it but it didn't seem to do anything. >> These systems have no connection to the internet - our repositories are >> all internal to the network (one repo for base, one for updates, and one >> for EPEL), and they have all the latest updates anyway, so there was >> nothing to update. >> Not sure where to go with this. >> Just to add to my second post - older versions of CentOS 7 aren't having >> issues, and there's many systems still on CentOS 6 that don't have any >> issues either. So that leads me to believe there's something about the >> differences in OS versions that are the root of the problem. >> >> Paul >> >> On Thu, Feb 13, 2020 at 7:23 PM Ezequiel Sozzi wrote: >> >>> Hi Paul, >>> >>> This a more often issue than everybody things, in order to fix this, >>> what we do is to run the next commands on the client side: >>> >>> Disable all the plugins to disable rhnplugin: sed -i >>> 's/plugins=1/plugins=0/g' /etc/yum.conf >>> >>> Disable all the external repositores: yum-config-manager --disable \* >>> >>> Re-enable all the plugins to enable rhnplugin: sed -i >>> 's/plugins=0/plugins=1/g' /etc/yum.conf >>> Update all the packages related to rpm, rhn, and yum: yum update rpm* >>> rhn* yum* -y >>> >>> This fix the issue. At least that's my experience. Hope this helps. >>> >>> BR, >>> >>> Ezequiel >>> >>> >>> >>> El jue., 13 de febrero de 2020 7:26 p. m., Paul Greene < >>> paul.greene...@gmail.com> escribió: >>> >>>> I have a spacewalk 2.9 server with CentOS 7 clients. When I run a >>>> scheduled remote command on 50 systems, usually about half of the systems >>>> will get marked as "failed" with the error "Invalid function call attempted >>>> (code 6)". >>>> >>>> They all have the same configuration, and every line put in the remote >>>> command will run just fine from a command prompt. If I go into a system >>>> that has been marked "failed" and manually verify if the command did what >>>> it was supposed to do, many times it actually did succeed, but was still >>>> marked "failed". And there are some that did in fact fail. >>>> >>>> How can I address this error to get rid of the false "failed" messages? >>>> >>>> I looked in /var/log/up2date on the clients that failed and get just >>>> these messages at the time the scheduled task failed: >>>> >>>> up2date updateLoginfo() login info >>>> up2date logging into up2date server >>>> up2date successfully retrieved authentication token from up2date server >>>> ___ >>>> Spacewalk-list mailing list >>>> Spacewalk-list@redhat.com >>>> https://www.redhat.com/mailman/listinfo/spacewalk-list >>> >>> ___ >>> Spacewalk-list mailing list >>> Spacewalk-list@redhat.com >>> https://www.redhat.com/mailman/listinfo/spacewalk-list >> >> ___ >> Spacewalk-list mailing list >> Spacewalk-list@redhat.com >> https://www.redhat.com/mailman/listinfo/spacewalk-list > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] "Invalid function call attempted (code 6)"
Ezequiel, I tried it but it didn't seem to do anything. These systems have no connection to the internet - our repositories are all internal to the network (one repo for base, one for updates, and one for EPEL), and they have all the latest updates anyway, so there was nothing to update. Not sure where to go with this. Just to add to my second post - older versions of CentOS 7 aren't having issues, and there's many systems still on CentOS 6 that don't have any issues either. So that leads me to believe there's something about the differences in OS versions that are the root of the problem. Paul On Thu, Feb 13, 2020 at 7:23 PM Ezequiel Sozzi wrote: > Hi Paul, > > This a more often issue than everybody things, in order to fix this, > what we do is to run the next commands on the client side: > > Disable all the plugins to disable rhnplugin: sed -i > 's/plugins=1/plugins=0/g' /etc/yum.conf > > Disable all the external repositores: yum-config-manager --disable \* > > Re-enable all the plugins to enable rhnplugin: sed -i > 's/plugins=0/plugins=1/g' /etc/yum.conf > Update all the packages related to rpm, rhn, and yum: yum update rpm* rhn* > yum* -y > > This fix the issue. At least that's my experience. Hope this helps. > > BR, > > Ezequiel > > > > El jue., 13 de febrero de 2020 7:26 p. m., Paul Greene < > paul.greene...@gmail.com> escribió: > >> I have a spacewalk 2.9 server with CentOS 7 clients. When I run a >> scheduled remote command on 50 systems, usually about half of the systems >> will get marked as "failed" with the error "Invalid function call attempted >> (code 6)". >> >> They all have the same configuration, and every line put in the remote >> command will run just fine from a command prompt. If I go into a system >> that has been marked "failed" and manually verify if the command did what >> it was supposed to do, many times it actually did succeed, but was still >> marked "failed". And there are some that did in fact fail. >> >> How can I address this error to get rid of the false "failed" messages? >> >> I looked in /var/log/up2date on the clients that failed and get just >> these messages at the time the scheduled task failed: >> >> up2date updateLoginfo() login info >> up2date logging into up2date server >> up2date successfully retrieved authentication token from up2date server >> ___ >> 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] "Invalid function call attempted (code 6)"
Just to add some more info that might be relevant. The spacewalk server itself is running CentOS 7.7, kernel 3.10.0-1062.9.1.el7.x86_64, and most of the clients that are failing are running the same kernel. There's some machines running an older kernel - 3.10.0-862.14.4.el7.x86_64 - and on these machines they seem to reliably run the task without problems. A small number of machines on the newer kernel succeed with the task, but most don't. On Thu, Feb 13, 2020 at 5:25 PM Paul Greene wrote: > I have a spacewalk 2.9 server with CentOS 7 clients. When I run a > scheduled remote command on 50 systems, usually about half of the systems > will get marked as "failed" with the error "Invalid function call attempted > (code 6)". > > They all have the same configuration, and every line put in the remote > command will run just fine from a command prompt. If I go into a system > that has been marked "failed" and manually verify if the command did what > it was supposed to do, many times it actually did succeed, but was still > marked "failed". And there are some that did in fact fail. > > How can I address this error to get rid of the false "failed" messages? > > I looked in /var/log/up2date on the clients that failed and get just these > messages at the time the scheduled task failed: > > up2date updateLoginfo() login info > up2date logging into up2date server > up2date successfully retrieved authentication token from up2date server > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] "Invalid function call attempted (code 6)"
I have a spacewalk 2.9 server with CentOS 7 clients. When I run a scheduled remote command on 50 systems, usually about half of the systems will get marked as "failed" with the error "Invalid function call attempted (code 6)". They all have the same configuration, and every line put in the remote command will run just fine from a command prompt. If I go into a system that has been marked "failed" and manually verify if the command did what it was supposed to do, many times it actually did succeed, but was still marked "failed". And there are some that did in fact fail. How can I address this error to get rid of the false "failed" messages? I looked in /var/log/up2date on the clients that failed and get just these messages at the time the scheduled task failed: up2date updateLoginfo() login info up2date logging into up2date server up2date successfully retrieved authentication token from up2date server ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Invalid function call attempted (code 6)
Please don't hijack threads
On Tue, Jan 21, 2020 at 4:27 PM Muhammad Mosleh Uddin
wrote:
> No. That wasn’t the issue..
> It was the repo issue..
> Thanks for your support
>
> On Tue, Jan 21, 2020 at 4:01 PM Robert Paschedag
> wrote:
>
>> At least one "Action" is missing in /usr/share/rhn/actions that has the
>> checkNeedUpdate
>>
>> Robert
>>
>> sent from my mobile device
>>
>>
>> Originale Nachricht
>> Von: Muhammad Mosleh Uddin
>> Gesendet: Tue Jan 21 17:18:21 GMT+01:00 2020
>> An: spacewalk-list@redhat.com
>> Betreff: Re: [Spacewalk-list] Invalid function call attempted (code 6)
>>
>> Hi.
>> Thanks for your respond.
>> No, it wasnt the issue.
>>
>>
>> On Mon, Jan 20, 2020 at 4:52 AM Michael Mraka
>> wrote:
>>
>> > Muhammad Mosleh Uddin:
>> > > i paul,
>> > > my rhel client is not pulling package from spacewalk server.
>> > > my spacewalk client is test01. spacewalk can sync redhat channel and I
>> > see
>> > > some packages.
>> > >
>> > > [root@test01 yum.repos.d]# rhn_check -vv
>> > > D: do_call packages.checkNeedUpdate('rhnsd=1',){}
>> > > D: Attempt to call an unsupported action
>> > > packages.checkNeedUpdate('rhnsd=1',)
>> > > D: local action status: (6, 'Invalid function call attempted', {})
>> > > D: rpcServer: Calling XMLRPC registration.welcome_message
>> >
>> > It looks like yum-rhn-plugin is missing on the client.
>> >
>> > Regards,
>> >
>> > --
>> > Michael Mráka
>> > System Management Engineering, Red Hat
>> >
>> > ___
>> > Spacewalk-list mailing list
>> > Spacewalk-list@redhat.com
>> > https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>>
>>
>> --
>>
>>
>>
>>
>> Muhammad Mosleh Uddin
>>
>>
>>
>>
>> ___
>> 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
>
> --
> Sent from Iphone
> ___
> 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] Invalid function call attempted (code 6)
I checked into a few systems that failed and looked for logs at the time the failure supposedly happened, and it just had these 3 lines at that specific time: up2date updateLoginfo() login info up2date logging into up2date server up2date successfully retrieved authentication token from up2date server On Fri, Jan 17, 2020 at 7:45 AM Michael Mraka wrote: > Paul Greene: > > I have a spacewalk 2.9 server with CentOS 7 clients. When I run a > scheduled > > remote command on 50 systems, usually about half of the systems will get > > marked as "failed" with the error "Invalid function call attempted (code > > 6)". > > > > They all have the same configuration, and every line put in the remote > > command will run just fine from a command prompt. If I go into a system > > that has been marked "failed" and manually verify if the command did what > > it was supposed to do, many times it actually did succeed, but was still > > marked "failed". And there are some that did in fact fail. > > > > How can I address this error to get rid of the false "failed" messages? > > Hello Paul, > > There should be more detailed error message in /var/log/up2date on > failed client. > > Regards, > > -- > Michael Mráka > System Management Engineering, Red Hat > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Invalid function call attempted (code 6)
I have a spacewalk 2.9 server with CentOS 7 clients. When I run a scheduled remote command on 50 systems, usually about half of the systems will get marked as "failed" with the error "Invalid function call attempted (code 6)". They all have the same configuration, and every line put in the remote command will run just fine from a command prompt. If I go into a system that has been marked "failed" and manually verify if the command did what it was supposed to do, many times it actually did succeed, but was still marked "failed". And there are some that did in fact fail. How can I address this error to get rid of the false "failed" messages? ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Migrating from 2.7 to 2.9
I probably jumped the gun on the slow response rate of the remote tasks I'd scheduled - they eventually did kick in But, if anyone has some input on whether or not there's likely to be an issue because I didn't update the clients, I'd eagerly appreciate some feedback. Thanks On Wed, Jun 26, 2019 at 4:01 PM Paul Greene wrote: > Hello, > > I have a bunch of systems registered to a Spacewalk 2.7 server and am in > the process of moving them over to a newly built 2.9 server. > > For the first client I moved over, I removed all of the old 2.7 client > packages and then installed the new ones from the 2.9 client packages. > > For subsequent clients, I found that I could replace the existing 2.7 > /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT with the cert from that first 2.9 > client, and then re-run: > rhnreg_ks --serverUrl=https:///XMLRPC --ssl > CACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1- > --force > > It seemed to register with the new server just fine without having to > update any rhn-* client packages. > > Maybe I'm overthinking it, but I'm wondering if not updating any of the > client packages to 2.9 is going to cause any issues that aren't initially > apparent. I tried to push out some remote commands to a group of 7 systems, > and I usually start seeing some successful and/or failed actions within > maybe 15 minutes or so, but it's been about an hour and a half now and > there hasn't been any movement yet on the remote tasks. > > Can anyone think of any potential issues I might be running in to taking > this route? > > PG > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Migrating from 2.7 to 2.9
Hello, I have a bunch of systems registered to a Spacewalk 2.7 server and am in the process of moving them over to a newly built 2.9 server. For the first client I moved over, I removed all of the old 2.7 client packages and then installed the new ones from the 2.9 client packages. For subsequent clients, I found that I could replace the existing 2.7 /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT with the cert from that first 2.9 client, and then re-run: rhnreg_ks --serverUrl=https:///XMLRPC --ssl CACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1- --force It seemed to register with the new server just fine without having to update any rhn-* client packages. Maybe I'm overthinking it, but I'm wondering if not updating any of the client packages to 2.9 is going to cause any issues that aren't initially apparent. I tried to push out some remote commands to a group of 7 systems, and I usually start seeing some successful and/or failed actions within maybe 15 minutes or so, but it's been about an hour and a half now and there hasn't been any movement yet on the remote tasks. Can anyone think of any potential issues I might be running in to taking this route? PG ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] How to download Spacewalk for an offline install?
Is there an archive you can download of just the needed Spacewalk 2.9 packages to do an offline install of Spacewalk (the server and client packages)? I have access to CentOS 7 base, updates, and EPEL 7 via local repos, so I don't need anything from there - I just need the spacewalk rpms. Thanks, PG ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
When I'd do upgrades from 7.5 to 7.6, they ran fine - no errors, everything
seemed normal. Nothing out of the ordinary in yum history.
I thought for a while that maybe 7.6 didn't like our video hardware - an
older NVIDIA card, some were dual head (the 315 card) and some were 3 heads
(the 440 card), but another sys admin with another group wasn't having any
issues with 7.6 using similar hardware. I tried building a clean machine
and did an update to 7.6, but didn't join it to Spacewalk and used it as my
work machine for a couple of weeks and didn't have any issues with it.
I like Spacewalk and want to continue using it. I did start to try Ansible,
but I was finding most of what I wanted to do with Ansible I could do using
remote commands through Spacewalk, and it was quick and easy, so I got lazy
about working through the Ansible learning curve. Ansible is probably a lot
more powerful for such things than Spacewalk, so maybe I just need to
revisit it again and grind through the learning curve.
On Thu, Jun 20, 2019 at 10:49 AM p.cook...@bham.ac.uk
wrote:
> May be I should have said, don’t use a local repo unless you really have
> to – and it seems like you do. There are clear benefits in having Spacewalk
> patching though – you get a clearer graphical view of the system’s patch
> status etc. May be you could push for an exception for web access
> controlled through something like Squid but, obviously, I don’t know what
> hurdles you face within your organisation.
>
>
>
> As I suggested, running a manual “yum update” or checking out “yum
> history” may help you identify any problem in that area. Equally, tailing
> the sync log file, while syncing, or using “reposync” from the command line.
>
>
>
> 2.9 has been out since January and still the current version so, yes, I
> would say use that for any new build.
>
>
>
> The systems will continue to look to Spacewalk for updates as a yum plugin
> etc is installed during registration. I’ve developed a procedure to
> un-register a system or re-register to a different Spacewalk server, for
> our environments, if you think that would be useful?
>
>
>
> Re Scott’s comments, below, I’ve just began using Ansible AWX and starting
> to realise its benefitsJ
>
>
>
> Regards
>
> Phil
>
>
>
> *From:* spacewalk-list-boun...@redhat.com <
> spacewalk-list-boun...@redhat.com> *On Behalf Of *
> scott.c.worthing...@gmail.com
> *Sent:* 20 June 2019 15:08
> *To:* spacewalk-list
> *Subject:* Re: [Spacewalk-list] Oddball question about Spacewalk possibly
> corrupting yum update
>
>
>
> If you want to stick to your local yum repo, have you considered the
> following:
>
>
>
> * For collecting hardware inventory and installed packages:
>
> 1. https://github.com/fboender/ansible-cmdb
>
>
>
> * Using Ansible for configuration management ("sending remote commands to
> big groups at once")?
>
>
>
> And if you need a front end for Ansible, you could investigate:
>
> 1. https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin
>
> 2. https://github.com/Batix/rundeck-ansible-plugin
>
> 3. https://github.com/ansible/awx
>
>
>
>
>
> On Thu, Jun 20, 2019 at 8:29 AM Paul Greene
> wrote:
>
> These systems are on a network that has no access to the internet - local
> repos are the only way to update them.
>
> I have no idea which X package is causing trouble.
>
> I never really wanted to use the Spacewalk server for patching in the
> first place. My local yum repository works just fine. I like using
> Spacewalk as a management tool - it's good at showing the hardware
> inventory, and for sending remote commands to big groups at once. There
> isn't enough time in the day to have to go out and touch 250 systems one by
> one for basic maintenance tasks.
>
> Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already?
>
>
>
> On Thu, Jun 20, 2019 at 4:26 AM p.cook...@bham.ac.uk
> wrote:
>
> Hi Paul
>
>
>
> I haven’t got any CentOS systems to patch, with Spacewalk, but a few
> thoughts…..
>
>
>
> Not sure why you would start with 2.7 or sync from a local repo really? If
> you just didn’t want to go too bleeding edge with 2.9 I would at least
> start with 2.8. In addition, I wouldn’t bother syncing from a local repo as
> you can go direct to the CentOS web repo’s which are kept up to date – see
> eg’s below:
>
>
>
> http://mirror.centos.org/centos/7/os/x86_64/ #Base
>
> http://mirror.centos.org/centos/7/extras/x86_64/ #Extras
>
> http://mirror.centos.org/centos/7/updates/x86_64/ #Updates
>
>
>
> You should find this combination will resolve any issues b
Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
These systems are on a network that has no access to the internet - local repos are the only way to update them. I have no idea which X package is causing trouble. I never really wanted to use the Spacewalk server for patching in the first place. My local yum repository works just fine. I like using Spacewalk as a management tool - it's good at showing the hardware inventory, and for sending remote commands to big groups at once. There isn't enough time in the day to have to go out and touch 250 systems one by one for basic maintenance tasks. Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already? On Thu, Jun 20, 2019 at 4:26 AM p.cook...@bham.ac.uk wrote: > Hi Paul > > > > I haven’t got any CentOS systems to patch, with Spacewalk, but a few > thoughts….. > > > > Not sure why you would start with 2.7 or sync from a local repo really? If > you just didn’t want to go too bleeding edge with 2.9 I would at least > start with 2.8. In addition, I wouldn’t bother syncing from a local repo as > you can go direct to the CentOS web repo’s which are kept up to date – see > eg’s below: > > > > http://mirror.centos.org/centos/7/os/x86_64/ #Base > > http://mirror.centos.org/centos/7/extras/x86_64/ #Extras > > http://mirror.centos.org/centos/7/updates/x86_64/ #Updates > > > > You should find this combination will resolve any issues but, if not, you > could sync the repo from the command line (using “reposync”) so you can > watch it go through. However, there are repo sync logs in > /var/log/rhn/reposync/ as well. > > > > In addition, you could try manually updating a system from the command > line (using “yum update”) and/or excluding the X-Windows package you > suspect (using “yum update -X ”), which may help you identify the > problem too. > > > > Unfortunately, Spacewalk does not provide an option to un-register a > client system (similar to registering - “rhnreg_ks”) – the only option is > to remove the client system’s profile from the Spacewalk server, then > remove the /etc/sysconfig/rhn/systemid file etc on the client system. > > > > Hope this is of help. > > > > Regards > > Phil > > > > > > > > > > > > *From:* spacewalk-list-boun...@redhat.com < > spacewalk-list-boun...@redhat.com> *On Behalf Of *paul.greene...@gmail.com > *Sent:* 19 June 2019 17:00 > *To:* spacewalk-list@redhat.com > *Subject:* [Spacewalk-list] Oddball question about Spacewalk possibly > corrupting yum update > > > > I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6 > workstations, and synced it to a local yum repository. > > > > After a few months I started adding some CentOS 7 systems to the mix, and > also synced to the same local yum repository (same server, different path > to the repositories, of course). > > > > The Spacewalk server always seemed to have an issue getting a successful > full sync with the CentOS 7 local repository after the 7.6 series came out. > I wasn't concerned at first because the systems were configured to go to > the local yum repository anyway (configured in /etc/yum.repos.d). > > > > After the CentOS 7.6 series came out, I started having an issue with any > machine that got the 7.6 updates where the system would freeze and lock up, > requiring a hard reboot to get it usable again. That happened on at least a > daily basis and sometimes multiple times a day. I rolled those users back > to CentOS 7.5 to get them a functioning stable machine again, and didn't > update anybody that was running 7.5. It seemed definitely related to X > windows - I could still go to a command prompt with ctrl-alt-f2 and work > from a command prompt, but X windows wouldn't come back without a hard > reboot. On a couple of servers that didn't need X windows and had the run > level set to multi-user.target, they didn't have an issue - it was only the > workstations that needed X windows. > > > > I have access to another yum repository independent of the Spacewalk > server, and noticed if I updated a workstation to that repository and did > NOT join the machine to the Spacewalk server, they all ran fine with CentOS > 7.6. As long as I didn't join them to the Spacewalk server there were no > issues. I tried deleting the CentOS 7 yum repository from the Spacewalk > server, thinking maybe the yum repository on the Spacewalk server had > gotten corrupted and was pushing out some bad files, but that didn't work. > > > > The systems still seem to be looking to the Spacewalk server for updates, > regardless of what is in /etc/yum.repos.d. > > > > Hopefully someone else has seen something like this before. I would either > like to remove any and all yum configurations from the Spacewalk server, if > possible, and just point to the local yum repository for any kind of > updates. > > > > Barring that, I'm interested in updating to Spacewalk 2.9 anyway, and > would build a new 2.9 server, migrate everything over to that, and leave > out any yum repository configuration at
[Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6 workstations, and synced it to a local yum repository. After a few months I started adding some CentOS 7 systems to the mix, and also synced to the same local yum repository (same server, different path to the repositories, of course). The Spacewalk server always seemed to have an issue getting a successful full sync with the CentOS 7 local repository after the 7.6 series came out. I wasn't concerned at first because the systems were configured to go to the local yum repository anyway (configured in /etc/yum.repos.d). After the CentOS 7.6 series came out, I started having an issue with any machine that got the 7.6 updates where the system would freeze and lock up, requiring a hard reboot to get it usable again. That happened on at least a daily basis and sometimes multiple times a day. I rolled those users back to CentOS 7.5 to get them a functioning stable machine again, and didn't update anybody that was running 7.5. It seemed definitely related to X windows - I could still go to a command prompt with ctrl-alt-f2 and work from a command prompt, but X windows wouldn't come back without a hard reboot. On a couple of servers that didn't need X windows and had the run level set to multi-user.target, they didn't have an issue - it was only the workstations that needed X windows. I have access to another yum repository independent of the Spacewalk server, and noticed if I updated a workstation to that repository and did NOT join the machine to the Spacewalk server, they all ran fine with CentOS 7.6. As long as I didn't join them to the Spacewalk server there were no issues. I tried deleting the CentOS 7 yum repository from the Spacewalk server, thinking maybe the yum repository on the Spacewalk server had gotten corrupted and was pushing out some bad files, but that didn't work. The systems still seem to be looking to the Spacewalk server for updates, regardless of what is in /etc/yum.repos.d. Hopefully someone else has seen something like this before. I would either like to remove any and all yum configurations from the Spacewalk server, if possible, and just point to the local yum repository for any kind of updates. Barring that, I'm interested in updating to Spacewalk 2.9 anyway, and would build a new 2.9 server, migrate everything over to that, and leave out any yum repository configuration at all on that new server. The CentOS 6 systems are fine - no issues at all with updates and/or yum repositories. Thanks, PG ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Is the rhnsd service required to be able to communicate with a spacewalk server?
I'm going to ask them to exempt this one. The spacewalk server is very useful for managing large numbers of machines, and it sounds like this would break some of that management capability. On Thu, Jun 13, 2019 at 2:18 PM William Hongach wrote: > Hello, > > > > It is the service (or related timer) that runs rhn_check based on the > interval specified in /etc/sysconfig/rhn/rhnsd. This is how Spacewalk > clients check in with the server for queued tasks. There should be a man > page available for rhnsd. > > > > If you shut it down, the client will not check in with the server, unless > rhn_check is run manually or via a scheduled task like cron. However, if > you run osad (I do not) then I do not believe you need it since that is a > different model. But your security team may also flag osad like they > flagged rhnsd. > > > > *From:* spacewalk-list-boun...@redhat.com < > spacewalk-list-boun...@redhat.com> *On Behalf Of *Paul Greene > *Sent:* Thursday, June 13, 2019 1:56 PM > *To:* spacewalk-list@redhat.com > *Subject:* Re: [Spacewalk-list] Is the rhnsd service required to be able > to communicate with a spacewalk server? > > > > What is the actual function of rhnsd? What is actually being lost if its > not running? > > > > On Thu, Jun 13, 2019 at 1:02 PM William Hongach < > william.hong...@marist.edu> wrote: > > Hello, > > > > I suppose you could run rhn_check out of cron if you did not want rhnsd to > schedule it. > > > > *From:* spacewalk-list-boun...@redhat.com < > spacewalk-list-boun...@redhat.com> *On Behalf Of *Paul Greene > *Sent:* Thursday, June 13, 2019 12:31 PM > *To:* Spacewalk-list@redhat.com > *Subject:* [Spacewalk-list] Is the rhnsd service required to be able to > communicate with a spacewalk server? > > > > Our security group is telling me, based on a Nessus scan, that I need to > disable the rhnsd service. > > > > Is the rhnsd service required to be able to communicate with a spacewalk > server? > > ___ > 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] Is the rhnsd service required to be able to communicate with a spacewalk server?
What is the actual function of rhnsd? What is actually being lost if its not running? On Thu, Jun 13, 2019 at 1:02 PM William Hongach wrote: > Hello, > > > > I suppose you could run rhn_check out of cron if you did not want rhnsd to > schedule it. > > > > *From:* spacewalk-list-boun...@redhat.com < > spacewalk-list-boun...@redhat.com> *On Behalf Of *Paul Greene > *Sent:* Thursday, June 13, 2019 12:31 PM > *To:* Spacewalk-list@redhat.com > *Subject:* [Spacewalk-list] Is the rhnsd service required to be able to > communicate with a spacewalk server? > > > > Our security group is telling me, based on a Nessus scan, that I need to > disable the rhnsd service. > > > > Is the rhnsd service required to be able to communicate with a spacewalk > server? > ___ > 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 the rhnsd service required to be able to communicate with a spacewalk server?
Our security group is telling me, based on a Nessus scan, that I need to disable the rhnsd service. Is the rhnsd service required to be able to communicate with a spacewalk server? ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk capability question
Thank you for such detailed information William. Do those rhn-action commands need to be run on each individual client? Or do they need to be run on the Spacewalk server? On Tue, Apr 10, 2018 at 5:50 PM, William H. ten Bensel <whten...@up.com> wrote: > Spacewalk should be setup to already schedule. IF you want the commands > to run immediately, then install osad on the clients. However there is a > cost with doing that (Will not cover). If you do not install osad, on the > next rhn-check (default every 4 hours) the commands will run. > > On the client side, > > When you registered the SSL cert should have been applied.. You can verify: > by looking in /etc/sysconfig/up2date and the file > /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT ( > > If you installed rhncfg-actions, then check to see it they are enabled > rhn-actions-control --report > rhn-actions-control --enable-all (or whatever you want) > rhn-actions-control --report > > Once that is done you have multiple ways of scheduling: > UI > > spacecmd (To make it so that the password is not in history) > --> more under man spacecmd >vi ~/.spacecmd/config >[spacewalk] >server=.x.com >username=xx > password=xx > > spacecmd -s spacewalk help system_runscript > spacecmd -s spacewalk -- system_runscript server1 server2 server3 > -u root -g root -t7200 -f script.xx >spacecmd -s spacewalk -- system_runscript channel:xx -u > root -g root -t7200 -f script.xx > >The script can be bash/perl/python.. exit 1 if there is a problem, > the Spacewalk UI -> Schedule will have a list of failed. Or you can get > the list of failures trough spacecmd as well. > > > # below pkg needed for rhn registration > rhn-check > rhnsd > rhn-setup > rhn-client-tools > yum-rhn-plugin > libidn > rhncfg > rhncfg-client > rhncfg-actions > pyOpenSSL > libxml2-python > rhnlib > libxml2 > perl > > > > > > From:Paul Greene <paul.greene...@gmail.com> > To:spacewalk-list@redhat.com > Date:04/10/2018 01:17 PM > Subject:Re: [Spacewalk-list] Spacewalk capability question > Sent by:spacewalk-list-boun...@redhat.com > -- > > > > This email originated from outside of the company. Please use discretion > if opening attachments or clicking on links. > -- > > > It looks like, to use that feature, you need osa-dispatcher installed, and > SSL configured between Spacewalk and the clients - is that correct? (I have > neither installed/configured at this point) > > On Tue, Apr 10, 2018 at 1:49 PM, Ezequiel Sozzi <*soz...@gmail.com* > <soz...@gmail.com>> wrote: > Paul, > > You can push commands with the option "remote commands" from SSM. > > BR, > > 2018-04-10 14:37 GMT-03:00 Paul Greene <*paul.greene...@gmail.com* > <paul.greene...@gmail.com>>: > I'm new to Spacewalk - just got it installed and registered a couple > hundred CentOS workstations (6.9). > > I need to implement a security setting on all of these machines - > "chkconfig --level 2345 restorecond on" > > Is there a way in Spacewalk to push that setting/command out to all of > these machines automatically? > > Thanks > > PG > > ___ > Spacewalk-list mailing list > *Spacewalk-list@redhat.com* <Spacewalk-list@redhat.com> > *https://www.redhat.com/mailman/listinfo/spacewalk-list* > <https://www.redhat.com/mailman/listinfo/spacewalk-list> > > > ___ > Spacewalk-list mailing list > *Spacewalk-list@redhat.com* <Spacewalk-list@redhat.com> > *https://www.redhat.com/mailman/listinfo/spacewalk-list* > <https://www.redhat.com/mailman/listinfo/spacewalk-list> > This email originated from outside of the company. Please use discretion > if opening attachments or clicking on links. > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > > > > > ** > > > > This email and any attachments may contain information that is > confidential and/or privileged for the sole use of the intended recipient. > Any use, review, disclosure, copying, distribution or reliance by others, > and any forwarding of this email or its contents, without the express > permission of the sender is strictly prohibited by law. If you are not the > intended recipient, please contact the sender immediately, delete the > e-mail and destroy all copies. > > ** > > > ___ > 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 capability question
It looks like, to use that feature, you need osa-dispatcher installed, and SSL configured between Spacewalk and the clients - is that correct? (I have neither installed/configured at this point) On Tue, Apr 10, 2018 at 1:49 PM, Ezequiel Sozzi <soz...@gmail.com> wrote: > Paul, > > You can push commands with the option "remote commands" from SSM. > > BR, > > 2018-04-10 14:37 GMT-03:00 Paul Greene <paul.greene...@gmail.com>: > >> I'm new to Spacewalk - just got it installed and registered a couple >> hundred CentOS workstations (6.9). >> >> I need to implement a security setting on all of these machines - >> "chkconfig --level 2345 restorecond on" >> >> Is there a way in Spacewalk to push that setting/command out to all of >> these machines automatically? >> >> Thanks >> >> PG >> >> ___ >> 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] Spacewalk capability question
I'm new to Spacewalk - just got it installed and registered a couple hundred CentOS workstations (6.9). I need to implement a security setting on all of these machines - "chkconfig --level 2345 restorecond on" Is there a way in Spacewalk to push that setting/command out to all of these machines automatically? Thanks PG ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Can spacewalk be used on a disconnected network?
Hi All, I have a requirement to manage a bunch of CentOS servers that are all disconnected from the internet. These are the kinds of things I'm looking to accomplish: yum updates and security patches, preferably for multiple version #s of CentOS 6.7, 6.8, 6.9, and 7.x rapid deployment of new servers, preferably with predefined security configurations; currently, the systems are primarily physical, virtualization might come later sometimes the "rapid deployment of servers" might include blowing away what is currently on an existing server and reinstalling a fresh system For the building of the spacewalk server itself, how complicated is it to build the server itself offline - i.e. resolving all the dependencies and populating with all the needed rpms? (It might be possible to build the server connected to the internet initially, and then move it offline) Is spacewalk a good tool to meet these requirements? Paul ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
