> I propose a different design: Works for me as long as you also craft a script that handles the run from a whole CSV file.
In other words, the main workflow starts with a single 3-field CSV file exported from an inventory system... > Thinking on an ongoing basis, it also means that it's much easier to > only generate delegations for the schools where the lists of laptops > have changed. You can store md5sums of the one-file-per-school laptop > lists and only re-run that school through the delegation generator if > it has changed since yesterday. Yep, that'd be a nice optimisation. The base scripts pre-date my involvement, and have a horrible approach. I was in a rush and "followed the style", which has ended up not so pretty. A rethink/rewrite is welcome now, before these become popular. I am also thinking of splitting them off into a "olpc-bios-crypto-utils". Makes no sense to carry (and build!) the slow-moving bios-crypto stuff with our fast-moving glue scripts. Did the lib ever get packaged as "libtomcrypt-audited" as was discussed in fedora-devel? m -- [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
