Re: [Spacewalk-list] Spacewalk's planned cert expiration

2019-07-26 Thread p.cook...@bham.ac.uk 
Thanks for that clarification, fortunately we're running a later version 
already:-)

Regards
Phil

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of jmci...@bclc.com
Sent: 26 July 2019 15:50
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk's planned cert expiration

Hi Phil,

The cert I believe to be in question:
/usr/share/spacewalk/setup/spacewalk-public.cert

Last expiry date of that cert was 2018-07-13. Redhat renewed it one last time, 
stating that it would never be renewed again. I couldn't find a solid date but 
heard somewhere that it was to expire in Aug. This in turn will kill any 
spacewalk 2.4 and earlier installations. Upgrading to Spacewalk 2.5 or better 
apparently resolves this as the cert is simply ignored.

In preparation, we have upgraded all our spacewalk servers (4 servers for 4 
environs) from 2.4 to 2.6. Everything "seems" fine, but I was trying to 
simulate the dreaded cert failure, to simply ease my mind, so there's no 
surprises on day-of.

Details here:
https://github.com/spacewalkproject/spacewalk/wiki/Refreshing-certificate

Cert contents (public):


  SPACEWALK-001
  Spacewalk Default Organization
  2007-07-13 00:00:00
  2018-07-13 00:00:00
  2
  2
  2
  2
  2
  spacewalk
  2
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEABECAAYFAlNg/40ACgkQnnKdrwaUeTIXqwCgmRiTmzFuO7x3bitYPWcJFsZe
UPgAn0kTzWo7xUGDpedM0No9nEnWa84P
=FTXc
-END PGP SIGNATURE-



Jody McIvor
Sr. Systems Administrator, Integration
Les Services D'intégration





-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of spacewalk-list-requ...@redhat.com
Sent: July 26, 2019 1:57 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk-list Digest, Vol 134, Issue 28

Send Spacewalk-list mailing list submissions to spacewalk-list@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit 
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to 
spacewalk-list-requ...@redhat.com

You can reach the person managing the list at spacewalk-list-ow...@redhat.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Spacewalk-list digest..."


Today's Topics:

   1. In light of Satellite 5's inevitable sunset, can you sync
  official RHEL channels somehow? (gargunkle)
   2. Re: In light of Satellite 5's inevitable sunset, can you sync
  official RHEL channels somehow? (Matthew Madey)
   3. Re: Spacewalk's planned cert expiration in (p.cook...@bham.ac.uk)


--

Message: 1
Date: Thu, 25 Jul 2019 14:39:41 -0400
From: gargunkle 
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] In light of Satellite 5's inevitable sunset, can you 
sync official RHEL channels somehow?
Message-ID:

Content-Type: text/plain; charset="utf-8"

I'm 90% sure I know the answer to this, but wanted to check if there might be 
some good news.

My organization has official Red Hat Satellite licenses.  However, I really do 
not care for the Satellite 6 product.

Is there a way to sync official Red Hat channels/content to a Spacewalk server, 
perhaps leveraging the Satellite license my organization is paying for?  Maybe 
using COPR but I haven't figured out how that works yet.

Thanks for any pointers.

EP
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://www.redhat.com/archives/spacewalk-list/attachments/20190725/867af40a/attachment.html>

--

Message: 2
Date: Thu, 25 Jul 2019 14:12:45 -0500
From: Matthew Madey 
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] In light of Satellite 5's inevitable sunset, can 
you sync official RHEL channels somehow?
Message-ID:

Content-Type: text/plain; charset="utf-8"

I believe this method still works:
https://www.suse.com/documentation/suse-best-practices/sbp-sumaforrhel/data/sbp-sumaforrhel.html


On Thu, Jul 25, 2019 at 1:40 PM gargunkle  wrote:

> I'm 90% sure I know the answer to this, but wanted to check if there 
> might be some good news.
>
> My organization has official Red Hat Satellite licenses.  However, I 
> really do not care for the Satellite 6 product.
>
> Is there a way to sync official Red Hat channels/content to a 
> Spacewalk server, perhaps leveraging the Satellite license my 
> organization is paying for?  Maybe using COPR but I haven't figured out how 
> that works yet.
>
> Thanks for any pointers.
>
> EP
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://www.redhat.com/archives/spacewalk-list/attachments/20190725/437f2216/

Re: [Spacewalk-list] Spacewalk's planned cert expiration

2019-07-26 Thread Jody McIvor 
Hi Phil,

The cert I believe to be in question:
/usr/share/spacewalk/setup/spacewalk-public.cert

Last expiry date of that cert was 2018-07-13. Redhat renewed it one last time, 
stating that it would never be renewed again. I couldn't find a solid date but 
heard somewhere that it was to expire in Aug. This in turn will kill any 
spacewalk 2.4 and earlier installations. Upgrading to Spacewalk 2.5 or better 
apparently resolves this as the cert is simply ignored.

In preparation, we have upgraded all our spacewalk servers (4 servers for 4 
environs) from 2.4 to 2.6. Everything "seems" fine, but I was trying to 
simulate the dreaded cert failure, to simply ease my mind, so there's no 
surprises on day-of.

Details here:
https://github.com/spacewalkproject/spacewalk/wiki/Refreshing-certificate

Cert contents (public):


  SPACEWALK-001
  Spacewalk Default Organization
  2007-07-13 00:00:00
  2018-07-13 00:00:00
  2
  2
  2
  2
  2
  spacewalk
  2
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEABECAAYFAlNg/40ACgkQnnKdrwaUeTIXqwCgmRiTmzFuO7x3bitYPWcJFsZe
UPgAn0kTzWo7xUGDpedM0No9nEnWa84P
=FTXc
-END PGP SIGNATURE-



Jody McIvor
Sr. Systems Administrator, Integration
Les Services D'intégration





-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of spacewalk-list-requ...@redhat.com
Sent: July 26, 2019 1:57 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk-list Digest, Vol 134, Issue 28

Send Spacewalk-list mailing list submissions to
spacewalk-list@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to
spacewalk-list-requ...@redhat.com

You can reach the person managing the list at
spacewalk-list-ow...@redhat.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Spacewalk-list digest..."


Today's Topics:

   1. In light of Satellite 5's inevitable sunset, can you sync
  official RHEL channels somehow? (gargunkle)
   2. Re: In light of Satellite 5's inevitable sunset, can you sync
  official RHEL channels somehow? (Matthew Madey)
   3. Re: Spacewalk's planned cert expiration in (p.cook...@bham.ac.uk)


--

Message: 1
Date: Thu, 25 Jul 2019 14:39:41 -0400
From: gargunkle 
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] In light of Satellite 5's inevitable sunset,
can you sync official RHEL channels somehow?
Message-ID:

Content-Type: text/plain; charset="utf-8"

I'm 90% sure I know the answer to this, but wanted to check if there might be 
some good news.

My organization has official Red Hat Satellite licenses.  However, I really do 
not care for the Satellite 6 product.

Is there a way to sync official Red Hat channels/content to a Spacewalk server, 
perhaps leveraging the Satellite license my organization is paying for?  Maybe 
using COPR but I haven't figured out how that works yet.

Thanks for any pointers.

EP
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://www.redhat.com/archives/spacewalk-list/attachments/20190725/867af40a/attachment.html>

--

Message: 2
Date: Thu, 25 Jul 2019 14:12:45 -0500
From: Matthew Madey 
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] In light of Satellite 5's inevitable
sunset, can you sync official RHEL channels somehow?
Message-ID:

Content-Type: text/plain; charset="utf-8"

I believe this method still works:
https://www.suse.com/documentation/suse-best-practices/sbp-sumaforrhel/data/sbp-sumaforrhel.html


On Thu, Jul 25, 2019 at 1:40 PM gargunkle  wrote:

> I'm 90% sure I know the answer to this, but wanted to check if there
> might be some good news.
>
> My organization has official Red Hat Satellite licenses.  However, I
> really do not care for the Satellite 6 product.
>
> Is there a way to sync official Red Hat channels/content to a
> Spacewalk server, perhaps leveraging the Satellite license my
> organization is paying for?  Maybe using COPR but I haven't figured out how 
> that works yet.
>
> Thanks for any pointers.
>
> EP
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://www.redhat.com/archives/spacewalk-list/attachments/20190725/437f2216/attachment.html>

--

Message: 3
Date: Fri, 26 Jul 2019 08:56:59 +0000
From: "p.cook...@bham.ac.uk" 
To: "spacewalk-list@redhat.com" 
Subject: Re: [Spacewalk-list] Spacewalk's planned cert expiration in
Message-ID: <2468f0f312a84a458f3540fde214e...@bham.ac.uk>
Content-Typ

Re: [Spacewalk-list] Spacewalk's planned cert expiration in

2019-07-26 Thread p.cook...@bham.ac.uk 
Hi Jody

Spacewalk is the free open source up-stream version of Red Hat Satellite 5 so, 
unless I'm misinterpreting what you're saying, there's no license/certificate 
to expire really (apart from the SSL one I mentioned below - 
/etc/httpd/conf/ssl.crt/server.crt).

Which article are you referring to? If there's something that is going to stop 
Spacewalk syncing RHEL repo's, I imagine it would be a concern for a lot of 
people really!

Regards
Phil

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of jmci...@bclc.com
Sent: 24 July 2019 15:47
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk's planned cert expiration in

Hi Phil,

Thanks for the response. I checked that one and its expiry is 2038... It was my 
understanding that Redhat's dropping of support for Spacewalk included them no 
longer renewing the entitlement cert for Spacewalk servers. This resulted in 
versions 2.5 and higher not implementing this cert, as Redhat planned this 
final cert to expire this Aug 2019. So the expiry date confuses me, I would 
have expected it to be expiring in the next few weeks?

Maybe I'm just misinterpreting things.

Jody McIvor
Sr. Systems Administrator, Integration
Les Services D'intégration
[TEL] (250) 852-5202


jmci...@bclc.com
BCLC.com





-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of spacewalk-list-requ...@redhat.com
Sent: July 24, 2019 2:01 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk-list Digest, Vol 134, Issue 22

Send Spacewalk-list mailing list submissions to spacewalk-list@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit 
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to 
spacewalk-list-requ...@redhat.com

You can reach the person managing the list at spacewalk-list-ow...@redhat.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Spacewalk-list digest..."


Today's Topics:

   1. Re: Spacewalk-list Digest, Vol 134, Issue 19 (Dennis Pittman)
   2. Re: Spacewalk's planned cert expiration in Aug (Can we
  simulate this?) (p.cook...@bham.ac.uk)


--

Message: 1
Date: Wed, 24 Jul 2019 08:51:13 +
From: Dennis Pittman 
To: "spacewalk-list@redhat.com" 
Subject: Re: [Spacewalk-list] Spacewalk-list Digest, Vol 134, Issue 19
Message-ID:


Content-Type: text/plain; charset="us-ascii"

Since you stated that you had to restart your server, I would make certain that 
all file systems are mounted correctly, then also check for errors in your 
messages and audit files.  Once you have verified that everything is recovered 
successfully then try restarting the spacewalk-Services.



Sent from my iPhone

> On Jul 23, 2019, at 12:22 PM, Ellis, Merphis  
> wrote:
>
> Yea I found that I get the error "command not found" there,  get message that 
> command not found I did a find / -name spacewalk* and I do not see much, 
> couple config files.
>
> -Original Message-
> From: spacewalk-list-boun...@redhat.com 
>  On Behalf Of 
> spacewalk-list-requ...@redhat.com
> Sent: Tuesday, July 23, 2019 12:09 PM
> To: spacewalk-list@redhat.com
> Subject: Spacewalk-list Digest, Vol 134, Issue 19
>
> Send Spacewalk-list mailing list submissions to
>spacewalk-list@redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> redhat.com%2Fmailman%2Flistinfo%2Fspacewalk-listdata=02%7C01%7C%7
> C3296714f56714b54d22108d70f89e5f6%7C84df9e7fe9f640afb435%7
> C1%7C0%7C636994957247832135sdata=qQ%2By%2F0TxWz26lSntVUJBntRARINm
> Cb9E5E5mtv85xKc%3Dreserved=0 or, via email, send a message with 
> subject or body 'help' to
>spacewalk-list-requ...@redhat.com
>
> You can reach the person managing the list at
>spacewalk-list-ow...@redhat.com
>
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of Spacewalk-list digest..."
>
>
> Today's Topics:
>
>   1. Re: Spacewalk Start up (bryan.nor...@gmail.com)
>
>
> --
>
> Message: 1
> Date: Tue, 23 Jul 2019 18:08:28 +0200
> From: 
> To: 
> Subject: Re: [Spacewalk-list] Spacewalk Start up
> Message-ID: <004101d54170$de6c9be0$9b45d3a0$@gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Not sure if it was the same in 2.7 that it is in 2.9, but for 2.9, 
> it's
>
>
>
> Spacewalk-service start
>
>
>
> Bryan
>
>
>
>
>
> From: spacewalk-list-boun...@redhat.com 
> 
> On Behalf Of Ellis, Merphis
> Sent: Tuesday, July 2

Re: [Spacewalk-list] Spacewalk's planned cert expiration in

2019-07-24 Thread Jody McIvor 
t; Desc: not available
> URL:
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .redhat.com%2Farchives%2Fspacewalk-list%2Fattachments%2F20190723%2Fb94
> 56561%2Fattachment-0003.gifdata=02%7C01%7C%7C3296714f56714b54d221
> 08d70f89e5f6%7C84df9e7fe9f640afb435%7C1%7C0%7C636994957247
> 852151sdata=6ebi52V8xIp%2BbBhtBByndD8D8EoCMtgIow90rKbFYFM%3D
> reserved=0>
> -- next part -- A non-text attachment was
> scrubbed...
> Name: image005.gif
> Type: image/gif
> Size: 1498 bytes
> Desc: not available
> URL:
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .redhat.com%2Farchives%2Fspacewalk-list%2Fattachments%2F20190723%2Fb94
> 56561%2Fattachment-0004.gifdata=02%7C01%7C%7C3296714f56714b54d221
> 08d70f89e5f6%7C84df9e7fe9f640afb435%7C1%7C0%7C636994957247
> 852151sdata=URKpiNhFB3gQMiWFvD%2Bedr02MB1%2FxmIBezwprFB%2B3%2Fo%3
> Dreserved=0>
> -- next part -- A non-text attachment was
> scrubbed...
> Name: image006.gif
> Type: image/gif
> Size: 2049 bytes
> Desc: not available
> URL:
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .redhat.com%2Farchives%2Fspacewalk-list%2Fattachments%2F20190723%2Fb94
> 56561%2Fattachment-0005.gifdata=02%7C01%7C%7C3296714f56714b54d221
> 08d70f89e5f6%7C84df9e7fe9f640afb435%7C1%7C0%7C636994957247
> 852151sdata=Kog0egjOEpX1%2FyFjbBZ2UH4SS%2BuXkD5lP1H698rM0NQ%3D
> p;reserved=0>
> -- next part -- A non-text attachment was
> scrubbed...
> Name: image007.gif
> Type: image/gif
> Size: 1579 bytes
> Desc: not available
> URL:
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .redhat.com%2Farchives%2Fspacewalk-list%2Fattachments%2F20190723%2Fb94
> 56561%2Fattachment-0006.gifdata=02%7C01%7C%7C3296714f56714b54d221
> 08d70f89e5f6%7C84df9e7fe9f640afb435%7C1%7C0%7C636994957247
> 852151sdata=E7u68zya%2B%2B1D1PSWIqujmHKDUtX8v6LQh5g4sYCAxD0%3D
> p;reserved=0>
>
> --
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> redhat.com%2Fmailman%2Flistinfo%2Fspacewalk-listdata=02%7C01%7C%7
> C3296714f56714b54d22108d70f89e5f6%7C84df9e7fe9f640afb435%7
> C1%7C0%7C636994957247852151sdata=D709EPtY8OHomZGsWBT1ZIG3sj6uZJLL
> RFoqO6idPgg%3Dreserved=0
>
> End of Spacewalk-list Digest, Vol 134, Issue 19
> ***
>
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> redhat.com%2Fmailman%2Flistinfo%2Fspacewalk-listdata=02%7C01%7C%7
> C3296714f56714b54d22108d70f89e5f6%7C84df9e7fe9f640afb435%7
> C1%7C0%7C636994957247852151sdata=D709EPtY8OHomZGsWBT1ZIG3sj6uZJLL
> RFoqO6idPgg%3Dreserved=0



--

Message: 2
Date: Wed, 24 Jul 2019 09:00:35 +
From: "p.cook...@bham.ac.uk" 
To: "spacewalk-list@redhat.com" 
Subject: Re: [Spacewalk-list] Spacewalk's planned cert expiration in
Aug (Can we simulate this?)
Message-ID: <6ca656d7b9c64c2ea23d562a5115b...@bham.ac.uk>
Content-Type: text/plain; charset="iso-8859-1"

Hi Merphis

If you're referring to the SSL certificate created when running 
"spacewalk-setup" I believe the certificate file is 
"/etc/httpd/conf/ssl.crt/server.crt" and the expiration date is the line 
beginning "Not After" so you could try the following:

# grep "Not After" /etc/httpd/conf/ssl.crt/server.crt

Regards
Phil

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of jmci...@bclc.com
Sent: 23 July 2019 17:17
To: 'spacewalk-list@redhat.com' 
Subject: Re: [Spacewalk-list] Spacewalk's planned cert expiration in Aug (Can 
we simulate this?)

Also, I'm failing to find a solid date for Aug's cert expiry. Does anyone know 
this?


-Original Message-
From: Jody McIvor
Sent: July 19, 2019 7:18 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk's planned cert expiration in Aug (Can we simulate this?)

Hi All,

In preparation for Redhat's dropping of Spacewalk support (And any further 
certificate renewals), we have updated all of our spacewalk servers to no less 
than 2.6. I have been (unsuccessfully, since I'm not sure exactly which file it 
is) attempting to "simulate" the cert expiration by:
 - Renaming what I thought was the cert file (Pretty sure I was wrong)
 - Forcing date/time change to 2019 on Spacewalk server (Everything seemed 
fine, but still not convinced.

My question

Re: [Spacewalk-list] Spacewalk's planned cert expiration in Aug (Can we simulate this?)

2019-07-24 Thread p.cook...@bham.ac.uk 
Hi Merphis

If you're referring to the SSL certificate created when running 
"spacewalk-setup" I believe the certificate file is 
"/etc/httpd/conf/ssl.crt/server.crt" and the expiration date is the line 
beginning "Not After" so you could try the following:

# grep "Not After" /etc/httpd/conf/ssl.crt/server.crt

Regards
Phil

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of jmci...@bclc.com
Sent: 23 July 2019 17:17
To: 'spacewalk-list@redhat.com' 
Subject: Re: [Spacewalk-list] Spacewalk's planned cert expiration in Aug (Can 
we simulate this?)

Also, I'm failing to find a solid date for Aug's cert expiry. Does anyone know 
this?


-Original Message-
From: Jody McIvor
Sent: July 19, 2019 7:18 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk's planned cert expiration in Aug (Can we simulate this?)

Hi All,

In preparation for Redhat's dropping of Spacewalk support (And any further 
certificate renewals), we have updated all of our spacewalk servers to no less 
than 2.6. I have been (unsuccessfully, since I'm not sure exactly which file it 
is) attempting to "simulate" the cert expiration by:
 - Renaming what I thought was the cert file (Pretty sure I was wrong)
 - Forcing date/time change to 2019 on Spacewalk server (Everything seemed 
fine, but still not convinced.

My questions are:
 - Can someone enlighten me as to which file is truly the cert that will expire 
next month?
 - Was changing the time on the server my best bet for testing the effects of 
the cert failure?

Any input on this subject is appreciated, because if this doesn't go smoothly 
in Aug it WILL have a massive impact on company income until resolved.

Jody McIvor
Sr. Systems Administrator, Integration
Les Services D'intégration




-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of spacewalk-list-requ...@redhat.com
Sent: July 19, 2019 6:27 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk-list Digest, Vol 134, Issue 13

Send Spacewalk-list mailing list submissions to spacewalk-list@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit 
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to 
spacewalk-list-requ...@redhat.com

You can reach the person managing the list at spacewalk-list-ow...@redhat.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Spacewalk-list digest..."


Today's Topics:

   1. Needs-Restarting shows perpetual reboot need afterKickstart
  (bryan.nor...@gmail.com)
   2. Re: Needs-Restarting shows perpetual reboot needafter
  Kickstart (bryan.nor...@gmail.com)
   3. Re: Update failing for no public key (Lubbers, Nicholas)


--

Message: 1
Date: Fri, 19 Jul 2019 06:11:15 +0200
From: 
To: 
Subject: [Spacewalk-list] Needs-Restarting shows perpetual reboot need 
afterKickstart
Message-ID: <01d53de8$03363990$09a2acb0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"

Since I couldn't get around the Internal Server Error when attempting to 
Profile Sync, I found a work around using spacecmd and a post script during the 
Kickstart process.



Everything works great, with one exception.  After the provisioning is done, 
and the server is accessible, it shows that it needs a reboot.  After rebooting 
it, it still shows a reboot is needed.  It says (amongst other
components) that the kernel has been updated, yet uname -r shows it is running 
the kernel that it thinks it needs to reboot to use.



Have you all seen this before?  I'm stumped.no amount of googling has produced 
anything close to helpful.



Thanks!

Bryan

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://www.redhat.com/archives/spacewalk-list/attachments/20190719/26001fd3/attachment.html>

--

Message: 2
Date: Fri, 19 Jul 2019 10:10:45 +0200
From: 
To: 
Subject: Re: [Spacewalk-list] Needs-Restarting shows perpetual reboot needafter 
Kickstart
Message-ID: <000201d53e09$7890a1f0$69b1e5d0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"

It looks like it was a date/time issue.  When the system was kickstarted, it 
used the default GMT.  Somewhere in the update process after install, the time 
was corrected to GMT+2.  After 2 hours, I rebooted it again, and no it no 
longer thinks it needs to reboot to load a more recent kernel, and shows the 
system is up to date.



From: bryan.nor...@gmail.com 
Sent: Friday, July 19, 2019 06:11
To: spacewalk-list@redhat.com
Subject: Needs-Restarting shows perpetual reboot need after Kickstart



Since I couldn't get around the Internal Server Error when attempting to 
Profile Sync, I found a work around using spacecmd and a post script during the 
Kickstart process.



Everythi

Re: [Spacewalk-list] Spacewalk's planned cert expiration in Aug (Can we simulate this?)

2019-07-23 Thread Jody McIvor 
Also, I'm failing to find a solid date for Aug's cert expiry. Does anyone know 
this?


-Original Message-
From: Jody McIvor
Sent: July 19, 2019 7:18 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk's planned cert expiration in Aug (Can we simulate this?)

Hi All,

In preparation for Redhat's dropping of Spacewalk support (And any further 
certificate renewals), we have updated all of our spacewalk servers to no less 
than 2.6. I have been (unsuccessfully, since I'm not sure exactly which file it 
is) attempting to "simulate" the cert expiration by:
 - Renaming what I thought was the cert file (Pretty sure I was wrong)
 - Forcing date/time change to 2019 on Spacewalk server (Everything seemed 
fine, but still not convinced.

My questions are:
 - Can someone enlighten me as to which file is truly the cert that will expire 
next month?
 - Was changing the time on the server my best bet for testing the effects of 
the cert failure?

Any input on this subject is appreciated, because if this doesn't go smoothly 
in Aug it WILL have a massive impact on company income until resolved.

Jody McIvor
Sr. Systems Administrator, Integration
Les Services D'intégration




-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of spacewalk-list-requ...@redhat.com
Sent: July 19, 2019 6:27 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk-list Digest, Vol 134, Issue 13

Send Spacewalk-list mailing list submissions to
spacewalk-list@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to
spacewalk-list-requ...@redhat.com

You can reach the person managing the list at
spacewalk-list-ow...@redhat.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Spacewalk-list digest..."


Today's Topics:

   1. Needs-Restarting shows perpetual reboot need afterKickstart
  (bryan.nor...@gmail.com)
   2. Re: Needs-Restarting shows perpetual reboot needafter
  Kickstart (bryan.nor...@gmail.com)
   3. Re: Update failing for no public key (Lubbers, Nicholas)


--

Message: 1
Date: Fri, 19 Jul 2019 06:11:15 +0200
From: 
To: 
Subject: [Spacewalk-list] Needs-Restarting shows perpetual reboot need
afterKickstart
Message-ID: <01d53de8$03363990$09a2acb0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"

Since I couldn't get around the Internal Server Error when attempting to 
Profile Sync, I found a work around using spacecmd and a post script during the 
Kickstart process.



Everything works great, with one exception.  After the provisioning is done, 
and the server is accessible, it shows that it needs a reboot.  After rebooting 
it, it still shows a reboot is needed.  It says (amongst other
components) that the kernel has been updated, yet uname -r shows it is running 
the kernel that it thinks it needs to reboot to use.



Have you all seen this before?  I'm stumped.no amount of googling has produced 
anything close to helpful.



Thanks!

Bryan

-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Fri, 19 Jul 2019 10:10:45 +0200
From: 
To: 
Subject: Re: [Spacewalk-list] Needs-Restarting shows perpetual reboot
needafter Kickstart
Message-ID: <000201d53e09$7890a1f0$69b1e5d0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"

It looks like it was a date/time issue.  When the system was kickstarted, it 
used the default GMT.  Somewhere in the update process after install, the time 
was corrected to GMT+2.  After 2 hours, I rebooted it again, and no it no 
longer thinks it needs to reboot to load a more recent kernel, and shows the 
system is up to date.



From: bryan.nor...@gmail.com 
Sent: Friday, July 19, 2019 06:11
To: spacewalk-list@redhat.com
Subject: Needs-Restarting shows perpetual reboot need after Kickstart



Since I couldn't get around the Internal Server Error when attempting to 
Profile Sync, I found a work around using spacecmd and a post script during the 
Kickstart process.



Everything works great, with one exception.  After the provisioning is done, 
and the server is accessible, it shows that it needs a reboot.  After rebooting 
it, it still shows a reboot is needed.  It says (amongst other
components) that the kernel has been updated, yet uname -r shows it is running 
the kernel that it thinks it needs to reboot to use.



Have you all seen this before?  I'm stumped.no amount of googling has produced 
anything close to helpful.



Thanks!

Bryan

-- next part --
An HTML attachment was scrubbed...
URL: 


--

[Spacewalk-list] Spacewalk's planned cert expiration in Aug (Can we simulate this?)

2019-07-19 Thread Jody McIvor 
Hi All,

In preparation for Redhat's dropping of Spacewalk support (And any further 
certificate renewals), we have updated all of our spacewalk servers to no less 
than 2.6. I have been (unsuccessfully, since I'm not sure exactly which file it 
is) attempting to "simulate" the cert expiration by:
 - Renaming what I thought was the cert file (Pretty sure I was wrong)
 - Forcing date/time change to 2019 on Spacewalk server (Everything seemed 
fine, but still not convinced.

My questions are:
 - Can someone enlighten me as to which file is truly the cert that will expire 
next month?
 - Was changing the time on the server my best bet for testing the effects of 
the cert failure?

Any input on this subject is appreciated, because if this doesn't go smoothly 
in Aug it WILL have a massive impact on company income until resolved.

Jody McIvor
Sr. Systems Administrator, Integration
Les Services D'intégration




-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of spacewalk-list-requ...@redhat.com
Sent: July 19, 2019 6:27 AM
To: spacewalk-list@redhat.com
Subject: Spacewalk-list Digest, Vol 134, Issue 13

Send Spacewalk-list mailing list submissions to
spacewalk-list@redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to
spacewalk-list-requ...@redhat.com

You can reach the person managing the list at
spacewalk-list-ow...@redhat.com

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Spacewalk-list digest..."


Today's Topics:

   1. Needs-Restarting shows perpetual reboot need afterKickstart
  (bryan.nor...@gmail.com)
   2. Re: Needs-Restarting shows perpetual reboot needafter
  Kickstart (bryan.nor...@gmail.com)
   3. Re: Update failing for no public key (Lubbers, Nicholas)


--

Message: 1
Date: Fri, 19 Jul 2019 06:11:15 +0200
From: 
To: 
Subject: [Spacewalk-list] Needs-Restarting shows perpetual reboot need
afterKickstart
Message-ID: <01d53de8$03363990$09a2acb0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"

Since I couldn't get around the Internal Server Error when attempting to 
Profile Sync, I found a work around using spacecmd and a post script during the 
Kickstart process.



Everything works great, with one exception.  After the provisioning is done, 
and the server is accessible, it shows that it needs a reboot.  After rebooting 
it, it still shows a reboot is needed.  It says (amongst other
components) that the kernel has been updated, yet uname -r shows it is running 
the kernel that it thinks it needs to reboot to use.



Have you all seen this before?  I'm stumped.no amount of googling has produced 
anything close to helpful.



Thanks!

Bryan

-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Fri, 19 Jul 2019 10:10:45 +0200
From: 
To: 
Subject: Re: [Spacewalk-list] Needs-Restarting shows perpetual reboot
needafter Kickstart
Message-ID: <000201d53e09$7890a1f0$69b1e5d0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"

It looks like it was a date/time issue.  When the system was kickstarted, it 
used the default GMT.  Somewhere in the update process after install, the time 
was corrected to GMT+2.  After 2 hours, I rebooted it again, and no it no 
longer thinks it needs to reboot to load a more recent kernel, and shows the 
system is up to date.



From: bryan.nor...@gmail.com 
Sent: Friday, July 19, 2019 06:11
To: spacewalk-list@redhat.com
Subject: Needs-Restarting shows perpetual reboot need after Kickstart



Since I couldn't get around the Internal Server Error when attempting to 
Profile Sync, I found a work around using spacecmd and a post script during the 
Kickstart process.



Everything works great, with one exception.  After the provisioning is done, 
and the server is accessible, it shows that it needs a reboot.  After rebooting 
it, it still shows a reboot is needed.  It says (amongst other
components) that the kernel has been updated, yet uname -r shows it is running 
the kernel that it thinks it needs to reboot to use.



Have you all seen this before?  I'm stumped.no amount of googling has produced 
anything close to helpful.



Thanks!

Bryan

-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 3
Date: Fri, 19 Jul 2019 13:27:14 +
From: "Lubbers, Nicholas" 
To: "spacewalk-list@redhat.com" 
Subject: Re: [Spacewalk-list] Update failing for no public key
Message-ID:

Content-Type: text/plain; charset="utf-8"

We started to see this on all our CentOS 7