In <[🔎] 4A389C05.3050408@gulfsat.mg>, Rakotomandimby Mihamina wrote: >Hi >Still learning to package... ;-) > >I would like to make a package that I will install in a set of "servers". >Let's call it "admins_ssh_keys" As Ben mentioned this isn't a valid package name. Replace the underscores with hyphens and it's fine. >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 >b - copies the public keys into each $USER/.ssh >c - modifies sshd_config in a way that > c1 - Password acces is disabled > c2 - Only auth by Key is enabled >d - puts the users in the right group (admin) >e - depends on a set of packages usefull for our admins These goals can't be cleanly handled by the package manager. As such, it couldn't be an official Debian package. That said, if you'd like to (ab)use the package system to do this it is possible. I'd recommend against it, though. Mainly because packages need to be designed to be removed. In particular, a package *should* revert most (if not all) of the changes it makes during install if it is removed/purged. It's not clear that these actions can be cleanly reversed or even if they should ever be reversed. Instead, I think you might make a $org-admin-scripts package that contained (among other things) a script do make these changes that is run "manually" and Depends on all the tools required to do so. Then a second package $org- admin-tools that Depends on $org-admin-scripts and all the Debian packages your organization expects. The rest of my advice is for if you decide to make this a package, despite my and Ben's recommendations. >Well... >For a, b, c, and d: should it be just a post intallation action? I'd handle (a) in your preinst, and not remove the users as part of removing/purging/upgrading the package. This would leave users behind, but I think that's better than having the package remove users you (might have) created manually. Or, heaven forbid locking you out of the system by removing your only login path. (b), (c), and (d) would be part of your postinst. (b) can be applied with a simple append operation and reverted with a good sed. (c) is easy enough to apply with sed and append operations, but virtually impossible to revert. It's also a conffile handled by another package, so it's not really a good idea to have your package affect it. (d) is in the same boat as (a). You'd want to do it during install, but I'd decline to revert it even though it is easy to do so. >Then when comes the time of "upgrading" this package (adding or removing > an admin)... What advices would you give? If you really do want to maintain a set of user accounts with a package, allowing the package inst/rm commands to add, modify, and remove users, you *need* to have at least one administrator account that is not modified by the package, so if the package fails dramatically you can still get in to fix the system. Again, I'd recommend against it and instead have your $org-admin-scripts package contain $org-addadmin and $org-deladmin scripts that are installed to /usr/sbin. Whatever method you are using for mass package-installation should be able to handle mass script-running. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.