Re: Temporary Files in Packages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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 <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...
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJPQnSOAAoJEMN150efeMrlby0P+wa/EkpKJOcoRZ1JK1SULtDx
mIEbHCWDXoVO3pGeJ+fgY4comLTS29vdZVnGbocmiMln6tVD0v+U1g0Z61TXb1xS
QPclq3XQRxWlE7+n2JS8yvwx/CmgjEhuDSojOpG/7rMQO1Neu19fpUK3JqoFqjsc
rJfsWwmaX3eMpnmJZrwVdgfdcBIUKS2LVigBtwCr9nCyxzHTkj7P/XX1FgzImDg5
x7uz1+32nNJrOwwIf3pSJ/guVmGJ5ZrCmUmJz84oUzPO4IDHvzJW/fDIczhx+tFG
KWK9v/BDZyBZQ5TXb5LdoxCHzi8pT5VeEDNiRtPh9XGrGLvfOo3meVJ6UAHXrrzz
LC2ReP0eLTJvqJkyi7ge5fp2NmzY1FHugibzR98fI7rUpoZjvfrbRfbkisGXBrAe
7BHcbETuPmIe4Voc33B40tfuxJZ9oj3FDs1to07UC9uw/j2cTnFmxyLRb//CvBIU
Vm8iXRaxWTx5EAhdRjB46Yp08M8kdXK0x7gYofW+yVe+yeCgwfBNR0su01X9FAqK
fJTSjws7cSXC+tQUHesVeChMlh3qsQzvZyM+fKiBmoqH2TZlb4V0uvWyPu7RBLyS
AKS4QU1sz6cSjD8zAdf56JOqYShkpHNIvZO+D5+4NZ+ffesACtjgYwblK9xRn4Qv
oAwdYqaUdw4NW156v0aN
=GE9+
-----END PGP SIGNATURE-----
Reply to: