Introduction
by Onalenna Junior Makhura
Hi,
I have been a member of this list for a few years now but due to some
constraints I have not been able to actively participate. I would now
like to start be active in Fedora development. I have been using fedora
as my 1st choice OS since Fedora Core 6.
I would be very glad to have someone who can show me the ropes.
Regards,
Onalenna Junior Makhura
11 years, 1 month
builders of the future!!!!!
by Seth Vidal
The discussion on devel list about ARM and my work last week on
reinstalling builders quickly and commonly has raised a number of
issues with how we manage our builders and how we should manage them in
the future.
It is apparent that if we add arm builders they will be lots of
physical systems (probably in a very small space) but physical,
none-the-less. So we need a sensible way to manage and reinstall these
hosts commonly and quickly.
Additionally, we need to consider what the introduction of a largish
number of arm builders (and other arm infrastructure) would do to our
existing puppet setup. Specifically overloading it pretty badly and
making it not-very-manageable.
I'm making certain assumptions here and I'd like to be clear about what
those are:
1. the builders need to be kept pristine
2. that currently our builders are not freshly installed frequently
enough.
3. that the builders are relatively static in their
configuration and most changes are done with pkg additions
4. that builder setups require at least two manual-ish steps of a koji
admin who can disable/enable/register the builder with the kojihub.
5. that the builders are fairly different networking and setup-wise to
the rest of our systems.
So I am proposing that we consider the following as a general process
for maintaining our builders:
1. disable the builder in koji
2. make sure all jobs are finished
3. add installer entries into grub (or run the undefine, reinstall
process if the builder is virt-based)
4. reinstall the system
5. monitor for ssh to return
6. connect in and force our post-install configuration: identification,
network, mount-point setup, ssl certs/keys for koji, etc
7. reboot
8. re-enable host in koji
We would do this with frequency and regularity. Perhaps even having
some percentage of our builders doing this at all times. Ie: 1/10th of
the boxes reinstalling at any given moment so in a certain time
frame*10 all of them are reinstalled.
Additionally, this would mean these systems would NOT have a puppet
management piece at all. Package updates would still be handled
by pushes as we do now, if things were security critical, but barring
the need for significant changes we could rely on the boxes simply being
refreshed frequently enough that it wouldn't need to be pushed.
What do folks think about this idea? It would dramatically reduce the
node entries in our puppet config, it would drop the number of hosts
connecting to puppet, too. It will mean more systems being reinstalled
and more often. It will also require some work to make the steps I
mention above be automated. I think I can achieve that without too much
difficulty, actually. I think, in general, it will increase our ability
to scale up to more and more builders.
I'd like input, constructive, please.
Thanks,
-sv
11 years, 4 months
Fedora Account Change
by Leonardo Rodrigues de Mello
Hi,
I do not know if this is the correct place to place this question, please
feel free to redirect me to the right place.
I have one account at fedora project 'lmello' this account is assigned with
my old employer email (lmello AT redhat.com), since i no longer work at
redhat i am unable to change my password and associate my account with my
new email address.
Could some one change my lmello account email address from lmello AT
redhat.com to l at lmello.eu.org ? I had created a new account associated
with my new email address called lmello2, feel free to remove it if
necessary.
Best.
--
Leonardo Rodrigues de Mello
jabber: l(a)lmello.eu.org
11 years, 5 months
qa machine management
by Kevin Fenzi
Greetings.
Just had a talk with tflink on IRC about the management of the qa
network machines. Long ago when we setup those machines we were
thinking we could use them as a testbed for bcfg2 to see if we wanted
to start using it or if it worked ok, etc. I setup a bcfg2 server to
try this with, but sadly have never found the time to even start
configuring it.
Machines involved:
virthost-comm01.qa (real hardware)
autoqa01.qa (guest)
autoqa-stg01.qa (guest)
lockbox-comm01.qa (guest)
bastion-comm01.qa (guest)
(someday we may add a sign-bridge-comm01 and sign-vault-comm01 to allow
secondary archs like ppc and arm to sign packages).
Options:
- Try and push forward with a bcfg2 setup on lockbox-comm01.qa and
evaluate it. This would be nice, but I'm really not sure anyone has
the time to do it.
- Just add all the above machines to our puppet repo and configure them
there and call it done. This would mean they wouldn't be seperate
from us and we just update and configure and monitor them like any
other machine.
- Try and work out some setup with ansible or the like to see if it
could manage them. Again, this would be a learning and tweaking
curve, so not sure we have the time.
- We could setup a new puppet for them on lockbox-comm01.qa and use
that to manage them. We could reuse a lot of our current puppet
setup, but it would still be a fair bit of work to get it all
configured.
Thoughts? Brilliant ideas?
kevin
11 years, 5 months
Re: Name of the blog on the planet Fedora
by Kévin Raymond
On Thu, May 24, 2012 at 6:39 PM, Arif Tri Waluyo
<arifiauo(a)fedoraproject.org> wrote:
> On Tue, May 22, 2012 at 10:16 PM, Kévin Raymond <shaiton(a)fedoraproject.org>
> wrote:
>>
>> On Tue, May 22, 2012 at 12:48 PM, Arif Tri Waluyo
>> <arifiauo(a)fedoraproject.org> wrote:
>> > Hi I'm Arif,
>> > I was one of the contributors in Indonesia community site[1]. I
>> > registered
>> > the site to Planet Fedora in the name of "Fedora Indonesia". But when I
>> > check if the configuration is correct, it turns out there are sites[2]
>> > on
>> > behalf of "Fedora Indonesia (fedora-id)". I was afraid there was
>> > confusion
>> > about this. What should we do?
>> >
>> > Regards,
>> > Arif Tri Waluyo
>> >
>> > 1. http://id.fedoracommunity.org/
>> > 2. http://www.abenk.com/
>>
>> Yep correct, this one is quite wrong, abenk.com features blacberry stuff…
>> CC-ing Yafiz who could have some clues about fedora-id account.
>>
>> Arif, if this is not resolved soon, please ping us back we will see
>> with which account it is linked.
>
> It's been more than 24 hours. Are we still going to wait?
>>
Adding the infra mailing list for them to look at it closly…
(I haven't find who is behind this name)
--
Kévin Raymond
(shaiton)
GPG-Key: A5BCB3A2
11 years, 6 months
gitweb[-caching] vs cgit
by Seth Vidal
We're currently using gitweb[-caching] on fedorahosted and on
fedorapeople.
A discussion today suggested maybe we should move to cgit in its lieu.
First things first:
1. cgit means we break old links to gitweb urls
2. cgit is a different pkg - maintained by other folks
3. gitweb-caching appears to be abandoned (gitweb is maintained but it
doesn't do caching) - kernel.org is using gitweb-caching
so - question - is cgit different and better enough to warrant the hurt
of moving?
is cgit more reliably maintained?
is it faster? (hell, not sure it is possible for it to be slower)
Are we overlooking other options?
-sv
11 years, 6 months
Plan for tomorrow's Fedora Infrastructure meeting (2012-05-31 18UTC)
by Kevin Fenzi
The infrastructure team will be having it's weekly meeting tomorrow,
2012-05-31 at 18:00 UTC in #fedora-meeting on the freenode network.
Suggested topics:
#topic New folks introductions and Apprentice tasks.
If any new folks want to give a quick one line bio or any apprentices
would like to ask general questions, they can do so here.
#topic two factor auth status
#topic Applications status / discussion
Check in on status of our applications: pkgdb, fas, bodhi, koji,
community, voting, tagger, packager, dpsearch, etc.
If there's new releases, bugs we need to work around or things to note.
#topic Upcoming Tasks/Items
#info 2012-06-01 - nag fi-apprentices.
#info 2011-06-03 - gitweb-cache removal day.
#info 2012-06-04 - class B reboots?
#info 2012-06-05 - class A reboots?
#info 2012-06-08 OOW: osuosl01.fedoraproject.org
#info 2012-06-17 OOW: sign-vault02.phx2.fedoraproject.org
#info 2012-06-21 to 2012-07-04 Kevin is off on trains and boats.
#info 2012-06-26 Fedora 15 end of life.
#topic Meeting tagged tickets:
https://fedorahosted.org/fedora-infrastructure/report/10
#topic Open Floor
Submit your agenda items, as tickets in the trac instance and send a
note replying to this thread.
More info here:
https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings
Thanks
kevin
11 years, 6 months
Fedorapeople repos and koji build
by Jonathan MERCIER
Dear,
I wold like to put a little feature request: link Fedorapeople repos and
koji system. Often i do:
- koji scratch build (uploading srpm + build
- once time build successfully ended downloading generated rpm
- uploading rpm to Fedorapeople repos
i will be really good by example to put koji scratch build in a special
directory and when you are connected to your fedorapeople account just
use cp . I have a do package for 0ad and this package take ~ 1Go, that
take too many times: upload, build, downlaod, upload ...
thanks a lot for your great job
kinds regard
11 years, 6 months
Proper setting for smtp_from in new trac instance?
by Jason L Tibbitts III
Perhaps I missed it but I didn't see any kind of guide to setting up a
new fedorahosted trac instance so I copied from one other trac where I
have privileges. That trac has smtp_from set to trac(a)fedorahosted.org.
The problem with this is that some hosts appear to do SMTP callouts and
reject messages sent with that setting:
May 29 04:42:36 hosted03.vpn.fedoraproject.org postfix/smtpd[17813]:
NOQUEUE: reject: RCPT from XXX: 550 5.1.1 <trac(a)fedorahosted.org>:
Recipient address rejected: User unknown in local recipient table;
from=<> to=<trac(a)fedorahosted.org> proto=SMTP helo=XXX
infradead.org is one such host that does this, but it is not the only
one.
It appears that several trac instances are using this setting. Should I
be using something else or is it possible to get an alias from trac@ to
nobody@ set up so that this will work?
- J<
11 years, 6 months
F17 Final Freeze over.
by Kevin Fenzi
Greetings.
Just a note that with the release of Fedora 17 yesterday, we are now
out of freeze.
Our next freeze is for F18Alpha. Currently scheduled for:
2012-08-07 to 2012-08-21
Enjoy.
kevin
11 years, 6 months
