ticket#2673 - nitrate deployment
by James Laska
Greetings,
I am in search of sponsorship for hosting space to deploy a test
instance of nitrate [1]. Some of you may recall several years back when
we deployed an instance of Testopia. That exploration was cut short
when we discovered license incompatibilities between testopia and
Fedora. At that time, a small group of Red Hat associates began
creating a new Django-based test management system to remove the
components that had conflicting licenses. That new system became
nitrate [1].
The Fedora QA team would like to experiment/explore this newer
Django-based test management system. At the very least, I believe we'll
need a publicly accessible server where we can host the nitrate instance
and a mysql database for it.
I filed ticket#2673
(https://fedorahosted.org/fedora-infrastructure/ticket/2673) to track
this request. Please don't hesitate with any
questions/comments/concerns.
Thanks,
James
[1] https://fedorahosted.org/nitrate/
12 years, 8 months
Second rounds of lists clean-up
by Andrea Veri
hey guys,
I've just finished tracking down inactive lists et all on
collab01.
The list can be found at [1].
Will wait 14 days from now and then clean-up the really
inactive lists.
I've used the following policy to avoid any problem:
Lists with messages older than January 2011 or with no messages at all,
will receive a mail from me asking if they still think their list is active or will
be so in the near future. If no mails will be sent back to me within 14
days from today the list will be closed using the procedure explained above.
(lists can be re-opened at any time later)
Obviously the above didnt apply to the summer-coding lists that are inactive
now since september for a valid motivation.
Wow, it's finally done, it was a never-ending list!
cheers!
Andrea
[1] http://averi.fedorapeople.org/inactive_lists_fp.txt
13 years
[Bug 656076] BFO installation PITA (fwd)
by Mike McGrath
Who wants to be the BFO wrangler? :)
-Mike
---------- Forwarded message ----------
Date: Mon, 28 Mar 2011 11:39:27
From: bugzilla(a)redhat.com
To: mmcgrath(a)redhat.com
Subject: [Bug 656076] BFO installation PITA
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=656076
Will Woods <wwoods(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flag| |needinfo?
--- Comment #15 from Will Woods <wwoods(a)redhat.com> 2011-03-28 12:39:25 EDT ---
To be clear: this is not a bug in anaconda, it's a problem with the
configuration used by boot.fedoraproject.org. This was fixed for Fedora 14 and
earlier on February 28.
As suggested in comment #12, for Fedora 15 no "method=xxx" line is necessary.
Remove it and the install will proceed without the constant "Retry? message.
(Apparently, whoever added the Fedora 15 configuration sections on
boot.fedoraproject.org didn't see the email telling them to leave out the
"append method=..." part. Oh well.)
If anyone can confirm that removing "method=xxx" from the boot commandline
makes the install proceed as expected, we'll change the configuration on
boot.fedoraproject.org and close this bug.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
13 years, 1 month
loggerhead updated for a CVE
by Toshio Kuratomi
I've updated loggerhead on hosted01/02 due to an XSS flaw. This is using
the new EPEL5 builds. The changes are not large but (since el5 was on 1.17
and the fix is in 1.18.1) the changes do touch things that aren't related to
the XSS fix.
Likely, only projects that I'm involved in use bzr on fedorahosted (and thus
loggerhead as the web viewer), but in case someone complains about problems,
this is a likely culprit.
PS: Thanks to ricky for making sure I saw this.
-Toshio
13 years, 1 month
Re: Outage: Upgrading nagios - 2011-03-25 18:00 UTC
by Stephen John Smoogen
Ugh. I put in the wrong date:
The outage will be 2011-03-25 1800 UTC and last 2 hours.
On Thu, Mar 24, 2011 at 16:26, Stephen Smoogen <smooge(a)gmail.com> wrote:
> There will be an outage starting at 2011-03-25 18:00 UTC, which will last
> approximately X hours.
>
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
>
> date -d '2011-03-25 18:00 UTC'
>
> Reason for outage:
>
> Moving from EL5 nagios to EL6 nagios
>
> Affected Services:
>
> Nagios
> Zodbot
> DHCP for PHX2 application network.
>
> Unaffected Services:
>
>
> BFO - http://boot.fedoraproject.org/
> Bodhi - https://admin.fedoraproject.org/updates/
> Buildsystem - http://koji.fedoraproject.org/
> CVS / Source Control
> DNS - ns1.fedoraproject.org, ns2.fedoraproject.org
> Docs - http://docs.fedoraproject.org/
> Email system
> Fedora Account System - https://admin.fedoraproject.org/accounts/
> Fedora Community - https://admin.fedoraproject.org/community/
> Fedora Hosted - https://fedorahosted.org/
> Fedora People - http://fedorapeople.org/
> Fedora Talk - http://talk.fedoraproject.org/
> Main Website - http://fedoraproject.org/
> Mirror List - https://mirrors.fedoraproject.org/
> Mirror Manager - https://admin.fedoraproject.org/mirrormanager/
> Package Database - https://admin.fedoraproject.org/pkgdb/
> Smolt - http://smolts.org/
> Spins - http://spins.fedoraproject.org/
> Start - http://start.fedoraproject.org/
> Torrent - http://torrent.fedoraproject.org/
> Translation Services - http://translate.fedoraproject.org/
> Wiki - http://fedoraproject.org/wiki/
>
> https://fedorahosted.org/fedora-infrastructure/ticket/2681#preview
>
> Contact Information:
>
> Please join #fedora-admin in irc.freenode.net or respond to this email to
> track the status of this outage.
>
>
> --
> Stephen J Smoogen. Fedora Team
> "Tell me and I'll forget; show me and I may remember; involve me
> and I'll understand." Mencius
> “Let us be kind to one another, for most of us are fighting a
> hard battle.” -- Ian MacLaren
>
>
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
13 years, 1 month
RE: Introduction
by Richard Walker
Hi Infrastructure Team,
I'm an Enterprise Support Analyst from Yorkshire, United Kingdom. I have
a fair amount of Linux experience and now work full time with Tru64,
HP-UX and most significantly Red Hat Enterprise. Although I still have a
lot to learn I will be getting formal Red Hat training at some point and
more experience under my belt moving forward.
I'm still finding my way around here but hope to get involved if I have
anything to offer, I'm a fan of Red Hat/Fedora and hope to master
everything about it - so if I can learn and help out along the way - all
the better!
Regards,
Richard.
13 years, 1 month
changing a few things in our host mgmt tools
by Seth Vidal
Hi folks,
some thoughts have been slowly coalescing in my head about how we're
managing our boxes/services and I have some suggestions I've passed by
various folks but I wanted to check them out with everyone:
1. puppetd sucks..... memory. Right now we have puppetd running on every
box and it wakes up every half hour and runs itself. This is fine but in
the time where it is not doing anything it just eats memory for no good
reason. I'd like to suggest we move to a cron-driven model instead of
puppetd. I'd write a simple cron job that runs every half hour to run
puppetd, if a lock file is not found. Pretty straightforward, of
course.
2. monitoring if puppetd has run properly:
two things we want to know about puppet runs:
a. when they last happened per-box
b. if they fell over in a horrible way.
(a) can be known by looking at the $nodename.yaml file which lives
on the puppetmaster. I've written a script to check if that file is
older than 1 hour and report the nodename if it is.
(b) can be done via the cron job - ie: taking error output from the
puppet run and mailing to people until we fix it! :)
3. sign** boxes. problems here:
a. These boxes are falling out of date, repeatedly, b/c they aren't
in our normal updating path.
b. these boxes don't email out to the same locations as the other
boxes
c. these boxes don't get faspassword updates properly
d. these boxes don't get config changes normally via puppet
(a) I'd like to suggest that they be put into a normal updating path
and/or we setup a nag mail to tell us about them
(b) obviously, fix their mail configs
(c) fasclient is failing b/c of a missing token b/c, most likely, of
(d)
I'm open to suggestions on those but it is a bit annoying b/c while I
understand their 'sensitivity' I think our way of treating them is
making the problem WORSE not better.
-sv
13 years, 1 month