Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Portal

Portal

Emulab Portal Support

Emulab Portal Support

Emulab Portal Support is an experimental feature we have recently developed and are testing. Briefly, the portal support builds on top of the ProtoGeni federation layer, to provide a single signon "web portal" to a group of Emulab's that have agreed to share user accounts and project defintions. One Emulab (perhaps a nodeless Emulab) acts as the portal, and is where all users go for project and account requests. Those accounts and projects (and project subgroups) are then distributed to other Emulab's using the ProtoGeni XMLRPC layer. Not all members of the ProtoGeni federation have to participate; a seperate permission system os used to control who can build accounts on your Emulab.

From the user's perspective, they interact with a single Emulab for their account and project membership, but can access any of the other Emulab's to start or control an experiment. Login is through the portal; they do not need to use the login page at the individual Emulab clusters. A new drop down menu has been added on the user's front page, that has a list of Emulab clusters they can access. Simply choosing a cluster from the list will log the user into that cluster.

The rest of this document is mostly for Emulab administrators. We describe the command line tool that is used to manage the portal, but otherwise assume you are familar with Emulab, know how to administer an Emulab, and understand the ProtoGeni layer. You must also be a member of a ProtoGeni Federation.

Build Emulab with Portal Support

To turn on Portal support, add these two lines to the defs file on the Emulab site that will be acting as the portal. Then reconfigure, rebuild, and reinstall.

	PORTAL_ENABLE=1
	PORTAL_ISPRIMARY=1

On the other Emulab clusters, add the following to the defs file, and then reconfigure, rebuild, and reinstall.

PORTAL_ENABLE=1

At this time, only one Emulab can be the primary.

Adding Peer Clusters

Emulab needs to know about the other clusters; the portal needs to know about all of the (peer) clusters, and the (peer) clusters need to know about the portal. Lets use a simple example of three clusters; EmulabA is the portal and EmulabB and EmulabC are the backend clusters. On EmulabA:

boss> wap manageremote addpeer EmulabB urn:publicid:IDN+EmulabB.net+authority+sa https://www.EmulabB.net
boss> wap manageremote addpeer EmulabC urn:publicid:IDN+EmulabC.net+authority+sa https://www.EmulabC.net

The urn and the url above are examples; you will need to look at the ProtoGeni certificate for each peer cluster, for the appropriate urn. The URL is just the regular url for the web interface. Be sure to use https.

On each of EmulabB and EmulabC, you need to specify the portal site.

boss> wap manageremote addpeer EmulabA urn:publicid:IDN+EmulabA.net+authority+sa https://www.EmulabA.net is_primary

Note the additional is_primary argument, since EmulabA is the portal. The reason for this argument is that we plan to add support for a richer arrangement of portals and peer clusters.

Exporting Projects to Peers

At this time, projects are not automatically exported to all of the peers; an administrator must do this on the command line. To export ProjectA to EmulabB:

boss> wap manageremote addproject EmulabB ProjectA

You can of course export the project to any or all of the peers; just execute the above command for each peer. This operation will result in an RPC operation to the peer, which can take as long as 10-15 seconds.

Note that the project leader and all current and future project members are automatically exported to the peer. Project members are exported in the background (via the portal_daemon), so there is a small delay when adding a user to a project. Typically this delay is less then 10 minutes, unless there is a network partition that prevents the portal from contacting the peer(s).

Exporting Users to Peers

While users are automatically exported to peers (see previous bullet), it is sometimes necessary to do this by hand. To export UserA to EmulabB:

boss> wap manageremote adduser EmulabB UserA

You can of course export the user to any or all of the peers; just execute the above command for each peer. This operation will result in an RPC operation to the peer, which can take as long as 10-15 seconds.

Deleting Users from Peers

To delete a user from a peer:

boss> wap manageremote deluser EmulabB UserA

This operation will result in an RPC operation to the peer, which can take as long as 10-15 seconds.

Note that this operation will fail if the user still has experiments on the target Emulab. Typically, an administrator will need to terminate those experiments on the target Emulab before the user can be removed.

Also note that you may not delete a user from the portal if they have been exported to peers; an administrator must first use the deluser command above.

Extended Commands

Most of the following commands do not need to be run by hand since they happen automatically.

Exporting a Group to a Peer

Project subgroups are automatically exported to peers as they are created on the portal. To run this by hand:

boss> wap manageremote addgroup EmulabB ProjectA,SubGroupA

Note that there is a small delay between the group creation on the portal and when it is pushed out. Typically this delay is less then 10 minutes, unless there is a network partition that prevents the portal from contacting the peer.

Updating a User Profile

User profile modifications are automatically exported to peers after the user makes the change. This includes changes to the user's ssh keys. To run this by hand for a specific user and peer:

boss> wap manageremote moduser EmulabB UserA

Note that there is a small delay before the update is pushed out. Typically this delay is less then 10 minutes, unless there is a network partition that prevents the portal from contacting the peer.

Updating Project/Group Membership

Each time a user is added or deleted from a project or subgroup on the portal, that change is automatically exported to peers. To run this by hand for a specific user and peer:

boss> wap manageremote setgroups EmulabB UserA

Note that there is a small delay before the update is pushed out. Typically this delay is less then 10 minutes, unless there is a network partition that prevents the portal from contacting the peer.