Re: [Spacewalk-list] Repo syncs in Spacewalk 2.9 ERROR: 'NoneType' object has no attribute 'isdigit'

2019-01-24 Thread Michael Mraka
Kalchik, Jeffery:
> Good morning, all
> 
> I upgraded my spacewalk host from 2.8 to 2.9 on Monday morning, Jan. 21 
> (CentOS 6.10 64bit hosted,) I thought completely successfully.  However, 17 
> of my download channels/repositories are now showing the following error:
> 
> ERROR: 'NoneType' object has no attribute 'isdigit'
> 
> I haven't found a pattern, as multiple sources and EL5, EL6 and EL7 
> repositories are all showing the issue.  Not all are, just 17.  Manually 
> executing spacewalk-repo-sync with a '-vvv' option isn't giving any more 
> detail in the reposync channel logs, unfortunately.  The errors are displayed 
> after the errata count with no more detail.  I also haven't found anything 
> suspicious or smoking anywhere else.
> 
> Just to get even more odd, it looks like the first reposync on at least a 
> couple of these completed successfully after the upgrade, but has been 
> falling since.
> 
> I'm at a loss on how to proceed at this point.  None of the log files I've 
> spun through seem to have any other bearing on this, and I'm definitely not a 
> Python type to begin debugging the internals.
> 
> Is anyone else experiencing this?

This bug has been fixed yesterday, please update (spacewalk-backend-2.9.34-1).

Regards,

--
Michael Mráka
System Management Engineering, Red Hat

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

[Spacewalk-list] Taskomatic : Debian repodata generation issue

2019-01-24 Thread philippe bidault
Hi all,

Something strange is happening on my Spacewalk 2.9: taskomatic is
regenerating my Ubuntu repodatas some times to times:

INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,144
[Thread-3446] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
- File Modified Date:2019-01-24 03:05:24 CET
INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,144
[Thread-3446] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
- Channel Modified Date:2019-01-24 03:33:49
CET
INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,374
[Thread-3447] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
- Generating new DEB repository for channel
bionic-security
INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,544
[Thread-3446] INFO  com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
- Generating new DEB repository for channel
bionic-updates

I know that this is the purpose of taskomatic, but this is really annoying
as the "Packages" and "Release" files are "manually" generated, thus having
taskomatic triggering their re-generation just break everything.

I don't think remember having seen such behaviour in Spacewaok 2.8. Is
there a way to force taskomatic to ignore the DEB repodatas ?

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

Re: [Spacewalk-list] Repo syncs in Spacewalk 2.9 ERROR: 'NoneType' object has no attribute 'isdigit'

2019-01-24 Thread Kalchik, Jeffery
Good morning, all.

Applied the patch this morning, and ran a -vvv spacewalk-repo-sync against one 
of the problem children, I mean, channels.  Lot of "No checksum found for 
...Skipping Package" warnings, and two warnings that an errata was skipped due 
to the same error I experienced yesterday (at least they're now 
identified/identifiable.)

I can proceed with this.  Thanks for the efforts.

Jeff

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Michael Mraka
Sent: Thursday, January 24, 2019 3:27 AM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Repo syncs in Spacewalk 2.9 ERROR: 'NoneType' 
object has no attribute 'isdigit'

Kalchik, Jeffery:
> Good morning, all
>
> I upgraded my spacewalk host from 2.8 to 2.9 on Monday morning, Jan. 21 
> (CentOS 6.10 64bit hosted,) I thought completely successfully.  However, 17 
> of my download channels/repositories are now showing the following error:
>
> ERROR: 'NoneType' object has no attribute 'isdigit'
>
> I haven't found a pattern, as multiple sources and EL5, EL6 and EL7 
> repositories are all showing the issue.  Not all are, just 17.  Manually 
> executing spacewalk-repo-sync with a '-vvv' option isn't giving any more 
> detail in the reposync channel logs, unfortunately.  The errors are displayed 
> after the errata count with no more detail.  I also haven't found anything 
> suspicious or smoking anywhere else.
>
> Just to get even more odd, it looks like the first reposync on at least a 
> couple of these completed successfully after the upgrade, but has been 
> falling since.
>
> I'm at a loss on how to proceed at this point.  None of the log files I've 
> spun through seem to have any other bearing on this, and I'm definitely not a 
> Python type to begin debugging the internals.
>
> Is anyone else experiencing this?

This bug has been fixed yesterday, please update (spacewalk-backend-2.9.34-1).

Regards,

--
Michael Mráka
System Management Engineering, Red Hat

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Flistinfo%2Fspacewalk-list&data=01%7C01%7Cjdkalchik%40landolakes.com%7C5fbcbd84d3de4f84d7bc08d681de1e73%7C21ab97d78e754056826b9d8ec665c5a3%7C1&sdata=IKQb8DRSC%2FqTR%2Fi0lAf4fOKmi9H1rqHuGOi%2B5VIxIXE%3D&reserved=0
This message may contain confidential material from Land O'Lakes, Inc. (or its 
subsidiary) for the sole use of the intended recipient(s) and may not be 
reviewed, disclosed, copied, distributed or used by anyone other than the 
intended recipient(s). If you are not the intended recipient, please contact 
the sender by reply email and delete all copies of this message.

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

Re: [Spacewalk-list] copr-be.cloud.fedoraproject.org is down?

2019-01-24 Thread Kalchik, Jeffery
It’s apparently up here now:

--2019-01-24 07:10:08--  
https://copr-be.cloud.fedoraproject.org/results/%40spacewalkproject/spacewalk-2.8-client/epel-7-x86_64/repodata/repomd.xml
Resolving copr-be.cloud.fedoraproject.org... 209.132.184.48
Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3090 (3.0K) [text/xml]
Saving to: “/dev/null”

100%[==>] 3,090   --.-K/s   in 0s

2019-01-24 07:10:08 (35.6 MB/s) - “/dev/null” saved [3090/3090]

Jeff Kalchik
Server Support Managed Resources
Land O’Lakes

From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Zhou, Rui A. (NSB - CN/Shanghai)
Sent: Thursday, January 24, 2019 12:22 AM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] copr-be.cloud.fedoraproject.org is down?

This copr-be.cloud.fedoraproject.org seems to be down:

curl 
https://copr-be.cloud.fedoraproject.org/results/%40spacewalkproject/spacewalk-2.8-client/epel-7-x86_64/repodata/repomd.xml
curl: (7) Failed connect to copr-be.cloud.fedoraproject.org:443; Connection 
timed out

if it is true?
This message may contain confidential material from Land O'Lakes, Inc. (or its 
subsidiary) for the sole use of the intended recipient(s) and may not be 
reviewed, disclosed, copied, distributed or used by anyone other than the 
intended recipient(s). If you are not the intended recipient, please contact 
the sender by reply email and delete all copies of this message.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

[Spacewalk-list] Antwort: Re: Any chance to get "Schedule"-Jobs running on SW-Server?

2019-01-24 Thread Matthias Gruber
Hi!

Danke für den Hinweis, heheh ich hatte den SW zwar registirert, aber nie 
einen OSAD drauf gepackt... o.O erschien mir damals einfach nicht logisch, 
wenn er doch selbst der Server ist ;-)
Aber jetzt scheduled er auch sauber.

cheers
Matthias Gruber


METZLER 
Informationstechnologie

Matthias Gruber 
IT-Infrastruktur & -Betrieb

B. Metzler seel. Sohn & Co.
Kommanditgesellschaft auf Aktien
Untermainanlage 1
60329 Frankfurt am Main
Telefon (0 69) 21 04 - 43 30
Telefax (0 69) 21 04 - 40 40
mgru...@metzler.com
www.metzler.com



Von:"Kevin Olbrich" 
An: spacewalk-list@redhat.com
Kopie:  mgru...@metzler.com
Datum:  23.01.2019 13:50
Betreff:Re: [Spacewalk-list] Any chance to get "Schedule"-Jobs 
running on SW-Server?



Hi Matthias,

I did not try it but you could add / register the SW server itself to
the inventory.
This would give you the same features on the server that the clients can 
use.

Kind regards
Kevin

Am Mi., 23. Jan. 2019 um 10:57 Uhr schrieb Matthias Gruber
:
>
> Hi!
>
> Is there any chance to Schedule-Jobs via "system_runscript" working on a 
SpaceWalk-Server like it works on any Client?
> I know taskomatic is the "scheduler" within SpaceWalk, but that is not 
configurable.
>
> At the moment I use at to schedule dynamic processes, but thats a bit 
"tricky"
>
> Perhaps someone has a better solution, and not using something like 
obsidian or Automic?
>
> cheers
> Matthias
>
> 

> METZLER
> Informationstechnologie
>
> Matthias Gruber
> IT-Infrastruktur & -Betrieb
>
> B. Metzler seel. Sohn & Co.
> Kommanditgesellschaft auf Aktien
> Untermainanlage 1
> 60329 Frankfurt am Main
> Telefon (0 69) 21 04 - 43 30
> Telefax (0 69) 21 04 - 40 40
> mgru...@metzler.com
> www.metzler.com
>
>
> Persönlich haftende Gesellschafter: Harald Illy, Michael Klaus, 
Friedrich von Metzler, Emmerich Müller, Gerhard Wiesheu
> Vorsitzender des Aufsichtsrats: Dr. Christoph Schücking
> Sitz der Gesellschaft: Frankfurt am Main, Handelsregister-Nr. HRB 27 515
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene 
Empfänger sein, so bitten wir Sie höflich, dies unverzüglich dem Absender 
mitzuteilen und die Nachricht zu löschen. Es ist unzulässig, die Nachricht 
unbefugt weiterzuleiten oder zu kopieren. Da wir nicht die Echtheit oder 
Vollständigkeit der in dieser Nachricht enthaltenen Informationen 
garantieren oder zusichern können, sind die vorstehenden Ausführungen 
rechtlich nicht bindend. Eine Haftung hierfür wird ausgeschlossen.
> This message is confidential. If you are not the intended recipient, we 
kindly ask you to inform the sender and delete the information. Any 
unauthorised dissemination or copying hereof is prohibited. As we cannot 
guarantee or assure the genuineness or completeness of the information 
contained in this message, the statements set forth above are not legally 
binding. Accordingly we cannot accept any liability for their contents. 
___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list



 

Persönlich haftende Gesellschafter: Harald Illy, Michael Klaus, Friedrich von 
Metzler, Emmerich Müller, Gerhard Wiesheu
Vorsitzender des Aufsichtsrats: Dr. Christoph Schücking
Sitz der Gesellschaft: Frankfurt am Main, Handelsregister-Nr. HRB 27 515

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfänger 
sein, so bitten wir Sie höflich, dies unverzüglich dem Absender mitzuteilen und 
die Nachricht zu löschen. Es ist unzulässig, die Nachricht unbefugt 
weiterzuleiten oder zu kopieren. Da wir nicht die Echtheit oder Vollständigkeit 
der in dieser Nachricht enthaltenen Informationen garantieren oder zusichern 
können, sind die vorstehenden Ausführungen rechtlich nicht bindend. Eine 
Haftung hierfür wird ausgeschlossen.
This message is confidential. If you are not the intended recipient, we kindly 
ask you to inform the sender and delete the information. Any unauthorised 
dissemination or copying hereof is prohibited. As we cannot guarantee or assure 
the genuineness or completeness of the information contained in this message, 
the statements set forth above are not legally binding. Accordingly we cannot 
accept any liability for their contents.


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

[Spacewalk-list] Antwort: Re: Any chance to get "Schedule"-Jobs running on SW-Server?

2019-01-24 Thread Matthias Gruber
Apologizes for the german... didnt glimpse on the "To:" :-)

Again in some broken english :-)

I had the SW registred, but never ever installed an OSAD onto it, was 
illogical at that time I installed the Server, but now, he schedules as 
expected/whished.

Cheers
Matthias Gruber



METZLER 
Informationstechnologie

Matthias Gruber 
IT-Infrastruktur & -Betrieb

B. Metzler seel. Sohn & Co.
Kommanditgesellschaft auf Aktien
Untermainanlage 1
60329 Frankfurt am Main
Telefon (0 69) 21 04 - 43 30
Telefax (0 69) 21 04 - 40 40
mgru...@metzler.com
www.metzler.com



Von:"Kevin Olbrich" 
An: spacewalk-list@redhat.com
Kopie:  mgru...@metzler.com
Datum:  23.01.2019 13:50
Betreff:Re: [Spacewalk-list] Any chance to get "Schedule"-Jobs 
running on SW-Server?



Hi Matthias,

I did not try it but you could add / register the SW server itself to
the inventory.
This would give you the same features on the server that the clients can 
use.

Kind regards
Kevin

Am Mi., 23. Jan. 2019 um 10:57 Uhr schrieb Matthias Gruber
:
>
> Hi!
>
> Is there any chance to Schedule-Jobs via "system_runscript" working on a 
SpaceWalk-Server like it works on any Client?
> I know taskomatic is the "scheduler" within SpaceWalk, but that is not 
configurable.
>
> At the moment I use at to schedule dynamic processes, but thats a bit 
"tricky"
>
> Perhaps someone has a better solution, and not using something like 
obsidian or Automic?
>
> cheers
> Matthias
>
> 

> METZLER
> Informationstechnologie
>
> Matthias Gruber
> IT-Infrastruktur & -Betrieb
>
> B. Metzler seel. Sohn & Co.
> Kommanditgesellschaft auf Aktien
> Untermainanlage 1
> 60329 Frankfurt am Main
> Telefon (0 69) 21 04 - 43 30
> Telefax (0 69) 21 04 - 40 40
> mgru...@metzler.com
> www.metzler.com
>
>
> Persönlich haftende Gesellschafter: Harald Illy, Michael Klaus, 
Friedrich von Metzler, Emmerich Müller, Gerhard Wiesheu
> Vorsitzender des Aufsichtsrats: Dr. Christoph Schücking
> Sitz der Gesellschaft: Frankfurt am Main, Handelsregister-Nr. HRB 27 515
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene 
Empfänger sein, so bitten wir Sie höflich, dies unverzüglich dem Absender 
mitzuteilen und die Nachricht zu löschen. Es ist unzulässig, die Nachricht 
unbefugt weiterzuleiten oder zu kopieren. Da wir nicht die Echtheit oder 
Vollständigkeit der in dieser Nachricht enthaltenen Informationen 
garantieren oder zusichern können, sind die vorstehenden Ausführungen 
rechtlich nicht bindend. Eine Haftung hierfür wird ausgeschlossen.
> This message is confidential. If you are not the intended recipient, we 
kindly ask you to inform the sender and delete the information. Any 
unauthorised dissemination or copying hereof is prohibited. As we cannot 
guarantee or assure the genuineness or completeness of the information 
contained in this message, the statements set forth above are not legally 
binding. Accordingly we cannot accept any liability for their contents. 
___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list



 

Persönlich haftende Gesellschafter: Harald Illy, Michael Klaus, Friedrich von 
Metzler, Emmerich Müller, Gerhard Wiesheu
Vorsitzender des Aufsichtsrats: Dr. Christoph Schücking
Sitz der Gesellschaft: Frankfurt am Main, Handelsregister-Nr. HRB 27 515

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfänger 
sein, so bitten wir Sie höflich, dies unverzüglich dem Absender mitzuteilen und 
die Nachricht zu löschen. Es ist unzulässig, die Nachricht unbefugt 
weiterzuleiten oder zu kopieren. Da wir nicht die Echtheit oder Vollständigkeit 
der in dieser Nachricht enthaltenen Informationen garantieren oder zusichern 
können, sind die vorstehenden Ausführungen rechtlich nicht bindend. Eine 
Haftung hierfür wird ausgeschlossen.
This message is confidential. If you are not the intended recipient, we kindly 
ask you to inform the sender and delete the information. Any unauthorised 
dissemination or copying hereof is prohibited. As we cannot guarantee or assure 
the genuineness or completeness of the information contained in this message, 
the statements set forth above are not legally binding. Accordingly we cannot 
accept any liability for their contents.


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

[Spacewalk-list] rhnContentSource: label column sizing

2019-01-24 Thread Kalchik, Jeffery
Good morning, all.

Seems to be my week.  I'd like to revisit something I ran across better than 3 
years ago (tell me to file a bug report)

For reference:

https://github.com/spacewalkproject/spacewalk/commit/facb6866380eb36e7791340614f765b004e564bd
https://www.redhat.com/archives/spacewalk-list/2015-May/msg00109.html

This morning, I've discovered that going in through the web UI, when updating a 
repository (Channels/Manage Software Channels/Manage Repositories,) when a 
repository label is long, I'm getting the following error:


  *   Label cannot be greater than 64 characters (Note: double byte chars are 
not supported).
The underlying table appears to be correct, per the github commit:

Table "public.rhncontentsource"
   Column   |   Type   |   Modifiers
+--+
id | numeric  | not null
org_id | numeric  |
type_id| numeric  | not null
source_url | character varying(2048)  | not null
label  | character varying(128)   | not null
created| timestamp with time zone | not null default now()
modified   | timestamp with time zone | not null default now()

Looks to me that while the schema has been updated, the UI code hasn't been (or 
got rolled back, somehow)

Jeff Kalchik
Server Support Managed Resources
Land O'Lakes
This message may contain confidential material from Land O'Lakes, Inc. (or its 
subsidiary) for the sole use of the intended recipient(s) and may not be 
reviewed, disclosed, copied, distributed or used by anyone other than the 
intended recipient(s). If you are not the intended recipient, please contact 
the sender by reply email and delete all copies of this message.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Taskomatic : Debian repodata generation issue

2019-01-24 Thread Robert Paschedag
Am 24. Januar 2019 11:41:45 MEZ schrieb philippe bidault 
:
>Hi all,
>
>Something strange is happening on my Spacewalk 2.9: taskomatic is
>regenerating my Ubuntu repodatas some times to times:
>
>INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,144
>[Thread-3446] INFO 
>com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
>- File Modified Date:2019-01-24 03:05:24 CET
>INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,144
>[Thread-3446] INFO 
>com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
>- Channel Modified Date:2019-01-24 03:33:49
>CET
>INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,374
>[Thread-3447] INFO 
>com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
>- Generating new DEB repository for channel
>bionic-security
>INFO   | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,544
>[Thread-3446] INFO 
>com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter
>- Generating new DEB repository for channel
>bionic-updates
>
>I know that this is the purpose of taskomatic, but this is really
>annoying
>as the "Packages" and "Release" files are "manually" generated, thus
>having
>taskomatic triggering their re-generation just break everything.
>
>I don't think remember having seen such behaviour in Spacewaok 2.8. Is
>there a way to force taskomatic to ignore the DEB repodatas ?
>
>Regards,
>Philippe.

This always happens. You have to make sure, that you keep (transfer) the 
timestamp of the original Packages and Packages.gz file after you modified 
them. See "touch -r ..."

Robert


-- 
sent from my mobile device

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


Re: [Spacewalk-list] Errata...purpose?

2019-01-24 Thread Dave Thoms
Steve,



Thank you so much for the overview.  I'm surprised most people don't ask this 
question...or maybe they are just smarter than me.  😊



So errata is official which mean it only comes from Red Had?  Or do others 
(python, etc.) release official errata?




Dave T


From: spacewalk-list-boun...@redhat.com  on 
behalf of Steve Meier 
Sent: Tuesday, January 22, 2019 1:47:18 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Errata...purpose?

[ALERT]


Hi Dave,

since I have done a lot of stuff around Errata in the last few years
(see https://cefs.steve-meier.de), I wanted to share my knowledge.

Errata for RedHat/CentOS come in three "flavours": Security, Bugfix and
Enhancement. An erratum includes one or more RPMs that fixes one or
more bugs of that flavour.

Let's look at a specific example: CESA-2019:0049
(Source:
https://lists.centos.org/pipermail/centos-announce/2019-January/023143.html)

This erratum holds three important pieces of information for a sysadmin.
It's a security update, its severity is "Important" (which is the second
highest) and you need to install "systemd-219-62.el7_6.2.x86_64.rpm"
(plus
its dependencies also listed) to remediate this on your system.

When you run "yum check-update" on a standalone CentOS server, the only
information you will see is that "systemd-219-62.el7_6.2.x86_64.rpm"
(again,
plus dependencies) is available. The CentOS repositories do not contain
additional information about these updates (type, severity, release
date, etc.).

When you have Spacewalk and Errata loaded you will get a nice overview
of
how many systems have which Errata outstanding and what their type and
severity is. You will also be able to schedule the installation of the
those updates easily.

Especially in an environment where compliance (HIIPA, PCI, SOX, etc.) is
important, such an overview can be very valuable.

In my past job as a sysadmin I would go through this list each week and
put the installation of security updates into our change plan for the
coming week. Once the next audit rolled around we could just pull out
these plans and prove that we had kept up with security patching.

Let me know if you have further questions.

Kind regards,
   Steve


Am 2019-01-22 19:45, schrieb Dave Thoms:
> I have a Spacewalk 2.8 install on CentOS 7.x.  I've done a fair amount
> of digging to understand what errata actually is.  Why it's needed
> when you are already getting all updates.  Whether it applies to ALL
> repos or just the official ones for CentOS.  Does anyone have a handle
> on this - fundamentally speaking?
>
> Thanks in advance,
>
> Dave T. The information in this e-mail (including attachments, if any)
> is considered confidential and is intended only for the recipient(s)
> listed above. Any review, use, disclosure, distribution or copying of
> this e-mail is prohibited except by or on behalf of the intended
> recipient. If you have received this email in error, please notify me
> immediately by reply e-mail, delete this e-mail, and do not disclose
> its contents to anyone. Any opinions expressed in this e-mail are
> those of the individual and not necessarily the TruHearing group.
> Thank you.
> ___
> 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

[External Email] This email originated outside TruHearing. Please exercise 
caution with links and attachments. For assistance, please contact HelpDesk
--IT Ops Team

The information in this e-mail (including attachments, if any) is considered 
confidential and is intended only for the recipient(s) listed above. Any 
review, use, disclosure, distribution or copying of this e-mail is prohibited 
except by or on behalf of the intended recipient. If you have received this 
email in error, please notify me immediately by reply e-mail, delete this 
e-mail, and do not disclose its contents to anyone. Any opinions expressed in 
this e-mail are those of the individual and not necessarily the TruHearing 
group. Thank you.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Errata...purpose?

2019-01-24 Thread Dennis Pittman
Dave,

I think this is a great source of information for your questions?

https://petersouter.xyz/the-story-of-errata-for-centos/

— Dennis P

Get Outlook for iOS


From: spacewalk-list-boun...@redhat.com on behalf of Dave Thoms 

Sent: Thursday, January 24, 2019 6:50 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Errata...purpose?


Steve,



Thank you so much for the overview.  I'm surprised most people don't ask this 
question...or maybe they are just smarter than me.  😊



So errata is official which mean it only comes from Red Had?  Or do others 
(python, etc.) release official errata?




Dave T


From: spacewalk-list-boun...@redhat.com  on 
behalf of Steve Meier 
Sent: Tuesday, January 22, 2019 1:47:18 PM
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Errata...purpose?

[ALERT]


Hi Dave,

since I have done a lot of stuff around Errata in the last few years
(see 
https://cefs.steve-meier.de),
 I wanted to share my knowledge.

Errata for RedHat/CentOS come in three "flavours": Security, Bugfix and
Enhancement. An erratum includes one or more RPMs that fixes one or
more bugs of that flavour.

Let's look at a specific example: CESA-2019:0049
(Source:
https://lists.centos.org/pipermail/centos-announce/2019-January/023143.html)

This erratum holds three important pieces of information for a sysadmin.
It's a security update, its severity is "Important" (which is the second
highest) and you need to install "systemd-219-62.el7_6.2.x86_64.rpm"
(plus
its dependencies also listed) to remediate this on your system.

When you run "yum check-update" on a standalone CentOS server, the only
information you will see is that "systemd-219-62.el7_6.2.x86_64.rpm"
(again,
plus dependencies) is available. The CentOS repositories do not contain
additional information about these updates (type, severity, release
date, etc.).

When you have Spacewalk and Errata loaded you will get a nice overview
of
how many systems have which Errata outstanding and what their type and
severity is. You will also be able to schedule the installation of the
those updates easily.

Especially in an environment where compliance (HIIPA, PCI, SOX, etc.) is
important, such an overview can be very valuable.

In my past job as a sysadmin I would go through this list each week and
put the installation of security updates into our change plan for the
coming week. Once the next audit rolled around we could just pull out
these plans and prove that we had kept up with security patching.

Let me know if you have further questions.

Kind regards,
   Steve


Am 2019-01-22 19:45, schrieb Dave Thoms:
> I have a Spacewalk 2.8 install on CentOS 7.x.  I've done a fair amount
> of digging to understand what errata actually is.  Why it's needed
> when you are already getting all updates.  Whether it applies to ALL
> repos or just the official ones for CentOS.  Does anyone have a handle
> on this - fundamentally speaking?
>
> Thanks in advance,
>
> Dave T. The information in this e-mail (including attachments, if any)
> is considered confidential and is intended only for the recipient(s)
> listed above. Any review, use, disclosure, distribution or copying of
> this e-mail is prohibited except by or on behalf of the intended
> recipient. If you have received this email in error, please notify me
> immediately by reply e-mail, delete this e-mail, and do not disclose
> its contents to anyone. Any opinions expressed in this e-mail are
> those of the individual and not necessarily the TruHearing group.
> Thank you.
> ___
> 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