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/
11 years, 10 months
Calendaring. Again.
by Adam Williamson
Hey, folks. Just wanted to take another shot at one of my oldest
windmills :)
So, we talked about calendaring for a long time. Then we picked Zarafa.
Then we kind of implemented it. Then no-one used it, and we took it out
again:
http://smoogespace.blogspot.com/2011/02/resetting-expectations-fedora.html
That wasn't what you might call a 'success', I know. I think there's
maybe a couple of reasons for that. One, I'm still not really sure why
we'd pick Zarafa. It's explicitly designed to be a Microsoft Exchange
replacement, and I don't think Fedora is a project with a lot of people
who really need to use ActiveSync or Outlook, so...huh? It just doesn't
seem like it was ever a great fit. By the Zarafa page on the wiki -
https://fedoraproject.org/wiki/Zarafa - we couldn't even ship Z-Push
because ActiveSync is patented, so apparently our only ever official
calendaring system never had a working sync mechanism at all, and I
don't think Zarafa's web interface is any great shakes.
Two, there was never any particular driver towards using it.
So, I think another try with a more appropriate calendaring system - if
we can find one - and a 'seed' use of it might be a good idea.
I've been using eGroupware, personally, for quite a while, and I think
it's a good system. I'm not aware of any major barriers to including it
in Fedora. It has internal copies of a few Pear modules, but that's
pretty small beer and it should be trivial to use the system-wide copies
or get an exception (some of them are extensively modified). It has a
nice web UI and decent sync capabilities via CalDAV: I've used it
synchronized with Evolution on two systems and never had major problems.
It seems at least a better fit than Zarafa. Citadel would be another one
to look at.
As for a 'seed' use, I think an ideal fit here would be the release
schedules. Currently, these are dumb HTML tables with ICS files living
in the current release manager's personal fedoraproject space:
http://rbergero.fedorapeople.org/schedules/f-16/
which sucks for any number of reasons, not least of which you need to
know who the hell the release manager is at the moment in order to find
the schedule. =) Using a proper calendaring system would seem to be a
far better way to handle the release calendars, and would be a great
kickstarter for a project calendaring system. Since the calendars are
maintained by one person, we only need to get one person (hi, Robyn!) to
buy in, in order to kick off this seed use.
To restrict the liability issues mentioned in Smooge's blog post, we
could not enable the email function of the system we choose (this is
possible with both EGW and Citadel). We could also not have individual
accounts for all Fedora project members, at least at first: we could
have just a few individual accounts with commit access, mainly for the
release manager to maintain the calendars, and then have a single
read-only guest account which people could use to view the calendars and
sync them read-only to their phones and desktop clients. It may even be
possible to set things up so people can view and read-only sync without
any authentication required.
What do people think of this idea? If it seems like an approach that's
simpler to maintain and more likely to produce actual useful results,
that'd be great. I'm willing to work on packaging eGroupware and
resolving the private-copies-of-pear-modules issue - I already maintain
eGW for Mandriva, so it wouldn't be too much work to convert the spec to
Fedora standards.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11 years, 10 months
Hello
by Hui Li
Hi,
I'm a sysadmin working at a software company. Here's the skills I got.
- Linux system administration
- FTP/Web/NFS/NIS/DNS/DHCP/Kerberos/OpenAFS services setting
up/troubleshooting experience
- Be familiar with Nagios and Ganglia settings/configurations
- Skillfully Shell scripting
- HPC administration experience
- Be familiar with IBM/HP/Dell servers operation and firmware upgrade
- Be familiar with data center infrastructural devices like
Rack/PDU/KVM/Console Server
- Linux Live CD building experience
- Experience with creating/managing Open Source projects
If anything I can help pls. let me know.
Thanks very much.
Hui
11 years, 10 months
[PATCH] hosted: Remove gzip encoding for .gz*.asc files in apache config
by Todd Zullinger
It was reported that various browsers were giving errors when attempting
to download the .asc file for func-0.28¹. The reason appears to be that
the func .asc file did not match the simple *.gz.asc pattern used to
remove the .gz encoding.
Using FilesMatch should be more reliable. Arguably, we could just use
*.asc here as well.
¹ https://www.redhat.com/archives/func-list/2011-July/msg00017.html
---
I know hosted isn't in a freeze at the moment, but I thought I'd check
before committing this change. I'd have just changed the pattern to
*.asc, but I wasn't sure whether httpd would take issue to a
RemoveEncoding call on files that lacked it previously.
Anyone see a problem with this fix or the simpler one to continue
using <Files> and just changing the pattern to *.asc? (I'd fix the
mis-cased </files> then too.)
configs/web/fedorahosted.org.conf | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/web/fedorahosted.org.conf b/configs/web/fedorahosted.org.conf
index 44c0597..b300f7c 100644
--- a/configs/web/fedorahosted.org.conf
+++ b/configs/web/fedorahosted.org.conf
@@ -11,9 +11,9 @@ Listen 443
ServerName fedorahosted.org
ServerAdmin webmaster(a)fedoraproject.org
- <Files *.gz.asc>
+ <FilesMatch "\.gz.*\.asc$">
RemoveEncoding .gz
- </files>
+ </FilesMatch>
Alias /robots.txt /srv/web/fedorahosted.org/robots.txt
--
1.7.6
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Even celibacy isn't a 100% fool proof way to avoid pregnancy... just
ask the Virgin Mary.
11 years, 10 months
proposal: stop using servergroups in puppet
by Seth Vidal
I'd like to propose that we stop using servergroups as a subdir in our
puppet manifests dir.
proposal is just:
move all .pp files over to 'services' and remove servergroups subdir
entirely.
justification:
1. the distinction between servergroups and services is..... blurry.
2. the actual usage difference between them is confused - if only b/c
we have things which could be services in servergroups and servergroups
in services.
3. the distinction doesn't actually buy us anything we don't get with
just services.
alternative proposal:
- since services tend to be module-represented in puppet more than in
manifests, we could move to having:
manifests/
nodes <-- actual node definitions like we have now
attributes <-- attributes nodes can include (essentially
services but with a less confusing name vis-a-vis our modules/*
services)
Thoughts?
-sv
11 years, 10 months
