On Mon, 20 Feb 2012 10:38:05 -0500 Brandon Phelps <bphelps@gls.com> wrote: > I'm not sure if this is the best list for this question so please > correct me if not. Probably not the right list, IMHO. > I am putting together some packages for our internal servers and have an > SQL file that I need to run on the database during the package install. > I realize I could put the .sql file in /tmp and simply remove it after > I've successfully imported it into the mysql database like this: > > service mysqld stop > mysqld --bootstrap < /tmp/dbscript.sql > service mysqld start > rm /tmp/dbscript.sql > But I am wondering if there is a better place for this? Yes. From previous experience of exactly these startup situations, there will *always* be situations where the local admin is going to need to redo this SQL injection for whatever reason and it is a lot easier, therefore, if the SQL file is kept in the package, maintained by the package and used from that location by the package. Myself, I'd put the .sql file in /var/lib/ or /usr/share/ and let your postinst read it from there. What is generating the content of the SQL file? If the rest of the postinst generates the SQL itself, then maybe /tmp might be OK but you should allow admins to rescue systems which may get into a state where the first part of the generation process takes an amount of time / hit a bug elsewhere and just having the .sql somewhere outside /tmp and not hidden away in an unusual location would make things easier. Perhaps generate the SQL in the package build and then include it directly in the postinst? (No need to remove it either, for above reasons.) Make life easier for the local admins to see what was done to cover situations where it just doesn't work as expected. Don't hide (or erase) useful stuff...someday, you'll regret that 'rm' when someone files a bug... -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp8ZSx78DfOp.pgp
Description: PGP signature