Re: [Spacewalk-list] "Invalid function call attempted (code 6)"

[Ezequiel Sozzi]

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

Re: [Spacewalk-list] "Invalid function call attempted (code 6)"

[Ezequiel Sozzi]

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

Re: [Spacewalk-list] Spacewalk - Packages renamed while errata is installed.

[Ezequiel Sozzi]

Michael,

Yes, I've been able to install it manually, but also have found the
problem, it was not the server, but the client, the RHN Plugin was
installed but not enabled, so the server didn't have any repositories to
download the package.

Thanks all for the Help!

BR

El lun., 16 de abr. de 2018 04:56, Michael Mraka <michael.mr...@redhat.com>
escribió:

> Ezequiel Sozzi:
> >  Michael,
> >
> > The package is under /var/satellite path, yes I can download the package
> > from the webUI, I have tested again the errata's deploy and there are not
> > errors showed on the error_log file.
> >
> > Any further ideas?
>
> Are you able to install this package manually?
>
> yum install libgudev1-219-30.el7_3.9
>
> > Thanks in advance.
> >
> > Ezequiel A. Sozzi.
>
> 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

Re: [Spacewalk-list] Spacewalk - Packages renamed while errata is installed.

[Ezequiel Sozzi]

 Michael,

The package is under /var/satellite path, yes I can download the package
from the webUI, I have tested again the errata's deploy and there are not
errors showed on the error_log file.

Any further ideas?

Thanks in advance.

Ezequiel A. Sozzi.

2018-04-11 4:59 GMT-03:00 Michael Mraka <michael.mr...@redhat.com>:

> Ezequiel Sozzi:
> >  Hello!
> >
> > I'm currently have a problem with erratas deployments. While I'm trying
> to
> > deploy an errata I get the following error:
> >
> > *Details:*
> > This action will be executed after 4/9/18 12:16:00 PM GMT
> > This action's status is: Failed.
> > The client picked up this action on 4/9/18 8:23 AM
> > The client completed this action on 4/9/18 8:23 AM
> > Client execution returned "Failed: Packages failed to install properly:
> > Package libgudev1-0:219-30.el7_3.9.x86_64 is not available for
> > installation" (code 32)
> >
> > Errata Affected:
> >- RHBA-2017:1311 - systemd bug fix update
> ...
> > sha256:d36b44c7639c9ef352289a48c78e2b7b2c20ad16fa140154bdf6d152a6e702ab
> > libgudev1-219-30.el7_3.9-x86_64
> ...
> >
> > Comparing the packages I found that Spacewalk is trying to download
> > libgudev1-*0:*219-30.el7_3.9.x86_64 instead
> libgudev1-219-30.el7_3.9-x86_64
> > I've been looking on rhn logs but I didn't find any log that could advice
> > me about where the "0:" is added to the packages name.
> > More weird is this problem only happens with only one repository.
> >
> > Does anyone have any Idea about what it could be happening?
>
> Hello Ezequiel,
>
> It's not a but It's just two different way how to reference the package.
> libgudev1-219-30.el7_3.9-x86_64 in the erratum is the real filename of
> the package. While action refers to so-called NEVRA
> (name-epoch-version-release-arch) so the "0:" part is epoch which is not
> included in filename.
>
> IMHO this is not a cause of your issue.
>
> Is the pacakge on the spacewalk filesystem (under /var/satellite)?
> Can you download package from the package detail page in webUI?
> Is there any error in /var/log/httpd/*error_log?
>
> > Thanks in advance
> >
> > Best Regards.
> >
> > Ezequiel Sozzi.
>
> 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] Java heap space

[Ezequiel Sozzi]

Hello,

I'm currently having a problem with taskomatic. while is trying to generate
the reporsitory metadata for my repository 'rh6-x86_64-os' I'm getting the
following error:

rhn_taskomatic_daemon.log

INFO   | jvm 1| 2018/04/10 14:52:15 | 2018-04-10 14:52:15,756
[Thread-53] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter -
Generating new repository metadata for channel 'rh6-x86_64-os'(sha1) 28664
packages, 4902 errata

INFO   | jvm 1| 2018/04/10 15:00:28 | Exception in thread "Thread-53"
java.lang.OutOfMemoryError: Java heap space
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
org.postgresql.util.PGbytea.toBytesHexEscaped(PGbytea.java:40)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
org.postgresql.util.PGbytea.toBytes(PGbytea.java:35)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBytes(AbstractJdbc2ResultSet.java:2433)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.internalGetObject(AbstractJdbc2ResultSet.java:165)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
org.postgresql.jdbc3.AbstractJdbc3ResultSet.internalGetObject(AbstractJdbc3ResultSet.java:36)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
org.postgresql.jdbc4.AbstractJdbc4ResultSet.internalGetObject(AbstractJdbc4ResultSet.java:296)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(AbstractJdbc2ResultSet.java:2703)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(AbstractJdbc2ResultSet.java:2715)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.mchange.v2.c3p0.impl.NewProxyResultSet.getObject(NewProxyResultSet.java:4303)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.CachedStatement.getObject(CachedStatement.java:732)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.CachedStatement.addToObject(CachedStatement.java:715)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.CachedStatement.processResultSet(CachedStatement.java:570)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:420)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.CachedStatement.executeElaboratorBatch(CachedStatement.java:346)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.CachedStatement.executeElaboratorBatch(CachedStatement.java:373)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.CachedStatement.executeElaborator(CachedStatement.java:325)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.SelectMode.elaborate(SelectMode.java:130)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.common.db.datasource.DataResult.elaborate(DataResult.java:159)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.taskomatic.task.repomd.RpmRepositoryWriter.writeRepomdFiles(RpmRepositoryWriter.java:185)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
com.redhat.rhn.taskomatic.task.repomd.ChannelRepodataWorker.run(ChannelRepodataWorker.java:104)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
INFO   | jvm 1| 2018/04/10 15:00:28 |   at
java.lang.Thread.run(Thread.java:748)

I have extended the memory parameter in the /etc/sysconfig/tomcat file from
256 to 1024

JAVA_OPTS="-ea -Xms1024m -Xmx1024m -Djava.awt.headless=true
-Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser
-Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=1024 -XX:MaxNewSize=256
-XX:-UseConcMarkSweepGC -Dnet.sf.ehcache.skipUpdateCheck=true"

Also I have added the option tasomatic.maxmemory = 4096 to the file
/etc/rhn/rhn.conf but the problem persist.

Any Ideas how to fix this?
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Spacewalk capability question

[Ezequiel Sozzi]

Paul,

You can push commands with the option "remote commands" from SSM.

BR,

2018-04-10 14:37 GMT-03:00 Paul Greene :

> 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

Re: [Spacewalk-list] Kickstart through Spacewalk Proxy

[Ezequiel Sozzi]

Hi Frank,

The following link contains all the information that I found about this:

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

Hope it fits to your needs.

BR,



[image: --]

Ezequiel Sozzi
[image: https://]about.me/ezequielsozzi
<https://about.me/ezequielsozzi?promo=email_sig_source=email_sig_medium=email_sig_campaign=external_links>

2018-04-10 9:41 GMT-03:00 Frank Paulick <frank.paul...@baaderbank.de>:

> Hi,
>
>
> does anyone know, what needs to be configured on a Spacewalk Proxy ,
>
> after the initial Installation and configuration of the Spacewalk Proxy is
> done, to be able to kickstart systems from this proxy ?
>
> Is there any documentation on this available ?
>
> We are currently running spacewalk server 2.6 and have a firewalled
> spacewalk proxy in another network, which i would like to use as kickstart
> server.
>
> any help is appreciated.
>
>
> Regards
>
> Frank
>
> --
> Mit freundlichen Grüßen
>
> Frank Paulick
> IT Infrastruktur
> _
>
> Baader Bank AG
> Weihenstephaner Straße 4
> 85716 Unterschleißheim, Deutschland
>  T +49 89 5150 1522
> F +49 89 5150 2421
>
> frank.paul...@baaderbank.de
> http://www.baaderbank.de
> _
>
> Baader Bank Aktiengesellschaft • Vorstand: Nico Baader (Vors.), Dieter
> Brichmann (stv. Vors.), Christian Bacherl, Oliver Riedel
> Vorsitzender des Aufsichtsrates: Dr. Horst Schiessl
> Amtsgericht München HRB 121537 • Sitz der Gesellschaft: Unterschleißheim •
> StNr. 143/100/10066 • USt-IdNr. DE114123893
> 
> _
>
> Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich
> geschützte Informationen. Wenn Sie nicht der richtige Adressat dieser
> E-Mail sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie
> uns bitte unverzüglich und löschen Sie diese E-Mail. Das unerlaubte
> Vervielfältigen oder Weiterleiten dieser E-Mail ist strikt untersagt.
>
> ___
> 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 - Packages renamed while errata is installed.

[Ezequiel Sozzi]

 Hello!

I'm currently have a problem with erratas deployments. While I'm trying to
deploy an errata I get the following error:

*Details:*
This action will be executed after 4/9/18 12:16:00 PM GMT
This action's status is: Failed.
The client picked up this action on 4/9/18 8:23 AM
The client completed this action on 4/9/18 8:23 AM
Client execution returned "Failed: Packages failed to install properly:
Package libgudev1-0:219-30.el7_3.9.x86_64 is not available for
installation" (code 32)

Errata Affected:

   - RHBA-2017:1311 - systemd bug fix update





When I check the errata's packages I get this list:

 RHBA-2017:1311 - Bug Fix Advisory  - Packages

RHEL 6 OS (x86_64)
sha256:01a653b21762a7fe70639da531283bcf7df7e7261fd414ed4ee2766f84ec18e8
libgudev1-219-30.el7_3.9-i686
sha256:d36b44c7639c9ef352289a48c78e2b7b2c20ad16fa140154bdf6d152a6e702ab
libgudev1-219-30.el7_3.9-x86_64
sha256:890025aa0efd5996f298fe9ca9245d0039eace186764deb142f0b3b6dc7e3293
libgudev1-devel-219-30.el7_3.9-i686
sha256:4c0d644eb4eab019af4afc8f350cdafb340bafe43ada1e4e26c4c7e9652528ca
libgudev1-devel-219-30.el7_3.9-x86_64
sha256:9704dc2026c37a3fb48ef8aebebcec69727b7eca5eb7935eed13068f4ca9df58
systemd-219-30.el7_3.9-x86_64
sha256:f0cfd9f15a30a6bdd0d3918f583ed72a0a5d6c83245781aee9acbc725498
systemd-devel-219-30.el7_3.9-i686
sha256:e53cef6019e84ab3a0dd88953807d153c138d3dcdf2b82b1ae142ad8af0311a9
systemd-devel-219-30.el7_3.9-x86_64
sha256:236477aaa7892d0cdc69309babf2a6c965e9a5c015a4c33a98efe6f97a9cb5c0
systemd-libs-219-30.el7_3.9-i686
sha256:63ecd208f49be14ce5114d889ad634ef5f30c5bc3f14c145431471f00230bee2
systemd-libs-219-30.el7_3.9-x86_64
sha256:9604832bc4cafb57b41cbf092c40dccdd5d8fa62389e77b5a9c6c8b48b16f857
systemd-python-219-30.el7_3.9-x86_64
sha256:5f640b78a329045b0795b4a3cff510af03d5ace91e80cb3dc3cf322019d3dce1
systemd-sysv-219-30.el7_3.9-x86_64

Comparing the packages I found that Spacewalk is trying to download
libgudev1-*0:*219-30.el7_3.9.x86_64 instead  libgudev1-219-30.el7_3.9-x86_64
I've been looking on rhn logs but I didn't find any log that could advice
me about where the "0:" is added to the packages name.
More weird is this problem only happens with only one repository.

Does anyone have any Idea about what it could be happening?

Thanks in advance

Best Regards.

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