I'm working on FAS 2, specifically group application. The present
system works like this:
User applies for a group and specifies:
* Group name
* Role Domain
* Role Type
Does anyone know what 'Role Domain' is for?
Just some stats I ran on the current data posted for the mirrors.
Everything (Core + Extras, FC 1 through 6, 7test, development,
updates, repodata): 492GB
so we're already expecting mirrors to carry ~25GB per arch per release
If we continue with 3 arches, 2 releases per year, that's at least 150GB
per year growth. If we add arches, Unity respins, more CD/DVD objects,
and the like, it'll grow faster.
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
I've been examining more closely why wiki saves are slow. At this time
it appears the issue is in notifications. More to the point,
determining who to notify. Our wiki supports regex for page
notifications. This means that when you save a page, Moin has to
iterate over all users (currently about 10,000 registered) before it
knows who to notify. Actually sending the notifications doesn't take
that long, but figuring out who to mail can take a long long time. My
tests show between 30 and 95 seconds. When I disabled notifications
saves dropped to 2-3 seconds. I'm not sure what to do from here but it
looks like it will take a code change (I'm working with some guys in
#moin). I'm continuing to look into it but wanted to let everyone know
what was going on.
NOTE: This info is not relevant to the near-term Fedora merge or any
infrastructure supporting it. We will continue to use the existing CVS
+ ACL system.
Toshio was wondering about the possibility of using filesystem ACL's as
part of a future ideal SCM's ACL enforcement. It would work something
1) PackageDB knows about all packages, owners, granted permissions,
2) PackageDB generates xattrs or FS ACL (themselves based on xattrs)
within the SCM files/directories.
3) SCM has a custom ACL enforcement script that reads those xattrs,
making it very fast and flexible. ACL's could be enforced based on a
list of users, groups, or a combination of users and groups.
I talked with a few filesystem experts within Red Hat. They said...
- ext3 has a limit of 4KB for xattr data. If you use the standard
encoding of 8 bytes per uid, that has a limit of roughly 100 entities
that could be associated with a file. Is this too limiting? I dunno.
Perhaps it need not be too limiting if more extensive use of
group-based-ACL's are used.
- XFS could possibly allow a maximum of 64KB xattr's per file, but that
is very inefficient in filesystem storage.
- xattr's are currently not supported by NFS.
It came to my attention recently that by having duplicate content at
www.fedoraproject.com and fedoraproject.org that both would receive a
lower ranking in google's system. As a result I've got everything
redirecting to fedoraproject.org. My Google-fu isn't that great so I'd
like to ask if anyone out there would like to do some research to find
out how we can increase our hits. Would a robot file help? I honestly
have no idea. Anyone interested?
Right now I'm setting up the torrent box to use puppet. In order to do
this puppet needs access to lockbox. In order to do this I've decided
it best to use ssh forwarding. We've talked about VPNs in the past, and
we can discuss it again in the future. For the time being, however, I
think I'd prefer to be more surgical.
Can anyone think of any issues with doing this? We've never actually
made this link before with external hosts, even the fas integration uses
a public facing website to wget the info we need.