Temporary Files in Packages
-----BEGIN PGP SIGNED MESSAGE-----
You are right. Now that I think about it, having the script available
after the install could be useful if we ever need to roll back the
database to the initial state sometime down the road.
The .sql itself doesn't need to be generated on the fly by postinst or
anything, it will be a static file that I simply include in the
package. The package itself is a simple web interface for one of our
internal applications. Currently the package installs directly to
/var/www/<appname> but I think I will transition to /opt/<appname> and
simply add an <appname>.conf file to /etc/apache2/conf.d/, this way I
can store all of the web stuff in /opt/<appname>/htdocs, and store
stuff like the .sql script in /opt/<appname>/, which should prevent
access to it from the web.
Thanks for your input!
On 02/20/2012 11:08 AM, Neil Williams wrote:
> On Mon, 20 Feb 2012 10:38:05 -0500 Brandon Phelps <email@example.com>
>> 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
> 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...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org