Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Moved contents to infra.a.o and left a redirect.

When you want to run an application that is not part of the offered services (like a demo setup of the project), you need to request a dedicated virtual machine (vm). It is not possible to request a physical machine. Physical machines are shared resources for all ASF projects.

Infra maintains hosts in different computer centers around the world. Most of these hosts are used to run virtual machines, so your vm can be relocated as requirements change, without you having to reinstall anything.

Requesting the vm

You need to open a Jira issue with at least the following content:

  1. A short description of the use
    1. Why you need a dedicated vm
    2. Is logging in used in the project's application (HTTPS is mandatory for use of login)?
    3. Are any special ports required to be opened?
  2. VM Resources:
    1. CPU cores (default is 1)
    2. RAM (default is 1Gb)
    3. Disk (default is 20Gb)
    4. OS will be Ubuntu latest LTS release; currently 16.04
    5. Name (default is <project>-vm.a.o)
    6. Apache ID of project administrator
  3. Application resources:
    1. Database (infra have central sql servers, with postgresql and mysql supported)
    2. Httpd (installed pr default, configuration is to be agreed upon)
    3. Non-standard packages (will be maintained by puppet)
    4. DNS names needed (default is to create vmname only)
    5. Backup needed (default is NO backups other than what is in puppet)
  4. Maintainers
    1. Provide the name, Apache ID, and contact info for at least three PMC members who will maintain the vm.

CPU and RAM are expensive resources, so we will (unless you make a really compelling case) start the vm with default values, and then if you/we see problems we can always add more. Adding CPU cores/RAM can be done without reinstalling anything.

The OS needs to be supported by our standard applications like puppet, therefore we currently only offer Ubuntu.

Important: the ticket must be acknowledged by a PMC member.

Handling the request

We will have a look at the Jira issue, and maybe ask additional questions using the comments feature on the issue.

Deploying the vm

After all questions have been answered, we will create the vm according to specifications, install the OS and the mandatory standard (infra) applications. The mandatory application guarantee a level of security and provide ssh access common to all vms.

Once we have tested the vm, we will ask the project maintainer to do ssh to the vm.

Project maintainers

The project maintainers are responsible for maintaining the vm. Infra will normally not maintain the vm, but will check on security from time to time.

Each project maintainer needs to have ssh keys uploaded to id.a.o before requesting the vm. ssh keys stored in LDAP are used for logins.

When the vm is created, each maintainer gets karma to access the vm (ldap add host to userid). Once that has been tested, it is time to get sudo karma if it is required.

To prepare for sudo karma follow the OPIE guidelines.

When opie works, contact us on #asfinfra, or by commenting on the issue, and sudo karma will be granted (ldap add userid to sudoer group).

Obtaining ssh keys

To use key-based login, you need to generate a key on your local desktop (do not use a publicly accessible server for this) and then add your public key to LDAP using the self-service app at

Once you have done this, wait at least 10 mins. You should then be able to login as follows:

:::shell $ ssh [username]@$

Depending on your client setup, you may need to run the following command to ensure the key(s) are made available to the ssh client on your system:

:::shell $ ssh-add

If you use PuTTY then ensure that it is configured to force SSH v2 protocol. And use keyboard-interactive.

Once you are logged on, there are few tasks best performed right away. Please take care when using your shell account.

You need to check that your umask is set in a group friendly fashion. This ensures that the documents you create are editable by your fellow committers. To do this, (depending on which shell you use) edit the .cshrc file or .profile (sh derivatives) and ensure that the umask is set as follows:

umask 002

If a umask line already exists, modify it. Otherwise, a new line needs to be added. (You will need to use a *nix command-line editor such as vi.)

Tip: You can view the files of some other committer, e.g. ls -al ~mymentor; cat ~mymentor/.cshrc

General maintenance

There are no mandatory rules, but here are some suggestions:

  1. Keep all changes in Git/Puppet. See:
    1. If you do not have karma, please create PRs in a branch against our Github repository.
  2. Keep all application data in /x1 if possible.
  3. Update puppet with all extra installed packages.
    1. See<vmname>/manifests/init.pp
    2. See also:

A word of warning

Please do not try to change items controlled by puppet, such as:

  1. iptables
  2. sshd
  3. ldap
  4. /root/bin

in essence, anything relevant for security.

As sudoer you are expected to know what you do, and are expected to clear any problems you create.

Before doing something, you are always welcome to join #asfinfra and ask about itThis material has moved here.