Comments you submit will be routed for moderation. If you have an account, please log in first.
Modify

Ticket #3950 (closed enhancement: invalid)

Opened 10 years ago

Last modified 8 years ago

Setup configuration of per-directory control

Reported by: wehart Owned by: wehart
Priority: minor Milestone:
Component: Acro Admin Version: acro 1.0.2
Keywords: Cc: jdsiiro
Subcomponent: Documentation and Web Pages

Description (last modified by wehart) (diff)

  • This would not replace actual e-mail distribution lists. The only thing this would do is distribute commit log messages, which are already archived in SVN. The only things this wouldn't catch are:

1) any "reply-to-all" e-mail chains started from the commit message (that aren't CC'd to an actual list)
2) if a sysadmin changes the log message in the SVN repo itself (log messages are unversioned properties in svn)

  • Yes, sorta - this could supplement the intent of the public/private stuff. Per-directory ACLs is a lot more work for the svn server. In general, blanket access to a repo is easier / preferable (both for config management and philosophy). We could still administer it though a similar file in the repo -- it just would work through an apache system instead of through the subversion per-dir system. Ironically, the current public/private configuration actually uses the svn per-directory system, even through it is only used for blanket access.

BTW: There *is* a security risk here: the ACL files themselves would be owned by the apache user... if someone hacked into apache, they "could" change the repo ACLs... Plus, anyone with access to the repo, can change the ACL. Granted, only someone with write access to that repo could change the ACL for that repo, and this is not creating apache user accounts on the host machine -- unless we use Kerberos authentication, that step will still have to be done by a sysadmin.

john


From: Hart, William E
Sent: Wednesday, June 18, 2008 6:03 AM
To: Siirola, John D; Eldred, Michael S; Adams, Brian M
Subject: RE: dakota sandbox svn

Two thoughts:

  • A significant feature of our current checkins for Dakota/Acro? is that all checkins are archived in an email distribution list. I don't think that that is precluded in this mechanism, but it's not encouraged/required. There might be a QA issue if someone does not include the standard checkin list for a directory.
  • I like the idea of supporting per-directory acl's. This would eliminated the public/private subversion stuff on s.s.g., right? I think it's worth exploring that idea further.

--Bill


From: Siirola, John D
Sent: Monday, June 16, 2008 3:10 PM
To: Eldred, Michael S; Adams, Brian M
Cc: Hart, William E
Subject: dakota sandbox svn

On a whim this weekend I looked at writing a commit script
that could work for the subversion "sandbox" idea we talked
about at the last Dakota meeting. The result is attached.

The idea was to create a single svn repo (on the SRN) that
allowed people to set up scratch directories within it. Each
subdirectory off the repository root could have its own
commit e-mail distribution list. The post-commit script
would produce the commit message "distribution list" by
collecting the e-mail addresses from a file *in the
repository*. In this case, the script looks for
"checkin-list" in the top-level directory(ies) that are
referenced by the checkin. This works both on s.s.g, and
(with a little modification) on d.s.g.

While the idea behind a sandbox repo would be to let anyone
carve out a top-level directory, we could easily use the same
ideas in the post-commit script to let directory owners to
control access to their directory. For example, someone
would create a top-level directory, "foo", and then create
and add two files to the foo directory: commit-list &
access-list to establish the checkin e-mail distribution and
the list of user id's that have read or write access to that
specific directory.

john

Attachments

Change History

comment:1 Changed 10 years ago by wehart

  • Cc jdsiiro added
  • Version changed from 1.0 to acro 1.0.2
  • Type changed from defect to enhancement
  • Description modified (diff)
  • Milestone set to acro 2.0

comment:2 Changed 10 years ago by jdsiiro

  • Priority changed from high to minor
  • severity minor deleted

Converting all severities into priorities and deprecating the severity field.

comment:3 Changed 10 years ago by wehart

  • Milestone acro 2.0 deleted

comment:4 Changed 10 years ago by wehart

  • Component changed from acro to Acro Admin

comment:5 Changed 8 years ago by jdsiiro

  • Status changed from new to closed
  • Resolution set to invalid

This was implemented for the Sandbox repositories and is not relevant for Acro.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.