4. VO Configuration¶
This section provides the needed steps for supporting a new VO in your infrastructure
4.1. EGI AAI¶
4.1.1. OpenStack¶
The usual method of supporting a VO is by creating a local project for it. You should assign quotas to this project as agreed in the OLA defining the support for the given VO.
4.1.1.1. Check-in VOs (OpenID Connect)¶
Follow these steps if you are using OpenID Connect to integrate with EGI:
Create a group where users belongig to the VO will be mapped to:
group_id=$(openstack group create -f value -c id <new_group>)
Add that group to the desired local project:
openstack role add member --group $group_id --project <your project>
Expand your mapping.json with the VO membership to the created group (substitute
group_id
andvo_name
as appropriate):[ <existing mappings>, { "local": [ { "user": { "name": "{0}" }, "group": { "id": "<group_id>" } } ], "remote": [ { "type": "HTTP_OIDC_SUB" }, { "type": "HTTP_OIDC_ISS", "any_one_of": [ "https://aai-dev.egi.eu/oidc/" ] }, { "type": "OIDC-eduperson_entitlement", "regex": true, "any_one_of": [ "^urn:mace:egi.eu:group:<vo_name>:role=vm_operator#aai.egi.eu$" ] } ] } ]
Update the mapping in your Keystone IdP:
openstack mapping set --rules mapping.json egi-mapping
4.1.1.2. Legacy VOs (VOMS)¶
When using the Keystone-VOMS module, you should follow these steps:
Configure your LSC files according to the VOMS documentation, e.g.:
mkdir -p /etc/grid-security/vomsdir/ops cat > /etc/grid-security/vomsdir/ops/lcg-voms2.cern.ch.lsc << EOF /DC=ch/DC=cern/OU=computers/CN=lcg-voms2.cern.ch /DC=ch/DC=cern/CN=CERN Grid Certification Authority EOF cat > /etc/grid-security/vomsdir/ops/voms2.cern.ch.lsc << EOF /DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch /DC=ch/DC=cern/CN=CERN Grid Certification Authority EOF
Add the mapping to your
voms.json
mapping. It must be proper JSON (you can check its correctness online or withpython -mjson.tool /etc/keystone/voms.json
). Edit the file, and add an entry like this:{ "<voname|FQAN>": { "tenant": "<project_name>" } }
Note that you can use the FQAN from the incoming proxy, so you can map a group within a VO into a tenant, like this:
{ "dteam": { "tenant": "dteam" }, "/dteam/NGI_IBERGRID": { "tenant": "dteam_ibergrid" } }
Restart Apache server, and it’s done.
4.1.2. OpenNebula¶
TBC
4.2. EGI Accounting¶
4.2.1. OpenStack¶
Add the project supporting the VO to cASO:
projects
in/etc/caso/caso.conf
projects = vo_project1, vo_project2, <your_new_vo_project>
as a new mapping in
/etc/caso/voms.json
{ "<your new vo>": { "projects": ["<your new vo project>"] } }
Be sure to include the user running cASO as member of the project if it does not have admin privileges:
openstack role add member --user <your caso user> --project <your new vo project>
4.2.2. OpenNebula¶
Update /etc/oneacct-export/groups.include
or /etc/oneacct-export/groups.exclude
to allow extracting information from the new group. Specify one group name per line.
4.3. EGI Information System¶
4.3.1. OpenStack¶
Add the user configured in your cloud-info-provider as member of the new project:
openstack role add member --user <your cloud-info-provider user> --project <your new vo project>
4.4. EGI VM Image Management¶
4.4.1. cloudkeeper-core¶
Add the new image list to the cloudkeeper
configuration in /etc/cloudkeeper/cloudkeeper.yml
(or /etc/cloudkeeper/image-lists.conf
if using the appliance), new entry should look similar to:
https://<APPDB_TOKEN>:x-oauth-basic@vmcaster.appdb.egi.eu/store/vo/<your new vo>/image.list:
4.4.2. OpenStack¶
Add the user configured in cloudkeeper-os as member of the new project:
openstack role add member --user <your cloudkeeper-os user> --project <your new vo project>
Add the mapping of the project to the VO in /etc/cloudkeeper-os/voms.json
:
{
"<your new vo>": {
"tenant": "<your new vo project>"
}
}