package advices
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 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 Well... For a, b, c, and d: should it be just a post intallation action? Then when comes the time of upgrading this package (adding or removing an admin)... What advices would you give? -- Architecte Informatique: Administration Système, Recherche et Développement. Phone: +261 33 11 207 36 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: package advices
Rakotomandimby Mihamina miham...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: package advices
In 4a389c05.3050...@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. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
