Wiki code for SCM hosting implementation specification

Hide Line numbers
1: = OpenSolaris
2: 
3: = Source Code Management Implementation Specification
4: 
5: = (DRAFT)
6: 
7: //Copyright 2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.//
8: 
9: == 1. Summary
10: 
11: The SCM deployment method for opensolaris.org is outlined, with specific details presented for the initial Subversion support. Although the SCM facility is not intended to support the download of large static files, an HTTP URL scheme is defined such that it may be used for simple document sharing by the community.
12: 
13: == 2. Introduction
14: 
15: Source code and its manipulation is the key next step for fostering collaboration on opensolaris.org. Although numerous consolidations require distributed SCM support, a variety of efforts’ needs are well met by a centralized SCM solution, such as Subversion. Accordingly, we present a means of implementing a hosting facility for a large number of repositories.
16: 
17: Assumptions guiding the implementation are as follows:
18: 
19: * Contributors will particpate in one or more projects;
20: * Projects will have one or more repositories;
21: * There are no secret repositories, so all repositories will have anonymous read only access;
22: * There will be two supported SCM solutions: one centralized, one distributed.
23: 
24: The implementation is restricted by the network security guidelines from our hosting organization, which merely means that the system will be running a minimized version of Solaris 10.
25: 
26: == 3. Repository access, write side
27: 
28: We’ll use the SCMs tunnelled through SSH, implying the requirement that the SCMs can be tunnelled in such a manner. This moves the authentication and authorization to a model we understand well, and removes the need to understand the individual SCMs’ distinct direct connect approaches.
29: 
30: The account on the server side will be placed in a {{code}}chroot(2){{/code}} environment and assigned a {{code}}umask(2){{/code}} of 0000, by means of a group-specific PAM session module. This environment will consist of a read-only home directory, populated with read-write loopback mounts of the repositories the user is a committer to and of enough of / and /usr to make the SCMs function.
31: 
32: === 3.1 Example paths.
33: 
34: As an example, Alice is a committer to the main and docs repositories of the foo project and to the main repository of the bar project. Her home directory would look, from a global perspective, like
35: 
36: {{{
37: 
38: /home/alice/ [read only]
39: /home/alice/bin [read only]
40: /home/alice/lib [read only]
41: /home/alice/usr/bin [read only]
42: /home/alice/usr/lib [read only]
43: ... [as needed for svn function]
44: /home/alice/svn/bar/main [read write]
45: /home/alice/svn/foo/docs [read write]
46: /home/alice/svn/foo/main [read write]
47: 
48: }}}
49: 
50: Once {{code}}chroot("/home/alice"){{/code}} has been issued, this tree becomes
51: 
52: {{{
53: 
54: / [read only]
55: /bin [read only]
56: /lib [read only]
57: /usr/bin [read only]
58: /usr/lib [read only]
59: ... [as needed for svn function]
60: /svn/bar/main [read write]
61: /svn/foo/docs [read write]
62: /svn/foo/main [read write]
63: 
64: }}}
65: 
66: With this approach, all committers have identical paths to all repositories. That is, the repositories have Subversion URLs
67: 
68: {{{
69: 
70: svn+ssh://[user]@svn.opensolaris.org/svn/bar/main
71: svn+ssh://[user]@svn.opensolaris.org/svn/foo/docs
72: svn+ssh://[user]@svn.opensolaris.org/svn/foo/main
73: 
74: }}}
75: 
76: for all users, although non-committers use the "anon" account. (These URLs may be compared to the CVS repository specifications
77: 
78: {{{
79: 
80: ext:developername@cvs.sourceforge.net:/cvsroot/[project]
81: server:anonymous@cvs.sourceforge.net:/cvsroot/[project]
82: 
83: }}}
84: 
85: and the SVN repository URL
86: 
87: {{{
88: 
89: https://svn.sourceforge.net/svnroot/[project]/[repository]/trunk
90: 
91: }}}
92: 
93: for SourceForge’s implementations of repository hosting.)
94: 
95: Additional SCM schemes will have similar URLs, using the pattern
96: 
97: {{{
98: 
99: [scm].opensolaris.org/[scm]/[project]/[repository]
100: 
101: }}}
102: 
103: In theory, these mounts could be created using the automounter, using one or more tables that are populated from the application database, specifically from the user-project membership and project-repository association tables (or query results, depending on schema implementation). The {{code}}/etc/auto_home{{/code}} file for our example involving Alice would look like
104: 
105: {{{
106: 
107: /home/alice -ro /export/home/pad /home/alice/bin -ro /bin ... \
108: /home/alice/svn/bar/main -rw /svn/bar/main ...
109: 
110: }}}
111: 
112: This output could be generated by explicit map construction, or by means of an executable automount map. See {{code}}automount(1M){{/code}} for further details.
113: 
114: Unfortunately, the initial deployment of the SCM infrastructure had problems making the automounter-based approach work, so the PAM module creates the mounts itself at session open and tears down the mounts at session close.
115: 
116: The PAM module uses two mechanisms to ensure that filesystems are not unmounted prematurely. This is needed to support concurrent logins by the same user, or even sequential logins that happen right after each other. First, a per-user lockfile is used as a mutex, preventing the session-open and session-close code from running at the same time. Second, the session-open code opens each mounted filesystem and stores the open file descriptor in the PAM state for the module. This forces any unmount requests to fail until the session-close routine has closed the file descriptor.
117: 
118: The "usr" and "user" projects should be reserved from the project/community namespace for future use (if we elect to offer per-user repositories).
119: 
120: === 3.2. User authentication.
121: 
122: The machine hosting the SCM has a {{code}}passwd(4){{/code}} map generated automatically from the application database. (Eventually, a network name service should be used for the {{code}}passwd(4){{/code}} map.) At present, the {{code}}passwd(4){{/code}} entries are in "NP" mode, where no password is used, but the accounts are not locked. Authentication is instead done using SSH keys exclusively.
123: 
124: In part this is due to password hashing incompatibilities between the web application and Solaris, but the overall experience of using Subversion via SSH is unpleasant if manual password entry is required. Instead, efforts to document use of {{code}}ssh-agent(1){{/code}} and {{code}}ssh-add(1){{/code}} will be made.
125: 
126: == 4. Repository access, read side.
127: 
128: === 4.1 As repository.
129: 
130: Read only access to the repositories will be provided as anonymous access tunnelled through SSH. (For the purposes of initial deployment, we ignore for the moment the various browsable tree CGI scripts the various SCMs offer.) That is, an account entitled "anonymous" will be created with a scheme similiar to the example in Section 2, but with all repositories loopback mounted read-only.
131: 
132: Thus, URIs appear as
133: 
134: > {{code}}svn+ssh://anon@svn.opensolaris.org/svn/project/repo{{/code}}
135: 
136: === 4.2 As static content.
137: 
138: An HTTP server will be established with the various repositories accessible as loopback read-only mounts. Thus,
139: 
140: {{{
141: 
142: http://svn.opensolaris.org/svn/project/repo/foo.c
143: 
144: }}}
145: 
146: will retrieve the HEAD version of foo.c from the project/repo repository.
147: 
148: == 5. Future concerns.
149: 
150: === 5.1 Scaling.
151: 
152: In principle, the number of repositories or the number of operations on the repositories may exhaust the capabilities of a single system. The application may be partitioned initially by separating the SSH-based interactions from the HTTP-based interactions, but the ultimate solution will require splitting the repositories across multiple systems. Achieving this split without fragmenting the external namespace may be problematic, although having SCMs that function correctly across NFS could provide an easy means of alleviating loading issues.
153: 
154: === 5.2 Browsable trees.
155: 
156: Because of the technical attractiveness and modular structure of OpenGrok [1], we defer consideration of the use of per-SCM specific code search/browsing support to a separate, future discussion.
157: 
158: === 5.3 Additional repositories.
159: 
160: It is expected that users will also be permitted to have individual repositories. The project and community namespace has not been managed for conflict with the user namespace, so distinguished paths will be required.
161: 
162: == 6. References.
163: 
164: [1] Chandan Bellur Nandakumaraiah, OpenGrok code search and cross reference engine,http://www.opensolaris.org/os/project/opengrok/, 2005.
165: 
166: == 7. History
167: 
168: 2009-10-07 (kupfer): Add description of how the PAM module manages loopback mounts in the face of concurrent sessions.
169: 
170: 2009-08 (kupfer): HTML cleanup and formatting changes to improve migration to XWiki.
171: 
172: Originally from //"$Id: d-scm-hosting.txt 270 2006-10-13 12:12:26Z $ SMI"//
173: 
174: //Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
175:  stephen dot hahn at sun dot com http://blogs.sun.com/sch///
OpenSolaris

Top Menu

Wiki code for SCM hosting implementation specification

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group tools Pages
