Status

This page documents a current Infrastructure best practice. When editing, please ensure that your edits reflect the consensus.

Abstract

This page outlines the best/preferred ways to contact infra about various issues --- project questions, resource creation requests, and many others.

Should I contact the Infrastructure Team?

Normally yes, although we sometimes receive queries that are best directed at another entity:

  • If your query concerns an Apache project, contact the project directly (start from their http://{project}.apache.org/ homepage).

  • If a service is down, unresponsive or failing, check http://status.apache.org first. If it's listed as down on that page, chances are we already know about it.

  • If you have a feature request for a software that ASF servers run (such as JIRA or Review Board), and it cannot be implemented by changing the configuration (e.g., editing httpd.conf), report a bug to the upstream project (e.g., http://www.atlassian.com/software/jira, http://www.reviewboard.org/).

  • Requests for simple configuration changes and karma grants can often be done by someone in the project (for example, the volunteer moderators and project-wiki admins).

Should I email you, fill a webapp form, or file a ticket?

Depending on what you want to do, the mode of contact might be IRC, email, file a ticket, or a custom webapp. Please refer to the following table of options, and pick the first one that applies:

If you are.. and want to.. then contact.. Notes
anyone report a security vulnerability in a service that runs on apache.org root@apache.org You may optionally encrypt the email to the following set of keys: https://people.apache.org/keys/group/infrastructure-root.asc.
anyone report a security vulnerability in an Apache project Apache Security Team The Security Team is not part of the Infrastructure Team.
anyone report that a service is down (and http://status.apache.org/ doesn't show that) IRC channel #asfinfra on Freenode (irc://chat.freenode.net, Browser-based client available) IRC preferred, email to infrastructure@apache.org is an acceptable alternative. The infrabot twitter feed may contain information about current outages and maintenances.
a newly-invited committer ask a question about your committership private@${project}.apache.org, for the project that invited you to become a committer
a committer regain access to your account; resetting your password didn't work See "Regaining account access", below. If commits fail, double-check that you are using https:// (not http://).
a supplier (you donate or sell hardware or services to Apache) anything infrastructure-private@apache.org Passwords should be encrypted or sent by other means (to be coordinated)
submitted an ICLA in the past change your contact details of record secretary@apache.org Fax or snail mail are possible too; see https://www.apache.org/foundation/contact
prospective official download mirror request being listed as an official download mirror see the "new mirror" documentation Please email mirrors@apache.org if you have any questions.
existing official download mirror ask a question concerning your mirror mirrors@apache.org Questions not suitable for public discussion may be sent to apmirror@apache.org (currently an alias with limited distribution).
anyone report a problem with a download mirror (other than it being out of date) the Apache project whose product you were trying to download The project will escalate to infra if necessary.
anyone unsubscribe from a mailing list See unsubscription instructions
a committer change your account details Selfserve at https://id.apache.org/ Details include forwarding email address, password, and SSH or PGP public keys of record.
a PMC request account creation for a newly-elected committer https://id.apache.org/acreq/ See docs for details
a newly-accepted podling create podling infrastructure (site, lists, etc) See below
a podling that has just graduated migrate resources from Incubator locations to TLP locations See below
an existing PMC or podling request mailing list creation https://infra.apache.org/officers/mlreq Only Members and Officers (this includes all PMC chairs) can submit the form.
a committer or PMC add/remove mailing list moderators email apmail@apache.org Feel free to follow up via IRC to #asfinfra or file a Jira ticket if no reply after 48 hours or so
a committer or PMC change Jenkins (nee Hudson) build settings email builds@apache.org Some tasks can be done by project members having hudson-jobadmin karma; ask your dev@ list
a PMC request Infrastructure to do something create a JIRA ticket See "On Requests" and "Providing needed information", below.
an Officer of the ASF ask an organizational question (as opposed to technical) VP Infrastructure, or infrastructure-private@apache.org The target audience for this item is the Apache Board of Directors, the VP Fundraising, etc.
posted to an Apache mailing list edit the mail archives Public Forum Archive Policy Virtually all requests are denied.
anyone discuss something publicly with the Team infrastructure-dev@apache.org Archives: http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/
anyone ask Infra a question infrastructure@apache.org The infra@ mailing list should be considered a semipublic list as many Apache committers --- not only Team members --- are subscribed.

Finally, if you would like to volunteer, please join IRC and introduce yourself. :-)

Requesting podling creation

The podling creation process is as follows:

  1. The IPMC vote passes.

  2. The podling is added to the IPMC's podlings.xml summary file with status=current. (See notes about that, and other initial tasks.)

  3. An ASF Member or PMC chair files mailing list creation requests.

  4. Infra creates the lists and notifies the IPMC.

  5. An Incubator PMC member who is also an ASF member or a PMC chair edits asf-authorization-template and adds a [/incubator/podling] section. If the section refers to an @podling group, a definition of that group, as a comma-separated list of availids (usernames), MUST be added to the [groups] section. Alternatively, just set @incubator = rw as the section's body.

  6. An Incubator PMC member runs svn mkdir ^/incubator/podling. The commit mail will get delivered to the mailing list created earlier.

  7. The podling community sets up a project site.

  8. An ASF Member or PMC chair files a website creation request.

If additional services need to be created (beyond mailing lists, svn tree, and web site), file one "Create Foo Podling" parent ticket in JIRA and one sub-task ticket for each service. (If you have N services, create N sub-tasks.) To save everyone's time, consult "Providing needed information" before filing each ticket.

Requesting podling->TLP graduation

Please follow the Graduation Guide, and then create the following jira tickets:

  1. Create a "Graduate Foo to TLP" parent ticket.

  2. Create a "Foo TLP: common tasks" ticket as a sub-task of (1). This ticket will handle: DNS entry, Unix/LDAP group creation, PMC Chair karma, mailing list migration, native Git repository migrations (but not git-svn mirrors), Subversion public tree migration, buildbot config changes, website migration. There is no need to file individual tickets for these tasks.
     
    In the ticket, specify the UNIX name of the TLP --- that is, the 'foo' in 'dev@foo.apache.org'.

  3. For each additional service that needs configuration changes as the result of the migration, create another sub-task of (1). (If you have N services, create N sub-tasks.) "Services" here includes everything pointered below, including (but not limited to): Subversion private tree, git-svn mirrors, issue trackers, wikis, continuous integration (Jenkins, Buildbot, Continuum etc.)

See Flex's graduation tickets for a good example.

Note that the new PMC chair is still responsible for using modify_unix_group.pl as appropriate. The group membership is initialized on a best-guess basis, but the chair must check that it's accurate and add/rm people as needed. The modify_committee.pl data, however, is initialized directly from the Board resolution and as such should be correct.

Regaining access to an account (committers only)

If you forgot your password...

  1. Try to reset it at https://id.apache.org/reset/enter. That will email your @apache.org address (which forwards to your non-apache email account) a short-lived password reset link. (The link may be encrypted to your PGP key.)

Decrypting the e-mail - one way to do this is as follows:

Save the e-mail contents as a text file, e.g. password.txt. Open a shell command window, and run the following command:

gpg -d password.txt

This should decrypt the file and display the output in the window

  1. If that didn't work, you need to email root@. In your email, mention the following information:

    • Your username.

    • The fact that you have tried a self-service password reset, and why it didn't work. (Was the mail received? Did you decrypt it successfully?)

    • Why you need to regain access to your Apache account --- e.g., if it is to work on a foundation project, name that project; or if you are a foundation member, state that.

    • Whether you have SSH access to people.apache.org (or to a PMC jail/zone/VM) via public-key authentication

    • Whether you ever set up OPIE on any *.apache.org box. (This is only applicable to people who had root on PMC VMs.)

    • Whether you have access to the private part of a PGP key associated with your Apache account.

    • Whether the contact information on your ICLA is valid.

    • (ASF Members only) Whether the contact information in your members.txt entry is valid.

    • Whether you are able to send a new ICLA, with the same signature as your original one, which specifies new contact information.

    • Whether there is any other way in which we (infra) might satisfy ourselves that you --- a person asking us to reset the password of a given @apache.org account --- is the legitimate owner of that account.

Note: please do not ask other ASF committers or Members to email root@ and vouch for you.

On Requests

This section applies to everything from "add a moderator" through "create an account for a committer" and up to "set up a new TLP".

What can I ask for?

See list of services we run. If you want something that isn't listed, get in touch --- it might be possible to support it (especially if the feature request is equipped with volunteers who will help maintain it --- hint, hint).

Where should I submit my request?

Briefly, if there is a dedicated webapp, use it; if not, file a JIRA ticket. The complete answer is in the table above. Please read the table before filing a ticket - often you or someone in your PMC can effect the change without involving infra at all.

Before you press Send

  • Do ask in your project whether someone has the karma to implement the requested change before asking infra. (This eases the load on the infra team: we are a dozen volunteers looking after 100+ projects, so we delegate what we can.) The moderators and volunteer admins of the project's issue tracker and wiki can often address issues with those services.

  • Do aggregate requests: instead of sending five emails each asking for one more moderator to be added, send one email asking for five moderators to be added.

  • Do CC your PMC on emails. In JIRA tickets, it is helpful to link to a thread that demonstrates PMC consensus. (If you request a significant or major configuration change, we will probably ask for that link if you don't provide it.)

  • If you create a JIRA ticket, do create it in the right JIRA component. (If it's not obvious which component is the right one, it's a bug in the documentation.) (This helps our volunteers efficiently spot outstanding tasks in their areas.)

  • Be patient. Remember that everyone is a volunteer.

  • Research your topic. See the developer information homepage.

  • Thanks. Making requests following these guidelines might be a little effort, but saves time for all involved.

Providing needed information.

If you ask us to.. then we need to know.. Notes
Promote a podling to TLP See above
Create a podling See above
Load Subversion history URL and checksum (or PGP signature) of a dumpfile; proof of IP rights Produce with svnadmin dump --incremental --deltas or svnrdump. The paths within the dumpfile should be relative to the project root (e.g., to /repos/asf/incubator/MyPodling).
Load Git history URL and of a repository or an export stream; proof of IP rights If linking to a file, provide PGP signature or checksum. If to a remote repository, you will be asked to review and sign off on the import ("Yes, that is the repository and history we asked to import and have IP rights for") before it will be writable.
Create a CMS-based site URL of the layout-compliant site source, and what build system to use Build system types include: default (path.pm), shell (build_cms.sh), maven/ant/forrest. Use the webreq app. Followup post-setup to complete the process.
Create an svnpubsub-based site SVN URL of the compiled site (directory containing HTML files) Git is not supported by svnpubsub. Use the webreq app.
Create an svnpubsub-based Dist area Create or ask to create dist release dir. Specify release area only or release and dev areas. Mailing list for commits to go, if omitted the default is the project commits list. Any existing release dir will be blown away (archive releases remain). A release or KEYS/NOTICE file will be asked for upon creation.
Create a project blog project name, brief one-line description of the project, and Apache usernames (and fullnames) of 1+ editors
Create a blog account (for an editor) The Apache username (and fullnames) of the editor Non-PMC members need to demonstrate PMC consensus too (link to a lazy consensus thread suffices).
Create a moin wiki wiki name, destination for commit mails, and moin usernames of two+ community members - volunteer AdminGroup members See http://s.apache.org/moin-wiki-access-control. Make sure the users can sign in to the new wiki before (asking to) add them to AdminGroup.
Create a confluence wiki wiki name, destination for commit mails, and confluence usernames of two+ community members - volunteer space admins
Set up your project on Review Board Project name, which svn/git branches to support
Create a JIRA project Key name (e.g., INFRA), JIRA usernames of 1-2 project members - volunteer project admins, mailing list address to which JIRA notifications should go The INFRA JIRA you will file must use the "New JIRA Project" issue type.
Migrate your project's SVN to Git project unix name, project layout, portions of svn tree to leave writable (e.g. ASF CMS site sources)
Grant a committer SSH access to a puppet-ed VM committer's availid (username), VM hostname The committer must add his key to id.a.o beforehand.
Grant a committer root access to a puppet-ed VM committer's availid (username), VM hostname The committer must already have SSH access, and must set up OPIE beforehand.

Don't see here what you're looking for? See above for other cases.

My issue got closed with a request to reopen it.

Then reopen it. Usually we ask that you do something as you reopen it, so do that too (or say why you didn't).

Background: we tend to close issues that are not actionable upon by us for an extended period, since we use the INFRA queue as a todo list. In our workflow, this kind of close/reopen cycle is a matter of ordinary routing (much like reverting a commit that broke the build system).

My issue got ignored.

There could be a few reasons: some areas are staffed mainly by volunteers, so may have longer turn-around times (relative to other areas); sometimes we're busy on backend projects (e.g., installing new hardware via our remote hands) and have little time for user-facing tasks; sometimes an issue blocks on prerequisite new hardware to get shipped, installed, and configured, which takes time; sometimes we're just backlogged and are working on issues ahead of yours in the queue; and sometimes we do tickets of a certain category in batch, and yours will be done in the next batch in a few days.

If you'd like to inquire as to the status and ensure your issue doesn't get lost, feel free to add a comment to the relevant JIRA issue (if any) to that effect, or email the infrastructure@ list with a question. If the matter remains unresolved after that, feel free to escalate the matter to the VP, Infrastructure or to the operations@ privately-archived mailing list (everyone may post to it).

In case of emergency

The following describes how to page root@ people when there is an absolutely urgent problem, such as a malicious cracker having an active root shell on archive.apache.org. This is only intended for pressing, ASF-wide problems that must be handled at once, even if that means waking people up in the middle of the night or having them miss their flight.

Normally, pinging #asfinfra or emailing root@ or infrastructure-private@ suffices. Pinging people privately (via email, IRC, or twitter) is a recommended second route. If all of these have been exhausted, or are not sufficiently timely, the last resort is to look up root@ people (see list of names here or here) and call them or SMS them. Infrastructure volunteers can do that with the sms command in infrabot.

Finally, the VP Infrastructure has the authority to contact third parties directly. The contact information is available to him via docs/vp/littleblackbook.txt.

Reminder: this facility is for emergency use only. It wakes people up.