I think that a minor variation on Neil's strategy should not be too
difficult to do (but I'll certainly agree that it is not an ideal
situation). What you'd do is first just download (via the "Bam" method
below :) the planet packages you want. Then, if you look inside this
directory:
(build-path (find-system-path 'addon-dir)
"planet"
"300")
you should find some files with extensions ".plt". Re-build that same
portion of the directory structure to contain those files in the
deployment environment, and then set the PLTPLANETURL environment
variable to something bogus.
This should set you up to re-create the same planet setup. You will
still have the planet install step happening on each machine (each
filesystem with the path above, technically), but setting PLTPLANETURL
will ensure that planet cannot get online to try to find new (possibly
untrusted) versions of things.
hth,
Robby
Also, FWIW, I maintain, in the weakest sense of the word, the current
planet service. (All I really do is react to emergencies that break
things.) Jay and Eli are looking into a whole new thing and have been
talking about it for more than a year, I believe, so hopefully plans
are firming up. Their system should be able to support this kind of
use-case much more effectively. I think that kind of thing is designed
in for them.
On Thu, Dec 29, 2011 at 8:50 PM, Neil Van Dyke <n...@neilvandyke.org> wrote:
> Daniel Farina wrote at 12/29/2011 07:59 PM:
>
>> The goal is that a program written, say, three
>> years ago should be able to run the same way it did when it was
>> written, so it's really useful to freeze all the dependencies into the
>> file system somehow and preserve it.
>>
>
>
> Someone else can comment on any automated ways of ``compiling in'' PLaneT
> packages, and solutions like that.
>
> A so-so solution I *don't* recommend... If you preserved the exact PLaneT
> linkage table, and were very careful, then I think you could preserve the
> exact versions of PLaneT modules used ("required" directly, and indirectly).
> This assumes either: (1) integrity of the PLaneT server, and trust in your
> connection to it; or (2) preservation of the pertinent parts of "~/.racket".
> Then you'd want to disable attempts to access the PLaneT server. Perhaps,
> if you were to automate this, it could be done safely and reliably.
>
> Something that has been done for a large Racket-based Web app on production
> servers is to manually determine all the PLaneT packages that are used,
> downloaded and extract these packages (in a directory scheme that preserves
> naming and version info), check it all into their configuration management
> system, change all the PLaneT module references to filesystem ones, check it
> into CM again, and audit. PLaneT server access is always blocked, except
> for the manual download. You can make simple tools to help automate the
> more mechanical parts of this (I don't know of any such tools publicly
> available at this time), but the audit is mostly human expertise-intensive.
> This cloning of PLaneT packages is not something that most people need to
> do, and it totally spoils the buzz of ``I'll just add a "(require (planet
> ...))" and bam!,'' but it's not too hard to do if you choose to.
>
> PLaneT isn't my baby (I think Jay and Eli are leading it right now), but I'm
> looking into funding so that I can put solid chunks of time into helping
> with ways to improve PLaneT security. Security is usually a constant
> consideration in my Internet consulting work. Part of this tentative work
> will address your concerns about stability, and (in my current thinking)
> about having the option of removing PLaneT server dependencies for an app.
> Much of this work has implications for some other network software
> distribution methods, so PLaneT is both a research testbed and an early
> practical beneficiary (much like Racket in general). Stay tuned (I have a
> lot more experience in solving problems than in writing research grant
> proposals).
>
> --
> http://www.neilvandyke.org/
>
>
> _________________________
> Racket Developers list:
> http://lists.racket-lang.org/dev
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
