| 237 | |
| 238 | This is a standard perfSONAR exchange. We send a NMWG request and get back a response with an eventType and possibly a response message. In this case the eventType is "success.ma.replaced" and the message "data element(s) successfully replaced". Great! Everything worked. Our topology is now in UNIS and our services can request it to learn more about the network and their own configuration. If this step fails for you, check that your credential is valid, that you're using the right certificate for the credential, and that you gave the correct slice URN. Contact us at lamp@damsl.cis.udel.edu if the problems persist. |
| 239 | |
| 240 | === 4. Request and setup the LAMP certificate === |
| 241 | |
| 242 | Right now our topology is on UNIS and our slice has started/is starting. Because of security considerations, only those with a valid slice credential can access the slice's topology information in UNIS. However, LAMP services rely on that information to configure themselves (and sometimes also need to communicate with each other). This requires LAMP services to have access to a special certificate that grants them the necessary permissions. Right now the only way we have to provide this is to give users a slice specific certificate that lasts until the slice's expiration time (given in the slice credential). Users can request this certificate with the lamp-getcertificate.py script. This script works similarly to the ProtoGENI test scripts and requires only the name of the slice as an argument. |
| 243 | |
| 244 | {{{ |
| 245 | fernandes@debian:~/dev/geni$ test/lamp-getcertificate.py -n lamptutorial |
| 246 | Got my SA credential, looking up lamptutorial |
| 247 | Asking for slice credential for lamptutorial |
| 248 | Got the slice credential |
| 249 | Asking for my lamp certificate |
| 250 | Paste the following certificate *as is* into a file called lampcert.pem |
| 251 | Upload the certificate to all LAMP enabled nodes at /usr/local/etc/protogeni/ssl/lampcert.pem |
| 252 | -----BEGIN RSA PRIVATE KEY----- |
| 253 | ... certificate's private key ... |
| 254 | -----END RSA PRIVATE KEY----- |
| 255 | Certificate: |
| 256 | Data: |
| 257 | ... certificate's data ... |
| 258 | |
| 259 | X509v3 Subject Alternative Name: |
| 260 | URI:urn:publicid:IDN+emulab.net+service+lamp@lamptutorial |
| 261 | ... |
| 262 | |
| 263 | -----BEGIN CERTIFICATE----- |
| 264 | ... certificate ... |
| 265 | -----END CERTIFICATE----- |
| 266 | }}} |
| 267 | |
| 268 | Following the instructions shown by the script, we copy paste the certificate '''with the private key''' into a file, say lamptutorial-cert.pem (you can call it anything you want locally, but it must be called lampcert.pem at the nodes). This file will then need to be uploaded to each of the nodes that have LAMP services at the indicated location: /usr/local/etc/protogeni/ssl/lampcert.pem. (Sorry for the work this causes right now, we will try to streamline it in the future.) Note that the certificate file cannot be password protected because services will use it without user intervention. |
| 269 | |
| 270 | To upload the certificate to all the nodes we can use the following Unix commands. Feel free to do it in your preferred way. |
| 271 | |
| 272 | Get the list of hostnames in our slice (you might need manually check if some nodes are not LAMP related): |
| 273 | |
| 274 | {{{ |
| 275 | $ grep "login" lamptutorial-manifest.xml |
| 276 | <services><login authentication="ssh-keys" hostname="pc123.emulab.net" port="22"/></services></node> |
| 277 | <services><login authentication="ssh-keys" hostname="pc112.emulab.net" port="22"/></services></node> |
| 278 | <services><login authentication="ssh-keys" hostname="pc99.emulab.net" port="22"/></services></node> |
| 279 | }}} |
| 280 | |
| 281 | Use bash scripting to upload the certificate, move it to the right place, set the correct permissions and owner/group, and finally restart pSConfig: |
| 282 | |
| 283 | {{{ |
| 284 | $ for node in pc123.emulab.net pc112.emulab.net pc99.emulab.net; do |
| 285 | > scp lamptutorial-cert.pem fernande@$node: |
| 286 | > ssh fernande@$node "sudo mv lamptutorial-cert.pem /usr/local/etc/protogeni/ssl/lampcert.pem" |
| 287 | > ssh fernande@$node "sudo chown root.perfsonar /usr/local/etc/protogeni/ssl/lampcert.pem" |
| 288 | > ssh fernande@$node "sudo chmod 440 /usr/local/etc/protogeni/ssl/lampcert.pem" |
| 289 | > ssh fernande@$node "sudo /etc/init.d/psconfig restart" |
| 290 | > done |
| 291 | }}} |
| 292 | |
| 293 | Note that services run under the ''perfsonar'' user, and the httpd server will read the certificate as ''root''. The last step is to (re)start ''pSConfig'', the service that fetches and configures the nodes according to the topology information. If you did not setup the RSpec to run the bootstrap.sh script on startup, you will need to run it on all nodes before starting pSConfig (e.g. I would add {{{ssh fernande@$node "sudo /usr/local/etc/lamp/bootstrap.sh urn:publicid:IDN+emulab.net+slice+lamptutorial urn:publicid:IDN+emulab.net+user+fernande"}}} before the last line on the above command, while you would need to change the slice and user URNs). |
| 294 | |
| 295 | === 5. Accessing the LAMP Portal === |
| 296 | |
| 297 | We have now uploaded our slice's topology to UNIS and we have setup our nodes with the LAMP certificate (and bootstrapped the configuration). As soon as pSConfig starts, the service will contact UNIS and fetch the configuration for the node. On our tutorial's RSpec, only one service is enabled for now: the LAMP Portal on the ''lamp'' node. pSConfig will thus enable the service automatically. It can take up to 5 minutes for services to start/stop based on configuration changes (a ''service watcher'' script runs every 5 minutes and will make sure that any enabled/disabled services are running/stopped). |
| 298 | |
| 299 | After a few minutes we try to access the LAMP Portal at our ''lamp'' node: https://pc99.emulab.net/lamp/. To our surprise, however, we get an error: |
| 300 | |
| 301 | [[Image(portal-error.png)]] |
| 302 | |
| 303 | We're sorry that right now our error reporting is so uninformative, so the user doesn't really know what happened. Looking at the error log for the web server (/var/log/apache2/error.log) we see the following error message: |
| 304 | |
| 305 | {{{ |
| 306 | [Tue Sep 21 16:44:17 2010] [error] [client 128.4.62.115] You're not authorized to access this service. at /opt/perfsonar_ps/perfSONAR_PS-Toolkit/web/root/gui/services/../../../../lib/perfSONAR_PS/Utils/GENIPolicy.pm line 91. |
| 307 | }}} |
| 308 | |
| 309 | Ah, so everything makes sense now. We either did not use a certificate to access the server, or used a certificate for a user that is not allowed to access the service. Currently in our slice, only us (the slice owner) will be able to access the LAMP Portal with their ProtoGENI certificate, or anyone using the LAMP certificate (remember, LAMP services trust the LAMP certificate implicitly! so be carefully with it). To setup you browser to use a certificate, if you haven't done so already, follow the instructions at [https://www.protogeni.net/trac/protogeni/wiki/FlashClientSetup ProtoGENI Flash Client Setup]. You'll have to look for similar instructions for other browsers (e.g. for [http://code.google.com/p/chromium/wiki/LinuxCertManagement Google Chromium]). |
| 310 | |
| 311 | After setting up the certificate |
| 312 | |
| 313 | |