Temporary Files in Packages
 

Hello all,

I'm not sure if this is the best list for this question so please
correct me if not.

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? For example if
I include the .sql file in the control.tar.gz file (where the postinst
script is) can I access that somehow via the postinst script? Or is
there some other temporary location I can include in my .deb's that will
be accessible during postinst?

I hope this makes sense!

Thanks,
Brandon


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F4268DD.60405@gls.com">http://lists.debian.org/4F4268DD.60405@gls.com

Temporary Files in Packages
 

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/

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
rJfsWwmaX3eMpnmJZrwVdgfdcBIUKS2LVigBtwCr9nCyxzHTkj 7P/XX1FgzImDg5
x7uz1+32nNJrOwwIf3pSJ/guVmGJ5ZrCmUmJz84oUzPO4IDHvzJW/fDIczhx+tFG
KWK9v/BDZyBZQ5TXb5LdoxCHzi8pT5VeEDNiRtPh9XGrGLvfOo3meVJ6 UAHXrrzz
LC2ReP0eLTJvqJkyi7ge5fp2NmzY1FHugibzR98fI7rUpoZjvf rbRfbkisGXBrAe
7BHcbETuPmIe4Voc33B40tfuxJZ9oj3FDs1to07UC9uw/j2cTnFmxyLRb//CvBIU
Vm8iXRaxWTx5EAhdRjB46Yp08M8kdXK0x7gYofW+yVe+yeCgwf BNR0su01X9FAqK
fJTSjws7cSXC+tQUHesVeChMlh3qsQzvZyM+fKiBmoqH2TZlb4 V0uvWyPu7RBLyS
AKS4QU1sz6cSjD8zAdf56JOqYShkpHNIvZO+D5+4NZ+ffesACt jgYwblK9xRn4Qv
oAwdYqaUdw4NW156v0aN
=GE9+
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F42748E.4070407@gls.com">http://lists.debian.org/4F42748E.4070407@gls.com

Temporary Files in Packages
 

Hi Brandon,

On Mon, Feb 20, 2012 at 10:38:05AM -0500, Brandon Phelps wrote:
> 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

You might be interested in

http://people.debian.org/~seanius/policy/examples/dbconfig-common/doc/dbconfig-common-using.html

Depending on your needs, you might be able to use that instead of having to
code anything yourself.


sean


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120222012428.GB27041@cobija.connexer.com">http://lists.debian.org/20120222012428.GB27041@cobija.connexer.com