Re: package advices

[Ben Finney <ben+debian@benfinney.id.au>]

Rakotomandimby Mihamina <mihamina@gulfsat.mg> writes:

> Hi
> Still learning to package... ;-)

Thanks for learning, it's good to have more people willing to educate
themselves on how Debian's package system works.

> I would like to make a package that I will install in a set of
> "servers". Let's call it "admins_ssh_keys"

That name would not conform with Debian policy; package names can't
include underscores.

> This package is the set of "public keys" of admins in my department.
> 
> I would like then to install "admins_ssh_keys" then it:
> a - creates the right users

This is within the scope of a Debian package, but only for the purpose
of supporting some role that e.g. programs within the apckage will use
to run. It's not for creating regular real-person user accounts.

> b - copies the public keys into each $USER/.ssh

Definitely outside the scope of the Debian package system. The package
system has no business touching the contents of user home directories.

> c - modifies sshd_config in a way that
>   c1 - Password acces is disabled
>   c2 - Only auth by Key is enabled

Modifying configuration files at package install time should only be
done via well-defined interfaces to those configuration files. Going in
and trampling over local customisations is a big no-no.

> d - puts the users in the right group (admin)

This, too, is for the administrator to do, and isn't the business of the
package system.

> e - depends on a set of packages usefull for our admins

This is about the only part of your requirements that I think makes
sense as a package: you create a ‘useful-admin-tools’ package that
depends on whatever tools you expect will be useful to your
administrators.

> Well...
> For a, b, c, and d: should it be just a post intallation action?

No. It should be a program that you write, preferably with good defaults
but customisable behaviour, make a package for that tool and distribute
it, and *the administrator runs that tool at their discretion*. None of
the actions you describe are suitable for running as part of package
installation, IMO.

Have a good read of the Debian policy document, to see how
comprehensively the policy is in requiring packages that *don't*
overrule the authority of the administrator, and what actions are
acceptable for performing as part of a package installation.

-- 
 \        “Kill myself? Killing myself is the last thing I'd ever do.” |
  `\                                            —Homer, _The Simpsons_ |
_o__)                                                                  |
Ben Finney