[PL #13410] Private Planetlab Broken

Thierry Parmentelat via RT devel at planet-lab.org
Mon Apr 10 06:03:48 EDT 2006


Email Recipients (see http://www.planet-lab.org/Support)
       Owner: Nobody
       Requestor: jaffe at cs.huji.ac.il
       Ticket Ccs: jaffe at cs.huji.ac.il, kirk at cs.huji.ac.il

==================================================

Mark

Thanks for the cvs access.

I like your proposal in that it provides a first step in the right 
direction.

The issue I see with your proposal is that the cache file, 
/etc/plc_config.xml, would still hold some values (e.g. the ones that 
are uuidgen-created).
To workaround this, I'd suggest to populate default_config.xml with 
uuidgen *at install-time*, and then mark the file read-only - (it is 
likely that most of this stuff will need to be run as root, on whom the 
restriction wont apply, but this way we indicate this file should not be 
changed. this is a minor detail)

As a consequence we'd also suppress the ability to set the related 
paswds in /etc/sysconfig (the xml model being way more powerful, let's 
take full advantage of it).

Once this is done we can enforce the policy to store site-dependant xml 
files in /etc/planetlab/configs like you propose, and my own script 
would help doing that. I assume this area would survive an rpm update.

The consolidation of all configs - your cache - could then be generated by

plc-config --xml \
	/etc/planetlab/default_config.xml \
	/etc/planetlab/configs/* \
	> /etc/planetlab/plc_config.xml
The cache could even be cleaned up after we dont need it anymore - so 
maybe the name needs to be changed too. Anyway for the sake of clarity 
we should avoid using default values and  explicitly pass the filename 
to plc-config. What if the default became default_config + configs/*.xml ?


What do you think ? I would volunteer to help in making this happen if 
you agree on the general lines.

PS. I agree the idea of having --save write the last file is not right, 
I tried it myself but realized it was not needed actually.

Thierry

Mark Huang via RT wrote:
> Email Recipients (see http://www.planet-lab.org/Support)
>        Owner: Nobody
>        Requestor: jaffe at cs.huji.ac.il
>        Ticket Ccs: jaffe at cs.huji.ac.il, kirk at cs.huji.ac.il
> 
> ==================================================
> 
> Thierry Parmentelat via RT wrote:
>> Ah yes, I tried to check this in but to no avail (no write access...)
>> would you mind doing it ?
>> btw, I also needed to patch plc_config.py, so that in the save method 
>> the file is open with 'w' mode instead of 'r+', for the initial creation 
>> of the site-specific file
> 
> You should have access to myplc now.
> 
>> I did not make myself clear.
>> I'd like to reach the point where one can routinely update the myplc 
>> rpm. To that end, the plc_config.xml file *needs* to be updated with the 
>> rpm (in case new tunings are introduced), so it needs to be physically 
>> located under /plc/root if I got everything right. And site_config.xml 
>> would then need to be physically located under /plc/data, so that it is 
>> preserved across updates.
> 
> I see. What we need to do, then, is make /etc/planetlab/plc_config.xml 
> just a cache that is rebuilt from all a default template that should 
> never be changed and the files in, say, /etc/planetlab/configs/*. 
> guest.init:reload() would begin like this:
> 
> # Merge any new defaults
> tmp=$(mktemp /tmp/plc_config.xml.XXXXXX)
> plc-config --xml \
> 	/etc/planetlab/default_config.xml \
> 	/etc/planetlab/configs/* \
> 	/etc/planetlab/plc_config.xml \
> 	>$tmp
> mv $tmp /etc/planetlab/plc_config.xml
> 
> # ...rest is the same
> 
> I could change the semantics of --save so that it saves to the last file 
> instead of the first file if we wanted to avoid the temporary file 
> creation, which is kind of ugly. What do you think?
> 
> --Mark
> 
> _______________________________________________
> Devel-community mailing list
> Devel-community at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel-community




More information about the Devel-community mailing list