Hi Guilhem, Thank you for replying to my request.
On Mon., Oct. 21, 2019, 21:08 Guilhem Moulin, <guil...@debian.org> wrote: > Hi Anton, > > [dropbear package maintainer here.] > > On Mon, 21 Oct 2019 at 16:07:11 -0400, Anton Avramov wrote: > > For a long time now I've maintained servers remotely. One problem that > > I've faced is what when there is problem booting I lose ability to login > > remotely and help the person on premises. Further more that person can > > be not technically capable or comfortable with writing console > > commands. There are instances where there is not even a keyboard or > > monitor attached. > > Given the scope of this package, I strongly believe it'd make more sense > to merge it with src:dropbear rather than shipping a separate source > package. > I agree. However I don't know how I can contribute to that. > > Following dropbear-initramfs package > > You seem to suggest that your code takes inspiration from > dropbear-initramfs, > but your copyright information doesn't reflect that. > Sorry about that! I've tried to change that, but I'm not absolutely certain I've done it right. > > that will install dropbear and would have the appropriate initramfs > > scripts to start it in case the system enters rescue mode. > > Why couldn't that be done in dropbear-initramfs instead? Right now the > script is run at premount stage, but I guess we could have an option to > run it at another stage instead. The only argument I can think of is to give the option to have separate access for panic and crypt unlock. For example in my scenario I have crypt unlock on different port with different hostkeys. And in principle I can give someone the right to unlock the fs, but not login in case of panic where in that case and admin with higher access should step in. However the first step would be to > document the ‘panic’ stage in initramfs-tools(7) (the “boot scripts” > section of the manual doesn't mention it AFAICT). > > > I've tried to keep the package compatible with dropbear-initramfs > > package. > > Depending what you mean by “compatible”, please note that the only > public interface of that package is the configuration file. Relying on > something else would be another argument in favor of integrating this > into src:dropbear. Also I didn't review the code but at first glance I > see similarities, please see §4.13 of the Debian Policy. > By compatible I mean they can run together without interfering given they use different port. Since there are only 2 scripts in initramfs I'm not sure how would they suppose to share the code if we assume they are different packages > Cheers, > -- > Guilhem. >
