Re: help with packaging (preinst scripts)
Hi Karl, thanks for your answers
Pre-inst? It is quite uncommon do need to do much in the
PRE-installation script. Most things end up in the post-installation
scripts - e.g. many of the existing packages which create users do so
in their post-installation scripts.
yes I suppose what is done in the preinst script for the package I'm working
on could be done in the postinst script - not sure why it was in preinst
in the first place ..
Setting a password for the user: That's a very strange thing to do in
an installation script, as it implies that the password is
predictable. Which is probably a very bad idea for security.
I know this sounds weird, but the context is this : we're talking about
company LAN servers (not internet-facing servers). Some people in
the Operations team will know the password, some other users won't.
Those who know the password have to be able to use a login shell
under this account. This is an internal company application.
However,
you can probably get the installation to generate a random password
and set it (but this still leaves the problem of communicating the
password out in a secure fasion):
password=$( perl -e 'print map{("a".."z","A".."Z",0..9)[int(rand(62))]}(1..16)' )
interesting, but not applicable here.
echo "newuser:$password" | chpasswd
chpasswd is probably the command I need in this case - thanks.
If it is a system-type user, then the user should not be able to log
in anyway, so it will be not be necessary to create a password. Just
create it with:
adduser --system --disabled-login ...
it's sort of a system-type user, but we need to log in anyway - I won't
get into the software's specifics, but there's daemons, a web interface,
and command-line tools that have to be run under this user's account.
2. ssh-keygen with no user input ("Enter passphrase")
If this is to give the user an SSH key, then this is a probably a bad
idea: The private part of the key should really never leave his
desktop.
again, this is a specific user dedicated to this app, to which only some
authorized people in our Operations team will have access. And we're
on a production server, not a desktop machine.
But generating user-keys is really no different than generating server
keys - have a look in the preinst/postinst scripts of
e.g. openssh-server for inspiration.
thanks for the pointer
3. add/edit some MySQL tables without knowing the MySQL root password
Another odd case, but not entirely unheard of. You may be able to use
the 'debian-sys-maint' user:
mysql --defaults-file=/etc/mysql/debian.cnf< yourscript.sql
But I'm not convinced that this is the "correct" usage of the
debian-sys-maint user.
will have a look
I've fooled around with Expect for 1. and 2., and tried
mysqld_safe --skip-grant-tables for 3., but I feel
lame (and I have to have my preinst script stop/start the
MySQL server during install) ..
Sounds pretty bad if you need to restart the MySQL server. And during
PRE-INST? As I hinted at earlier, doing this in the post-inst script
is much more common (if common at all). There is always the
possibility that installation may fail - and then you're left with
figuring out how to revert things out that the preinst script did.
If I'm not asking the correct list, I'm sorry, but could you please
direct me to the documentation I should read or other mailing list
I should contact ?
debian-devel would probably be a better place, as many of the package
maintainers hang out there...
Hope this helps
it does help a lot, thanks !
Reply to: