[Fedora-infrastructure-list] Officers
by Mike McGrath
The infrastructure group is getting bigger and I think its time that
we start examining whether we would benefit from officers in the admin
group. I don't want to create a high barrier to getting involved with
the infrastructure project but at the same time right now everyone is
trying to do everything and as a result sometimes stuff isn't getting
done. (ppc1 has over 200 updates that need to be done).
If we got more fine grained with security we could allow people access
to systems without giving them full root on all the systems. For
example it would be very easy to create a nagios group so multiple
people could access and restart nagios without giving them root to the
box and other boxes. Some apps don't even need shell access to admin,
otrs and mailman comes to mind immediately.
I could see a use for the following officers:
ticketmaster
updates
dba
noc (nagios/cacti)
accounting
VCS
external (someone who can coordinate with the other non-infrastructure
teams on things)
I'm thinking that officers should be limited to people that have been
a part of the team for months and have a good record in the true sense
of a meritocracy. I'm also under the opinion that some systems could
have multiple officers. (for example I could very easily see Warren
and myself as contacts for VCS).
Anyway I'm throwing it out there. What do you guys think? Am I
trying to solve a problem that doesn't exist?
-Mike
17 years, 9 months
[Fedora-infrastructure-list] Hardware Tracker
by Damian Myerscough
Hey all,
I have attached an XML file that is produced by the hardware tracker,
the problem I have
encountered is asking the user if the device works. I am not sure how
to go about this?
Should I just filter out the info.product field which, would give:
<info.product>USB Hub Interface</info.product>
<info.product>USB Raw Device Access</info.product>
<info.product>UHCI Host Controller</info.product>
<info.product>82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller
#1</info.product>
This information from a new user to Linux would be hard for them to
understand if its working correctly. Any suggestions are most welcome.
17 years, 9 months
[Fedora-infrastructure-list] debian's problems
by Max Spevack
I'm sure you guys are all following the stories on slashdot about the
problems that Debian is having due to password insecurity that led to a
compromised account.
What sort of safeguards do we have? Is this a good time to thnk about how
we can improve our security *before* there is a problem rather than after?
Do we have some sort of general plan for what to do if one of our public
boxes is compromised, so that we don't act randomly, or forget things in
the panic of the moment?
--Max
--
Max Spevack
+ http://fedoraproject.org/wiki/MaxSpevack
+ gpg key -- http://spevack.org/max.asc
+ fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21
17 years, 9 months
[Fedora-infrastructure-list] Re: CVS admin request
by Warren Togami
Hans de Goede wrote:
> Hi Warren,
>
> Could you please create an empty devel branch for gkrellm. gkrellm is
> already in CVs, but only RHL-8 and RHL-9 branches as after that it moved
> to core, now its moving back and because of the exisiting branches
> cvs-import.sh won't work.
>
> I already put this on the CVSSyncNeeded wiki-page, in the special
> requests section, but special requests usually take ages to get handled.
> And this is currently blocking import of 2 new packages into FE (gkrellm
> and gkrellm-wifi).
>
> This is also discussed here:
> http://fedoraproject.org/wiki/Extras/CVSSyncNeeded
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197967
>
> Thanks & Regards,
>
> Hans
The way the CVS system was designed, it is a huge mess to re-add a devel
branch after it has been deleted. It might be easier to just blow away
the entire directory and import it from scratch. I'll go ahead and do
this after talking to infrastructure people.
Warren Togami
wtogami(a)redhat.com
17 years, 9 months
[Fedora-infrastructure-list] better passwords ,etc
by seth vidal
Hi,
Following on the post about stronger passwords - I have a better idea -
why don't we have no password at all.
meaning - if you don't have the ssh key you cannot login to any of our
systems.
Then we don't have to muck with passwords at all we just put nice
little !! in the field in the shadow.db file and we're done with it.
What do you think?
-sv
17 years, 9 months
Re: [Fedora-infrastructure-list] better passwords ,etc
by Jeffrey Tadlock
Mike McGrath wrote:
> We'll have to find the balance. We could go key
> kerberos crazy if we wanted to. On the one hand we should have a
> very secure system. On the other hand we cannot burden the
> developers. After all thats the whole reason our team exists... to
> aid the developers.
There is definitely a balance to be struck. Keep the systems usable
while at the same time secure. The sysadmin's conundrum, eh?
SSH keys shouldn't be a big deal to developers though right?
As far as the web passwords, we obviously can't do away with those, that
crosses the usability line. But maybe there needs to be a check in
place before the ssh keys are pushed across systems? Not sure how that
check would work without adding overhead though.
In either case, finding potential pitfalls as these are part of
determining the balance. At least knowing where the weaker points of
the system are will allow us as a group to decide the acceptabilty of
that risk. An audit such as I suggest should help us find our weaker
spots along the way so we can at least discuss them and weigh risks
versus benefits.
The best practices portion are often times changes that few would notice
but could reduce our attack vector with no real penalty. Take a peek a
the sshd_config on bastion sometime. I was a little surprised. I had
assumed that host was only accepting ssh keys. Hardening ssh on that
machine wouldn't affect many people at all and we would still see some
potential gains from it.
> It should also be said that I've never actually worked at a place
> that would end up on Slashdot if we got hacked.... I guess there's a
> bit of pride in me that wants to make sure that if the Fedora
> infrastructure ever does get hacked that it doesn't happen on my
> watch
Agreed!! :)
-Jeffrey
17 years, 9 months
[Fedora-infrastructure-list] TurboGears update
by Luke Macken
I bumped FC-5 and devel branches to 0.8.9 last week, and have been
working on getting 0.9a6 packaged up for devel. I wrote RPMS for the
rest of the dependencies for the latest TG, which are waiting for
review:
Bug #198285 - python-simplejson
Bug #198289 - python-pastescript
Bug #198287 - python-paste
Bug #198288 - python-pastedeploy
Bug #198284 - python-configobj
A few existing packages will need to get bumped as well:
Bug #198905 python-formencode >= 0.5.1
python-sqlobject >= 0.7.1dev_r1457
TurboJson, TurboCheetah, TurboKid, and fastdata are all deps as well,
but are shipped in the TurboGears tarball in the plugins/ directory. So
these will most likely need to be pulled out into subpackages of
TurboGears (unless someone can think of a better way to do it).
Since Ignacio is MIA, I'll probably end up making these bumps once we get
the rest of the deps into extras.
So, if anyone has any free time on their hands, package reviews would
definitely be appreciated :)
luke
17 years, 9 months
