Re: [Spacewalk-list] postgresql db move issues

[Ian Forde]

Found the issue.  Because these are VMs, I had the DB on a separate disk
and moved the DB disk over to the new instance (spacewalk-db1).  Turns out
that the db user needed to have superuser privs in the DB to make it work.
So, one "ALTER USER spacewalkuser with SUPERUSER;" later...

I believe this also could have been postgresql ACL-related, but I didn't
want to dive too deeply into that as... scary. ;)

 -I

On Fri, Feb 12, 2016 at 12:23 PM, Ian Forde <ianfo...@gmail.com> wrote:

> (After setting up a few Spacewalk instances over the years, I've run into
> one of those... seemingly truly weird issues.  Hopefully this is an easy
> one...)
>
> I've got a spacewalk server named spacewalk1 (version 2.4) that had the
> postgresql DB on it.  I recently moved the DB over to another host, and
> updated /etc/rhn/rhn.conf on the Spacewalk server to point to it.
>
> Things seemed to work, and then...
>
> a) I started seeing some newly-registered hosts try to do a
> 'rhn-profile-sync' and fail with the following:
>
> Updating package profile...
>
> Updating package profile
>
> D: rpcServer: Calling XMLRPC registration.welcome_message
>
> D: rpcServer: Calling XMLRPC registration.update_packages
>
> A protocol error occurred: Internal Server Error , attempt #1,
>
> An error has occurred:
>
> rhn-plugin: Error communicating with server. The message was:
>
> Internal Server Error
>
> See /var/log/up2date for more information
>
>
> Looking on the db server at postgresql-Fri.log (since today is Friday) I
> see the following:
>
> 2016-02-12 14:15:13.479 CST ERROR:  current transaction is aborted,
> commands ignored until end of transaction block
>
> 2016-02-12 14:15:13.479 CST STATEMENT:  SELECT queue_server(111758, 0)
>
> 2016-02-12 14:15:17.492 CST ERROR:  password is required
>
> 2016-02-12 14:15:17.492 CST DETAIL:  Non-superusers must provide a
> password in the connection string.
>
> 2016-02-12 14:15:17.492 CST CONTEXT:  SQL statement "SELECT
> dblink_connect('at_conn', 'dbname=' || current_database() || ' port=' ||
> coalesce(inet_server_port(), '5432'))"
>
> PL/pgSQL function "pg_dblink_exec" line 5 at PERFORM
>
> SQL statement "SELECT  pg_dblink_exec( 'insert into rhnPackageEVR(id,
> epoch, version, release, evr) values (' ||  $1  || ', ' ||  $2  || ', ' ||
> $3  || ', ' ||  $4  || ', evr_t(' ||  $2  || ', ' ||  $3  || ', ' ||  $4
> || '))' )"
>
> PL/pgSQL function "lookup_evr" line 18 at PERFORM
>
> 2016-02-12 14:15:17.492 CST STATEMENT:
>
> insert into rhnServerPackage
>
> (server_id, name_id, evr_id, package_arch_id, installtime)
>
> values (111758, LOOKUP_PACKAGE_NAME(E'druid'),
> LOOKUP_EVR(NULL, E'0.8.3', E'0.1'),
>
> LOOKUP_PACKAGE_ARCH(E'noarch'), TO_TIMESTAMP(E'2016-02-11
> 15:12:08', '-MM-DD HH24:MI:SS')
>
> )
>
>
>
> 2016-02-12 14:15:17.495 CST ERROR:  current transaction is aborted,
> commands ignored until end of transaction block
>
> 2016-02-12 14:15:17.495 CST STATEMENT:  SELECT queue_server(111758, 0)
>
> b) I'm now seeing the following in the repo sync logs on the spacewalk
> server (/var/log/rhn/reposync/)
>
> [root@spacewalk1 reposync]# tail rhel7-x86_64-ulyaoth.log
>
> Repo URL: https://repos.ulyaoth.net/RHEL/7/x86_64/os/
>
> Packages in repo:   436
>
> Packages already synced:435
>
> Packages to sync: 1
>
> 1/1 : ulyaoth-nginx-mainline-1.9.11-1.el7-1.x86_64
>
> (9, 'ERROR:  password is required', 'DETAIL:  Non-superusers must
> provide a password in the connection string.\nCONTEXT:  SQL statement
> "SELECT  dblink_connect(\'at_conn\', \'dbname=\' || current_database() ||
> \' port=\' || coalesce(inet_server_port(), \'5432\'))"\nPL/pgSQL function
> "pg_dblink_exec" line 5 at PERFORM\nSQL statement "SELECT  pg_dblink_exec(
> \'insert into rhnPackageEVR(id, epoch, version, release, evr) values (\'
> ||  $1  || \', \' ||  $2  || \', \' ||  $3  || \', \' ||  $4  || \',
> evr_t(\' ||  $2  || \', \' ||  $3  || \', \' ||  $4  || \'))\' )"\nPL/pgSQL
> function "lookup_evr" line 18 at PERFORM\n', InternalError('password is
> required\nDETAIL:  Non-superusers must provide a password in the connection
> string.\nCONTEXT:  SQL statement "SELECT  dblink_connect(\'at_conn\',
> \'dbname=\' || current_database() || \' port=\' ||
> coalesce(inet_server_port(), \'5432\'))"\nPL/pgSQL function
> "pg_dblink_exec" line 5 at PERFORM\nSQL statement "SELECT  pg_dblink_exec(
> \'insert into rhnPackageEVR(id, epoch, version, release, evr) values (\'
> ||  $

[Spacewalk-list] postgresql db move issues

[Ian Forde]

(After setting up a few Spacewalk instances over the years, I've run into
one of those... seemingly truly weird issues.  Hopefully this is an easy
one...)

I've got a spacewalk server named spacewalk1 (version 2.4) that had the
postgresql DB on it.  I recently moved the DB over to another host, and
updated /etc/rhn/rhn.conf on the Spacewalk server to point to it.

Things seemed to work, and then...

a) I started seeing some newly-registered hosts try to do a
'rhn-profile-sync' and fail with the following:

Updating package profile...

Updating package profile

D: rpcServer: Calling XMLRPC registration.welcome_message

D: rpcServer: Calling XMLRPC registration.update_packages

A protocol error occurred: Internal Server Error , attempt #1,

An error has occurred:

rhn-plugin: Error communicating with server. The message was:

Internal Server Error

See /var/log/up2date for more information


Looking on the db server at postgresql-Fri.log (since today is Friday) I
see the following:

2016-02-12 14:15:13.479 CST ERROR:  current transaction is aborted,
commands ignored until end of transaction block

2016-02-12 14:15:13.479 CST STATEMENT:  SELECT queue_server(111758, 0)

2016-02-12 14:15:17.492 CST ERROR:  password is required

2016-02-12 14:15:17.492 CST DETAIL:  Non-superusers must provide a password
in the connection string.

2016-02-12 14:15:17.492 CST CONTEXT:  SQL statement "SELECT
dblink_connect('at_conn', 'dbname=' || current_database() || ' port=' ||
coalesce(inet_server_port(), '5432'))"

PL/pgSQL function "pg_dblink_exec" line 5 at PERFORM

SQL statement "SELECT  pg_dblink_exec( 'insert into rhnPackageEVR(id,
epoch, version, release, evr) values (' ||  $1  || ', ' ||  $2  || ', ' ||
$3  || ', ' ||  $4  || ', evr_t(' ||  $2  || ', ' ||  $3  || ', ' ||  $4
|| '))' )"

PL/pgSQL function "lookup_evr" line 18 at PERFORM

2016-02-12 14:15:17.492 CST STATEMENT:

insert into rhnServerPackage

(server_id, name_id, evr_id, package_arch_id, installtime)

values (111758, LOOKUP_PACKAGE_NAME(E'druid'),
LOOKUP_EVR(NULL, E'0.8.3', E'0.1'),

LOOKUP_PACKAGE_ARCH(E'noarch'), TO_TIMESTAMP(E'2016-02-11
15:12:08', '-MM-DD HH24:MI:SS')

)



2016-02-12 14:15:17.495 CST ERROR:  current transaction is aborted,
commands ignored until end of transaction block

2016-02-12 14:15:17.495 CST STATEMENT:  SELECT queue_server(111758, 0)

b) I'm now seeing the following in the repo sync logs on the spacewalk
server (/var/log/rhn/reposync/)

[root@spacewalk1 reposync]# tail rhel7-x86_64-ulyaoth.log

Repo URL: https://repos.ulyaoth.net/RHEL/7/x86_64/os/

Packages in repo:   436

Packages already synced:435

Packages to sync: 1

1/1 : ulyaoth-nginx-mainline-1.9.11-1.el7-1.x86_64

(9, 'ERROR:  password is required', 'DETAIL:  Non-superusers must
provide a password in the connection string.\nCONTEXT:  SQL statement
"SELECT  dblink_connect(\'at_conn\', \'dbname=\' || current_database() ||
\' port=\' || coalesce(inet_server_port(), \'5432\'))"\nPL/pgSQL function
"pg_dblink_exec" line 5 at PERFORM\nSQL statement "SELECT  pg_dblink_exec(
\'insert into rhnPackageEVR(id, epoch, version, release, evr) values (\'
||  $1  || \', \' ||  $2  || \', \' ||  $3  || \', \' ||  $4  || \',
evr_t(\' ||  $2  || \', \' ||  $3  || \', \' ||  $4  || \'))\' )"\nPL/pgSQL
function "lookup_evr" line 18 at PERFORM\n', InternalError('password is
required\nDETAIL:  Non-superusers must provide a password in the connection
string.\nCONTEXT:  SQL statement "SELECT  dblink_connect(\'at_conn\',
\'dbname=\' || current_database() || \' port=\' ||
coalesce(inet_server_port(), \'5432\'))"\nPL/pgSQL function
"pg_dblink_exec" line 5 at PERFORM\nSQL statement "SELECT  pg_dblink_exec(
\'insert into rhnPackageEVR(id, epoch, version, release, evr) values (\'
||  $1  || \', \' ||  $2  || \', \' ||  $3  || \', \' ||  $4  || \',
evr_t(\' ||  $2  || \', \' ||  $3  || \', \' ||  $4  || \'))\' )"\nPL/pgSQL
function "lookup_evr" line 18 at PERFORM\n',))

Linking packages to channel.

Repo https://repos.ulyaoth.net/RHEL/7/x86_64/os/ has 0 errata.

Sync completed.

Total time: 0:01:38

[root@spacewalk1 reposync]#

It seems like something didn't get updated to tell Spacewalk to use the
remote dbusername and password, even though it's hitting the database
server.

Any ideas what I'm missing?  Help!

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

Re: [Spacewalk-list] Upgrading clients to 2.4

[Ian Forde]

You could always use SSM to execute remote commands on your hosts,
(consisting of a curl/wget to download key to their local filesystems and
import the keys...) Then you should be able to upgrade the packages.

On Fri, Feb 12, 2016 at 12:37 PM, Matt Bayliss 
wrote:

> OK, so I pushed out the package rhncfg-actions so I could run remote
> commands.  I figured I could set up a configuration channel to push out the
> gpg key and then use a remote command to install it.  I found that I could
> not use configuration channels or use remote commands until I logged onto
> each server and enabled the functionality with 'rhn-actions-control
> --enable-all' (why is this not on by default?!).
>
> Anyway, I've finally jumped through enough hoops to run the 'gpg --import
> RPM-GPG-KEY-spacewalk-2015' command, problem is though is that the
> 2.4-client packages still won't install and I'm getting the same "Error
> while executing packages action: Public key for
> rhn-setup-2.4.11-1.el6.noarch.rpm is not installed [[6]]"
>
> GPG keys on my system are:
> # rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
>
> gpg-pubkey-c105b9de-4e0fd3a3 --> gpg(CentOS-6 Key (CentOS 6 Official
> Signing Key) )
> gpg-pubkey-863a853d-4f55f54d --> gpg(Spacewalk  >)
> gpg-pubkey-0608b895-4bd22942 --> gpg(EPEL (6) )
>
> It seems that the key has not been imported properly.  I'll check the file
> I pushed out again.
>
> # gpg --with-fingerprint RPM-GPG-KEY-spacewalk-2015
> pub  1024D/B8002DE1 2015-04-17 Spacewalk 
>   Key fingerprint = A5FC 508C DD3C C46D 3C3B  4612 DCC9 81CD B800 2DE1
>
> OK, so that looks right,. I'll try and import it again..
>
> # gpg --import RPM-GPG-KEY-spacewalk-2015
> gpg: key B8002DE1: "Spacewalk " not changed
> gpg: Total number processed: 1
> gpg:  unchanged: 1
>
> It's processed and unchanged but it's still not in my list:
>
> # rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
> gpg-pubkey-c105b9de-4e0fd3a3 --> gpg(CentOS-6 Key (CentOS 6 Official
> Signing Key) )
> gpg-pubkey-863a853d-4f55f54d --> gpg(Spacewalk  >)
> gpg-pubkey-0608b895-4bd22942 --> gpg(EPEL (6) )
>
> wtf?  Why won't the key import/update?
>
> On 12 February 2016 at 15:18, Dimitri Yioulos 
> wrote:
>
>> Matt,
>>
>>
>>
>> I think you can use Manage|Provisioning|Run remote commands against a
>> group of servers.  If you use Ansible in your environment, I have a simple
>> playbooks to accomplish installing the public key which I’m happy to share
>> with you.
>>
>>
>>
>> Dimitri
>>
>>
>>
>> *From:* spacewalk-list-boun...@redhat.com [mailto:
>> spacewalk-list-boun...@redhat.com] *On Behalf Of *Matt Bayliss
>> *Sent:* Friday, February 12, 2016 9:41 AM
>> *To:* spacewalk-list@redhat.com
>> *Subject:* [Spacewalk-list] Upgrading clients to 2.4
>>
>>
>>
>> I'm trying to bring a bunch of Spacewalk clients which are currently
>> using the 2.2-client version, up to 2.4-client.
>>
>> I created a new channel & repo and used the SSM to transfer systems over
>> to the new channel.  The updates then appeaar as available and I scheduled
>> the upgrade.
>>
>> The problem is that I receive the error "Error while executing packages
>> action: Public key for rhn-setup-2.4.11-1.el6.noarch.rpm is not installed
>> [[6]]" as the 2015 key is not installed by my clients.
>>
>> What's the best way to fix this using Spacewalk, I'd rather avoid having
>> to import the key manually on each system.
>>
>> Thanks,
>>
>> Matt
>>
>> ___
>> 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] libxml2-python and kickstart

[Ian Forde]

That's what I was getting at. ;)  I knew that your answer couldn't be
considered official, given the circumstances.  Which is why I posted to
see if there's a way through to a solution rather than a workaround...

  -I


On Fri, Jun 14, 2013 at 4:40 AM, Jan Hutař jhu...@redhat.com wrote:

 Sorry,
 can not give you official answer/recommendation. From the bug
 you have linked it is not clear if it is CentOS or Anaconda or
 Spacewalk issue.

 Sorry,
 Jan



 On Thu, 13 Jun 2013 19:52:15 -0700 Ian Forde
 ianfo...@gmail.com wrote:

  (To Jan) Question.  Given that this is discussed in
  http://bugs.centos.org/view.php?id=4978 (going back almost 2
  years now), and is still an active issue, I'm wondering if the
  official answer is to not use the updates repo during
  installation or not.  But if this is just a metadata bug, as
  described above and in the referenced bugzilla entry, can
  someone please elaborate on what we, the users, can do to help
  get this resolved in a way that we can specify additional
  repositories during installation safely, as described in
 
 https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-pkgselection-x86.html
  (section 9.18.1) and
 
 https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html
  (via
  the repo keyword)?  Or are we just SOL?
 
  (To Paul) Can you please elaborate on this?  As noted in the
  above-referenced bugzilla entry, people are still fighting
  with this issue 2 years later, but if you've got a working
  solution to this problem, I'm sure that many folks would like
  to know more about it...
 
  Thanks,
   -Ian
 
 
  On Thu, Jun 13, 2013 at 8:02 AM, Paul Robert Marino
  prmari...@gmail.comwrote:
 
   One thing I found is that you need to use the image files
   from the Everything install disk when creating the
   kickstart distribution or you will run into problems like
   the one you described with the update channel.
  
  
  
   On Mon, Jun 10, 2013 at 8:08 AM, Jan Hutař
   jhu...@redhat.com wrote:
On Mon, 3 Jun 2013 23:41:14 + Faye Salwin
faye.sal...@betfair.com wrote:
   
Centos6 updates contains libxml2-python and Spacewalk
pulls THAT version (as it is the latest available version
within any child channels of the selected distribution)
of the RPM when building kickstart files instead of a
package from a channel enabled for kickstart (The Java
code pulls these files using the file download url)
   
This works:
   
  
 http://x.x.x.x/download/package/2ca68cda56a77523c946e69ca5dc8d34e0f45f01/0/1/885/libxml2-python-2.7.6-8.el6_3.4.x86_64.rpm
   
  
 http://x.x.x.x/download/package/1e2379d4dadc3fef16c422d3aa705ff83264b469/0/1/5811/pyOpenSSL-0.10-2.el6.x86_64.rpm
   
  
 http://x.x.x.x/download/package/704fdbe78c79726bab6d1e5f8461045ef7f0a194/0/1/11132/rhnlib-2.5.55-1.el6.noarch.rpm
rpm -Uvh --replacepkgs
--replacefiles /tmp/rhn_rpms/optional/pyOpenSSL*
   /tmp/rhn_rpms/optional/rhnlib* /tmp/rhn_rpms/optional/libxml2-python*
   
If the Updates repo is disabled in the kickstarter, but
available as a child channel of the install tree, then
libxml2-python fails to install as it cannot supply the
dependencies to libxml2-python (*12-el6_4*) which are in
the Updates repo too.
   
I have read that one shouldn't enable the Updates Repo
during Kickstart, but if I do not delete libxml2-python
from the updates repo then a kickstart which does not
include the updates repo will fail.  If I do install the
updates repo to kickstart then it will lag the install
for a long time while it tries and retries to access a
comps file which does not exist. (there are comps files
for EPEL and Spacewalk which I have to include during
kickstart to install the rhn_client, rhncfg-client etc.
I have restricted EPEL to only those packages which the
Spacewalk repo depends upon.  I believe that the
kickstart will continue to function from the time that
libxml2-python from updates is added until the kickstart
profile is updated at which point it will re-evaluate the
includes.  It doesn't seem like a good solution to delete
libxml2-python every time you update kickstart and then
re-sync.
   
What is the best practice here?  Should I kickstart from a
tree with updates present?  What happens about the Comps
(groups file) in this case?  I've also noticed that
cloning child channels (using the manage channel
lifecycle script at least) does not clone the
RHNCHANNELCOMPS row that is relevant which caused me a
few frustrations early on.
   
Is it not possible to kickstart just one distribution 
channel selection and then switch parent channels at
activation time?  That would simplify a lot of the
workflow (perhaps allow you to have a single kickstart
for all your lifecycle locations and validate

Re: [Spacewalk-list] libxml2-python and kickstart

[Ian Forde]

(To Jan) Question.  Given that this is discussed in
http://bugs.centos.org/view.php?id=4978 (going back almost 2 years now),
and is still an active issue, I'm wondering if the official answer is to
not use the updates repo during installation or not.  But if this is just a
metadata bug, as described above and in the referenced bugzilla entry, can
someone please elaborate on what we, the users, can do to help get this
resolved in a way that we can specify additional repositories during
installation safely, as described in
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-pkgselection-x86.html
(section
9.18.1) and
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html
(via
the repo keyword)?  Or are we just SOL?

(To Paul) Can you please elaborate on this?  As noted in the
above-referenced bugzilla entry, people are still fighting with this issue
2 years later, but if you've got a working solution to this problem, I'm
sure that many folks would like to know more about it...

Thanks,
 -Ian


On Thu, Jun 13, 2013 at 8:02 AM, Paul Robert Marino prmari...@gmail.comwrote:

 One thing I found is that you need to use the image files from the
 Everything install disk when creating the kickstart distribution or
 you will run into problems like the one you described with the update
 channel.



 On Mon, Jun 10, 2013 at 8:08 AM, Jan Hutař jhu...@redhat.com wrote:
  On Mon, 3 Jun 2013 23:41:14 + Faye Salwin
  faye.sal...@betfair.com wrote:
 
  Centos6 updates contains libxml2-python and Spacewalk pulls
  THAT version (as it is the latest available version within any
  child channels of the selected distribution) of the RPM when
  building kickstart files instead of a package from a channel
  enabled for kickstart (The Java code pulls these files using
  the file download url)
 
  This works:
 
 http://x.x.x.x/download/package/2ca68cda56a77523c946e69ca5dc8d34e0f45f01/0/1/885/libxml2-python-2.7.6-8.el6_3.4.x86_64.rpm
 
 http://x.x.x.x/download/package/1e2379d4dadc3fef16c422d3aa705ff83264b469/0/1/5811/pyOpenSSL-0.10-2.el6.x86_64.rpm
 
 http://x.x.x.x/download/package/704fdbe78c79726bab6d1e5f8461045ef7f0a194/0/1/11132/rhnlib-2.5.55-1.el6.noarch.rpm
  rpm -Uvh --replacepkgs
  --replacefiles /tmp/rhn_rpms/optional/pyOpenSSL*
 /tmp/rhn_rpms/optional/rhnlib* /tmp/rhn_rpms/optional/libxml2-python*
 
  If the Updates repo is disabled in the kickstarter, but
  available as a child channel of the install tree, then
  libxml2-python fails to install as it cannot supply the
  dependencies to libxml2-python (*12-el6_4*) which are in the
  Updates repo too.
 
  I have read that one shouldn't enable the Updates Repo during
  Kickstart, but if I do not delete libxml2-python from the
  updates repo then a kickstart which does not include the
  updates repo will fail.  If I do install the updates repo to
  kickstart then it will lag the install for a long time while
  it tries and retries to access a comps file which does not
  exist. (there are comps files for EPEL and Spacewalk which I
  have to include during kickstart to install the rhn_client,
  rhncfg-client etc.  I have restricted EPEL to only those
  packages which the Spacewalk repo depends upon.  I believe
  that the kickstart will continue to function from the time
  that libxml2-python from updates is added until the kickstart
  profile is updated at which point it will re-evaluate the
  includes.  It doesn't seem like a good solution to delete
  libxml2-python every time you update kickstart and then
  re-sync.
 
  What is the best practice here?  Should I kickstart from a
  tree with updates present?  What happens about the Comps
  (groups file) in this case?  I've also noticed that cloning
  child channels (using the manage channel lifecycle script at
  least) does not clone the RHNCHANNELCOMPS row that is relevant
  which caused me a few frustrations early on.
 
  Is it not possible to kickstart just one distribution 
  channel selection and then switch parent channels at
  activation time?  That would simplify a lot of the workflow
  (perhaps allow you to have a single kickstart for all your
  lifecycle locations and validate that the parent channel is a
  clone of the one you are activating?)
 
  Why does the Kickstart file create java code include files
  that are from repos not included in the kickstart channels?  I
  am guessing it is so that you don't have to include the
  spacewalk repo as a child, but if you don't do that, it can't
  find rhnreg_ks for example (unless you use one of the many
  workarounds that have been posted in this list eg. tar ball of
  spacewalk files)
 
  It is entirely possible that I am just doing it wrong in
  which case a pointer to best practice would be appreciated.
 
  Thanks
 
 
  Faye
 
  Hello,
  you should kickstart with only base channel enabled (ideally no
  additional child channels/repos). After 

Re: [Spacewalk-list] Spacewalk and Cobbler - Ignoring architecture

[Ian Forde]

I had the same problem a while back and never figured it out.  So I stopped
using Spacewalk to provision VMs and started using ovirt (www.ovirt.org)
instead. Spacewalk still maintains everything else though.  *Much* easier
to deal with, and you have more options for managing VMs.

  -I

On Sun, Feb 17, 2013 at 7:24 PM, Ryan Davies r...@ryandavies.co.nz wrote:

 Hi Folks,

 I have Spacewalk sitting on a CentOS 6 server, I have a CentOS Channel set
 up with x86_64 architecture selected.

 However, when the Distribution is created from that, It's put into cobbler
 as i386. When koan kicks up to turn that into a virtual machine, it creates
 a i386 based KVM VM, and therefore the system cant kickstart because it's a
 64Bit OS.

 If I go in via ssh and update the distribution using cobbler edit, and
 change the arch to x86_64, the systems kickstart as expected.

 Is this a known issue? Or am I selecting the wrong architecture in the
 Channel ?

 Regards,

 Ryan

 ___
 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] Migrated postgresql database to separate box, but rhn-search doesn't know about it

[Ian Forde]

On Wed, Jul 18, 2012 at 2:09 AM, Jan Pazdziora jpazdzi...@redhat.com wrote:
 If the PostgreSQL is on different machine than localhost, you are
 hitting bug 836374 which was fixed in Spacewalk nightly.

 As noted in the bug, as a workaround you can try to setup a xinetd
 server to redirect that port from the localhost to the remote server.

You rock.  Exactly what I faced.  I put in the xinetd workaround for
now and it worked perfectly.  Thank you muchly!

  -I

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

Re: [Spacewalk-list] Migrated postgresql database to separate box, but rhn-search doesn't know about it

[Ian Forde]

On Wed, Jul 18, 2012 at 4:04 PM, Coy Hile coy.h...@coyhile.com wrote:

 Can you please paste the content of your xinetd work-around for posterity?


Absolutely.  Here goes...

filename:  /etc/xinetd.d/postgresql-tcp

service postgresql-tcp
{
disable = no
type= UNLISTED
socket_type = stream
protocol= tcp
wait= no
user= root
bind= 0.0.0.0
port= 5432
only_from   = 0.0.0.0
redirect= **DBHOST** 5432
}

Where **DBHOST** is the IP address of your Spacewalk database
server.  Also note that I called the file postgresql-tcp rather than
postgresql.  This is so that it can be managed via chkconfig without
conflicting with postgresql itself (which was on the box earlier
before I did the migration).

Hope that helps!

  -I

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

[Spacewalk-list] Migrated postgresql database to separate box, but rhn-search doesn't know about it

[Ian Forde]

As the subject alludes, I recently migrated the postgresql database
from the Spacewalk server to a separate box.  Checking the list
archives, I was under the impression that all I had to do was:

Stop Spacewalk
Dump the database
Restore the database onto the new box
Stop the old database
Change /etc/rhn/rhn.conf to have 'db_host = newhost'
Start Spacewalk

And while that seems to work for the majority of Spacewalk
functionality, rhn-search, used in Channels/Package Search doesn't
like it.  I keep getting Could not execute query 'packagename'
errors in a red bar at the top of the page.

Looking further, I see that even doing a 'service rhn-search
cleanindex' bombs out with the following at the bottom:


at java.sql.DriverManager.getConnection(DriverManager.java:620)
at java.sql.DriverManager.getConnection(DriverManager.java:200)
at 
com.ibatis.common.jdbc.SimpleDataSource.popConnection(SimpleDataSource.java:580)
at 
com.ibatis.common.jdbc.SimpleDataSource.getConnection(SimpleDataSource.java:222)
at 
com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.init(JdbcTransaction.java:48)
at 
com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.getConnection(JdbcTransaction.java:89)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeUpdate(GeneralStatement.java:78)
... 6 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
at java.net.Socket.connect(Socket.java:546)
at java.net.Socket.connect(Socket.java:495)
at java.net.Socket.init(Socket.java:392)
at java.net.Socket.init(Socket.java:206)
at org.postgresql.core.PGStream.init(PGStream.java:62)
at 
org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:76)
... 21 more
Starting rhn-search...

Following this, I ran it again under 'strace -f', which was showing
failed attempts to query localhost on port 5432, which is the
postgresql port.  At first, it they were ipv6 addresses, so I disabled
ipv6 in /etc/sysctl.conf, rebooted the box, and tried again.  Same
problem, but this time with:


[pid  3981] connect(30, {sa_family=AF_INET, sin_port=htons(5432),
sin_addr=inet_addr(127.0.0.1)}, 16) = -1 ECONNREFUSED (Connection
refused)

That's from the strace output.

I've already checked for a comparable parameter in
/usr/share/rhn/config-defaults/*.conf, but couldn't find anything.
Can someone tell me what, if anything, I'm missing here?

Version info: Spacewalk 1.7 on CentOS 6.3.  Database for this is
postgresql 8.4 stock from CentOS 6.3.  It's also happening on another
Spacewalk 1.7 instance on CentOS 5.8 (db server is postgresql 8.4 on
CentOS 6.3) that I maintain, though I've done my debugging on the 6.3
set of systems.

  -Ian

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

Re: [Spacewalk-list] centos-errata.py and announcement list format changes

[Ian Forde]

On Thu, Jan 19, 2012 at 8:30 AM, David Nutter david.nut...@bioss.ac.uk wrote:
 On Thu, Jan 19, 2012 at 11:49:43AM +, richard rigby wrote:

 hi david,

 excellent work - have just downloaded and updated, and all seems to be
 working well again, thanks for your efforts.

 Thanks :)

 i noticed there is a new requirement for python-lxml, which we didn't
 have installed, but all is now back up and running.

 Ah yes, that's just to aid the screen scraping of stuff downloaded
 from the RedHat site. I will mention it in the docs for version
 0.7. Release is hopefully imminent, just awaiting test results now.

Question - given that it focuses on the centos-announce mailing list,
when the CentOS project gets caught in a version squeeze (like when
RHEL 6.2 was released and CentOS didn't have 6.1 out the door yet),
they activate the CR repository.  Those announcements are made to the
centos-cr-announce mailing list.  Are there any plans to have an
option to utilize those archives?  Currently, I just make a copy of
the centos-errata.py script and edit it by hand, but it's something I
have to do for each version upgrade.  Of course, if this script is
eventually going away this may not be necessary, but...

  -I

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

Re: [Spacewalk-list] Subscription Management with Postgres in SW 1.6

[Ian Forde]

On Tue, Jan 17, 2012 at 8:36 PM, Ian Forde ianfo...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 11:19 AM, Jan Pazdziora jpazdzi...@redhat.com wrote:
 On Thu, Jan 12, 2012 at 04:04:14PM -0800, Ian Forde wrote:
 Has anyone successfully used Overview/Subscription Management/System
 Entitlements successfully in 1.6?  I'm trying to remove all of the
 monitoring entitlements from my boxes, so I enabled Monitoring,
 restarted Spacewalk, went to the aforementioned page, selected the
 boxes, clicked on Remove Entitlement, and got an Internal Server
 Error page.  In the emailed traceback, I saw the following:

 Exception:
 javax.servlet.ServletException: ERROR: function
 rhn_install_org_satellites(bigint, bigint, bigint) does not exist
       at 
 org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535)

 of course, there was much more output, but I think this one is the crux of 
 it...

 Please let us see some 20 more lines of that traceback.

Sorry about that - mis-clicked in gmail... one more thing before I
paste it.  Since I had to re-enable monitoring in the Spacewalk
Configuration/General page, I find that I have to clear the HTTP
proxy username and HTTP proxy password fields before clicking
Update.  (It's the same problem as the one that used to exist in
kickstart on the System Details page, when, say you wanted to change
the SELinux setting, it assumed that you wanted to change the password
as well.)

Okay - now that I've re-enabled monitoring in Spacewalk, when I give
the Monitoring provision to 2 hosts (both VMs) through the
Subscription Management page, this is what I get from the Show Tomcat
Logs page at the bottom...


2012-01-17 20:42:22,783 [TP-Processor2] WARN
org.apache.struts.util.PropertyMessageResources -   Resource
org/apache/struts/action/ActionResources_en_US.properties Not Found.
2012-01-17 20:42:22,789 [TP-Processor2] WARN
org.apache.struts.util.PropertyMessageResources -   Resource
org/apache/struts/action/ActionResources_en.properties Not Found.
2012-01-17 20:42:22,790 [TP-Processor2] WARN
org.apache.struts.action.RequestProcessor - Unhandled Exception
thrown: class com.redhat.rhn.common.db.WrappedSQLException
2012-01-17 20:42:22,794 [TP-Processor2] ERROR
com.redhat.rhn.frontend.servlets.SessionFilter - Error during
transaction. Rolling back
javax.servlet.ServletException:
com.redhat.rhn.common.db.WrappedSQLException: ERROR: function
rhn_install_org_satellites(bigint, bigint, bigint) does not exist
  Hint: No function matches the given name and argument types. You
might need to add explicit type casts.
  Position: 15
at 
org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:520)
at 
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:427)
at 
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228)
at 
com.redhat.rhn.frontend.struts.RhnRequestProcessor.process(RhnRequestProcessor.java:99)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:91)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129)
at 
com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter.doFilter(LocalizedEnvironmentFilter.java:67)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.redhat.rhn.frontend.servlets.EnvironmentFilter.doFilter(EnvironmentFilter.java:108)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.redhat.rhn.frontend.servlets.SessionFilter.doFilter(SessionFilter.java:55

[Spacewalk-list] Random Spacewalk things I've found...

[Ian Forde]

I *love* Spacewalk.  I really do.  There is no *but*.  In a past life,
I deployed Satellite for RH at customer sites, so the fact that I'm
still using the codebase years later says a lot about how I feel about
it.

Here are some things that I've found recently...

Kickstart...

I recently had a situation where I was testing kickstart profiles.  I
created 10 DNS entries for the hosts, and was creating/destroying them
at will.  I found some interesting things out...

1. If the VM doesn't have the XML file on the virtualization host, but
the filename used by the profile DOES exist, the kickstart will fail.
Silently.  (I had some NFS issues, where the files were owned by
root:root, so deleting them from virt-manager didn't actually work, so
this may be a libvirt issue in that it reports deleted even though
it's not.)
2. I had to put in a custom begin script to generate the hostname/IP
address for static entries (more on that later).  But it still
registers with the name localhost.localdomain.
3. After the packages are installed and the post section has
completed, the node usually reboots, and I see the checkbox in the
Register System to Spacewalk section.  But it doesn't get past that.
 Initially, I thought it was stuck at Deploy Configuration Files,
but I've since kickstarted with the option to sync a package profile
from another host, and it never gets there...  Not sure what's
happening there.

(more info on this)
I just kickstarted a node, and had it happen again.  I logged in, did
a 'rhn-profile-sync' successfully.  Then I did a 'rhn_check -vv' and
got the following back:

XMLRPC ProtocolError: ProtocolError for ordmantell.iforde.net
/XMLRPC: 500 Internal Server Error

I looked in /var/log/messages on the spacewalk server (I have logging
to syslog enabled in postgres for things like this), and saw the
following:

Jan 17 21:25:05 ordmantell postgres[22246]: [3-1] ERROR:  new row for
relation rhnpackageevr violates check constraint
vn_rhnpackageevr_epoch
Jan 17 21:25:05 ordmantell postgres[22246]: [3-2] CONTEXT:  SQL
statement INSERT INTO rhnPackageEvr (id, epoch, version, release,
evr) VALUES (nextval('rhn_pkg_evr_seq'),  $1 ,  $2 ,  $3 ,EVR_T( $1 ,
$2 ,  $3 ))
Jan 17 21:25:05 ordmantell postgres[22246]: [3-3] #011PL/pgSQL
function lookup_evr line 10 at SQL statement
Jan 17 21:25:05 ordmantell postgres[22246]: [3-4] #011SQL statement
SELECT LOOKUP_EVR( $1 ,  $2 ,  $3 )
Jan 17 21:25:05 ordmantell postgres[22246]: [3-5] #011PL/pgSQL
function lookup_transaction_package line 20 at SQL statement
Jan 17 21:25:05 ordmantell postgres[22246]: [3-6] STATEMENT:
Jan 17 21:25:05 ordmantell postgres[22246]: [3-7] #011insert into
rhnPackageDeltaElement
Jan 17 21:25:05 ordmantell postgres[22246]: [3-8] #011
(package_delta_id, transaction_package_id)
Jan 17 21:25:05 ordmantell postgres[22246]: [3-9] #011values
Jan 17 21:25:05 ordmantell postgres[22246]: [3-10] #011   (9240,
Jan 17 21:25:05 ordmantell postgres[22246]: [3-11] #011
lookup_transaction_package(E'insert', E'389-ds-base', E'',
E'1.2.9.14', E'1.el6', NULL))
Jan 17 21:25:05 ordmantell postgres[22246]: [3-12] #011

Hope that helps...

Back to the custom begin script - all it does is parse /proc/cmdline
to get the hostname, look it up in DNS, and if it's found, use that
hostname/IP, with the current netmask and default route.  If it's not
found, use the address that it picked up from DHCP.  It's not in any
way pretty, error-checking is minimal, and it isn't very generalized,
so I'm somewhat reluctant to share it... (plus the fact that it's a
little ugly!) ;)

Other random stuff...

4. When using SW 1.6 with PostgreSQL on CentOS 6.2 (just trying to be
specific here...), every night the Show differences between profiled
configuration files and deployed config files scheduled by (none) job
runs.  This drives the load through the roof.  I'm talking about in
the upper 40's here.  Eventually it calms down, but the box gets
slammed.  Is there something that I can do to mitigate this?
5. Even with selinux in permissive mode (and targeted policy) on both
the Spacewalk VM and the virtualization host, I keep getting s0 at the
end of the security labels on files that I've deployed from
configuration channels.  I redeploy, then they come back.  Not sure
what's happening here.  I suppose I could always relabel all of the
nodes via 'touch /.autorelabel' and reboot them, but I'd rather not...

Just some food for thought...

  -Ian

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

Re: [Spacewalk-list] kickstart profiles resetting to 3GB disk, and vibr0

[Ian Forde]

On Fri, Jan 13, 2012 at 7:16 AM, Tomas Lestach tlest...@redhat.com wrote:
 On Thursday 12 of January 2012 12:28:19 Ian Forde wrote:
 On Thu, Jan 12, 2012 at 7:41 AM, Tomas Lestach tlest...@redhat.com wrote:
  On Wednesday 28 of December 2011 19:43:31 Ian Forde wrote:
  First of all, thanks for Spacewalk 1.6.  Lots-o-bugs fixed, including
  the can't kickstart if you have the Provisioning entitlement bug.
 
  I've got a strange one.  Periodically, all of my kickstart profiles
  revert to 3GB disk and Virtual Bridge vibr0.  All of them.  Very
  weird.  The number of virtual CPUs may also reset, but I'm not sure as
  I don't currently have any multi-CPU profiles.
 
  Could you describe, you you exactly do and after what time the change
  happens? Do you write about kvm guest kickstart profiles?
  How can I reproduce it?

 I didn't do anything - that's the strange thing.  At some point, they
 simply... revert.  I'm not sure how to reproduce the issue.  Is there
 anywhere where the vibr0 is set as a default that I can change?

 Yes, there's a place, but it's hardcoded. This place definitelly isn't your
 problem.
 If you want us to investigate, please write, how did you set the values that
 got changed - via WebUI (what page) or API and again, where did you see the
 values have changed. Was it after or before the profiles were used for
 provisioning?

Thanks for getting back to me.  I set the values using the WebUI in
Systems/Kickstart/Profiles.  I don't kickstart systems often, so it's
hard to tell when they change.  I notice the changes when I attempt to
provision a VM.  From the Systems page, I select the host (it has a
Virtualization Platform entitlement) and go to
Virtualization/Provisioning.  From there, I see the list of profiles
available, and, if it has kicked in, I see all KS profile disk sizes
set to 3GB, with bridge vibr0.  That's before I start to provision.
That's when I have to go back into Systems/Kickstart/Profiles and
reset them back.

  -I

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

Re: [Spacewalk-list] Subscription Management with Postgres in SW 1.6

[Ian Forde]

On Thu, Jan 12, 2012 at 4:04 PM, Ian Forde ianfo...@gmail.com wrote:
 Has anyone successfully used Overview/Subscription Management/System
 Entitlements successfully in 1.6?  I'm trying to remove all of the
 monitoring entitlements from my boxes, so I enabled Monitoring,
 restarted Spacewalk, went to the aforementioned page, selected the
 boxes, clicked on Remove Entitlement, and got an Internal Server
 Error page.  In the emailed traceback, I saw the following:

 Exception:
 javax.servlet.ServletException: ERROR: function
 rhn_install_org_satellites(bigint, bigint, bigint) does not exist
        at 
 org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535)

 of course, there was much more output, but I think this one is the crux of 
 it...

Incidentally, I worked around it by using spacecmd in a loop to remove
the entitlements.  Nice tool!

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

Re: [Spacewalk-list] kickstart profiles resetting to 3GB disk, and vibr0

[Ian Forde]

On Thu, Jan 12, 2012 at 7:41 AM, Tomas Lestach tlest...@redhat.com wrote:
 On Wednesday 28 of December 2011 19:43:31 Ian Forde wrote:
 First of all, thanks for Spacewalk 1.6.  Lots-o-bugs fixed, including
 the can't kickstart if you have the Provisioning entitlement bug.

 I've got a strange one.  Periodically, all of my kickstart profiles
 revert to 3GB disk and Virtual Bridge vibr0.  All of them.  Very
 weird.  The number of virtual CPUs may also reset, but I'm not sure as
 I don't currently have any multi-CPU profiles.

 Could you describe, you you exactly do and after what time the change happens?
 Do you write about kvm guest kickstart profiles?
 How can I reproduce it?

I didn't do anything - that's the strange thing.  At some point, they
simply... revert.  I'm not sure how to reproduce the issue.  Is there
anywhere where the vibr0 is set as a default that I can change?

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

[Spacewalk-list] Subscription Management with Postgres in SW 1.6

[Ian Forde]

Has anyone successfully used Overview/Subscription Management/System
Entitlements successfully in 1.6?  I'm trying to remove all of the
monitoring entitlements from my boxes, so I enabled Monitoring,
restarted Spacewalk, went to the aforementioned page, selected the
boxes, clicked on Remove Entitlement, and got an Internal Server
Error page.  In the emailed traceback, I saw the following:

Exception:
javax.servlet.ServletException: ERROR: function
rhn_install_org_satellites(bigint, bigint, bigint) does not exist
at 
org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535)

of course, there was much more output, but I think this one is the crux of it...

  -I

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

Re: [Spacewalk-list] kickstart profiles resetting to 3GB disk, and vibr0

[Ian Forde]

On Wed, Dec 28, 2011 at 7:43 PM, Ian Forde ianfo...@gmail.com wrote:
 First of all, thanks for Spacewalk 1.6.  Lots-o-bugs fixed, including
 the can't kickstart if you have the Provisioning entitlement bug.

 I've got a strange one.  Periodically, all of my kickstart profiles
 revert to 3GB disk and Virtual Bridge vibr0.  All of them.  Very
 weird.  The number of virtual CPUs may also reset, but I'm not sure as
 I don't currently have any multi-CPU profiles.

 I couldn't find any indication in /var/log/rhn/ and /var/log/tomcat6/.
  Any ideas?  System is CentOS 6.2 fully patched.

I'm the only one experiencing this?  I've now seen this issue on 2
CentOS 5.7 servers and 1 CentOS 6.2 server.  All were running
Spacewalk 1.5 and experienced it.  Now they're running 1.6 and still
undergoing it.  All are running Postgresql for the db...

  -I

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

[Spacewalk-list] kickstart profiles resetting to 3GB disk, and vibr0

[Ian Forde]

First of all, thanks for Spacewalk 1.6.  Lots-o-bugs fixed, including
the can't kickstart if you have the Provisioning entitlement bug.

I've got a strange one.  Periodically, all of my kickstart profiles
revert to 3GB disk and Virtual Bridge vibr0.  All of them.  Very
weird.  The number of virtual CPUs may also reset, but I'm not sure as
I don't currently have any multi-CPU profiles.

I couldn't find any indication in /var/log/rhn/ and /var/log/tomcat6/.
 Any ideas?  System is CentOS 6.2 fully patched.

  -Ian

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

Re: [Spacewalk-list] Newbie, question about channels

[Ian Forde]

On Fri, Dec 9, 2011 at 10:59 AM, David Greco
david_gr...@harte-hanks.com wrote:

 I have 5 RH 5 servers at the moment that need to be configured similiarly. I 
 have setup one of these exactly the way I like, and would like the 4 others 
 to be setup similiarly. Same packages installed, same configuration, etc. Is 
 this something satellite is good for? I browsed the documentation but so no 
 mention of how to take an existing system, all its configs and packages, and 
 create a channel that other systems can update from.

Regarding the packages, you could do it with a channel or a package
profile.  I'd recommend the latter.  Once the first system that you
want done is built (which you say you've completed), ensure that it's
registered to Spacewalk.  Then you can build the other 4 systems, and
have them sync package profiles to that of the first system.  It's one
of the advanced options in Kickstart.  I'd tell you exactly where, but
my Spacewalk server is currently down in anticipation of the CentOS
6.1 upgrade that I'll be doing tonight. ;)

  -I

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

Re: [Spacewalk-list] Foolish me, keeping my systems up to date... cobbler... grr...

[Ian Forde]

On Mon, 2011-10-31 at 00:08 +0100, Miroslav Suchy wrote:
 Dne 29.10.2011 00:19, Ian Forde napsal(a):
  Here's another question - if it turns out to be a Spacewalk issue (ie -
  cobbler upgrade broke it, not I, and one or more of the Spacewalk RPMs
  needs an upgrade to address it), would we have to wait until 1.6 for the
  fix?  Thus requiring people to not upgrade their cobbler installations
  btw... Or would this be fixed in the 1.5 series, as cobbler 2.2.x is now
  in EPEL...
 
 Well it is still in testing:
 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-4633
 I wrote there that I'm against moving it to stable.
 
 We (as Spacewalk developers) did not test cobbler 2.2 yet. We may 
 support it in Spacewalk 1.6, but definitely not in EL5. That would be 
 *huge work*, and we do not have time for that and it is IMHO not worth 
 the work.
 So please on EL5 stay with cobbler 2.0.

Yep - looks like I still had EPEL-testing enabled on both of my
Spacewalk instances from when I initially set them up.  Part of the
steps at that time was to enable epel-testing... I never pulled the repo
for the boxes.  I've disabled it now.  Thanks for the info... I rolled
it back and now kickstart files look okay.  I'll test them later...

For those of you going through this, it was *not* a fun experience...

Rough steps were...

. spacewalk-service stop
. service cobblerd stop
. rpm -e --nodeps cobblerd
. yum clean all
. # disable the epel-testing repo
. yum install cobbler
. # restore the old cobbler configuration
. yum remove mod_wsgi
. service httpd restart
. service cobblerd restart
. cobbler check
. cobbler sync
. service spacewalk start

Moral of the story?  Back up your spacewalk servers.  Every day.
Seriously. ;)

-I

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

[Spacewalk-list] Foolish me, keeping my systems up to date... cobbler... grr...

[Ian Forde]

Recently I updated cobbler on my both of my CentOS 5.7 Spacewalk 1.5
servers.  After figuring out (last week) that I needed to enable wsgi
in /etc/httpd/conf.d/wsgi.conf things worked again.  Until today when I
needed to kickstart a box.

Going to https://fedorahosted.org/cobbler/wiki/WhatsNewInTwoTwo I see
the following instructions:


 Before upgrading be sure to make a backup of /etc/cobbler
 and /var/lib/cobbler, this is where all your data resides. As some
 things have changed, read these before you get into reading about all
 the new features.
 
 - Review/modify the /etc/cobbler/modules.conf.rpmnew file to include your 
 site specific settings. Then move the new file into place.
 - Review/modify the /etc/httpd/conf.d/cobbler_web.conf.rpmnew file and move 
 it into place.
 - Remove mod_python
 - Uncomment the LoadModule command in /etc/httpd/conf.d/wsgi.conf
 - Change $kickstart_start/_done to $SNIPPET('kickstart_start')/_done in the 
 default kickstart template.

So, I did the first step - it's just making sure that I have module = 
authn_spacewalk rather than module = authn_denyall
Second step?  Nothing to do.  It put in the new file just fine.
Third step?  DO NOT DO THIS.  IT WILL ATTEMPT TO REMOVE SPACEWALK. (why oh why 
would this step be listed in the first place?)
Fourth step?  Found that one on my own.  Done.
Fifth step?  This is what I've run smack into.  The generated kickstart files 
all have a section around line 43 as such:

 %pre$kickstart_start
 
 echo Saving RHN keys...  /dev/ttyS0
 SYSTEM_ID=/etc/sysconfig/rhn/systemid
 rhn_keys_found=no

So it appears that I have to change some default kickstart template.  
Somewhere.  Anyone know where?

-Ian

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

Re: [Spacewalk-list] Foolish me, keeping my systems up to date... cobbler... grr...

[Ian Forde]

On Fri, 2011-10-28 at 14:35 -0700, Ian Forde wrote:
  Before upgrading be sure to make a backup of /etc/cobbler
  and /var/lib/cobbler, this is where all your data resides. As some
  things have changed, read these before you get into reading about all
  the new features.
  
  - Review/modify the /etc/cobbler/modules.conf.rpmnew file to include your 
  site specific settings. Then move the new file into place.
  - Review/modify the /etc/httpd/conf.d/cobbler_web.conf.rpmnew file and move 
  it into place.
  - Remove mod_python
  - Uncomment the LoadModule command in /etc/httpd/conf.d/wsgi.conf
  - Change $kickstart_start/_done to $SNIPPET('kickstart_start')/_done in the 
  default kickstart template.

Some additional notes from detective work...

 So, I did the first step - it's just making sure that I have module = 
 authn_spacewalk rather than module = authn_denyall

I also had to enable the tftp server in the config - just remembered
that one...

 Third step?  DO NOT DO THIS.  IT WILL ATTEMPT TO REMOVE SPACEWALK. (why oh 
 why would this step be listed in the first place?)

Still freaked out by this one...

 Fifth step?  This is what I've run smack into.  The generated kickstart files 
 all have a section around line 43 as such:
 
  %pre$kickstart_start
  
  echo Saving RHN keys...  /dev/ttyS0
  SYSTEM_ID=/etc/sysconfig/rhn/systemid
  rhn_keys_found=no

The end of the generated kickstart file also has the following:

$kickstart_done

So it looks like something in Spacewalk isn't evaluating properly, as
the $kickstart_start and $kickstart_done macros are supposed to include
the new cobbler templates, but are just spitting out the raw text
instead.  I don't think this is something I've done wrong, but I'm
wondering if anyone else is seeing this, or if it's something obvious in
the code... I'm still digging to see if something pops out.

Here's another question - if it turns out to be a Spacewalk issue (ie -
cobbler upgrade broke it, not I, and one or more of the Spacewalk RPMs
needs an upgrade to address it), would we have to wait until 1.6 for the
fix?  Thus requiring people to not upgrade their cobbler installations
btw... Or would this be fixed in the 1.5 series, as cobbler 2.2.x is now
in EPEL...

-I

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

[Spacewalk-list] Spacewalk backups, restores, OS Updates, Oracle, and its bloody archivelogs (LONG)

[Ian Forde]

Sorry if any part of the subject offends, but I've just spent the last 4
days putting together a workable solution for what had appeared to be a
Spacewalk database crapping out.

Ingredients:
Spacewalk server: CentOS 5.5
Channels: CentOS 5 x86_64 OS and Updates, plus other misc channels

Problem: I wanted to upgrade my channels from CentOS 5.5 to 5.6.

The original plan: I thought I would empty the 5.5 base (OS) channel and
updates channel.  Then repopulate the channels with content from a local
mrepo server.

What went wrong: Some time ago, I setup backups on this box, which
requires archivelogs on the Oracle database to be enabled.  With such a
large number of updates, the contents
of /usr/lib/oracle/xe/app/oracle/flash_recovery_area/XE/archivelog/ grew
to over 4GB, leading to ORA-00257 errors.

Thoughts:  I thought I'd crapped out the whole thing.  And I'm not a
DBA.  So I wanted to do a restore.  Imagine my surprise when, after
having setup backups, I didn't see anything about restore to a specific
day without having a DBA.

What I did wrong: Don't do what I did.  Turn off the archive logs first.

How I fixed it (bear in mind that I have mrepo on a nearby server):
1. Update mrepo content for OS and updates
2. Update the /var/distro-trees/ iso on the spacewalk server
3. Stop Spacewalk, disable my backup script, disable Spacewalk sync
channel updates, and disable Oracle archive logs
spacewalk-service stop
other stuff to disable backup script and spacewalk sync goes here
su - oracle
. 
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle_env.sh
sqlplus /nolog
connect / as sysdba
shutdown immediate
startup mount
alter database noarchivelog;
alter database open;
select log_mode from sys.v$database;
quit
exit
spacewalk-service start
4. Import new OS and update packages, knowing that you won't, at this
point, blow up the archive log.
5. Stop Spacewalk (spacewalk-service stop)
5. Remove old archivelogs, then reenable them
su - oracle
. 
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle_env.sh
rman target sys/sys
delete archivelog all;
quit
sqlplus /nolog
connect / as sysdba
shutdown immediate
startup mount
alter database archivelog;
alter database open;
select log_mode from sys.v$database;
quit
exit
6. Put things back to normal and make an IMMEDIATE DATABASE BACKUP
spacewalk-service start
steps to enable backup script and spacewalk sync)
MAKE SPACEWALK DATABASE BACKUP (I used the procedure from the wiki)

Moral of the story: Have a DBA nearby.  I did, but not one that knows
Oracle.  Note that this procedure worked for me.  It may cause others'
computers to spontaneously turn into pixie dust, or offer guided aerial
porcine tours over the frozen wastes of hades.  NO WARRANTIES EXPRESSED
OR IMPLIED.

What I'd like to know is if I went about it in a roundabout way or if
this is what one does when one doesn't have an Oracle backup scheme to
integrate into...

-Ian

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

Re: [Spacewalk-list] how to backupspacewalk

[Ian Forde]

On Tue, 2011-02-22 at 08:32 +0100, rob morrien wrote:
 Hello to all,
 
 i found the web page how to backup spacewalk.
 
 i run the backup script
 /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/config/scripts/backup.sh
  as oracle but i get the message
 
 flash recovery area is not enabled
 
 can the solution for this problem be fixed on the web page and scripts
 on the how to backup page from spacewalk.

I went through this recently.  You're going to want to read the page
again, as it includes instructions regarding how to set that up.  It's
not just a run this script thing.  It's on the page...

-I

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

[Spacewalk-list] Child channel subscriptions of migrated KVM nodes

[Ian Forde]

Hi all - strange question here...

Server: Spacewalk 1.1 (freshly upgraded, but I've also experienced this
on Spacewalk 1.0)

I had 2 sets of VMware Server boxes, called vmserver 1-4.  vmserver1/2
utilized the same NFS storage for nodes, and vmserver3/4 utilized a
separate NFS share, so that they could share nodes.  Last week I
migrated the whole shebang over to KVM.  (Twas a little painful, as each
VM had to be hand-tweaked after booting from iso, but whatever...)

Anyhoo - I ended up having to delete the guest registrations from
Spacewalk as they didn't show up as being fully virtualized.  (I checked
the archives and found that someone else ran into this and fixed it by
tweaking Oracle directly - I'm not one to reach into Oracle to do that
so...)

I reregistered the systems and resubscribed them to the appropriate
Software Channels, Configuration Channels, and Groups.  The problem is
that the Software Channel subscriptions show with the red star, and a
note at the bottom stating: NOTE: These channels are not part of the
Red Hat Enterprise Linux subscription for this guest's host, vmserver1.
Subscribing to them will consume additional software entitlements.
Applying a different virtual system entitlement to the host system will
affect which channels have this mark.

???

So I've set vmserver1 to use the Virtualization Platform - no change.
Just Virtualization?  No change.  What's going on here?

oh - and when I change the entitlement for vmserver1, it gives a message
about having done some other things under the hood with a
link-to-nowhere promising details...

-I

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

Re: [Spacewalk-list] port forwarding bug

[Ian Forde]

On Thu, Jul 15, 2010 at 7:38 AM, Michael Mraka michael.mr...@redhat.com wrote:
 Ian Forde wrote:
 % On Wed, Jul 14, 2010 at 1:52 PM, Ian Forde ianfo...@gmail.com wrote:
 %  One of my spacewalk servers is behind a firewall that I'm on the
 %  outside of, so I use ssh port-forwarding to get to it.  I just thought
 %  I'd report that while most things work just fine with a non-443 port
 %  hitting spacewalk, I've found one (actually 2, but I don't remember
 %  where the other was) button that doesn't respect the relative url:
 % 
 %  When you delete a system's registered profile and do the confirmation,
 %  I think it's the 2nd confirmation click that doesn't respect it and
 %  tries to go to https://localhost/whatever rather than
 %  https://localhost:X/whatever (where X is the forwarding port
 %  number)
 % 
 %  Just an fyi... Spacewalk 1.0 on CentOS 5...
 %
 % Found the other one.  On the System Groups page, clicking on Use in
 % SSM has the same result...

 Hi Ian,

 please file a bugzilla for the issue so it doesn't get out of our radar :).


Will do!  Thanks!  (Found a third, so I'll include it in there...)

  -I

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

[Spacewalk-list] port forwarding bug

[Ian Forde]

One of my spacewalk servers is behind a firewall that I'm on the
outside of, so I use ssh port-forwarding to get to it.  I just thought
I'd report that while most things work just fine with a non-443 port
hitting spacewalk, I've found one (actually 2, but I don't remember
where the other was) button that doesn't respect the relative url:

When you delete a system's registered profile and do the confirmation,
I think it's the 2nd confirmation click that doesn't respect it and
tries to go to https://localhost/whatever rather than
https://localhost:X/whatever (where X is the forwarding port
number)

Just an fyi... Spacewalk 1.0 on CentOS 5...

  -I

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

Re: [Spacewalk-list] port forwarding bug

[Ian Forde]

On Wed, Jul 14, 2010 at 1:52 PM, Ian Forde ianfo...@gmail.com wrote:
 One of my spacewalk servers is behind a firewall that I'm on the
 outside of, so I use ssh port-forwarding to get to it.  I just thought
 I'd report that while most things work just fine with a non-443 port
 hitting spacewalk, I've found one (actually 2, but I don't remember
 where the other was) button that doesn't respect the relative url:

 When you delete a system's registered profile and do the confirmation,
 I think it's the 2nd confirmation click that doesn't respect it and
 tries to go to https://localhost/whatever rather than
 https://localhost:X/whatever (where X is the forwarding port
 number)

 Just an fyi... Spacewalk 1.0 on CentOS 5...

Found the other one.  On the System Groups page, clicking on Use in
SSM has the same result...

  -I

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

[Spacewalk-list] Kickstarting KVM nodes fail with Unable to download the kickstart file

[Ian Forde]

So I've got Spacewalk 1.0 setup on a box running CentOS 5.4.  My testing
KVM server is setup with CentOS 5.4 also.  I attempt to use Spacewalk's
provisioning facility to do a kickstart of a test KVM node.  And it's a
bear.  Right now, I've gotten the VM to boot and start the kickstart,
only to get stuck at the Unable to download the kickstart file message
within Anaconda.  Upon examining the VM using virt-manager, it appears
that *something* (Spacewalk? Cobbler? Cosmic Rays?) caused the VM to be
created without a network interface.

Some background info:  So far, I've run into the koan instance has no
attribute 'virt_auto_boot', which was resolved by downgrading koan from
2.0.3.1 to 1.6.6 on the KVM host.

Then I realized that by default, the KVM host only has a NAT interface.
So I setup br0 on the box as follows:

Contents of /etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0
HWADDR=XX:XX:XX:XX:XX:XX
ONBOOT=yes
BRIDGE=br0
ETHTOOL_OPTS=autoneg off speed 100 duplex full

Contents of /etc/sysconfig/network-scripts/ifcfg-br0:
DEVICE=br0
BOOTPROTO=static
ONBOOT=yes
IPADDR=X.X.X.X
NETMASK=255.255.255.0
GATEWAY=X.X.X.1
TYPE=Bridge
DELAY=0

I've also added the following to /etc/sysctl.conf (and subsequently run
'sysctl -p':
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

In Spacewalk, the profile is defined to use the Virtual Bridge 'br0'.

Can anyone see what I've missed here?  I've managed to replicate this on
an entirely different set of servers in another location (different
Spacewalk, different KVM server), so whatever I'm missing, I've missed
it twice...

Thanks,

-I

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

Re: [Spacewalk-list] Kickstarting KVM nodes fail with Unable to download the kickstart file

[Ian Forde]

On Fri, 2010-07-02 at 17:35 -0400, Justin Sherrill wrote:
 On 7/2/10 4:30 PM, Ian Forde wrote: 
  So I've got Spacewalk 1.0 setup on a box running CentOS 5.4.  My testing
  KVM server is setup with CentOS 5.4 also.  I attempt to use Spacewalk's
  provisioning facility to do a kickstart of a test KVM node.  And it's a
  bear.  Right now, I've gotten the VM to boot and start the kickstart,
  only to get stuck at the Unable to download the kickstart file message
  within Anaconda.  Upon examining the VM using virt-manager, it appears
  that *something* (Spacewalk? Cobbler? Cosmic Rays?) caused the VM to be
  created without a network interface.
  
  Some background info:  So far, I've run into the koan instance has no
  attribute 'virt_auto_boot', which was resolved by downgrading koan from
  2.0.3.1 to 1.6.6 on the KVM host.
  
  Then I realized that by default, the KVM host only has a NAT interface.
  So I setup br0 on the box as follows:
  
  Contents of /etc/sysconfig/network-scripts/ifcfg-eth0:
  DEVICE=eth0
  HWADDR=XX:XX:XX:XX:XX:XX
  ONBOOT=yes
  BRIDGE=br0
  ETHTOOL_OPTS=autoneg off speed 100 duplex full
  
  Contents of /etc/sysconfig/network-scripts/ifcfg-br0:
  DEVICE=br0
  BOOTPROTO=static
  ONBOOT=yes
  IPADDR=X.X.X.X
  NETMASK=255.255.255.0
  GATEWAY=X.X.X.1
  TYPE=Bridge
  DELAY=0
  
  I've also added the following to /etc/sysctl.conf (and subsequently run
  'sysctl -p':
  net.bridge.bridge-nf-call-ip6tables = 0
  net.bridge.bridge-nf-call-iptables = 0
  net.bridge.bridge-nf-call-arptables = 0
  
  In Spacewalk, the profile is defined to use the Virtual Bridge 'br0'.
  
  Can anyone see what I've missed here?  I've managed to replicate this on
  an entirely different set of servers in another location (different
  Spacewalk, different KVM server), so whatever I'm missing, I've missed
  it twice...
  
  Thanks,
  
  -I
  
  ___
  Spacewalk-list mailing list
  Spacewalk-list@redhat.com
  https://www.redhat.com/mailman/listinfo/spacewalk-list

 Hi Ian,
 
 We've fixed the virt_auto_boot bug, and it should be fixed in the next
 release.  
 
 As for the networking interface issue.  It sounds like you are hitting
 this bug:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=608811
 
 I'm not sure what introduced the issue, i'm guessing it was a change
 in cobbler, but I will need to do some test to verify.  In the
 meantime, you should be able to do something like this:
 
 cobbler system edit --name=COBBLER_SYSTEM_NAME --virt-bridge=br0
 
 Immediately after you provision in the UI, to add the virt bridge to
 your guest.  

Yep - looks like that did the trick.  Sort of.  I had to turn off osad
for this to work, and run rhn_check manually.  But I'd done that anyway
just so I could do 'rhn_check -vv' to see any other errors.  So now the
order of operations is:

1. Provision VM in Spacewalk UI
2. On the Spacewalk server cli run 'cobbler system edit...'
3. On the KVM host, run 'rhn_check'

and it seems to work.  (Now I have to go through and tweak the KS
profile, but that's on me...)

Here's the thing though... it looks like this solved that immediate
problem, but then the kickstart ran, I walked away, came back, and the
VM was powered off.  And now Spacewalk reports that the KS failed, even
though I was able to power on the VM.  And rhn_check is still stuck
displaying install is still running messages...  I'm hoping that
that's something in the KS profile that I can fix...

A couple of questions/observations though...
1. Having to turn off osad is a serious bummer in this regard...
2. The bug you referred me to is related to Xen, so it looks like it's
also applicable to KVM (at least in my case).  Regarding versions, I'm
using the same versions of spacewalk-base and spacewalk-oracle, but I'm
using cobbler-2.0.4-2 (from EPEL-testing).  
3. Since I've run into this issue on 2 separate instances of
Spacewalk/KVM, it looks like I'm in a good position to submit info on
this bug.  How can I help further in debugging it?  Let me know if you
need any debug info or logs...

Oh - and thanks for the quick turnaround!

-I

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

Re: [Spacewalk-list] change root password for all machines in a group

[Ian Forde]

On Wed, 2010-02-03 at 21:58 -0600, Daniel Wittenberg wrote:
 Could you just push a script to /etc/cron.daily so it'll run auto, and have 
 it replace the md5 crypted pass in /etc/shadow?  Then you don't have to pass 
 anything in the clear ?
 

Technically, you'd want to use an 'at' job rather than cron for this,
but that's nothing that Spacewalk's remote command isn't giving you
already.  The issue is how to get the new password to the box while:

a) transmitting it such that it cannot be seen on the command line on
the remote box
b) safely updating the entry in /etc/shadow with minimal risk of hosing
the file
c) not putting it in cleartext anywhere that it can be logged by either
Spacewalk or the client machine

Personally, I'd just use sed on /etc/shadow, but I've been using Linux
for over a decade and UNIX for about 2 (decades).  So I'm careful and
cautious about what I recommend.  I won't recommend sed-ding the shadow
file to others unless they feel comfortable about doing it...

-I

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

Re: [Spacewalk-list] change root password for all machines in a group

[Ian Forde]

On Thu, 2010-02-04 at 10:14 +0800, Colin Coe wrote:
 Shouldn't this be
 
 echo 'new_password' | passwd --stdin root
 
 You could do this simply with a remote command via the SSM.  Just
 remember that this will be in the spacewalk events for those servers
 so if you have people with access to spacewalk that shouldn't know the
 password, they'll be able to find it out.

Actually, for a decent safe option, you can try this as a procedure:

1. Push a new file called /tmp/.newrootpasswd and set it to be root:root
and perms 0400.  This file will contain the plaintext of the new
password.
2. Use a remote command (since you can make it a script) as such:

#!/bin/bash
cat /tmp/.newrootpasswd | passwd --stdin
rm -f /tmp/.newrootpasswd

Unfortunately, Spacewalk (AFAIK) doesn't support file push triggers yet
(item #3 in Brainbox), so you can't do it all in one step.  Another way,
however, would be to do it all in a script that retrieved the textfile
and ran 'passwd --stdin'.  The idea is to keep the password off of the
command line.

Of course, if the passwd command accepted encrypted passwords when used
with stdin, we wouldn't have this issue.  Sort of... (I don't even like
putting encrypted strings out there.)

From a security perspective, I think it's about finding a safe way to
get the password string to the client box, avoiding displaying it on the
clients' command line and risking exposure on the filesystem.

-I

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