EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata possibly incorrect

[John Griffin]

We now use Red Hat Satellite 6.3 and have it synchronizing to
https://dl.fedoraproject.org/pub/epel/6Server/

Recent updates to munin-node and munin-common require conntrack-tools x86_64
0.9.13-3.el6.

The conntrack-tools  x86_64 0.9.13-3.el6 was release in May 2014, based on rpm -qip, and
is in our synchronized EPEL content view on our Satellite. 

We use content view date filters to only select errata (patches) up to a specific date
(based on our patch cycle) and publish new content views based on said dates. We stumbled
upon the issue that the conntrack-tools x86_64 0.9.13-3.el6 package not being included in
the content view, even though it existed in the repository, and our date based content
filter should have encompassed the release date of the package. This caused yum update to
fail for the munin updates, as the prerequisite could not be satisfied.

Curious if there is indeed something amiss with this packages metadata, and also if other
EPEL packages suffer the same fate. We are concerned that we will not be able to rely on
the veracity of EPEL packages and will have to mitigate this in some fashion.

[Stephen John Smoogen]

On Wed, 31 Oct 2018 at 16:01, John Griffin <jgriffin(a)samhealth.org&gt; wrote:
>  We now use Red Hat Satellite 6.3 and have it synchronizing to
> https://dl.fedoraproject.org/pub/epel/6Server/
>
>  Recent updates to munin-node and munin-common require conntrack-tools x86_64
> 0.9.13-3.el6.
>
>  The conntrack-tools  x86_64 0.9.13-3.el6 was release in May 2014, based on rpm -qip, and
> is in our synchronized EPEL content view on our Satellite.
>
>  We use content view date filters to only select errata (patches) up to a specific date
> (based on our patch cycle) and publish new content views based on said dates. We stumbled
> upon the issue that the conntrack-tools x86_64 0.9.13-3.el6 package not being included in
> the content view, even though it existed in the repository, and our date based content
> filter should have encompassed the release date of the package. This caused yum update to
> fail for the munin updates, as the prerequisite could not be satisfied. 
I need more information like what you are exactly seeing. The
conntrack-tools is in the repository and can be downloaded and
installed via yum and reposync.

>  Curious if there is indeed something amiss with this packages
> metadata, and also if other EPEL packages suffer the same fate. We are concerned that we
> will not be able to rely on the veracity of EPEL packages and will have to mitigate this
> in some fashion.
>
>
>  _______________________________________________
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 


-- 
Stephen J Smoogen.

[John Griffin]

Hello Stephen,



Yes, we have the conntrack-tools in our Red Hat Satellite repository, and we can apply it
outside of our Satellite process; by manually copying the rpm to each server and
installing outside of our process.



The issue is the interworking of the metatdata in the conntrack-tools RPM and Red Hat
Satellite date filters for Content Views. Not sure how familiar you are with Red Hat
Satellite, but the data filters are the primary method used to create a cyclical patching
schedule and thus patch sets based on date.



In Red Hat Satellite, if I specify any date inclusion (Like from January 1, 1970 - October
12, 2018) and point it at the EPEL6 repository the filter does not pick up the
conntrack-tools. I opened support case with Red Hat, and with their assistance we have a
work around, where we don't specify any Satellite date filters for the EPEL
repositories (i.e. Get Everything no matter when released) and yes still keep the
Satellite date filters on the official Red Hat repositories used to create the combined 
Satellite content view.



However this work-around does not allow us to recreate a patch content view of EPEL
product or patches of any date other than 'today'. Without a date filter we get
all EPEL content and patches. This does not work with our Patching paradigm, as we base
patch sets on Date. We then use life-cycle management to promote a patch set to Production
after it has been vetted on Dev then Test.



Red Hat does not support EPEL, and indicated this is not a Satellite issue but a RPM
metadata issue with EPEL release process.



Let me know if you need further clarification.



Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  







-----Original Message-----
From: Stephen John Smoogen <smooge(a)gmail.com
>  
Sent: Wednesday, October 31, 2018 2:14 PM
To: epel-devel(a)lists.fedoraproject.org
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata possibly
incorrect



WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.

On Wed, 31 Oct 2018 at 16:01, John Griffin
<[e-mail]<mailto:[e-mail]>> wrote:

>  
>  We now use Red Hat Satellite 6.3 and have it synchronizing to
>  
>  https://dl.fedoraproject.org/pub/epel/6Server/
>  
>  
>  Recent updates to munin-node and munin-common require conntrack-tools
> x86_64 0.9.13-3.el6.
>  
>  
>  The conntrack-tools  x86_64 0.9.13-3.el6 was release in May 2014,
> based on rpm -qip, and is in our synchronized EPEL content view on our Satellite.
>  
>  
>  We use content view date filters to only select errata (patches) up
> to a specific date (based on our patch cycle) and publish new content views based on said
> dates. We stumbled upon the issue that the conntrack-tools x86_64 0.9.13-3.el6 package not
> being included in the content view, even though it existed in the repository, and our date
> based content filter should have encompassed the release date of the package. This caused
> yum update to fail for the munin updates, as the prerequisite could not be satisfied.
>  


I need more information like what you are exactly seeing. The conntrack-tools is in the
repository and can be downloaded and installed via yum and reposync.



>  Curious if there is indeed something amiss with this packages
> metadata, and also if other EPEL packages suffer the same fate. We are concerned that we
> will not be able to rely on the veracity of EPEL packages and will have to mitigate this
> in some fashion.
>  
>  
>  
>  _______________________________________________
>  
> epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
>  To unsubscribe send an email to
>  
>
[e-mail]<mailto:[e-mail]
>  
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  
>  List Guidelines:
>  
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  
>  List Archives:
>  
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  
>  roject.org
>  






--

Stephen J Smoogen.

_______________________________________________

epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]
>  
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...



To report this email as SPAM, please forward it to
[e-mail]<mailto:[e-mail]
>  
________________________________

Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

[Stephen John Smoogen]

On Thu, 1 Nov 2018 at 16:46, John Griffin <jgriffin(a)samhealth.org&gt; wrote:

>  Hello Stephen,
>
>
>
>  Yes, we have the conntrack-tools in our Red Hat Satellite repository, and
>  we can apply it outside of our Satellite process; by manually copying the
>  rpm to each server and installing outside of our process.
>
>
>
>  The issue is the interworking of the metatdata in the conntrack-tools RPM
>  and Red Hat Satellite date filters for Content Views. Not sure how familiar
>  you are with Red Hat Satellite, but the data filters are the primary method
>  used to create a cyclical patching schedule and thus patch sets based on
>  date.
>
>
>
>  In Red Hat Satellite, if I specify any date inclusion (Like from January
>  1, 1970 - October 12, 2018) and point it at the EPEL6 repository the filter
>  does not pick up the conntrack-tools. I opened support case with Red Hat,
>  and with their assistance we have a work around, where we don't specify any
>  Satellite date filters for the EPEL repositories (i.e. Get Everything no
>  matter when released) and yes still keep the Satellite date filters on the
>  official Red Hat repositories used to create the combined  Satellite
>  content view.
>
>
>
>  However this work-around does not allow us to recreate a patch content
>  view of EPEL product or patches of any date other than 'today'. Without a
>  date filter we get all EPEL content and patches. This does not work with
>  our Patching paradigm, as we base patch sets on Date. We then use
>  life-cycle management to promote a patch set to Production after it has
>  been vetted on Dev then Test.
>
>
>
>  Red Hat does not support EPEL, and indicated this is not a Satellite issue
>  but a RPM metadata issue with EPEL release process.
>
>
>  
I will check but I am not sure it is a problem we can solve quickly as I
don't know how Satellite categorizes dates currently. Do you also mirror
anything from other non Red Hat Network repositories and do they have the
problem also? [I am mostly looking to see if we are not setting something
up we should or not]



>  Let me know if you need further clarification.
>
>
>
>  Best Regards,
>
>  [image: cid:image005.jpg@01D24A1F.439697B0]
>
>  *John Griffin *|* Infrastructure Architect*
>
>  815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
>
>  P 541-768-4707
>
>  *jgriffin(a)samhealth.org <jgriffin(a)samhealth.org&gt;*
>
>
>
>
>
>
>
>
>
>  -----Original Message-----
>  From: Stephen John Smoogen <smooge(a)gmail.com&gt;
>  Sent: Wednesday, October 31, 2018 2:14 PM
>  To: epel-devel(a)lists.fedoraproject.org
>  Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64
>  metadata possibly incorrect
>
>
>
>  WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY
>  LINKS OR OPEN ATTACHMENTS unless you recognize the sender and know the
>  contents are safe.
>
>  On Wed, 31 Oct 2018 at 16:01, John Griffin <jgriffin(a)samhealth.org&gt; wrote:
>
>  >
>
>  > We now use Red Hat Satellite 6.3 and have it synchronizing to
>
>  > https://dl.fedoraproject.org/pub/epel/6Server/
>
>  >
>
>  > Recent updates to munin-node and munin-common require conntrack-tools
>  x86_64 0.9.13-3.el6.
>
>  >
>
>  > The conntrack-tools  x86_64 0.9.13-3.el6 was release in May 2014, based
>  on rpm -qip, and is in our synchronized EPEL content view on our Satellite.
>
>  >
>
>  > We use content view date filters to only select errata (patches) up to a
>  specific date (based on our patch cycle) and publish new content views
>  based on said dates. We stumbled upon the issue that the conntrack-tools
>  x86_64 0.9.13-3.el6 package not being included in the content view, even
>  though it existed in the repository, and our date based content filter
>  should have encompassed the release date of the package. This caused yum
>  update to fail for the munin updates, as the prerequisite could not be
>  satisfied.
>
>
>
>  I need more information like what you are exactly seeing. The
>  conntrack-tools is in the repository and can be downloaded and installed
>  via yum and reposync.
>
>
>
>  > Curious if there is indeed something amiss with this packages metadata,
>  and also if other EPEL packages suffer the same fate. We are concerned that
>  we will not be able to rely on the veracity of EPEL packages and will have
>  to mitigate this in some fashion.
>
>  >
>
>  >
>
>  > _______________________________________________
>
>  > epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>
>  > To unsubscribe send an email to
>
>  > epel-devel-leave(a)lists.fedoraproject.org
>
>  > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>
>  > List Guidelines:
>
>  > https://fedoraproject.org/wiki/Mailing_list_guidelines
>
>  > List Archives:
>
>  > https://lists.fedoraproject.org/archives/list/[e-mail]
>
>  > roject.org
>
>
>
>
>
>
>
>  --
>
>  Stephen J Smoogen.
>
>  _______________________________________________
>
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>
>  To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
>
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>
>
>
>  To report this email as SPAM, please forward it to spam(a)forcepoint.com
>
>  ------------------------------
>
>  Confidentiality Notice: This e-mail message, including any attachments, is
>  for the sole use of the intended recipient(s) and may contain confidential
>  and privileged information. Any unauthorized review, use, disclosure or
>  distribution is prohibited. If you are not the intended recipient, please
>  contact the sender by reply e-mail and destroy all copies of the original
>  message.
>  _______________________________________________
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  

-- 
Stephen J Smoogen.

[John Griffin]

Hello Stephen,

We mirror the EPEL5 and EPEL7 repositories, but I really don’t know if there are other
issues with those or EPEL6. The only reason I stumbled upon this one was due to the fact
that the munin update in Sept 2018 now requires conntrack-tools. There may be others, and
this also maybe be the only one.

I will request from RH the technical details they use when applying date filters in
Satellite, maybe with that I can scan the other RPM’s in our mirrors for other hits.

Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  


From: Stephen John Smoogen <smooge(a)gmail.com
>  
Sent: Thursday, November 1, 2018 2:04 PM
To: epel-devel(a)lists.fedoraproject.org
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata possibly
incorrect





WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.




On Thu, 1 Nov 2018 at 16:46, John Griffin
<[e-mail]<mailto:[e-mail]>> wrote:

Hello Stephen,



Yes, we have the conntrack-tools in our Red Hat Satellite repository, and we can apply it
outside of our Satellite process; by manually copying the rpm to each server and
installing outside of our process.



The issue is the interworking of the metatdata in the conntrack-tools RPM and Red Hat
Satellite date filters for Content Views. Not sure how familiar you are with Red Hat
Satellite, but the data filters are the primary method used to create a cyclical patching
schedule and thus patch sets based on date.



In Red Hat Satellite, if I specify any date inclusion (Like from January 1, 1970 - October
12, 2018) and point it at the EPEL6 repository the filter does not pick up the
conntrack-tools. I opened support case with Red Hat, and with their assistance we have a
work around, where we don't specify any Satellite date filters for the EPEL
repositories (i.e. Get Everything no matter when released) and yes still keep the
Satellite date filters on the official Red Hat repositories used to create the combined 
Satellite content view.



However this work-around does not allow us to recreate a patch content view of EPEL
product or patches of any date other than 'today'. Without a date filter we get
all EPEL content and patches. This does not work with our Patching paradigm, as we base
patch sets on Date. We then use life-cycle management to promote a patch set to Production
after it has been vetted on Dev then Test.



Red Hat does not support EPEL, and indicated this is not a Satellite issue but a RPM
metadata issue with EPEL release process.


I will check but I am not sure it is a problem we can solve quickly as I don't know
how Satellite categorizes dates currently. Do you also mirror anything from other non Red
Hat Network repositories and do they have the problem also? [I am mostly looking to see if
we are not setting something up we should or not]



Let me know if you need further clarification.



Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  







-----Original Message-----
From: Stephen John Smoogen <[e-mail]<mailto:[e-mail]>
>  
Sent: Wednesday, October 31, 2018 2:14 PM
To: [e-mail]<mailto:[e-mail]
>  
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata
possibly incorrect



WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.

On Wed, 31 Oct 2018 at 16:01, John Griffin
<[e-mail]<mailto:[e-mail]>> wrote:

>  
>  We now use Red Hat Satellite 6.3 and have it synchronizing to
>  
>  https://dl.fedoraproject.org/pub/epel/6Server/
>  
>  
>  Recent updates to munin-node and munin-common require conntrack-tools
> x86_64 0.9.13-3.el6.
>  
>  
>  The conntrack-tools  x86_64 0.9.13-3.el6 was release in May 2014,
> based on rpm -qip, and is in our synchronized EPEL content view on our Satellite.
>  
>  
>  We use content view date filters to only select errata (patches) up
> to a specific date (based on our patch cycle) and publish new content views based on said
> dates. We stumbled upon the issue that the conntrack-tools x86_64 0.9.13-3.el6 package not
> being included in the content view, even though it existed in the repository, and our date
> based content filter should have encompassed the release date of the package. This caused
> yum update to fail for the munin updates, as the prerequisite could not be satisfied.
>  


I need more information like what you are exactly seeing. The conntrack-tools is in the
repository and can be downloaded and installed via yum and reposync.



>  Curious if there is indeed something amiss with this packages
> metadata, and also if other EPEL packages suffer the same fate. We are concerned that we
> will not be able to rely on the veracity of EPEL packages and will have to mitigate this
> in some fashion.
>  
>  
>  
>  _______________________________________________
>  
> epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
>  To unsubscribe send an email to
>  
>
[e-mail]<mailto:[e-mail]
>  
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  
>  List Guidelines:
>  
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  
>  List Archives:
>  
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  
> roject.org<http://roject.org
>  






--

Stephen J Smoogen.

_______________________________________________

epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]
>  
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...



To report this email as SPAM, please forward it to
[e-mail]<mailto:[e-mail]
>  
________________________________

Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
_______________________________________________
epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]
>  
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...


--
Stephen J Smoogen.




Click
here<https://cdmzfp01-acg.int.samhealth.net:9449/pem/pages/digestProcess/digestProcess.jsf?content=41ae761a454f225b1b241bae58c1ec716125e4d51c4b1146ebd567275ac01bcb79d2f3f9146493f7f9ccac2416078300d70d4631dfc87e676fa4a64f907f21c71f5e342b0f1a0211a8538d2f21c4d889baf15dc0763ee412872247b91d9175c217ba4e6f1bf1f50e74f4e4a7d0e24504a90e2ff391dd451a41d050d6b24f5d1fdbd33fb9c13f32797059201a2cb940aa>
to report this email as spam

[John Griffin]

Hello Stephen,

Here is RH’s reply on the query as to how RH Satellite parses RPMs for date base
filters.


Hi John, I got some information for you. Errata filter based on date does not scan RPMs,
but scan errata (update or create) date and exclude/include all rpms which this specific
errata contains. Does this help in the process?

Re:
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  


From: John Griffin
Sent: Monday, November 5, 2018 8:34 AM
To: EPEL Development List <epel-devel(a)lists.fedoraproject.org
>  
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata
possibly incorrect





WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.



Hello Stephen,

We mirror the EPEL5 and EPEL7 repositories, but I really don’t know if there are other
issues with those or EPEL6. The only reason I stumbled upon this one was due to the fact
that the munin update in Sept 2018 now requires conntrack-tools. There may be others, and
this also maybe be the only one.

I will request from RH the technical details they use when applying date filters in
Satellite, maybe with that I can scan the other RPM’s in our mirrors for other hits.

Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  


From: Stephen John Smoogen <[e-mail]<mailto:[e-mail]>
>  
Sent: Thursday, November 1, 2018 2:04 PM
To: [e-mail]<mailto:[e-mail]
>  
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata
possibly incorrect





WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.




On Thu, 1 Nov 2018 at 16:46, John Griffin
<[e-mail]<mailto:[e-mail]>> wrote:

Hello Stephen,



Yes, we have the conntrack-tools in our Red Hat Satellite repository, and we can apply it
outside of our Satellite process; by manually copying the rpm to each server and
installing outside of our process.



The issue is the interworking of the metatdata in the conntrack-tools RPM and Red Hat
Satellite date filters for Content Views. Not sure how familiar you are with Red Hat
Satellite, but the data filters are the primary method used to create a cyclical patching
schedule and thus patch sets based on date.



In Red Hat Satellite, if I specify any date inclusion (Like from January 1, 1970 - October
12, 2018) and point it at the EPEL6 repository the filter does not pick up the
conntrack-tools. I opened support case with Red Hat, and with their assistance we have a
work around, where we don't specify any Satellite date filters for the EPEL
repositories (i.e. Get Everything no matter when released) and yes still keep the
Satellite date filters on the official Red Hat repositories used to create the combined 
Satellite content view.



However this work-around does not allow us to recreate a patch content view of EPEL
product or patches of any date other than 'today'. Without a date filter we get
all EPEL content and patches. This does not work with our Patching paradigm, as we base
patch sets on Date. We then use life-cycle management to promote a patch set to Production
after it has been vetted on Dev then Test.



Red Hat does not support EPEL, and indicated this is not a Satellite issue but a RPM
metadata issue with EPEL release process.


I will check but I am not sure it is a problem we can solve quickly as I don't know
how Satellite categorizes dates currently. Do you also mirror anything from other non Red
Hat Network repositories and do they have the problem also? [I am mostly looking to see if
we are not setting something up we should or not]



Let me know if you need further clarification.



Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  







-----Original Message-----
From: Stephen John Smoogen <[e-mail]<mailto:[e-mail]>
>  
Sent: Wednesday, October 31, 2018 2:14 PM
To: [e-mail]<mailto:[e-mail]
>  
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata
possibly incorrect



WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.

On Wed, 31 Oct 2018 at 16:01, John Griffin
<[e-mail]<mailto:[e-mail]>> wrote:

>  
>  We now use Red Hat Satellite 6.3 and have it synchronizing to
>  
>  https://dl.fedoraproject.org/pub/epel/6Server/
>  
>  
>  Recent updates to munin-node and munin-common require conntrack-tools
> x86_64 0.9.13-3.el6.
>  
>  
>  The conntrack-tools  x86_64 0.9.13-3.el6 was release in May 2014,
> based on rpm -qip, and is in our synchronized EPEL content view on our Satellite.
>  
>  
>  We use content view date filters to only select errata (patches) up
> to a specific date (based on our patch cycle) and publish new content views based on said
> dates. We stumbled upon the issue that the conntrack-tools x86_64 0.9.13-3.el6 package not
> being included in the content view, even though it existed in the repository, and our date
> based content filter should have encompassed the release date of the package. This caused
> yum update to fail for the munin updates, as the prerequisite could not be satisfied.
>  


I need more information like what you are exactly seeing. The conntrack-tools is in the
repository and can be downloaded and installed via yum and reposync.



>  Curious if there is indeed something amiss with this packages
> metadata, and also if other EPEL packages suffer the same fate. We are concerned that we
> will not be able to rely on the veracity of EPEL packages and will have to mitigate this
> in some fashion.
>  
>  
>  
>  _______________________________________________
>  
> epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
>  To unsubscribe send an email to
>  
>
[e-mail]<mailto:[e-mail]
>  
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  
>  List Guidelines:
>  
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  
>  List Archives:
>  
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  
> roject.org<http://roject.org
>  






--

Stephen J Smoogen.

_______________________________________________

epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]
>  
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...



To report this email as SPAM, please forward it to
[e-mail]<mailto:[e-mail]
>  
________________________________

Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
_______________________________________________
epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]
>  
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...


--
Stephen J Smoogen.




Click
here<https://cdmzfp01-acg.int.samhealth.net:9449/pem/pages/digestProcess/digestProcess.jsf?content=41ae761a454f225b1b241bae58c1ec716125e4d51c4b1146ebd567275ac01bcb79d2f3f9146493f7f9ccac2416078300d70d4631dfc87e676fa4a64f907f21c71f5e342b0f1a0211a8538d2f21c4d889baf15dc0763ee412872247b91d9175c217ba4e6f1bf1f50e74f4e4a7d0e24504a90e2ff391dd451a41d050d6b24f5d1fdbd33fb9c13f32797059201a2cb940aa>
to report this email as spam







Click
here<https://cdmzfp01-acg.int.samhealth.net:9449/pem/pages/digestProcess/digestProcess.jsf?content=41ae761a454f225b90d161d3e5ac76d6b95fcde3c3d16ab3605c0a90d3c184bb7d3ead764c2f4eaae5b5d1d911f5b4624b1e860b23cf12ef86128f7106cd14bfdfbc704a76e576026dc5d2a224cdd9bb540919d7a0b0019077ef50b81a86c9e78c87bd64ce01a394c48cdd3c0dc7c261d73c890d17febab8bb4b9879df9a58e2291753bfdfcdec197cd00ee1d69458ba>
to report this email as spam

[John Griffin]

Hello Stephen,

What else can I do or provide to move this issue along.

Best regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  


From: John Griffin
Sent: Monday, November 19, 2018 8:47 AM
To: EPEL Development List <epel-devel(a)lists.fedoraproject.org
>  
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata
possibly incorrect





WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.



Hello Stephen,

Here is RH’s reply on the query as to how RH Satellite parses RPMs for date base
filters.


Hi John, I got some information for you. Errata filter based on date does not scan RPMs,
but scan errata (update or create) date and exclude/include all rpms which this specific
errata contains. Does this help in the process?

Re:
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  


From: John Griffin
Sent: Monday, November 5, 2018 8:34 AM
To: EPEL Development List
<[e-mail]<mailto:[e-mail]>
>  
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata
possibly incorrect





WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.



Hello Stephen,

We mirror the EPEL5 and EPEL7 repositories, but I really don’t know if there are other
issues with those or EPEL6. The only reason I stumbled upon this one was due to the fact
that the munin update in Sept 2018 now requires conntrack-tools. There may be others, and
this also maybe be the only one.

I will request from RH the technical details they use when applying date filters in
Satellite, maybe with that I can scan the other RPM’s in our mirrors for other hits.

Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  


From: Stephen John Smoogen <[e-mail]<mailto:[e-mail]>
>  
Sent: Thursday, November 1, 2018 2:04 PM
To: [e-mail]<mailto:[e-mail]
>  
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata
possibly incorrect





WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.




On Thu, 1 Nov 2018 at 16:46, John Griffin
<[e-mail]<mailto:[e-mail]>> wrote:

Hello Stephen,



Yes, we have the conntrack-tools in our Red Hat Satellite repository, and we can apply it
outside of our Satellite process; by manually copying the rpm to each server and
installing outside of our process.



The issue is the interworking of the metatdata in the conntrack-tools RPM and Red Hat
Satellite date filters for Content Views. Not sure how familiar you are with Red Hat
Satellite, but the data filters are the primary method used to create a cyclical patching
schedule and thus patch sets based on date.



In Red Hat Satellite, if I specify any date inclusion (Like from January 1, 1970 - October
12, 2018) and point it at the EPEL6 repository the filter does not pick up the
conntrack-tools. I opened support case with Red Hat, and with their assistance we have a
work around, where we don't specify any Satellite date filters for the EPEL
repositories (i.e. Get Everything no matter when released) and yes still keep the
Satellite date filters on the official Red Hat repositories used to create the combined 
Satellite content view.



However this work-around does not allow us to recreate a patch content view of EPEL
product or patches of any date other than 'today'. Without a date filter we get
all EPEL content and patches. This does not work with our Patching paradigm, as we base
patch sets on Date. We then use life-cycle management to promote a patch set to Production
after it has been vetted on Dev then Test.



Red Hat does not support EPEL, and indicated this is not a Satellite issue but a RPM
metadata issue with EPEL release process.


I will check but I am not sure it is a problem we can solve quickly as I don't know
how Satellite categorizes dates currently. Do you also mirror anything from other non Red
Hat Network repositories and do they have the problem also? [I am mostly looking to see if
we are not setting something up we should or not]



Let me know if you need further clarification.



Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
[e-mail]<mailto:[e-mail]
>  







-----Original Message-----
From: Stephen John Smoogen <[e-mail]<mailto:[e-mail]>
>  
Sent: Wednesday, October 31, 2018 2:14 PM
To: [e-mail]<mailto:[e-mail]
>  
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata
possibly incorrect



WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR OPEN
ATTACHMENTS unless you recognize the sender and know the contents are safe.

On Wed, 31 Oct 2018 at 16:01, John Griffin
<[e-mail]<mailto:[e-mail]>> wrote:

>  
>  We now use Red Hat Satellite 6.3 and have it synchronizing to
>  
>  https://dl.fedoraproject.org/pub/epel/6Server/
>  
>  
>  Recent updates to munin-node and munin-common require conntrack-tools
> x86_64 0.9.13-3.el6.
>  
>  
>  The conntrack-tools  x86_64 0.9.13-3.el6 was release in May 2014,
> based on rpm -qip, and is in our synchronized EPEL content view on our Satellite.
>  
>  
>  We use content view date filters to only select errata (patches) up
> to a specific date (based on our patch cycle) and publish new content views based on said
> dates. We stumbled upon the issue that the conntrack-tools x86_64 0.9.13-3.el6 package not
> being included in the content view, even though it existed in the repository, and our date
> based content filter should have encompassed the release date of the package. This caused
> yum update to fail for the munin updates, as the prerequisite could not be satisfied.
>  


I need more information like what you are exactly seeing. The conntrack-tools is in the
repository and can be downloaded and installed via yum and reposync.



>  Curious if there is indeed something amiss with this packages
> metadata, and also if other EPEL packages suffer the same fate. We are concerned that we
> will not be able to rely on the veracity of EPEL packages and will have to mitigate this
> in some fashion.
>  
>  
>  
>  _______________________________________________
>  
> epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
>  To unsubscribe send an email to
>  
>
[e-mail]<mailto:[e-mail]
>  
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  
>  List Guidelines:
>  
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  
>  List Archives:
>  
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  
> roject.org<http://roject.org
>  






--

Stephen J Smoogen.

_______________________________________________

epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]
>  
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...



To report this email as SPAM, please forward it to
[e-mail]<mailto:[e-mail]
>  
________________________________

Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
_______________________________________________
epel-devel mailing list --
[e-mail]<mailto:[e-mail]
>  
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]
>  
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...


--
Stephen J Smoogen.




Click
here<https://cdmzfp01-acg.int.samhealth.net:9449/pem/pages/digestProcess/digestProcess.jsf?content=41ae761a454f225b1b241bae58c1ec716125e4d51c4b1146ebd567275ac01bcb79d2f3f9146493f7f9ccac2416078300d70d4631dfc87e676fa4a64f907f21c71f5e342b0f1a0211a8538d2f21c4d889baf15dc0763ee412872247b91d9175c217ba4e6f1bf1f50e74f4e4a7d0e24504a90e2ff391dd451a41d050d6b24f5d1fdbd33fb9c13f32797059201a2cb940aa>
to report this email as spam







Click
here<https://cdmzfp01-acg.int.samhealth.net:9449/pem/pages/digestProcess/digestProcess.jsf?content=41ae761a454f225b90d161d3e5ac76d6b95fcde3c3d16ab3605c0a90d3c184bb7d3ead764c2f4eaae5b5d1d911f5b4624b1e860b23cf12ef86128f7106cd14bfdfbc704a76e576026dc5d2a224cdd9bb540919d7a0b0019077ef50b81a86c9e78c87bd64ce01a394c48cdd3c0dc7c261d73c890d17febab8bb4b9879df9a58e2291753bfdfcdec197cd00ee1d69458ba>
to report this email as spam







Click
here<https://cdmzfp01-acg.int.samhealth.net:9449/pem/pages/digestProcess/digestProcess.jsf?content=41ae761a454f225ba1c91524bc972b8ac58d0674259c52a5ca93b8261b3d847f7d3ead764c2f4eaae5b5d1d911f5b4624b1e860b23cf12ef86128f7106cd14bfdfbc704a76e576026dc5d2a224cdd9bb540919d7a0b0019077ef50b81a86c9e78c87bd64ce01a394c48cdd3c0dc7c261d73c890d17febab8bb4b9879df9a58e2291753bfdfcdec197cd00ee1d69458ba>
to report this email as spam