My team recently updated from 2.5 to 2.7 but we also had an operational
issue where the database partition filled up (while running SW 2.5) and
postgres came to a halt. Since that time we have experienced a few issues
although the upgrade to 2.7 went smoothly.
One of them is that the Web UI shows
On Fri, Oct 13, 2017 at 3:58 AM, Michael Mraka
wrote:
>
> > One of them is that the Web UI shows packages available (and I can
> download
> > them from within the Web UI), but our clients cannot see the same
> packages
> > even if I remove /var/cache/yum, yum clean all, etc. on the client. I am
I was able to fix the database corruption by running vacuum and rebuilding
indices on each table; then I performed the following:
https://access.redhat.com/solutions/19303
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/ma
As some of you may remember, we had some PostGres DB corruption a few weeks
back. I thought we had fixed it, but now I realized the Spacewalk
registration bootstrap process is broken. The files that Spacewalk is
trying to download (rhn-lib, pyOpenSSL) are delivering HTML content instead
of actual
Running 2.7. Add a new kickstart script (specifying a snippet), try to
change order, get an internal server error. catalina.out shows the
following:
2017-11-21 08:50:35,755 [TP-Processor12] WARN
org.hibernate.util.JDBCExceptionReporter - SQL Error: 0, SQLState: 23505
2017-11-21 08:50:35,756 [TP-P
Ping. Any ideas why reordering the kickstart scripts causes an internal
server error and how I might recover?
On Tue, Nov 21, 2017 at 9:13 AM, Brian Long wrote:
> Running 2.7. Add a new kickstart script (specifying a snippet), try to
> change order, get an internal server
https://bugzilla.redhat.com/show_bug.cgi?id=1518670
/Brian/
On Wed, Nov 29, 2017 at 3:52 AM, Michael Mraka
wrote:
> Brian Long:
> > Ping. Any ideas why reordering the kickstart scripts causes an internal
> > server error and how I might recover?
>
> Hello Brian,
>
&
I found these two Satellite 5 articles helped with my Spacewalk 2.x's yum
repodata generation issues:
https://access.redhat.com/solutions/19303
https://access.redhat.com/articles/722693
We experienced a full filesystem and our Spacewalk Postgres database got
corrupted with no good backups. Lesson
Along these same lines, if we use Vintella / VAS client for Active
Directory authentication on Linux, how could we get Spacewalk to
authenticate via AD instead of local users. What parts of the
SpacewalkAndIPA document would I need to follow?
On Tue, Dec 19, 2017 at 9:35 AM, Michael Mraka
wrote
I've setup a fresh SW 2.7 instance on CentOS 7 and I used
spacewalk-common-channels to create the CentOS 7 repositories and
channels. I also manually created RHEL 7 repos (using mrepo) and
channels. I can use spacewalk-repo-sync -c [channel-name] to sync channels
properly, but when I visit the fo
I've had similar issues on our SW server that has been upgraded over time.
Take a look here:
https://access.redhat.com/solutions/19303
cd /var/cache/rhn/repodata
rm -rf (or mv /scratch to keep
a backup)
/root/regen-repodata.py -a --url https://localhost/rpc/api
Login as admin with password
ser
I use the "db-control" program to handle an online (DB running) backup.
db-control online-backup /local/backups/satellite-pgsql.$DATE 1>/dev/null
/Brian/
On Mon, Feb 26, 2018 at 1:23 PM, Nicole Beck wrote:
> Hello!
>
> I’m trying to backup my postgress DB using the Spacewalk install
> documenta
On Tue, Feb 27, 2018 at 5:23 PM, Dillon Mills wrote:
> I was recently trying to mass configure firewalld on a bunch of RHEL7
> boxes using Spacewalk, trying to ensure SNMP was enabled.
> So - mirroring what I would do from the shell - the script consisted of
> two lines:
> firewall-cmd --add-serv
Considering Spacewalk is the upstream for Red Hat Satellite 5.x and
Satellite 5 is end-of-life within a year, I'm not sure this move by SUSE is
a surprise.
https://access.redhat.com/solutions/3128641
I wonder how much longer Red Hat will provide engineering time focused on
Spacewalk 2.8+ when Sat
Gerald,
Months ago I ran into a similar issue on our SW 2.6 server and I found
that, because of a full filesystem issue, our database had become corrupt.
When SW 2.7 came out, I set up a fresh Spacewalk VM, fresh channels, etc.
and made sure everything was working. A coworker and I migrated all ou
I have two Spacewalk environments at different sites. Two weeks ago I
upgraded one of them from 2.7 to 2.9 (bypassed 2.8). The DB schema
upgrade was successful, but I noticed I could not view my Kickstart
profiles without receiving an error message:
There are errors in your kickstart template. Pl
On Tue, Jun 25, 2019 at 5:34 AM Michael Mraka wrote:
> It looks like cobbler is not able to parse kickstart file.
> There might be more info in /var/log/cobbler/cobbler.log.
Michael, thanks for the tip. I forgot about cobbler logs. I found
/etc/cobbler/settings had changed during the upgrade an
As many of you are probably aware, Red Hat recently had CDN issues
lasting almost two weeks. During that time, my Spacewalk server (and
many Satellite servers) were unable to download RHEL updates. For
years I have used mrepo that, under the hood, uses lftp with
certificate-based authentication t
Quick-n-dirty kickstart postinstall command we run:
# Disabling CentOS Internet Repos
egrep '^\[.*\]' /etc/yum.repos.d/CentOS-*.repo | awk -F: '{print $2}'
| sed -e 's/\[//g' -e 's/\]//g' | xargs yum-config-manager --disable
___
Spacewalk-list mailing l
Considering Spacewalk 2.9 was released in January 2019, what is the
plan for 2.10? Has Red Hat-sponsored Spacewalk development diminished
since Red Hat Satellite 6.x is based on TheForeman and Red Hat
Satellite 5.x is EOL in May 2020?
https://access.redhat.com/support/policy/updates/satellite
/B
On Wed, Jan 8, 2020 at 7:54 AM Len Ewen wrote:
> I know this a stupid noob question but I have a problem. I've got a clean
> built, fresh out of the box spacewalk 2.9 server and a 2.9 client. The
> client checked in once, but hasn't checked again for the last 16 hours. 16
> hours seems like a
I'll give you an example from a RHEL 6.9 spacewalk kickstart profile.
The "url" line provides the distribution tree and that distribution
has to be used at the end of each repo line to access the Spacewalk
yum repos directly.
url --url http://spacewalk-server.domain.com/ks/dist/org/1/RHEL_6.9_x86_
I'm not sure if you can retrieve a list systems that were removed from
Spacewalk, but you could write a script to query the API daily for a
list of active systems, then compare day-to-day.
https://spacewalkproject.github.io/documentation/api/2.4/handlers/SystemHandler.html#listActiveSystems
Here'
I think that document is outdated. I point Spacewalk to an upstream
CentOS and Fedora mirror and then just called spacewalk-repo-sync -c
name-of-centos-channel -c name-of-fedora-channel to sync the repo and
import everything all at once. I've never used rhnpush in the last
three years. Of course
Check previous threads from this morning and last week. The devs have
very limited time to work on Spacewalk since Red Hat no longer uses
Spacewalk as upstream for Satellite. :(
If you want to manage EL8 clients, you should install nightly (on EL7)
since it has various bug fixes. Spacewalk serv
I would like to know how folks are handing the default metadata_expire
of six hours when they push updates via Spacewalk. My team has run
into issues for years where we will sync new updates to a channel,
wait for the channel repodata to be rebuilt in Spacewalk, then select
a bunch of hosts to upd
Dennis, thanks for your response, but I'm not concerned with the
Spacewalk side of the metadata. I'm interesting in getting my clients
updating their metadata as soon as a Spacewalk channel is updated.
With default configuration, it could take six hours before they see
the channel has been updated
Michael, this is great news. Is it expected Spacewalk 2.10 will fully
support RHEL 8 clients including modules and appstreams? I imagine
due to previous threads you are not ready to support Spacewalk 2.10
server on RHEL 8, but I hope clients will be fully supported. Thank
you for any additional
a
update before trying to update?
/Brian/
On Mon, Feb 24, 2020 at 9:10 AM Brian Long wrote:
>
> Dennis, thanks for your response, but I'm not concerned with the
> Spacewalk side of the metadata. I'm interesting in getting my clients
> updating their metadata as soon as a
On your spacewalk server, visit /rhn/keys/CryptoKeysList.do and make
sure you add all GPG keys you want your systems to be able to
reference. In your kickstart profile, visit
rhn/kickstart/KickstartCryptoKeysList.do (System Details, GPG&SSL).
Put a checkbox next to each GPG key you want installed
t; In the past we were running Salt Stack to ensure packages were in place, and
> checking for a latest version of said packages (Salt Stack will auto expire
> and refresh the meta data when it does that).
>
> In order to alleviate some of the pain of having 6,000 machines attempt to
In my experience, this means your RHEL entitlement certificates expired and
you need to login to rhn.redhat.com, download a new set of certificates and
update your sync client to use the new certificates.
/Brian/
On Thu, Mar 19, 2020 at 6:08 AM Wenkai Chen <
wenkai_c...@ensigninfosecurity.com> wr
+1. Thanks for the extended support.
On Fri, Mar 20, 2020 at 9:30 AM Coffman, Anthony J
wrote:
>
> Michael Mráka
> >Spacewalk 2.10 was the last official release of Spacewalk.
>
> Thank you very much to the development team and to the community for this
> highly successful project and software.
Running Spacewalk 2.9-latest and I see errors like the following from my
Spacewalk server talking to itself (not a client talking to Spacewalk).
Does anyone know what causes this or how I can track it down further? I'm
receiving one or two emails per day with errors like this.
The following excep
If you're using spacewalk-repo-sync to sync an upstream yum repo to
spacewalk, you can edit the following file:
# cat /etc/rhn/spacewalk-repo-sync/yum.conf
[ansible-rhel7-x86_64]
exclude=ansible-2.9*,ansible-test-2.9*
[epel7-centos7-x86_64]
exclude=ansible-*
[epel7-rhel7-x86_64]
exclude=ansible-
In one of my RHEL 7 Kickstart profiles under System Details, Partitioning,
I have the following:
part /boot --fstype=ext4 --size=500
part pv.01 --grow --size=1
volgroup vg0 --pesize=32768 pv.01
logvol swap --fstype=swap --name=swap --vgname=vg0 --size=16384
logvol / --fstype=xfs --name=root --vgnam
My workflow before using Ansible was typically to download the vendor RPM
or release RPM that contains the .repo file and GPG key. I then place
every key I might ever want on my systems in /var/www/html/pub on my
spacewalk server. I then have a kickstart snippet script defined. The
script looks
Pau,
Without reading the detailed documentation, is Uyuni a true replacement or
upgrade for Spacewalk 2.10, managing CentOS 6, 7 and 8 as well as RHEL 6, 7
and 8, or is it more tied to Suse distributions now?
Thanks.
/Brian/
On Fri, Jul 24, 2020 at 8:17 PM Pau Garcia wrote:
> Hello
>
> Thank y
I'm running Spacewalk 2.9 and trying to determine why I get an error
syncing the repo from
https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.4/x86_64/. Of the 29
RPMs available, the 11 mongodb-cli RPMs fail to import into the DB. When I
run spacewalk-repo-sync with -vv, I see the following
There are a couple of things to check. When you promote a channel
using spacewalk-manage-channel-lifecycle, it takes a while for spacewalk to
generate the new yum metadata (could be 5-15 minutes depending on your
server and other activities). You can run "ls -ltr /var/cache/rhn/repodata
| tail" t
40 matches
Mail list logo
