[Spacewalk-list] Spacewalk keeps sending out errata notifications after each reposync

[Gerald Vogt]

I have a spacewalk 1.8 server with syncs to the EPEL5 repositories. I
sync every four hours and after each sync spacewalk sends out the same
errata notifications for updates on some of our clients. For example, I
get a notification e-mail of errata FEDORA-EPEL-2012-13346 ever four hours.

I think I used to get notification e-mails only for new errata the first
time they appear.

The reposync log shows:

> Repo URL: http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=x86_64
> Packages in repo:  7211
> No new packages to sync.
> Repo http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=x86_64 has 
> comps file 2d885cde94a18286cc5013da118d0c0a3a22666b-comps-el5.xml.gz.
> Repo http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=x86_64 has 
> 1872 errata.
> 5 errata skipped because of empty package list.
> Sync completed.
> Total time: 0:05:06

The rhn_taskomatic_daemon.log shows

> INFO   | jvm 3| 2012/11/22 08:22:20 | 2012-11-22 08:22:20,202 
> [DefaultQuartzScheduler_Worker-8] INFO  
> com.redhat.rhn.taskomatic.task.RepoSyncTask - Repo URL: 
> http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=x86_64
> INFO   | jvm 3| 2012/11/22 08:22:20 | Packages in repo:  7211
> INFO   | jvm 3| 2012/11/22 08:22:20 | No new packages to sync.
> INFO   | jvm 3| 2012/11/22 08:22:20 | Repo 
> http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=x86_64 has comps 
> file 2d885cde94a18286cc5013da118d0c0a3a22666b-comps-el5.xml.gz.
> INFO   | jvm 3| 2012/11/22 08:22:20 | Repo 
> http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=x86_64 has 1872 
> errata.
> INFO   | jvm 3| 2012/11/22 08:22:20 | 5 errata skipped because of empty 
> package list.
> INFO   | jvm 3| 2012/11/22 08:22:20 | Sync completed.
> INFO   | jvm 3| 2012/11/22 08:22:20 | Total time: 0:05:06
> INFO   | jvm 3| 2012/11/22 08:22:20 |
> INFO   | jvm 3| 2012/11/22 08:23:00 | 2012-11-22 08:23:00,023 
> [DefaultQuartzScheduler_Worker-2] INFO  
> com.redhat.rhn.taskomatic.task.ChannelRepodata - In the queue: 2
> INFO   | jvm 3| 2012/11/22 08:23:00 | 2012-11-22 08:23:00,077 
> [Thread-11129] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - 
> File Modified Date:2012-11-22 06:40:54 CET
> INFO   | jvm 3| 2012/11/22 08:23:00 | 2012-11-22 08:23:00,077 
> [Thread-11129] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - 
> Channel Modified Date:2012-11-22 08:17:12 CET
> INFO   | jvm 3| 2012/11/22 08:23:00 | 2012-11-22 08:23:00,078 
> [Thread-11130] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - 
> File Modified Date:2012-11-22 06:40:54 CET
> INFO   | jvm 3| 2012/11/22 08:23:00 | 2012-11-22 08:23:00,078 
> [Thread-11130] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - 
> Channel Modified Date:2012-11-22 08:17:11 CET
> INFO   | jvm 3| 2012/11/22 08:23:04 | 2012-11-22 08:23:04,316 
> [Thread-11129] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - 
> Generating new repository metadata for channel 'epel5-centos5-i386'(sha1) 
> 6271 packages, 1891 errata
> INFO   | jvm 3| 2012/11/22 08:23:04 | 2012-11-22 08:23:04,318 
> [Thread-11130] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - 
> Generating new repository metadata for channel 'epel5-centos5-x86_64'(sha1) 
> 7962 packages, 1892 errata
> INFO   | jvm 3| 2012/11/22 08:23:33 | 2012-11-22 08:23:33,183 
> [Thread-11129] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - 
> Repository metadata generation for 'epel5-centos5-i386' finished in 28 seconds
> INFO   | jvm 3| 2012/11/22 08:23:35 | 2012-11-22 08:23:35,587 
> [Thread-11130] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - 
> Repository metadata generation for 'epel5-centos5-x86_64' finished in 31 
> seconds
> INFO   | jvm 3| 2012/11/22 08:24:00 | 2012-11-22 08:24:00,081 
> [DefaultQuartzScheduler_Worker-9] INFO  
> com.redhat.rhn.taskomatic.task.ErrataQueue - In the queue: 3734
> INFO   | jvm 3| 2012/11/22 08:30:00 | 2012-11-22 08:30:00,056 
> [DefaultQuartzScheduler_Worker-3] INFO  
> com.redhat.rhn.taskomatic.task.ErrataCacheTask - In the queue: 1

And some time later it processes the queue and starts sending out the
notifications again.

Other than that I see nothing in the logs indicating a problem.

Any hint how to fix/troubleshoot this?

Thanks!

Gerald

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

Re: [Spacewalk-list] error while pushing pkgs from the server

[Gerald Vogt]

On 22.11.2012 06:51, Mohit Vadhera wrote:
> Is the RPMforge key is specific because for testing i am syncing with my
> local repository ? On the contrary from the clinet side i am able to
> install pkg using yum command .

The key is specific for that package you are trying to install. Maybe
you install other packages from a local repository file in
/etc/yum.repos.d/ with gpgcheck=0 set.

Run

# yum check-update

to see from which channels/repositories you install updates. Or if you
are trying to install a specific rpm run

# yum install 

to see from which channel/repo it comes from

Run

# yum repolist

to see which repositories/channels are used.

-Gerald

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

Re: [Spacewalk-list] error while pushing pkgs from the server

[Mohit Vadhera]

Hi,

Is the RPMforge key is specific because for testing i am syncing with my
local repository ? On the contrary from the clinet side i am able to
install pkg using yum command .

Any idea?

Thanks,
Mohit

On Thu, Nov 22, 2012 at 11:06 AM, Gerald Vogt  wrote:

> rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
>
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] error while pushing pkgs from the server

[Gerald Vogt]

On 22.11.2012 06:20, Mohit Vadhera wrote:
> While pushing package from the server i got following failed message.
> 
> Error while executing packages action: Public key for
> fslint-2.18-1.el5.rf.noarch.rpm is not installed [[6]] 

You did not install the GPG key for RPMforge on your client system.
Import the key on the client before installing packages from RPMforge.

rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

-Gerald

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

[Spacewalk-list] error while pushing pkgs from the server

[Mohit Vadhera]

Hi,

While pushing package from the server i got following failed message.

Error while executing packages action: Public key for
fslint-2.18-1.el5.rf.noarch.rpm is not installed [[6]]


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

Re: [Spacewalk-list] eva-direct-errata-sync.pl setup & example usage

[Paul Robert Marino]

Steve
Please chime in on the thread "errata api problem" on the developers list.
So we don't freak out the non programer users. I've been digging in a
little more and would like your input on the subject. Ill post some of my
test results tommorow but I found some intresting things
On Nov 21, 2012 5:08 PM, "Paul Robert Marino"  wrote:

> Don't worry
> No it wont be contaminated preventing the issue we are talking about
> and speed were the reasons I wrote my script in the first place.
> My script actually checks for this but some other scripts don't.
> I do execute the packages.findByNvrea method then check each of the
> result with the packages.getDetails method and confirm that the
> providing_channels field matches one or more of the destination
> channels.
>
> The new version I'm working on will do
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
>
> --destinationchannel=rh6-x64-base-channel,rh5-x64-base-channel,centos5-x64-base-channel,centos6-x64-base-channel
> but I'm hitting a bug in the API which emulating buggie behaviour Ive
> seen in other scripts but its actually a different issue that does not
> effect the current version on github
>
> The current version is safe!
>
> yes deleting the effected errata and resyncing the repos is the
> easiest way to fix it if it happens.
>
>
>
>
> On Wed, Nov 21, 2012 at 3:57 PM, Elias Abacioglu 
> wrote:
> > Does this mean that when i ran this commands
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> > --destinationchannel=rh6-x64-base-channel
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> > --destinationchannel=rh6-x64-base-channel
> >
> > my rhel and centos channels can in fact be cross-contaminated?
> > If it is contaminated, will it be solved if i delete all errata?
> >
> > ___
> > 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] Kickstarting a RHEL5 install - better with updates included or not?

[Paul Robert Marino]

I've actually thought of doing something simmilar with sattelite-sync
betwean instances in the various environments.
On Nov 21, 2012 2:48 PM, "Jens Skott"  wrote:

> I have 3 different environments cloned off the original repo, testing
> stagning and prod. I then use the orignial repo to sync the new errata
> and packages, then test stage and prod are "frozen" repos witch i
> update depending on my lifecycle plan.
> I then kickstart a server from a singel profile (bare minimal 300mb
> footprint) then add activationkeys in cobbler depending on prod test
> or stage.
> After I have kickstarted a machine I go over to using chef, where I
> handle all application configuration and installation using rpm
> packages from the different repos.
>
> Hope that helps you a little. I can assist you further with explaning
> in detail if you find it intresting and want to practice the setup i
> use for my environment =)
>
> Jens Skott
> Tel: +46-8-5142 4396
> Schibsted Centralen IT
>
>
>
> 2012/11/21 Paul Robert Marino :
> > Actually the install from spacewalk with all the updates is cleaner
> > because there is no chance an old package might have left artifacts
> > behind.
> > Although admittedly there are several schools of thought on this some
> > prefer to do the updates manually others prefer the updates done in
> > the install and there is still an other school of thought that if say
> > you are rebuilding a host it should have the exact same rpm versions
> > as the original and no additional updates.
> > none of them are completely right or wrong its more of a matter of
> > preference then any thing else.
> >
> >
> >
> > On Wed, Nov 21, 2012 at 9:47 AM, Snyder, Chris 
> wrote:
> >> Looking for some opinions here.
> >>
> >>
> >>
> >> I’ve got SW 1.8 working with RHEL5 now (thank you, J. Pazdziora) and
> have a
> >> kickstart profile uses three channels for initial package installation:
> core
> >> RHEL5 packages (from the ISO), all current RHEL5 updates so when all is
> said
> >> and done, I have a host ready to roll with no need for updates to be
> >> applied.
> >>
> >>
> >>
> >> Is this the best way to build a host?
> >>
> >>
> >>
> >> I don’t have any particular reason for this, but I have a gut feeling
> that a
> >> better way to build a host might be to ONLY use the core RHEL5 ISO
> packages
> >> and the spacewalk-client packages for initial host creation, then
> register
> >> the host with my RHEL5 update channel, and then apply any needed updates
> >> (could be done in a %post section).
> >>
> >>
> >>
> >> The second option seems ‘cleaner’ from the stand point of it mimics
> building
> >> a host from an ISO and then applying updates, whereas the first does
> >> everything at once.  Theoretically the end result should be the same.
> >>
> >>
> >>
> >> Thoughts?
> >>
> >>
> >>
> >> Thx
> >>
> >> Chris.
> >>
> >>
> >>
> >> --
> >>
> >> Chris Snyder
> >>
> >> SRA Senior Linux Geek
> >> Energystar Network O+M Team
> >> ESTAR Issues: https://estar18.energystar.gov/
> >>
> >>
> >>
> >>
> >> ___
> >> 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] eva-direct-errata-sync.pl setup & example usage

[Paul Robert Marino]

Don't worry
No it wont be contaminated preventing the issue we are talking about
and speed were the reasons I wrote my script in the first place.
My script actually checks for this but some other scripts don't.
I do execute the packages.findByNvrea method then check each of the
result with the packages.getDetails method and confirm that the
providing_channels field matches one or more of the destination
channels.

The new version I'm working on will do
./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
--destinationchannel=rh6-x64-base-channel,rh5-x64-base-channel,centos5-x64-base-channel,centos6-x64-base-channel
but I'm hitting a bug in the API which emulating buggie behaviour Ive
seen in other scripts but its actually a different issue that does not
effect the current version on github

The current version is safe!

yes deleting the effected errata and resyncing the repos is the
easiest way to fix it if it happens.




On Wed, Nov 21, 2012 at 3:57 PM, Elias Abacioglu  wrote:
> Does this mean that when i ran this commands
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=rh6-x64-base-channel
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=rh6-x64-base-channel
>
> my rhel and centos channels can in fact be cross-contaminated?
> If it is contaminated, will it be solved if i delete all errata?
>
> ___
> 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] eva-direct-errata-sync.pl setup & example usage

[Paul Robert Marino]

yea Ive come to a similar conclusion but its still messy.
I'm planning to look a little deeper into it and write an RFE with an
outline of what needs to be modified to make it work smoothly.

On Wed, Nov 21, 2012 at 2:26 PM, Steve Meier  wrote:
> Hi Paul,
>
> I have been bitten by cross-contamination myself when creating errata's as
> mentioned in 2).
>
> The workaround I have implemented in CEFS is to save the channel membership
> of each
> package before publishing an errata and then deleting newly created
> memberships. That
> restores the previous channel status. It's an ugly hack but so far the only
> solution I have found.
>
> Regards,
>   Steve
>
> Am 21.11.2012 um 07:09 schrieb Paul Robert Marino:
>
> By the way one thing I forgot and an other thing which is new information.
> 1) you should always use the -r flag if you intend to include child channels
> right now its broken and always acts like its always on but this will be
> fixed shortly.
> 2) I've gotten the multi base channel sync feature working on my development
> host but it introduces the problem where it cross contaminates the channels
> when two channels have a package with the same name so it is dangerous to
> use right now. The problem seems to be in the spacewalk APIs not in the
> script its self. I've tried several different methods to work around it but
> it looks like the APIs and possibly the database will need work before its
> viable.
>
> On Nov 20, 2012 12:59 PM, "Paul Robert Marino"  wrote:
>>
>> On Tue, Nov 20, 2012 at 11:16 AM, Elias Abacioglu 
>> wrote:
>> > Hello list,
>> >
>> > This is my very first post on this list.
>> > I have questions regarding eva-direct-errata-sync.pl.
>> > I have both RHEL and CentOS channels in my spacewalk. I'm pretty new to
>> > all
>> > this and wondering how I should setup the errata sync.
>> >
>> > I have the following RHEL channels in my spacewalk:
>> > rh6-x64-base-channel ( = rhel-x86_64-server-6)
>> > rh6-x64-optional-channel ( = rhel-x86_64-server-optional-6)
>> > rh5-x64-base-channel ( = rhel-x86_64-server-5)
>> > rh5-x64-rhn_tools-channel ( = rhn-tools-rhel-x86_64-server-5)
>> >
>> > And the following CentOS channels:
>> > centos6-x64-base-channel (contains base and updates repos)
>> > centos5-x64-base-channel (contains base and updates repos)
>> > centos5-x32-base-channel (contains base and updates repos)
>> >
>> > I want to run errata sync every night for both my RHEL and CentOS
>> > channels.
>> > So what I've come up with so far is this:
>> > ERRATASRCUSER=xxx
>> > ERRATADSTUSER=xxx
>> > ERRATASRCPASS=xxx
>> > ERRATADSTPASS=xxx
>> > ERRATADST=localhost
>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
>> > --destinationchannel=rh5-x64-base-channel -F day
>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
>> > --destinationchannel=rh6-x64-base-channel -F day
>> >
>> > So for the child channel rh6-x64-optional-channel, do I use the -r flag?
>> > And
>> > what will happen with my channel label name differences
>> > (rh6-x64-optional-channel/rhel-x86_64-server-optional-6)?
>> > #   -r or --recursive
>> >
>> > When do I use these flags?
>> > #   -e RH or --rewriteerratanamefrom RH
>> > #   -E CENTOSX86_64 or --rewriteerratanameto CENTOSX86_64
>> This rewrites the name of the errata so you don't get conflicting
>> errata names essentially you cant have two erratas with the same name
>> even if they are on different channels.
>> for example RHBA-2012:1441 would be published in spacewalk as
>> CENTOSX86_64BA-2012:1441
>>
>> > #   --rewritepackagereleasefrom el6
>> > #   --rewritepackagereleaseto el6.centos
>> these flags deal with alternate package names in Centos here is an
>> example in the Redhat errata it might say the package is names
>> at-spi-1.28.1-2.el6..x86_64.rpm but the Centos 6 name for the package
>> is at-spi-1.28.1-2.el6.centos.x86_64.rpm this happens when Centos has
>> added an additional patch that wasn't in the Redhat version of the
>> rpm.
>> These flags make it match the right package in the channel if it
>> matches the el6 or el6.centos
>> you should always use this for Centos channels
>>
>> >
>> >
>> > My best guess for the CentOS channels I should use these flags:
>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
>> > --destinationchannel=centos5-x64-base-channel
>> > --rewritepackagereleasefrom
>> > el6 --rewritepackagereleaseto el6.centos -F day
>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
>> > --destinationchannel=centos6-x64-base-channel
>> > --rewritepackagereleasefrom
>> > el6 --rewritepackagereleaseto el6.centos -F day
>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-i386-server-5
>> > --destinationchannel=centos5-x32-base-channel
>> > --rewritepackagereleasefrom
>> > el6 --rewritepackagereleaseto el6.centos -F day
>> >
>> this would give you better results
>> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
>> --destinationchannel=centos5-x64-base-chann

Re: [Spacewalk-list] eva-direct-errata-sync.pl setup & example usage

[Franky Van Liedekerke]

On Wed, 21 Nov 2012 19:58:29 +
"Snyder, Chris"  wrote:

> For the un-initiated, what does 'cross contaminates the channels when
> two channels have a package with the same name'  mean?
> 
> Thx
> Gopher.

A redhat channel and a centos channel might (and in fact have) many
package names in common, but they are different (even if only different
by the GPG signing key).
If a errata publish script doesn't take this into account, it uses the
wrong package (from e.g. redhat) with the centos errata. But publishing
an errata in a channel automatically copies the linked packages in the
channel as well, even if they are from different distro's. So you might
end up with redhat packages in a centos channel (or visa versa),
resulting in failed installations or updates later on.
Most of the python scripts suffer from this, since they use the
packages.findByNvrea call (search for package based on name,version,
release and arch) and if more than one result is returned (e.g. when
redhat and centos packages are both present in spacewalk) they use only
the first one. Stupid ...

Franky

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

Re: [Spacewalk-list] eva-direct-errata-sync.pl setup & example usage

[Snyder, Chris]

For the un-initiated, what does 'cross contaminates the channels when two 
channels have a package with the same name'  mean?

Thx
Gopher.

From: spacewalk-list-boun...@redhat.com 
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Paul Robert Marino
Sent: Wednesday, November 21, 2012 1:10 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] eva-direct-errata-sync.pl setup & example usage


By the way one thing I forgot and an other thing which is new information.
1) you should always use the -r flag if you intend to include child channels 
right now its broken and always acts like its always on but this will be fixed 
shortly.
2) I've gotten the multi base channel sync feature working on my development 
host but it introduces the problem where it cross contaminates the channels 
when two channels have a package with the same name so it is dangerous to use 
right now. The problem seems to be in the spacewalk APIs not in the script its 
self. I've tried several different methods to work around it but it looks like 
the APIs and possibly the database will need work before its viable.
On Nov 20, 2012 12:59 PM, "Paul Robert Marino" 
mailto:prmari...@gmail.com>> wrote:
On Tue, Nov 20, 2012 at 11:16 AM, Elias Abacioglu 
mailto:elias.r...@gmail.com>> wrote:
> Hello list,
>
> This is my very first post on this list.
> I have questions regarding 
> eva-direct-errata-sync.pl.
> I have both RHEL and CentOS channels in my spacewalk. I'm pretty new to all
> this and wondering how I should setup the errata sync.
>
> I have the following RHEL channels in my spacewalk:
> rh6-x64-base-channel ( = rhel-x86_64-server-6)
> rh6-x64-optional-channel ( = rhel-x86_64-server-optional-6)
> rh5-x64-base-channel ( = rhel-x86_64-server-5)
> rh5-x64-rhn_tools-channel ( = rhn-tools-rhel-x86_64-server-5)
>
> And the following CentOS channels:
> centos6-x64-base-channel (contains base and updates repos)
> centos5-x64-base-channel (contains base and updates repos)
> centos5-x32-base-channel (contains base and updates repos)
>
> I want to run errata sync every night for both my RHEL and CentOS channels.
> So what I've come up with so far is this:
> ERRATASRCUSER=xxx
> ERRATADSTUSER=xxx
> ERRATASRCPASS=xxx
> ERRATADSTPASS=xxx
> ERRATADST=localhost
> ./eva-direct-errata-sync.pl 
> --sourcechannel=rhel-x86_64-server-5
> --destinationchannel=rh5-x64-base-channel -F day
> ./eva-direct-errata-sync.pl 
> --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=rh6-x64-base-channel -F day
>
> So for the child channel rh6-x64-optional-channel, do I use the -r flag? And
> what will happen with my channel label name differences
> (rh6-x64-optional-channel/rhel-x86_64-server-optional-6)?
> #   -r or --recursive
>
> When do I use these flags?
> #   -e RH or --rewriteerratanamefrom RH
> #   -E CENTOSX86_64 or --rewriteerratanameto CENTOSX86_64
This rewrites the name of the errata so you don't get conflicting
errata names essentially you cant have two erratas with the same name
even if they are on different channels.
for example RHBA-2012:1441 would be published in spacewalk as
CENTOSX86_64BA-2012:1441

> #   --rewritepackagereleasefrom el6
> #   --rewritepackagereleaseto el6.centos
these flags deal with alternate package names in Centos here is an
example in the Redhat errata it might say the package is names
at-spi-1.28.1-2.el6..x86_64.rpm but the Centos 6 name for the package
is at-spi-1.28.1-2.el6.centos.x86_64.rpm this happens when Centos has
added an additional patch that wasn't in the Redhat version of the
rpm.
These flags make it match the right package in the channel if it
matches the el6 or el6.centos
you should always use this for Centos channels

>
>
> My best guess for the CentOS channels I should use these flags:
> ./eva-direct-errata-sync.pl 
> --sourcechannel=rhel-x86_64-server-5
> --destinationchannel=centos5-x64-base-channel --rewritepackagereleasefrom
> el6 --rewritepackagereleaseto el6.centos -F day
> ./eva-direct-errata-sync.pl 
> --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=centos6-x64-base-channel --rewritepackagereleasefrom
> el6 --rewritepackagereleaseto el6.centos -F day
> ./eva-direct-errata-sync.pl 
> --sourcechannel=rhel-i386-server-5
> --destinationchannel=centos5-x32-base-channel --rewritepackagereleasefrom
> el6 --rewritepackagereleaseto el6.centos -F day
>
this would give you better results
./eva-direct-errata-sync.pl 
--sourcechannel=rhel-x86_64-server-5
--destinationchannel=centos5-x64-base-channel
--rewritepackagereleasefrom el5 --rewritepackagereleaseto el5.centos
-F day  -e RH  -E CENTOS5X64

./eva-direct-errata-sync.pl 
--sourcechannel=rhel-x86_64-server-6
--destinationchannel=centos6-x64-base-channel
--rewritepackage

Re: [Spacewalk-list] Kickstarting a RHEL5 install - better with updates included or not?

[Jens Skott]

I have 3 different environments cloned off the original repo, testing
stagning and prod. I then use the orignial repo to sync the new errata
and packages, then test stage and prod are "frozen" repos witch i
update depending on my lifecycle plan.
I then kickstart a server from a singel profile (bare minimal 300mb
footprint) then add activationkeys in cobbler depending on prod test
or stage.
After I have kickstarted a machine I go over to using chef, where I
handle all application configuration and installation using rpm
packages from the different repos.

Hope that helps you a little. I can assist you further with explaning
in detail if you find it intresting and want to practice the setup i
use for my environment =)

Jens Skott
Tel: +46-8-5142 4396
Schibsted Centralen IT



2012/11/21 Paul Robert Marino :
> Actually the install from spacewalk with all the updates is cleaner
> because there is no chance an old package might have left artifacts
> behind.
> Although admittedly there are several schools of thought on this some
> prefer to do the updates manually others prefer the updates done in
> the install and there is still an other school of thought that if say
> you are rebuilding a host it should have the exact same rpm versions
> as the original and no additional updates.
> none of them are completely right or wrong its more of a matter of
> preference then any thing else.
>
>
>
> On Wed, Nov 21, 2012 at 9:47 AM, Snyder, Chris  wrote:
>> Looking for some opinions here.
>>
>>
>>
>> I’ve got SW 1.8 working with RHEL5 now (thank you, J. Pazdziora) and have a
>> kickstart profile uses three channels for initial package installation: core
>> RHEL5 packages (from the ISO), all current RHEL5 updates so when all is said
>> and done, I have a host ready to roll with no need for updates to be
>> applied.
>>
>>
>>
>> Is this the best way to build a host?
>>
>>
>>
>> I don’t have any particular reason for this, but I have a gut feeling that a
>> better way to build a host might be to ONLY use the core RHEL5 ISO packages
>> and the spacewalk-client packages for initial host creation, then register
>> the host with my RHEL5 update channel, and then apply any needed updates
>> (could be done in a %post section).
>>
>>
>>
>> The second option seems ‘cleaner’ from the stand point of it mimics building
>> a host from an ISO and then applying updates, whereas the first does
>> everything at once.  Theoretically the end result should be the same.
>>
>>
>>
>> Thoughts?
>>
>>
>>
>> Thx
>>
>> Chris.
>>
>>
>>
>> --
>>
>> Chris Snyder
>>
>> SRA Senior Linux Geek
>> Energystar Network O+M Team
>> ESTAR Issues: https://estar18.energystar.gov/
>>
>>
>>
>>
>> ___
>> 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] eva-direct-errata-sync.pl setup & example usage

[Steve Meier]

Hi Paul,

I have been bitten by cross-contamination myself when creating errata's as 
mentioned in 2).

The workaround I have implemented in CEFS is to save the channel membership of 
each
package before publishing an errata and then deleting newly created 
memberships. That
restores the previous channel status. It's an ugly hack but so far the only 
solution I have found.

Regards,
  Steve

Am 21.11.2012 um 07:09 schrieb Paul Robert Marino:

> By the way one thing I forgot and an other thing which is new information.
> 1) you should always use the -r flag if you intend to include child channels 
> right now its broken and always acts like its always on but this will be 
> fixed shortly.
> 2) I've gotten the multi base channel sync feature working on my development 
> host but it introduces the problem where it cross contaminates the channels 
> when two channels have a package with the same name so it is dangerous to use 
> right now. The problem seems to be in the spacewalk APIs not in the script 
> its self. I've tried several different methods to work around it but it looks 
> like the APIs and possibly the database will need work before its viable.
> 
> On Nov 20, 2012 12:59 PM, "Paul Robert Marino"  wrote:
> On Tue, Nov 20, 2012 at 11:16 AM, Elias Abacioglu  
> wrote:
> > Hello list,
> >
> > This is my very first post on this list.
> > I have questions regarding eva-direct-errata-sync.pl.
> > I have both RHEL and CentOS channels in my spacewalk. I'm pretty new to all
> > this and wondering how I should setup the errata sync.
> >
> > I have the following RHEL channels in my spacewalk:
> > rh6-x64-base-channel ( = rhel-x86_64-server-6)
> > rh6-x64-optional-channel ( = rhel-x86_64-server-optional-6)
> > rh5-x64-base-channel ( = rhel-x86_64-server-5)
> > rh5-x64-rhn_tools-channel ( = rhn-tools-rhel-x86_64-server-5)
> >
> > And the following CentOS channels:
> > centos6-x64-base-channel (contains base and updates repos)
> > centos5-x64-base-channel (contains base and updates repos)
> > centos5-x32-base-channel (contains base and updates repos)
> >
> > I want to run errata sync every night for both my RHEL and CentOS channels.
> > So what I've come up with so far is this:
> > ERRATASRCUSER=xxx
> > ERRATADSTUSER=xxx
> > ERRATASRCPASS=xxx
> > ERRATADSTPASS=xxx
> > ERRATADST=localhost
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> > --destinationchannel=rh5-x64-base-channel -F day
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> > --destinationchannel=rh6-x64-base-channel -F day
> >
> > So for the child channel rh6-x64-optional-channel, do I use the -r flag? And
> > what will happen with my channel label name differences
> > (rh6-x64-optional-channel/rhel-x86_64-server-optional-6)?
> > #   -r or --recursive
> >
> > When do I use these flags?
> > #   -e RH or --rewriteerratanamefrom RH
> > #   -E CENTOSX86_64 or --rewriteerratanameto CENTOSX86_64
> This rewrites the name of the errata so you don't get conflicting
> errata names essentially you cant have two erratas with the same name
> even if they are on different channels.
> for example RHBA-2012:1441 would be published in spacewalk as
> CENTOSX86_64BA-2012:1441
> 
> > #   --rewritepackagereleasefrom el6
> > #   --rewritepackagereleaseto el6.centos
> these flags deal with alternate package names in Centos here is an
> example in the Redhat errata it might say the package is names
> at-spi-1.28.1-2.el6..x86_64.rpm but the Centos 6 name for the package
> is at-spi-1.28.1-2.el6.centos.x86_64.rpm this happens when Centos has
> added an additional patch that wasn't in the Redhat version of the
> rpm.
> These flags make it match the right package in the channel if it
> matches the el6 or el6.centos
> you should always use this for Centos channels
> 
> >
> >
> > My best guess for the CentOS channels I should use these flags:
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> > --destinationchannel=centos5-x64-base-channel --rewritepackagereleasefrom
> > el6 --rewritepackagereleaseto el6.centos -F day
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> > --destinationchannel=centos6-x64-base-channel --rewritepackagereleasefrom
> > el6 --rewritepackagereleaseto el6.centos -F day
> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-i386-server-5
> > --destinationchannel=centos5-x32-base-channel --rewritepackagereleasefrom
> > el6 --rewritepackagereleaseto el6.centos -F day
> >
> this would give you better results
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> --destinationchannel=centos5-x64-base-channel
> --rewritepackagereleasefrom el5 --rewritepackagereleaseto el5.centos
> -F day  -e RH  -E CENTOS5X64
> 
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=centos6-x64-base-channel
> --rewritepackagereleasefrom el6 --rewritepackagereleaseto el6.centos
> -F day  -e RH  -E CENTOS6X64
> 
> ./eva-direct-errata-sync.pl --sourcech

Re: [Spacewalk-list] feature of spacewalk

[Paul Robert Marino]

Yes from the client side you use the yum command
On Nov 21, 2012 12:19 PM, "Mohit Vadhera"  wrote:

> Hi,
>
> Can anybody let me know what are other feature of spacewalk other than
> pushing packages from server side ?  Can we install packages from client
> side or not if yes how ?
>
> Thanks,
> Mohit
>
> ___
> 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] feature of spacewalk

[Boyd, Robert]

Yes you can tell yum to install whatever packages you like, or use the Red Hat 
GUI if your client is RHEL; e.g. :

Yum install 



Robert Boyd
Sr System Engineer | Peoplefluent
p. 919-645-2972 | c. 919-306-4681
e. robert.b...@peoplefluent.com
Visit: www.peoplefluent.com | Read: Peoplefluent 
Blog
Follow: @peoplefluent | Download: iPad 
App
[cid:image001.jpg@01CDC7E4.297AFF90]
[cid:image002.jpg@01CDC7E4.297AFF90]

From: spacewalk-list-boun...@redhat.com 
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Mohit Vadhera
Sent: Wednesday, November 21, 2012 12:16 PM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] feature of spacewalk

Hi,

Can anybody let me know what are other feature of spacewalk other than pushing 
packages from server side ?  Can we install packages from client side or not if 
yes how ?

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

[Spacewalk-list] feature of spacewalk

[Mohit Vadhera]

Hi,

Can anybody let me know what are other feature of spacewalk other than
pushing packages from server side ?  Can we install packages from client
side or not if yes how ?

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

Re: [Spacewalk-list] architecture for centos i686

[Mohit Vadhera]

thanks alot .it worked for i686 and hope the same should work for i386


On Wed, Nov 21, 2012 at 10:06 PM, Wolfgang Neudorfer  wrote:

> Hi,
>
> I think IA-32 is correct.
>
> Regards,
>
> Wolfgang
>
> - Original Message -
> From: "Mohit Vadhera" 
> To: spacewalk-list@redhat.com
> Sent: Wednesday, 21 November, 2012 4:01:55 PM
> Subject: [Spacewalk-list] architecture for centos i686
>
>
> Hi,
>
>
> Which architecture is suitable for centos i686 in spacewalk channel ?
>
>
> Thanks,
> Mohit
> ___
> 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] eva-direct-errata-sync.pl setup & example usage

[Paul Robert Marino]

I would add the -e RH  -E RH5X64 ect. to the RHEL channels although in
theory with the new version which I will post latter this week
covering both RHEL 5 and 6 channels in one sync would be safe as long
as you don't mix 32 and 64 but channels, because the rhel 5 packages
would have el5 in the package name and the RHEL 6 packages would have
el6 in them so there wouldn't be a conflict.
the problem pops up when you mix different CPU architectures or
distros in one sync.


On Wed, Nov 21, 2012 at 7:09 AM, Elias Abacioglu  wrote:
> 2012/11/21 Paul Robert Marino 
>>
>> By the way one thing I forgot and an other thing which is new information.
>> 1) you should always use the -r flag if you intend to include child
>> channels right now its broken and always acts like its always on but this
>> will be fixed shortly.
>> 2) I've gotten the multi base channel sync feature working on my
>> development host but it introduces the problem where it cross contaminates
>> the channels when two channels have a package with the same name so it is
>> dangerous to use right now. The problem seems to be in the spacewalk APIs
>> not in the script its self. I've tried several different methods to work
>> around it but it looks like the APIs and possibly the database will need
>> work before its viable.
>
> 2. That would be cool.
>
> So a good setup would look like this perhaps?
>
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> --destinationchannel=rh5-x64-base-channel -F day -r
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=rh6-x64-base-channel -F day -r
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> --destinationchannel=centos5-x64-base-channel --rewritepackagereleasefrom
> el5 --rewritepackagereleaseto el5.centos -F day  -e RH  -E CENTOS5X64 -r
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=centos6-x64-base-channel --rewritepackagereleasefrom
> el6 --rewritepackagereleaseto el6.centos -F day  -e RH  -E CENTOS6X64 -r
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-i386-server-5
> --destinationchannel=centos5-x32-base-channel --rewritepackagereleasefrom
> el5 --rewritepackagereleaseto el5.centos -F day -e RH  -E CENTOS5X32 -r
>
> This leads to another question, how does the rh5 and rh6 channel differ from
> eachother?
> Same question applies if I would have 32 and 64 bit RHEL channels.
> Do I need -e and -E flags to differ them? For instance "-e RH -E RH6X64" and
> "-e RH -E RH5X64"?
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
> --destinationchannel=rh5-x64-base-channel -F day -e RH  -E RH5X64 -r
> ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
> --destinationchannel=rh6-x64-base-channel -F day -e RH  -E RH6X64 -r
>
>
>
>> On Nov 20, 2012 12:59 PM, "Paul Robert Marino" 
>> wrote:
>>>
>>> On Tue, Nov 20, 2012 at 11:16 AM, Elias Abacioglu 
>>> wrote:
>>> > Hello list,
>>> >
>>> > This is my very first post on this list.
>>> > I have questions regarding eva-direct-errata-sync.pl.
>>> > I have both RHEL and CentOS channels in my spacewalk. I'm pretty new to
>>> > all
>>> > this and wondering how I should setup the errata sync.
>>> >
>>> > I have the following RHEL channels in my spacewalk:
>>> > rh6-x64-base-channel ( = rhel-x86_64-server-6)
>>> > rh6-x64-optional-channel ( = rhel-x86_64-server-optional-6)
>>> > rh5-x64-base-channel ( = rhel-x86_64-server-5)
>>> > rh5-x64-rhn_tools-channel ( = rhn-tools-rhel-x86_64-server-5)
>>> >
>>> > And the following CentOS channels:
>>> > centos6-x64-base-channel (contains base and updates repos)
>>> > centos5-x64-base-channel (contains base and updates repos)
>>> > centos5-x32-base-channel (contains base and updates repos)
>>> >
>>> > I want to run errata sync every night for both my RHEL and CentOS
>>> > channels.
>>> > So what I've come up with so far is this:
>>> > ERRATASRCUSER=xxx
>>> > ERRATADSTUSER=xxx
>>> > ERRATASRCPASS=xxx
>>> > ERRATADSTPASS=xxx
>>> > ERRATADST=localhost
>>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
>>> > --destinationchannel=rh5-x64-base-channel -F day
>>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
>>> > --destinationchannel=rh6-x64-base-channel -F day
>>> >
>>> > So for the child channel rh6-x64-optional-channel, do I use the -r
>>> > flag? And
>>> > what will happen with my channel label name differences
>>> > (rh6-x64-optional-channel/rhel-x86_64-server-optional-6)?
>>> > #   -r or --recursive
>>> >
>>> > When do I use these flags?
>>> > #   -e RH or --rewriteerratanamefrom RH
>>> > #   -E CENTOSX86_64 or --rewriteerratanameto CENTOSX86_64
>>> This rewrites the name of the errata so you don't get conflicting
>>> errata names essentially you cant have two erratas with the same name
>>> even if they are on different channels.
>>> for example RHBA-2012:1441 would be published in spacewalk as
>>> CENTOSX86_64BA-2012:1441
>>>
>>> > #   --rewritepackag

Re: [Spacewalk-list] Kickstarting a RHEL5 install - better with updates included or not?

[Paul Robert Marino]

Actually the install from spacewalk with all the updates is cleaner
because there is no chance an old package might have left artifacts
behind.
Although admittedly there are several schools of thought on this some
prefer to do the updates manually others prefer the updates done in
the install and there is still an other school of thought that if say
you are rebuilding a host it should have the exact same rpm versions
as the original and no additional updates.
none of them are completely right or wrong its more of a matter of
preference then any thing else.



On Wed, Nov 21, 2012 at 9:47 AM, Snyder, Chris  wrote:
> Looking for some opinions here.
>
>
>
> I’ve got SW 1.8 working with RHEL5 now (thank you, J. Pazdziora) and have a
> kickstart profile uses three channels for initial package installation: core
> RHEL5 packages (from the ISO), all current RHEL5 updates so when all is said
> and done, I have a host ready to roll with no need for updates to be
> applied.
>
>
>
> Is this the best way to build a host?
>
>
>
> I don’t have any particular reason for this, but I have a gut feeling that a
> better way to build a host might be to ONLY use the core RHEL5 ISO packages
> and the spacewalk-client packages for initial host creation, then register
> the host with my RHEL5 update channel, and then apply any needed updates
> (could be done in a %post section).
>
>
>
> The second option seems ‘cleaner’ from the stand point of it mimics building
> a host from an ISO and then applying updates, whereas the first does
> everything at once.  Theoretically the end result should be the same.
>
>
>
> Thoughts?
>
>
>
> Thx
>
> Chris.
>
>
>
> --
>
> Chris Snyder
>
> SRA Senior Linux Geek
> Energystar Network O+M Team
> ESTAR Issues: https://estar18.energystar.gov/
>
>
>
>
> ___
> 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] Changing spacewalk hostname

[James Hogarth]

>
>
> I am wondering though, would it be possible to use rhn-ssl-tool to
> override the current private key.  I do understand its kind of defeat the
> certificate security, but have not found any article online that rule out
> that possibility, hence the question
>
>
> Interestingly enough I have only just done this exact same thing.

Here's the process I used:

mv /root/ssl-build /root/ssl-build.bak
rhn-ssl-tool --gen-ca --force --set-country=""
--set-state="" --set-org=""

That wil generate a new CA (it'll ask you for a password to use) and then
spacewalk-hostname-rename will work as expected...

Since this is a new CA you will need to:

rm -rf /var/lib/jabberd/db/*

to make OSAD happy and on each system:

wget http://spacewalk.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT -O
/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
sed -i s'/oldhostname/newhostname/' /etc/sysconfig/rhn/up2date

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

Re: [Spacewalk-list] Changing spacewalk hostname

[Paul Robert Marino]

If you are using FreeIPA Just generate a crl and create a legitimate
cert using Dogtag

On Wed, Nov 21, 2012 at 11:12 AM, William Muriithi
 wrote:
> Hello,
>
> I am trying to change a hostname of a server running Spacewalk and I have
> encountered a problem.  My root issue is, I had initially assumed I could
> run spacewalk without SSL. (Its within data centre so I not too sensitive
> and only currently testing it on dev boxes)  So when I initializing the
> database, I did not record the password I used to generate the certificate.
>
> At some point, I changed the spacewalk hostname – needed to do this in order
> to use FreeIPA for authentication and that has broken osad and
> osa-dispatcher communication.  (jabber can no longer connect to the server).
> Took a while to figure out what happened but now I am sure changing hostname
> was a not a good idea.
>
> Luckily, looks like there is a script to go fixing all the hostname hard
> coded in the system configuration - spacewalk-hostname-rename.
> Unfortunately for me, I have forgotten the password I had used to secure the
> certificate  private key. So spacewalk-hostname-rename just bail out after
> trying to load the key.  At the moment, looks like my only solution is to
> redo the whole thing from start again, having learned the importance of the
> certificate used in this project.
>
> I am wondering though, would it be possible to use rhn-ssl-tool to override
> the current private key.  I do understand its kind of defeat the certificate
> security, but have not found any article online that rule out that
> possibility, hence the question
>
> Thanks for advice
>
> William
>
>
> ___
> 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] architecture for centos i686

[Wolfgang Neudorfer]

Hi,

I think IA-32 is correct.

Regards,

Wolfgang

- Original Message -
From: "Mohit Vadhera" 
To: spacewalk-list@redhat.com
Sent: Wednesday, 21 November, 2012 4:01:55 PM
Subject: [Spacewalk-list] architecture for centos i686


Hi, 


Which architecture is suitable for centos i686 in spacewalk channel ? 


Thanks, 
Mohit 
___
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] Popup "Error" in Overview

[Wolfgang Neudorfer]

Hi,

I scheduled a Remote Command on one host and got an Internal Server Error. 
After this, every time I click on overview (or log in), a popup appears saying 
just "Error". In catalina.out I see the following:


==> /var/log/tomcat6/catalina.out <==
2012-11-21 17:20:33,182 [TP-Processor12] WARN  
org.directwebremoting.impl.DefaultRemoter - Method execution failed:
com.redhat.rhn.common.hibernate.HibernateRuntimeException: Executing query 
Action.findByIdandOrgId with params {orgId=2, aid=335} failed
at 
com.redhat.rhn.common.hibernate.HibernateFactory.lookupObjectByNamedQuery(HibernateFactory.java:188)
at 
com.redhat.rhn.common.hibernate.HibernateFactory.lookupObjectByNamedQuery(HibernateFactory.java:158)
at 
com.redhat.rhn.domain.action.ActionFactory.lookupByUserAndId(ActionFactory.java:400)
at 
com.redhat.rhn.manager.action.ActionManager.lookupAction(ActionManager.java:143)
at 
com.redhat.rhn.frontend.action.renderers.PendingActionsRenderer.render(PendingActionsRenderer.java:51)
at 
com.redhat.rhn.frontend.action.renderers.BaseFragmentRenderer.renderAsync(BaseFragmentRenderer.java:53)
at sun.reflect.GeneratedMethodAccessor284.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.directwebremoting.impl.ExecuteAjaxFilter.doFilter(ExecuteAjaxFilter.java:34)
at 
org.directwebremoting.impl.DefaultRemoter$1.doFilter(DefaultRemoter.java:428)
at 
org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:431)
at 
org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:283)
at 
org.directwebremoting.servlet.PlainCallHandler.handle(PlainCallHandler.java:52)
at 
org.directwebremoting.servlet.UrlProcessor.handle(UrlProcessor.java:101)
at org.directwebremoting.servlet.DwrServlet.doPost(DwrServlet.java:146)
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.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)
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.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:97)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
at 
org.apache.

Re: [Spacewalk-list] spacewalk-postgresql-1.8.6-1.el5.noarch.rpm requires postgresql84-contrib

[Jeremy Davis]

My apologizes, I looked at the wrong contrib package for the provides. I
thought postgresql84-contrib had the provides for postgresql-contrib but it
doesn't as you say. It was the 9.1 postgresql91-contrib package that has
the provides. Seems like postgresql84-contrib could be updated to reflect
this but that is something that would need to change on RHEL (Which I still
recommend changing that package as it is a good standard to use just as the
9.1 package is doing). I will go ahead and use the 84 client packages with
9.1 to start and maybe switch them out after the upgrade.

Please disregard this email now as this whole email was relying on
postgresql84-contrib having a provides for postgresql-contrib like the
postgresq91-contrib package does but it doesn't so my recommendation is
null. Not sure how I didn't catch that. Sorry to have wasted your time on
this as I thought I checked before I sent this email.

Thank you for your time and have a great day!

Regards,
Jeremy

On Wed, Nov 21, 2012 at 1:00 AM, Jan Pazdziora wrote:

> On Tue, Nov 20, 2012 at 12:12:17PM -0700, Jeremy Davis wrote:
> >
> > What I am really asking is if we can update the rpm require lines to
> > reflect postgresql-contrib instead of postgresql84-contrib and use the
>
> No. There does not seem to be any such thing as postgresql-contrib which
> would be compatible with postgresql84-server on RHEL 5. The package
> postgresql84-contrib does not Provide postgresql-contrib.
>
> > postgresql >= 8.4 as the means to make sure we get at least 8.4 when
> > installed via yum. This also seems a lot cleaner than requiring
> > postgresql84-contrib when that package provides postgresql-contrib in the
> > package.
>
> The postgresql-contrib in RHEL 5 is version 8.1. 8.1 < 8.4.
>
> If you don't like the Requires list in the spacewalk-postgresql
> package, just don't use it and install all dependencies manually.
>
> > to choose which version of PostgreSQL to use, help smash any bugs that
> are
> > found with different versions, and allow Spacewalk to support newer
> version
> > more quickly.
>
> It is not our plan to support newer versions of PostgreSQL on
> RHEL 5. If you get it working, fine. We like to stay with the database
> version provided by the OS.
>
> > If I can't use 9.1 than I would recommend that you update the wiki or
> allow
> > me to update the wiki to change the documentation to state that only 8.4
> is
> > a solid requirement and that you can't use a newer version.
>
> You can just fine, on Fedoras, for example.
>
> --
> Jan Pazdziora
> Principal Software Engineer, Satellite Engineering, Red Hat
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] Changing spacewalk hostname

[William Muriithi]

Hello,

I am trying to change a hostname of a server running Spacewalk and I have
encountered a problem.  My root issue is, I had initially assumed I could
run spacewalk without SSL. (Its within data centre so I not too sensitive
and only currently testing it on dev boxes)  So when I initializing the
database, I did not record the password I used to generate the certificate.

At some point, I changed the spacewalk hostname – needed to do this in
order to use FreeIPA for authentication and that has broken osad and
osa-dispatcher communication.  (jabber can no longer connect to the
server). Took a while to figure out what happened but now I am sure
changing hostname was a not a good idea.

Luckily, looks like there is a script to go fixing all the hostname hard
coded in the system configuration - spacewalk-hostname-rename.
 Unfortunately for me, I have forgotten the password I had used to secure
the certificate  private key. So spacewalk-hostname-rename just bail out
after trying to load the key.  At the moment, looks like my only solution
is to redo the whole thing from start again, having learned the importance
of the certificate used in this project.

I am wondering though, would it be possible to use rhn-ssl-tool to override
the current private key.  I do understand its kind of defeat the
certificate security, but have not found any article online that rule out
that possibility, hence the question

Thanks for advice

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

[Spacewalk-list] architecture for centos i686

[Mohit Vadhera]

Hi,

Which architecture is suitable for centos i686 in spacewalk channel ?

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

[Spacewalk-list] Kickstarting a RHEL5 install - better with updates included or not?

[Snyder, Chris]

Looking for some opinions here.

I've got SW 1.8 working with RHEL5 now (thank you, J. Pazdziora) and have a 
kickstart profile uses three channels for initial package installation: core 
RHEL5 packages (from the ISO), all current RHEL5 updates so when all is said 
and done, I have a host ready to roll with no need for updates to be applied.

Is this the best way to build a host?

I don't have any particular reason for this, but I have a gut feeling that a 
better way to build a host might be to ONLY use the core RHEL5 ISO packages and 
the spacewalk-client packages for initial host creation, then register the host 
with my RHEL5 update channel, and then apply any needed updates (could be done 
in a %post section).

The second option seems 'cleaner' from the stand point of it mimics building a 
host from an ISO and then applying updates, whereas the first does everything 
at once.  Theoretically the end result should be the same.

Thoughts?

Thx
Chris.

--
Chris Snyder
SRA Senior Linux Geek
Energystar Network O+M Team
ESTAR Issues: https://estar18.energystar.gov/

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

Re: [Spacewalk-list] Customize pxeboot menus?

[Robert O'Connor]

That is absolutely perfect - many thanks!

Rob.

On Wed, Nov 21, 2012 at 12:02 PM, Stepan Rogov  wrote:

>  On 21.11.2012 15:02, Robert O'Connor wrote:
>
> Hi folks - I'm wanting to customize my /tftpboot/pxelinux.cfg/default menu
> such that one of the menu items (i.e spacewalk kickstart profiles) points
> the kickstart client to boot off another tftp server. Seeing as the
> kickstart stuff is all spacewalk-managed is it possible to (say) create a
> dummy kickstart profile which would add the required menu item?   Of course
> modifying the 'default' file directly results in it being overwritten each
> time changes are made in spacewalk.
>
> The way I'm currently fudging this is adding a mac address-specific
> 'next-server' entry in the dhcp configs for the desired clients to boot of
> the alternate tftp server but this is not an ideal solution for me.
>
> Thanks!
>
> Rob.
>
>
> ___
> Spacewalk-list mailing 
> listSpacewalk-list@redhat.comhttps://www.redhat.com/mailman/listinfo/spacewalk-list
>
>  Hi Rob.
>
> Cobbler  is responsible for kickstarts and pxe-menu.
> Default template is located in /etc/cobbler/pxe/pxedefault.template.
>
> Read the following to understand how to edit the templates:
> https://github.com/cobbler/cobbler/wiki/kickstart%20templating
> http://www.cheetahtemplate.org/docs/users_guide_html/users_guide.html
>
> Also see the documentation for cobbler.
>
>
>
> ___
> 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] eva-direct-errata-sync.pl setup & example usage

[Elias Abacioglu]

2012/11/21 Paul Robert Marino 

> By the way one thing I forgot and an other thing which is new information.
> 1) you should always use the -r flag if you intend to include child
> channels right now its broken and always acts like its always on but this
> will be fixed shortly.
> 2) I've gotten the multi base channel sync feature working on my
> development host but it introduces the problem where it cross contaminates
> the channels when two channels have a package with the same name so it is
> dangerous to use right now. The problem seems to be in the spacewalk APIs
> not in the script its self. I've tried several different methods to work
> around it but it looks like the APIs and possibly the database will need
> work before its viable.
>
2. That would be cool.

So a good setup would look like this perhaps?

./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
--destinationchannel=rh5-x64-base-channel -F day -r
./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
--destinationchannel=rh6-x64-base-channel -F day -r
./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
--destinationchannel=centos5-x64-base-channel --rewritepackagereleasefrom
el5 --rewritepackagereleaseto el5.centos -F day  -e RH  -E CENTOS5X64 -r
./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
--destinationchannel=centos6-x64-base-channel --rewritepackagereleasefrom
el6 --rewritepackagereleaseto el6.centos -F day  -e RH  -E CENTOS6X64 -r
./eva-direct-errata-sync.pl --sourcechannel=rhel-i386-server-5
--destinationchannel=centos5-x32-base-channel --rewritepackagereleasefrom
el5 --rewritepackagereleaseto el5.centos -F day -e RH  -E CENTOS5X32 -r

This leads to another question, how does the rh5 and rh6 channel differ
from eachother?
Same question applies if I would have 32 and 64 bit RHEL channels.
Do I need -e and -E flags to differ them? For instance "-e RH -E RH6X64"
and "-e RH -E RH5X64"?
./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
--destinationchannel=rh5-x64-base-channel -F day -e RH  -E RH5X64 -r
./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
--destinationchannel=rh6-x64-base-channel -F day -e RH  -E RH6X64 -r



On Nov 20, 2012 12:59 PM, "Paul Robert Marino"  wrote:
>
>> On Tue, Nov 20, 2012 at 11:16 AM, Elias Abacioglu 
>> wrote:
>> > Hello list,
>> >
>> > This is my very first post on this list.
>> > I have questions regarding eva-direct-errata-sync.pl.
>> > I have both RHEL and CentOS channels in my spacewalk. I'm pretty new to
>> all
>> > this and wondering how I should setup the errata sync.
>> >
>> > I have the following RHEL channels in my spacewalk:
>> > rh6-x64-base-channel ( = rhel-x86_64-server-6)
>> > rh6-x64-optional-channel ( = rhel-x86_64-server-optional-6)
>> > rh5-x64-base-channel ( = rhel-x86_64-server-5)
>> > rh5-x64-rhn_tools-channel ( = rhn-tools-rhel-x86_64-server-5)
>> >
>> > And the following CentOS channels:
>> > centos6-x64-base-channel (contains base and updates repos)
>> > centos5-x64-base-channel (contains base and updates repos)
>> > centos5-x32-base-channel (contains base and updates repos)
>> >
>> > I want to run errata sync every night for both my RHEL and CentOS
>> channels.
>> > So what I've come up with so far is this:
>> > ERRATASRCUSER=xxx
>> > ERRATADSTUSER=xxx
>> > ERRATASRCPASS=xxx
>> > ERRATADSTPASS=xxx
>> > ERRATADST=localhost
>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-5
>> > --destinationchannel=rh5-x64-base-channel -F day
>> > ./eva-direct-errata-sync.pl --sourcechannel=rhel-x86_64-server-6
>> > --destinationchannel=rh6-x64-base-channel -F day
>> >
>> > So for the child channel rh6-x64-optional-channel, do I use the -r
>> flag? And
>> > what will happen with my channel label name differences
>> > (rh6-x64-optional-channel/rhel-x86_64-server-optional-6)?
>> > #   -r or --recursive
>> >
>> > When do I use these flags?
>> > #   -e RH or --rewriteerratanamefrom RH
>> > #   -E CENTOSX86_64 or --rewriteerratanameto CENTOSX86_64
>> This rewrites the name of the errata so you don't get conflicting
>> errata names essentially you cant have two erratas with the same name
>> even if they are on different channels.
>> for example RHBA-2012:1441 would be published in spacewalk as
>> CENTOSX86_64BA-2012:1441
>>
>> > #   --rewritepackagereleasefrom el6
>> > #   --rewritepackagereleaseto el6.centos
>> these flags deal with alternate package names in Centos here is an
>> example in the Redhat errata it might say the package is names
>> at-spi-1.28.1-2.el6..x86_64.rpm but the Centos 6 name for the package
>> is at-spi-1.28.1-2.el6.centos.x86_64.rpm this happens when Centos has
>> added an additional patch that wasn't in the Redhat version of the
>> rpm.
>> These flags make it match the right package in the channel if it
>> matches the el6 or el6.centos
>> you should always use this for Centos channels
>>
>> >
>> >
>> > My best guess for the CentOS channels I should use these flags:
>> > ./ev

Re: [Spacewalk-list] Customize pxeboot menus?

[Stepan Rogov]

On 21.11.2012 15:02, Robert O'Connor wrote:
Hi folks - I'm wanting to customize my /tftpboot/pxelinux.cfg/default 
menu such that one of the menu items (i.e spacewalk kickstart 
profiles) points the kickstart client to boot off another tftp server. 
Seeing as the kickstart stuff is all spacewalk-managed is it possible 
to (say) create a dummy kickstart profile which would add the required 
menu item?   Of course modifying the 'default' file directly results 
in it being overwritten each time changes are made in spacewalk.


The way I'm currently fudging this is adding a mac address-specific 
'next-server' entry in the dhcp configs for the desired clients to 
boot of the alternate tftp server but this is not an ideal solution 
for me.


Thanks!

Rob.


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

Hi Rob.

Cobbler  is responsible for kickstarts and pxe-menu.
Default template is located in /etc/cobbler/pxe/pxedefault.template.

Read the following to understand how to edit the templates:
https://github.com/cobbler/cobbler/wiki/kickstart%20templating
http://www.cheetahtemplate.org/docs/users_guide_html/users_guide.html

Also see the documentation for cobbler.


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

Re: [Spacewalk-list] Need steps to push package to registered client from the server itself

[Mohit Vadhera]

Hi,

Thanks for answering. I would like to describe my problem as below.

1) After installing spacewalk i've tried to create a channel and synced
local repository. I can see the synced pkgs
2) I tried to add machine in the spacewalk using below command and got
result
[root@localhost i386]# rhnreg_ks -v
--serverUrl=http://172.20.3.32/XMLRPC--activationkey=1-df800dacea680fc25f632340c5322795
--force
This system is not subscribed to any channels.
RHN channel support will be disabled.

3) I can see the machine added under System > System but it doesn't show

Channel Name Provider Packages Systems
Centos5 Spacewalk Default Organization 2 0
4) I followed your given steps but the i can't see available packages there
to install.

Problem

when i synced repository. There are three pkgs in the repository that i
synced .but on spacewalk  it is showing 2 packages in one channel and one
pkg in no channel.

Channel   Packages
centos
fslint-2.18-1.el5.rf.noarch

 python-bugzilla-0.7.0-2.el5.noarch

Pkgs in no channel
 perl-Compress-Zlib-1.42-1.fc6.i386


Thanks,
Mohit Vadhera


On Wed, Nov 21, 2012 at 4:06 PM, Pietro Leone  wrote:

> Tab "systems", select the system you want to push the packages to. Select
> "software" (on the right of "details" under the title) and then choose the
> action you want to do. If you want to install new packages select "Install
> New Packages" then select the packages tou want to install and then press
> "install selected packages" at the end of the page.
>
> Ciao, Pietro.
>
>
>
> On 21.11.2012 11:27, Mohit Vadhera wrote:
>
>> Hi,
>>
>> Can anybody plz let me know the steps to push packages to registered
>> clients in spacewalk?  I am still on the testing phase and lot of
>> basic queries are coming. I've registered one client and the local
>> repository synced with one channel. Now i want to push packages to
>> registered client from the server it self.
>>
>> Thanks,
>> Mohit
>> __**_
>> Spacewalk-list mailing list
>> Spacewalk-list@redhat.com
>> https://www.redhat.com/**mailman/listinfo/spacewalk-**list
>>
>
> --
> I will build myself a copper tower
> With four ways out and no way in
> But mine the glory, mine the power
> (So I chose AmigaOS, GNU/Linux and OpenBSD)
>
> __**_
> 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] Customize pxeboot menus?

[Robert O'Connor]

Hi folks - I'm wanting to customize my /tftpboot/pxelinux.cfg/default menu
such that one of the menu items (i.e spacewalk kickstart profiles) points
the kickstart client to boot off another tftp server. Seeing as the
kickstart stuff is all spacewalk-managed is it possible to (say) create a
dummy kickstart profile which would add the required menu item?   Of course
modifying the 'default' file directly results in it being overwritten each
time changes are made in spacewalk.

The way I'm currently fudging this is adding a mac address-specific
'next-server' entry in the dhcp configs for the desired clients to boot of
the alternate tftp server but this is not an ideal solution for me.

Thanks!

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

Re: [Spacewalk-list] Need steps to push package to registered client from the server itself

[Pietro Leone]

Tab "systems", select the system you want to push the packages to. 
Select "software" (on the right of "details" under the title) and then 
choose the action you want to do. If you want to install new packages 
select "Install New Packages" then select the packages tou want to 
install and then press "install selected packages" at the end of the 
page.


Ciao, Pietro.


On 21.11.2012 11:27, Mohit Vadhera wrote:

Hi,

Can anybody plz let me know the steps to push packages to registered
clients in spacewalk?  I am still on the testing phase and lot of
basic queries are coming. I've registered one client and the local
repository synced with one channel. Now i want to push packages to
registered client from the server it self.

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


--
I will build myself a copper tower
With four ways out and no way in
But mine the glory, mine the power
(So I chose AmigaOS, GNU/Linux and OpenBSD)

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

[Spacewalk-list] Need steps to push package to registered client from the server itself

[Mohit Vadhera]

Hi,

Can anybody plz let me know the steps to push packages to registered
clients in spacewalk?  I am still on the testing phase and lot of basic
queries are coming. I've registered one client and the local repository
synced with one channel. Now i want to push packages to registered client
from the server it self.

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

[Spacewalk-list] m2crypto and SSL Certificates with SAN

[Steve Meier]

Dear all,

today I came across an interesting bug in the m2crypto package. When a
certificate has a Subject Alternative Name (SAN) the hostname verification
fails which causes a traceback and therefore interferes with
yum-rhn-plugin.

I have tested the different versions and this seems to be fixed in
m2crypto-0.16-6.el5.3 while m2crypto-0.16-6.el5.1 (and probably below) is
broken.

I would therefore like to recommend to update the dependencies of
yum-rhn-plugin to require m2crypto >= 0.16-6.el5.3 instead of >= 0.16-6.

Kind regards,
  Steve

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

[Spacewalk-list] Packages not supported by vendor?

[Pietro Leone]

Hallo, thanks to Sabine suggestions and a little of RTFM now we have a 
Spacewalk installation working with SLES and CentOS. On a test server I 
launched the update and appeared this warning:


"The following packages are not supported by their vendor"

All the packages are synced from SLES11 official repositories, why this 
warning? I do not want to break our support contract using unofficial 
packages (with several hundreds of server this event could upset a bit 
my employer ;-)


Thanks, Pietro.
--
I will build myself a copper tower
With four ways out and no way in
But mine the glory, mine the power
(So I chose AmigaOS, GNU/Linux and OpenBSD)

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

Re: [Spacewalk-list] FW: Problem migrating Oracle backend

[ŚLIPEK Krzysztof]

There were synonyms CONTACT, CUSTOMER and HOST but they had invalid status 
because after import views to which they are created were not compiled.

Best regards,
Chris

>Date: Tue, 20 Nov 2012 12:14:55 +0100
>From: Jan Pazdziora 
>To: spacewalk-list@redhat.com
>Subject: Re: [Spacewalk-list] FW: Problem migrating Oracle backend
>   from 10g XE to 11gR1 EE
>Message-ID: <20121120111455.gc1...@redhat.com>
>Content-Type: text/plain; charset=iso-8859-2
>
>On Tue, Nov 20, 2012 at 12:02:09PM +0100, ?LIPEK Krzysztof wrote:
>> 
>> Problem with DB resolved - I've recreated invalid synonyms and recompiled 
>> EVR_T type body.
>
>Which synonyms were those?
>
>--
>Jan Pazdziora
>Principal Software Engineer, Satellite Engineering, Red Hat

--
BNP Paribas Bank Polska SA z siedzibą w Warszawie przy ul. Suwak 3, 
zarejestrowany w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział 
Gospodarczy, KRS pod numerem 6421, NIP: 676-007-83-01, kapitał zakładowy 1 434 
646 300 zł, w całości wpłacony.
BNP Paribas Bank Polska SA with its registered office in Warsaw at ul. Suwak 3, 
registered with the District Court for the capital city of Warsaw, XIII 
Commercial Division of the National Court Register (KRS) under No. 6421, VAT PL 
6760078301, holding paid-up share capital of PLN 1,434,646,300.
BNP Paribas Bank Polska SA  
disclaimer: http://www.bnpparibas.pl/legal/disclaimer.htm
--


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

Re: [Spacewalk-list] Selinux enforcing breaks rhnmd

[James Hogarth]

>
>
> The problem is that rhnmd can do anything. It can execute all probes we
have in stack and even some custom, which we do not about.
> So it is IMHO impossible to write proper selinux policy for rhnmd (beside
donotaudit/unconfined).
>

That would make sense to have rhnmd run unconfined then ( allowing the rest
of the system to remain confined) but the thing is I'm seeing it run in an
sshd_t context which appears to be complicating matters.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] satellite-sync does not import kickstarts.

[Stepan Rogov]

I run satellite-sync:
# satellite-sync --debug-level=6 --include-custom-channel -c 
centos-5.4-non_updatable-x86_64

12:43:08 Red Hat Network Satellite - live synchronization
12:43:08url: https://spacewalk.
12:43:08debug/output level: 6
12:43:08+++ Satellite synchronization tool checking in.
12:43:08+++ Entitled satellite validated.
12:43:08db:  
spacewalk/@dbname=spacewalk_db;host=127.0.0.1;port=5432
12:43:08 Action list/commandline toggles: ['channels', 
'download-errata', 'download-packages', 'errata', 'packages', 'short', 
'kickstarts', 'channel-families', 'download-kickstarts', 'arches', 'rpms']




12:43:10p = previously imported/synced channel
12:43:10. = channel not yet imported/synced
12:43:10base-channels:
12:43:10   p centos-5.4-non_updatable-x86_64  3357   
full import from Thu Nov 15 16:03:44 2012

12:43:10
12:43:10
12:43:10 Syncing Channel centos-5.4-non_updatable-x86_64 to Org 1
12:43:10 Channel data complete
12:43:10
12:43:10 Retrieving short package metadata (used for indexing)
12:43:10Retrieving / parsing short package metadata: 
centos-5.4-non_updatable-x86_64 (3357)
12:43:18 Diffing package metadata (what's missing locally?): 
centos-5.4-non_updatable-x86_64


Diffing: - complete
12:43:24
12:43:24 Downloading package metadata
12:43:24Retrieving / parsing *relevant* package metadata: 
centos-5.4-non_updatable-x86_64 (NONE RELEVANT)

12:43:24
12:43:24 Downloading rpm packages
12:43:24Fetching any missing RPMs: centos-5.4-non_updatable-x86_64 
(NONE MISSING)

12:43:24 Processing rpm packages complete
12:43:24
12:43:24 Importing package metadata
12:43:24Importing *relevant* package metadata: 
centos-5.4-non_updatable-x86_64 (NONE RELEVANT)

12:43:24
12:43:24 Linking packages to channels
12:43:41
12:43:41 Downloading errata data
12:43:41Retrieving / parsing errata data: 
centos-5.4-non_updatable-x86_64 (NONE RELEVANT)

12:43:41 Downloading errata data complete
12:43:41
12:43:41 Downloading kickstartable trees metadata
12:43:41Retrieving / parsing kickstart data: 
centos-5.4-non_updatable-x86_64 (NONE RELEVANT)

12:43:41
12:43:41 Downloading kickstartable trees files
12:43:41Retrieving / parsing kickstart tree files: 
centos-5.4-non_updatable-x86_64 (NONE RELEVANT)

12:43:41
12:43:41 Importing channel errata
12:43:41 Importing 0 errata for channel centos-5.4-non_updatable-x86_64.
12:43:41Importing *relevant* errata: centos-5.4-non_updatable-x86_64 
(NONE RELEVANT)

12:43:41No new kickstartable tree to import
Import complete:
Begin time: Wed Nov 21 12:43:08 2012
End time:   Wed Nov 21 12:43:41 2012
Elapsed:0 hours, 0 minutes, 33 seconds


But kickstart from the primary server are not imported.
Why can this happen?

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

Re: [Spacewalk-list] spacewalk-postgresql-1.8.6-1.el5.noarch.rpm requires postgresql84-contrib

[Jan Pazdziora]

On Tue, Nov 20, 2012 at 12:12:17PM -0700, Jeremy Davis wrote:
> 
> What I am really asking is if we can update the rpm require lines to
> reflect postgresql-contrib instead of postgresql84-contrib and use the

No. There does not seem to be any such thing as postgresql-contrib which
would be compatible with postgresql84-server on RHEL 5. The package
postgresql84-contrib does not Provide postgresql-contrib.

> postgresql >= 8.4 as the means to make sure we get at least 8.4 when
> installed via yum. This also seems a lot cleaner than requiring
> postgresql84-contrib when that package provides postgresql-contrib in the
> package.

The postgresql-contrib in RHEL 5 is version 8.1. 8.1 < 8.4.

If you don't like the Requires list in the spacewalk-postgresql
package, just don't use it and install all dependencies manually.

> to choose which version of PostgreSQL to use, help smash any bugs that are
> found with different versions, and allow Spacewalk to support newer version
> more quickly.

It is not our plan to support newer versions of PostgreSQL on
RHEL 5. If you get it working, fine. We like to stay with the database
version provided by the OS.

> If I can't use 9.1 than I would recommend that you update the wiki or allow
> me to update the wiki to change the documentation to state that only 8.4 is
> a solid requirement and that you can't use a newer version.

You can just fine, on Fedoras, for example.

-- 
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat

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

Re: [Spacewalk-list] Selinux enforcing breaks rhnmd

[Miroslav Suchy]

On 8.11.2012 14:19, James Hogarth wrote:

Hi,

I decided to try and make use of monitoring in Spacewalk...

I'm not sure when this might not have worked from (an old 1.7 instance
behaves this way and my new 1.8 does as well) but with selinux enforcing
I'm getting an AVC stopping rhnmd from working properly...


The problem is that rhnmd can do anything. It can execute all probes we 
have in stack and even some custom, which we do not about.
So it is IMHO impossible to write proper selinux policy for rhnmd 
(beside donotaudit/unconfined).


Mirek

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