public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Problems setting up sshd on an installation kernel
Date: Wed, 9 Dec 2009 22:35:44 +0000	[thread overview]
Message-ID: <20091209223544.GA1358@muc.de> (raw)
In-Reply-To: <200912092142.56433.alan.mckinnon@gmail.com>

Hi, Alan,

On Wed, Dec 09, 2009 at 09:42:56PM +0200, Alan McKinnon wrote:
> On Wednesday 09 December 2009 18:46:11 Alan Mackenzie wrote:
> > > The supported method is to ssh into the "LiveCD" environment then
> > > chroot from that shell. It's hard to imagine a scenario where you
> > > would have more than one user doing that at the same time, so why
> > > run sshd in the chroot at all?

> > If you run sshd in the bare installation (as suggested), the ssh
> > client has to update his ~/.ssh/known_hosts every time the system is
> > booted (what?  There are people who only boot it once before getting
> > Gentoo completely installed? ;-).  When sshd'ing from within the
> > chrooted environment, the ssh client has to add an entry to
> > known_hosts just once, and this entry will persist even when the
> > embryonic gentoo has been fully installed and configured.

> > More to the point, though, is that the manual doesn't explicitly
> > state that sshd must be started from outside the chroot.  It sort of
> > implies it, but doesn't emphasise it.  Reading the manual, it was
> > clear to me that it didn't matter (turns out I was wrong).  Also,
> > people are going to be running sshd on their own initiative, and it
> > seems perverse knowingly to leave a hindrance on one of the two ways
> > they'll choose to do it.

> > This situation cost me around 10 hours of frustration.  Looks like
> > I'll not be the last victim.

> All I can add is that if I were the maintainer, I wouldn't support what
> you are asking either.

What you seem to be missing is that this change COSTS NOTHING, bar the
time it takes to change a few bytes of source code, recompile and commit.
Nothing which previously worked would cease to work, and the amount of
support required would decrease or stay the same.

> Installation is supposed to be an atomic operation - it starts then
> continues till it ends. It either fully completes or is considered to
> not have happened, meaning that persistence is diametrically opposed to
> what an install is.

OK, we don't live on the same planet.  I have never completed a Linux
installation in a single sitting, and don't expect ever to do so.
Particularly on a distribution like Gentoo where so much has to be done
by hand.  (That's not a criticism, by the way.  It's one of the things
which has attracted me to Gentoo.)  You and others around this list might
be supermen, I'm not, and I feel no shame about it.

> It's analogous to a compile - terminating compilation at some arbitrary
> point then picking up from where it ended at some later point is just
> not supported.

That analogy is so week as to be meaningless.  Installation, unlike
compilation, consists of a large number of discrete manual steps, and it
is silly to suggest that if you don't finish by bedtime you should wipe
the hard drive and start again from scratch when you get up in the
morning.

> Possible yes, but not supported by default.

The manual neither states nor implies that you've got to finish at one
sitting.  The only difficulty, and it's not much of one, is working out
how to restart in the middle.  Hey, even I managed that.

> But it's easy to get what you want: take what is there, modify it and
> create a fork. You become the maintainer of the fork and can accept or
> decline suggestions as you see fit.

Oh, that old stuff.  No thanks, Alan, I've got quite enough to do
supporting my own project (Emacs CC Mode).  I'll just carry on with my
own way of doing things, "supported" or not.  I'll keep my bright ideas
and "customer feedback" to myself from now on, since nobody here seems to
want them.  But I'll ask for help when I need it - you guys are great at
helping, and that's most appreciated.

Thanks for the chat, and good night for now!

> -- 
> alan dot mckinnon at gmail dot com

-- 
Alan Mackenzie (Nuremberg, Germany).



  parent reply	other threads:[~2009-12-09 22:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-06 14:48 [gentoo-user] Problems setting up sshd on an installation kernel Alan Mackenzie
2009-12-06 16:28 ` Mick
2009-12-06 20:23   ` Alan Mackenzie
2009-12-06 22:22     ` Mick
2009-12-06 16:59 ` Florian Philipp
2009-12-06 18:56   ` Joshua Murphy
2009-12-06 20:45     ` Alan Mackenzie
2009-12-09 15:24     ` Alan Mackenzie
2009-12-09 15:43       ` Alan McKinnon
2009-12-09 16:46         ` Alan Mackenzie
2009-12-09 19:42           ` Alan McKinnon
2009-12-09 21:57             ` Stroller
2009-12-09 22:20               ` Alan McKinnon
2009-12-10 10:36               ` Alan Mackenzie
2009-12-10 14:23                 ` Neil Bothwick
2009-12-10 18:41                   ` William Hubbs
2009-12-10 20:42                   ` Mick
2009-12-10 15:27                 ` Willie Wong
2009-12-10 16:52                   ` Joshua Murphy
2009-12-09 22:35             ` Alan Mackenzie [this message]
2009-12-10  5:00               ` Stroller
2009-12-09 21:27           ` Stroller
2009-12-10  0:23             ` Dale
2009-12-06 20:17   ` Alan Mackenzie
2009-12-06 18:36 ` Walter Dnes
2009-12-06 21:31   ` Joshua Murphy
2009-12-06 21:49     ` Boy Hartsuiker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091209223544.GA1358@muc.de \
    --to=acm@muc.de \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox