To help track the status of nodes at your site, we have created a Google Gadget that reports the last observed status of your machine and the last time the status changed. Please give it a try, and if there's a feature you can think of that would make maintaining PlanetLab nodes easier, let us know at email@example.com. Add the gadget to your google home page by clicking on the button:
The PlanetLab 4.2 Upgrade is underway! At the end of the upgrade all machines will be re-installed and include the following new features:
Registration with PI role.
Old netflow log requests. What's in, what's out? How do we get this information for requests?
This work is in preparation for asking sites to update their PCU information for Monitor.
I've created a better view for sites/index.php. It lists all nodes and allows techs or PIs to associate nodes with a PCU.
Additionally, the organization of the code is split more clearly between a template (standard html with minimal php variables, and loops) and control function.
I believe this will make it easier to integrate with additional ajax code later. I will request OneLab for comments on the code reorganization, using sites/index.php as an example.
I've completed a preliminary service for recording node downtimes throught the web.
While users/techs will have to log in twice, since it will not be hosted on the PlanetLab web server, the authentication mechanism uses the PL session key.
This may be kept for just admins. I'm not sure yet.
There is clearly confusion being caused by users still thinking that they need separate BootCD and plnode.txt/floppy files, when they are using the Custom, all-in-one BootCD.
I have made some changes to the myplc/db-config that sends messages, and I will make a few other changes to the GUI to provide in-line hints about what to do or download. I think there may be other sources of information causing confusion.
Also, the bootmanager, should look on the BootCD itself first, and ignore any other node configuration files it finds... Or not?
To facilitate a more structured commit, build, deploy model for the PLC WWW files, I'm working on creating an RPM package for new_plc_www. The idea is that it would be possible to have a nightly, or weekly or whatever build of the *branch*, not just HEAD, and for individual packages to be updated within the MyPLC on guarddog.
Currently, new_plc_www is not a separate RPM, it's just dumped in with myplc-*.rpm. To facilitate a more fine-grained upgrade of just the new_plc_www files, I'm trying to create an RPM.spec file for these files.
Monitor has been suspended this week, due to operational setbacks. At the beginning of the week the database server was experiencing extreme load, and resulting in timeouts or failed boots by remote sites, complicating support for Monitor tickets. Rather than generate additional traffic, I postponed running monitor again.
The mis-match of the PlanetLab-branch.tar.gz bundle that's downloaded during a 'rins' was fixed for I2 nodes (of which there are many), so that after a rins 'codemux' is correctly installed. It's not clear how this happened other than just a stale version of PlanetLab-branch.tar.gz that didn't get updated to the 4.1 version.
Faiyaz and I recognized that the ipod.conf.php script was returning the wrong IP/Subnet to nodes, resulting in misconfigured /proc/sys/net/ipv4/icmp_ipod* values, that prevented api.RebootNode() from working with IPOD.