This page documents a current Infrastructure best practice. When editing, please ensure that your edits reflect the consensus.
This page outlines the best/preferred ways to contact infra about various issues --- project questions, resource creation requests, and many others.
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).
Depending on what you want to do, the mode of contact might be Hipchat, email, file a ticket, or a custom webapp. Note that Infra maintains a publicly accessible Hipchat channel.
| If you are.. | and want to.. | then contact.. | Notes |
|---|---|---|---|
| anyone | report a security vulnerability in a service that runs on apache.org | [email protected] | You may optionally encrypt the email to the following set of keys: https://home.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) | Hipchat channel | Hipchat preferred, email to [email protected] 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@$ | |
| 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 | [email protected] | Passwords should be encrypted or sent by other means (to be coordinated) |
| submitted an ICLA in the past | change your contact details of record | [email protected] | 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 [email protected] if you have any questions. |
| existing official download mirror | ask a question concerning your mirror | [email protected] | Questions not suitable for public discussion may be sent to [email protected] (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 [email protected] | Feel free to follow up via Hipchat channel or file a Jira ticket if no reply after 48 hours or so |
| a committer or PMC | change Jenkins (nee Hudson) build settings | email [email protected] | 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 [email protected] | 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 Crack Infra Team | [email protected] | Archives: https://lists.apache.org/[email protected] |
| anyone | ask Infra a question | [email protected] | 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 Hipchat channel and introduce yourself. :-)
The podling creation process is as follows:
The IPMC vote passes.
The podling is added to the IPMC's podlings.xml summary file with status=current.
(See notes about that, and other initial tasks.)
Request INFRA to create the podling's DNS entry by going to service desk and asking for podling DNS for your new podling (include the podling's name)
After DNS is created, an ASF Member or PMC chair files mailing list creation requests.
Infra creates the lists and which will also notify the IPMC of the mailing list creation.
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.
If the podling wants to use SVN, an Incubator PMC member runs svn mkdir ^/incubator/podling. The commit
mail will get delivered to the mailing list created earlier.
If the podling wants to use GIT, one of the mentors should submit a request via https://reporeq.apache.org/
The podling community sets up a project site.
An ASF Member or PMC chair files a website creation request.
If additional services (e.g. Issue Tracker, Wiki, Blogs, etc) need to be created (beyond what is listed above), file a ticket via service desk using appropriate categories and as much information as possible. To save everyone's time, consult "Providing needed information" before filing each ticket.
Please follow the Graduation Guide, and then create the following jira tickets:
Create a "Graduate Foo to TLP" parent ticket.
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 '[email protected]'.
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.
If you forgot your password...
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
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 minotaur.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.
This section applies to everything from "add a moderator" through "create an account for a committer" and up to "set up a new TLP".
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).
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.
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.
| 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 | Moin is deprecated and no more Moin wikis are being created. | Please plan on using Confluence instead. |
| 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 | n/a | Please use reporeq to create your intended Git repo(s). Run svn2git locally using this authors file and push once the conversion result is confirmed. File an INFRA ticket to mark your SVN repository readonly. Optionally, file a ticket to temporarily disable commit emails for when you push your converted clone. |
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.
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).
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 users@infra 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).
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 private@infra
suffices. Pinging people privately (via email, Hipchat, or twitter) is generally
discouraged as then only a single person is aware of a request. . 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.
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.