Index: locker/doc/object-identifiers =================================================================== --- locker/doc/object-identifiers (revision 1026) +++ locker/doc/object-identifiers (revision 1026) @@ -0,0 +1,1 @@ +link /afs/sipb.mit.edu/admin/text/object-identifiers Index: locker/doc/scripts-admin-use-policy =================================================================== --- locker/doc/scripts-admin-use-policy (revision 1026) +++ locker/doc/scripts-admin-use-policy (revision 1026) @@ -0,0 +1,49 @@ + 2008-03-15 + amended 2008-08-05 +Policy on the Use of scripts.mit.edu Administrative Rights + +Users of scripts.mit.edu have a reasonable expectation that the data +and code they store on our servers, and in sections of their locker +accessible only by our servers, will not be improperly accessed or +modified by anyone else, including by scripts.mit.edu maintainers. To +fulfill this expectation, we define a policy governing the +maintainers’ use of special permissions and credentials held by our +servers. This includes any administrative access to the scripts +servers, any use of private keys stored on the servers, and any use of +scripts-specific permissions granted on locker directories. + +Such use of administrative rights shall only be permitted under any of +the following circumstances. + +* Maintenance of the scripts.mit.edu service itself that is unrelated + to private user data. + +* Any access that is explicitly authorized by the owners of the data + in question. + +* Handling a user support request that cannot be satisfactorily answered + without resorting to using administrative rights. This access should + be restricted to only those files and resources that are strictly + necessary to fully answer the request. + +* Performing upgrades to autoinstalled software, using permissions + granted to the system:scripts-security-upd group. This group is + normally empty, but the root instances of scripts maintainers will + be added when needed to perform upgrades, at the discretion of the + architect. + +* Modifications that are necessary for server security or reliability. + In this case, any modifications should be clearly marked and the + user should be contacted. + +* Ensuring that updates or planned updates to the scripts.mit.edu + service do not break existing user deployments. In this case, any + modifications should be clearly marked and the user should be + contacted. + +[The third clause formerly read +* Handling a user support request that can reasonably be considered an + implicit authorization for that use. In this case, whenever + possible, any modifications should be reverted and the user should + be told how to make these modifications themselves. +and was changed in August 2008.] Index: locker/doc/scripts-decision-policy =================================================================== --- locker/doc/scripts-decision-policy (revision 1026) +++ locker/doc/scripts-decision-policy (revision 1026) @@ -0,0 +1,131 @@ + 2007-07-07 +The Decision-Making Policy of the scripts.mit.edu Project: + +We, the creators of the scripts.mit.edu infrastructure, wish to define a +policy for how decisions of the scripts.mit.edu project will be reached in +order to avoid confusion on this subject among future contributors to the +project. We particularly want to avoid a situation in which the +leadership of the project is unclear after we leave MIT. + +In general, we believe that all contributors to the project should have a +say in how the service is run in approximate proportion to their +contributions. We furthermore believe that strong agreement among the +project's principal contributors is highly important to the project's +future, and so, whenever possible, the project's principal contributors +should reach near-unanimous agreement about how the project should +proceed. Ultimately, the decisions of a project of this nature need to be +made by the people who are making the project happen. + +Unfortunately, reaching unanimous agreement among all of the contributors +to the project might not always be possible. This document establishes +two leadership positions for the scripts.mit.edu project in order to +entrust decision-making authority to specific individuals. These leaders +are ultimately entrusted with the project, although they are expected to +take significant pause before using their authority to end a disagreement +before consensus of the principal contributors has been reached. These +leadership positions are based in part on the roles of "producer" and +"director" described in Frederick P. Brooks' _The Mythical Man-Month_. + +The "scripts team leader" is an MIT student who: +- "assembles the team, divides the work, and establishes the schedule" +- "acquires and keeps on acquiring the necessary resources" +- "establishes the pattern of communication and reporting within the team" +- "ensures that the schedule is met, shifting resources and organization + in order to respond to changing circumstances" + +The team leader is responsible for ensuring that the project continues to +make regular progress. The team leader is entrusted with arbitrating +decisions regarding the organization of the scripts team and the focus of +its ongoing development efforts. For example, the team leader may remove +individuals from the project who are deemed to be having an overall +negative influence on the project. + +The "scripts architect" is an MIT student who: +- "provides unity and conceptual integrity to the whole design" +- "serves as a limit to system complexity" +- "invents solutions for [large-scale technical problems] or shifts the + system design as required" + +The architect is responsible for ensuring the technical quality of the +scripts.mit.edu service. The architect is entrusted with arbitrating +decisions regarding the scope, design, and operation of the service. As +the guardian of the technical integrity of the service, the architect may +arbitrate all decisions regarding the project's production hardware and +software. + +Both positions may select their own replacement, and, in the case of a +vacancy, either position may select a replacement for the other position. +Before an individual assumes either position as a replacement, that +individual should be confirmed for that position by the SIPB Executive +Committee. A single individual may hold both positions simultaneously if +every individual who has significantly contributed to the project within +the last one calendar year agrees. Any objections must occur before the +Executive Committee has confirmed the appointment. + +The creator of the scripts.mit.edu project, Jeff Arnold, will serve as the +first team leader and architect. + +Any part of the scripts.mit.edu decision-making policy may be modified as +necessary by agreement between the scripts team leader and the scripts +architect. When changing the scripts.mit.edu decision-making policy, as +with any major decision, near-unanimous agreement among the project's +principal contributors should ideally be reached. + +The scripts.mit.edu project is affiliated with SIPB, and while the project +remains affiliated with SIPB, the project will follow appropriate SIPB +procedures for projects. + +This policy should be distributed to contributors to the project so that +they may decide not to contribute if they are dissatisfied with it. + + + + + + + ____________________________________ + jbarnold + + + + + + + ____________________________________ + presbrey + + + + + + + ____________________________________ + hartmans + + +As contributors to the scripts.mit.edu project, we have contributed to +the creation of this written decision-making policy and we fully support it. + + + + + + + ____________________________________ + tabbott + + + + + + + ____________________________________ + andersk + + + + + + + ____________________________________ + geofft Index: locker/doc/tickets/cnames.txt =================================================================== --- locker/doc/tickets/cnames.txt (revision 1026) +++ locker/doc/tickets/cnames.txt (revision 1026) @@ -0,0 +1,74 @@ +HANDLING CNAME REQUESTS + +When someone e-mails scripts.mit.edu asking for a foo.mit.edu hostname: + +1. Check that the hostname is not currently in use. The commands + stella foo.mit.edu + athrun ops qy ghal foo.mit.edu \* + should both say the name is not in use. (The latter checks for aliases of + deleted or otherwise inactive hostnames that stella ignores.) + + If the name is currently an alias of a name they own, make sure to forward + to jweiss the permission to move that name around. + + If the name is the primary name of a machine they own, ask them what they + would like to rename the machine to, and make it clear that they'll need to + have another name associated with that IP address. Or (especially if the + machine doesn't ping) ask them to confirm they're no longer using that IP + address. If they're totally confused and keep insisting they want scripts + to serve that name, go ahead and tell them you'll rename the current foo to + foo-old. + + If the name belongs to a deleted host on a dorm network, e-mail rccsuper to + reap it; they should do so quickly. If it belongs to an FSILG, e-mail + ht-$ILG-acl (ht-et-acl, ht-pika-acl, etc.) and ask nicely. If it belongs + to an academic network, they're not getting the name back unless they can + negotiate with the current owner of the name + +2. Check that they're requesting a scripts.mit.edu path that they control + (preferably, they'll give you a locker.scripts.mit.edu/something URL). If + they want a web.mit.edu path, you'll need to tell them to set up a redirect + according to http://scripts.mit.edu/faq/63/ in a directory in their + web_scripts, and ask them to tell us the directory. This doesn't block + requesting the hostname. + + If they want something more outlandish, make sure they're not confused + before proceeding. + +3. E-mail jweiss. + * Open the ticket in RT + * Click 'Comment' to the right of the body of the e-mail they sent + * CC: jweiss@mit.edu (Don't use "To:", there's a bug) + * Write something nice. I typically use + Subject: scripts CNAME request: foo.mit.edu + + At your convenience, please make foo.mit.edu an alias of scripts.mit.edu. + (or) + At your convenience, please move the alias foo.mit.edu from bar.mit.edu to + scripts.mit.edu. + (or) + At your convenience, please rename the current host foo.mit.edu to + foo-old.mit.edu and make foo.mit.edu an alias of scripts.mit.edu. + (or) + If the request below is sufficient authorization, please remove.... + + * Set Status => Waiting and Blocking On => Moira + + Occasionally jweiss is on vacation; check /mit/ops/Pager.Schedule for + "!jweiss" entries. It's worth asking him ahead of time if he's around. If + not, see if zacheiss or cfox or computing-help will handle the requests. + (zacheiss has been willing to do them in the past.) + +4. Reply to the requestor (from either RT or your e-mail client), with + something like "We've forwarded the hostname request to IS&T; it should take + effect in 2-3 business days." + +5. After the name updates (jweiss replies, and DNS updates - which you can + check on -i dns), ask someone with root access to run + + vhostadd foo.mit.edu + +6. Reply to the requestor again, and help them with stuff like MediaWiki URLs + or RewriteRules if they're having trouble. + +--geofft, last updated 2008-08-02 Index: locker/doc/tickets/rt.txt =================================================================== --- locker/doc/tickets/rt.txt (revision 1026) +++ locker/doc/tickets/rt.txt (revision 1026) @@ -0,0 +1,28 @@ +RT TRICKS + +To edit stuff like ticket status, click "Basic" in the left. + +Note the multiple ways to search for tickets: you can click "All +{new,open,waiting} Scripts Tickets" on the home page in the center, or +"Scripts" on the right in the list of queues. + +You should take a look in "Preferences" at the left. Make sure "Notify +yourself of own updates" is on. You can also set the "Default Working Queue" +to Scripts, and give yourself a signature referring to scripts@mit.edu. +Another useful option here is to set a password, so you don't need certs to +log in (and so you can use the zephyrbot). + +The zephyrbot (currently down) will take commands to -c scripts -i [ticket +number] of the form /set status=resolved or /set owner=geofft. + +You can also place these commands on a line by themselves inside e-mail; they +will be acted upon and removed before the e-mail gets sent back out. + +Don't use the To field, it doesn't work. If you want to send the ticket somewhere else, use CC. + +Don't CC other RT queues, it doesn't work. If you really need to, use your +e-mail client to forward it and remove the [help.mit.edu #nnn] tag. + +E-mail to scripts-comment that carries a [help.mit.edu #nnn] tag will be +included in the ticket history for the scripts team to see, but will not be +sent to the user. You can use this for asking "Help, what do I do here?"