2:11 p.m.
Do we want nagios to be upgraded to 3.0? The 2.x branch is still being
maintained upstream and we're still using it in Fedora. There would be a
requirement to change some of the config files, but nothing horrible.
-Mike
2:37 p.m.
On Mon, 2009-03-30 at 14:11 -0500, Mike McGrath wrote:
Do we want nagios to be upgraded to 3.0? The 2.x branch is still
being
maintained upstream and we're still using it in Fedora. There would be a
requirement to change some of the config files, but nothing horrible.
It could always be package labeled as "nagios3" for now, and co-exist
with "nagios" (2.x) until 2.x is no longer developed upstream. Just a
suggestion.
--
Bryan J Smith Senior Consultant Red Hat GPS SE US
mailto:bjs@redhat.com +1 (407) 489-7013 (Mobile)
mailto:b.j.smith@ieee.org (non-RH/ext to Blackberry)
--------------------------------------------------------
You already know Red Hat as the entity dedicated to 100%
no-IP-strings-attached, community software development.
But do you know where CIOs rate Red Hat versus other
software and services firms for their own, direct needs?
It's no comparison: http://www.redhat.com/promo/vendor/
2:42 p.m.
I like that idea. While I do think its cool to run updates and be
pleasantly surprised by brand new versions of software, I can see how
some people might not be so receptive in an enterprise environment.
-Adam
On Mon, Mar 30, 2009 at 2:37 PM, Bryan J Smith <bjs(a)redhat.com> wrote:
On Mon, 2009-03-30 at 14:11 -0500, Mike McGrath wrote:
> Do we want nagios to be upgraded to 3.0? The 2.x branch is still being
> maintained upstream and we're still using it in Fedora. There would be a
> requirement to change some of the config files, but nothing horrible.
It could always be package labeled as "nagios3" for now, and co-exist
with "nagios" (2.x) until 2.x is no longer developed upstream. Just a
suggestion.
--
Bryan J Smith Senior Consultant Red Hat GPS SE US
mailto:bjs@redhat.com +1 (407) 489-7013 (Mobile)
mailto:b.j.smith@ieee.org (non-RH/ext to Blackberry)
--------------------------------------------------------
You already know Red Hat as the entity dedicated to 100%
no-IP-strings-attached, community software development.
But do you know where CIOs rate Red Hat versus other
software and services firms for their own, direct needs?
It's no comparison: http://www.redhat.com/promo/vendor/
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
6:25 p.m.
Mike, if you take the two streams of packages idea, I'd offer to help
co-maintain since you'll have twice the work. Updates for two
versions doesn't sound all that fun to me.
Just a question, do people in Enterprises apply updates in EPEL
without reading through each one and ensuring it's compatible with
your needs/design? We review most every update, mostly curious.
stahnma
6:37 p.m.
On Mon, 2009-03-30 at 18:25 -0500, Michael Stahnke wrote:
Just a question, do people in Enterprises apply updates in EPEL
without reading through each one and ensuring it's compatible with
your needs/design? We review most every update, mostly curious.
My clients bring in select updates into their YUM Custom Repos or Red
Hat Network (RHN) Satellite Server Custom Channels, and rarely tap the
repo directly. But there could be some putting the EPEL YUM Repo
directly into their yum.conf/yum.repos.d.
--
Bryan J Smith Senior Consultant Red Hat GPS SE US
mailto:bjs@redhat.com +1 (407) 489-7013 (Mobile)
mailto:b.j.smith@ieee.org (non-RH/ext to Blackberry)
--------------------------------------------------------
You already know Red Hat as the entity dedicated to 100%
no-IP-strings-attached, community software development.
But do you know where CIOs rate Red Hat versus other
software and services firms for their own, direct needs?
It's no comparison: http://www.redhat.com/promo/vendor/
6:45 p.m.
On Mon, Mar 30, 2009 at 6:37 PM, Bryan J Smith <bjs(a)redhat.com> wrote:
On Mon, 2009-03-30 at 18:25 -0500, Michael Stahnke wrote:
> Just a question, do people in Enterprises apply updates in EPEL
> without reading through each one and ensuring it's compatible with
> your needs/design? We review most every update, mostly curious.
My clients bring in select updates into their YUM Custom Repos or Red
Hat Network (RHN) Satellite Server Custom Channels, and rarely tap the
repo directly. But there could be some putting the EPEL YUM Repo
directly into their yum.conf/yum.repos.d.
We have pulled EPEL directly in some cases, but still, we don't apply
updates without really looking into them. I think that's more what I
was trying to ask. I hope people aren't just running yum-cron or 'yum
-y update' in cron on EL. I mean, from a maintainers perspective,
having to have Nagios3 and Nagios isn't fun. From a client
perspective, you'd probably like both. You'd HATE it if you went from
2->3 and it broke all your monitoring, because you might not catch
that for a while...
--
Bryan J Smith Senior Consultant Red Hat GPS SE US
mailto:bjs@redhat.com +1 (407) 489-7013 (Mobile)
mailto:b.j.smith@ieee.org (non-RH/ext to Blackberry)
--------------------------------------------------------
You already know Red Hat as the entity dedicated to 100%
no-IP-strings-attached, community software development.
But do you know where CIOs rate Red Hat versus other
software and services firms for their own, direct needs?
It's no comparison: http://www.redhat.com/promo/vendor/
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
6:56 p.m.
On Mon, 2009-03-30 at 18:45 -0500, Michael Stahnke wrote:
We have pulled EPEL directly in some cases, but still, we don't
apply
updates without really looking into them. I think that's more what I
was trying to ask.
Understand. Although I still highly recommend Enterprises or even SMB
operations consider their own, internal, Custom Repos (YUM) or Custom
Channels (Spacewalk/RHN Sat) for release control.
I hope people aren't just running yum-cron or 'yum
-y update' in cron on EL. I mean, from a maintainers perspective,
having to have Nagios3 and Nagios isn't fun. From a client
perspective, you'd probably like both. You'd HATE it if you went from
2->3 and it broke all your monitoring, because you might not catch
that for a while...
I'm a tad ignorant on the standards for EPEL beyond the basics. But I
would assume a major version change that requires reconfiguration would
be implemented with a suffix on the package name (e.g., nagios3-3*),
much like RHEL, instead of a major version change with the same package
name (e.g., nagios-2*).
I know EPEL is not RHEL with the manhours to support backports. But as
long as Nagios 2.x is supported upstream, I would segment the two. When
Nagios 2.x development is suspended upstream, then that would be the
ideal time to consider rebasing the main package with no version suffix.
I'm hardly an authority on EPEL and produce little more than hotair from
a package standpoint, but that makes the most sense to me.
--
Bryan J Smith Senior Consultant Red Hat GPS SE US
mailto:bjs@redhat.com +1 (407) 489-7013 (Mobile)
mailto:b.j.smith@ieee.org (non-RH/ext to Blackberry)
--------------------------------------------------------
You already know Red Hat as the entity dedicated to 100%
no-IP-strings-attached, community software development.
But do you know where CIOs rate Red Hat versus other
software and services firms for their own, direct needs?
It's no comparison: http://www.redhat.com/promo/vendor/
2:36 a.m.
Michael Stahnke wrote:
Mike, if you take the two streams of packages idea, I'd offer to
help
co-maintain since you'll have twice the work. Updates for two
versions doesn't sound all that fun to me.
I like the idea of nagios 3 in EPEL too.
Just a note though, maintaining 2 nagios packages in EPEL probably means
maintaining 2 versions of some other packages that depends on nagios. I
didn't check which one yet.
Regards,
Xavier
1:49 a.m.
Bryan J Smith píše v Po 30. 03. 2009 v 15:37 -0400:
On Mon, 2009-03-30 at 14:11 -0500, Mike McGrath wrote:
> Do we want nagios to be upgraded to 3.0? The 2.x branch is still being
> maintained upstream and we're still using it in Fedora. There would be a
> requirement to change some of the config files, but nothing horrible.
It could always be package labeled as "nagios3" for now, and co-exist
with "nagios" (2.x) until 2.x is no longer developed upstream. Just a
suggestion.
There is a plan for RPM Fusion to add a repository for such cases when
you want to have newer version of a package than is normally in EPEL.
Zabbix is another candidate in this situation (1.4 in EPEL vs. 1.6 in
Fedora)
Dan
5498
days inactive
5499
days old
epel-devel@lists.fedoraproject.org
8 comments
6 participants
participants (6)
-
Adam Miller -
Bryan J Smith -
Dan Horák -
Michael Stahnke -
Mike McGrath -
Xavier Bachelot