FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 12-09-2009, 06:42 PM
Alan McKinnon
 
Default Problems setting up sshd on an installation kernel

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. 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. 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. Possible yes, but not supported by default.

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.

--
alan dot mckinnon at gmail dot com
 
Old 12-09-2009, 08:27 PM
Stroller
 
Default Problems setting up sshd on an installation kernel

On 9 Dec 2009, at 16:46, Alan Mackenzie wrote:

...
(what? There are people who only boot it once before getting Gentoo
completely installed? ;-).


Yes, absolutely. I would consider this to be the normal scenario.


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.


Well, it was totally worth wasting 10 hours of your time not to have
to delete one line of a text file.


FWIW I have in .bashrc:

alias ssg="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/
dev/null"



I do totally sympathise with you on trying to open bugs & improve
Gentoo. I have been brushed off and received snotty responses from
devs on a number of occasions. They're either a bunch of arrogant
knobs, or they simply deal with bugs in a terse manner (which, totally
unintended, happens to offend certain people such as you & I). I
suppose charitably we must assume the latter.


Stroller.
 
Old 12-09-2009, 08:57 PM
Stroller
 
Default Problems setting up sshd on an installation kernel

On 9 Dec 2009, at 19:42, Alan McKinnon wrote:

...
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. 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. Possible yes, but not supported by default.


I'd disagree with you on that point, assuming I'm reading you right.

If a compile fails it shouldn't be an "unsupported" situation. One
should be able to reemerge the package, possibly after emerging a
required dependency first. That should work just fine (and surely it
always does?).


Likewise it's not at all uncommon to make a mistake during the
installation process - to miss out an essential kernel driver or
package, and find that the installation fails to boot. The way I
interpret your statement is that the supported remedy is to start
again completely from scratch. Clearly this is not what one does - one
boots again with the LiveCD, chroots into the installation, makes the
fix and then reboots again to see if the system is now fixed. Every
new Gentoo user has to do this a number of times, it is our standard
advice to them, and we, as experienced users, will still have to do
the same thing occasionally due to our own oversights.


However, I would agree with you that resolving Alan Mackenzie's
problems with ssh should not be a priority. The "standard" procedure
should be written for a user sitting in front of the machine on which
Gentoo is being installed. Installing via SSH is an "advanced"
procedure and should be considered to be undertaken by users who know
what they're doing. The requirement to rarely remove a line from
~/.ssh/known_hosts is really not much hassle.


I am somewhat surprised that Mr Mackenzie managed to waste as much
time as 10 hours attempting to SSH into the "wrong" environment, as it
has never occurred to me to do it that way around, and Florian posted
appropriate advice to resolve the problem less than 2 hours after
Alan's original post.


I think this is typical of the kind of mistake we all make and learn
from - we have all wasted 10 hours on some occasion, only to kick
ourselves afterwards. When we do this we learn never again to make the
same mistake.


On 9 Dec 2009, at 16:46, Alan Mackenzie wrote:

However, setting up /dev completely (with --rbind) costs nothing, adds
capability, and takes nothing away.


It is not clear to me that this is the "obvious" and "optimal"
solution. It may be. I cannot foresee whether it may introduce side-
effects.


Stroller.
 
Old 12-09-2009, 09:20 PM
Alan McKinnon
 
Default Problems setting up sshd on an installation kernel

On Wednesday 09 December 2009 23:57:18 Stroller wrote:
> On 9 Dec 2009, at 19:42, Alan McKinnon wrote:
> > ...
> > 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. 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. Possible yes, but not supported by default.
>
> I'd disagree with you on that point, assuming I'm reading you right.
>
> If a compile fails it shouldn't be an "unsupported" situation. One
> should be able to reemerge the package, possibly after emerging a
> required dependency first. That should work just fine (and surely it
> always does?).

I made an analogy, a poor one :-), which only goes as far as it goes (and
that's not very far). I meant that if gcc is running and compiling some
arbitrary .c and you hit ^C, there's no magic incantation to tell gcc to find
what it was doing and continue from that point as if the interruption never
happened.

Likewise with installation - you can't just decide to stop halfway, shut the
box down and continue tomorrow expecting the software to pick up where you
left off automagically (without you having to do anything extra). Consider
*any* installation media of your choice for *any* OS; none of them that I have
ever used allow you to interrupt the install and continue later.

I see no reason why the install dev and the doc dev should support such a feat
on Gentoo even if it is technically feasible.

> Likewise it's not at all uncommon to make a mistake during the
> installation process - to miss out an essential kernel driver or
> package, and find that the installation fails to boot. The way I
> interpret your statement is that the supported remedy is to start
> again completely from scratch. Clearly this is not what one does

Correct, one normally redoes the setup commands:
boot, mkdir, mount, mkmoredirs, more mount, mount proc, chroot, cp resolv.conf
etc etc etc and continue. This only works because any data written to the disk
during $INSTALL_ATTEMPT_1 is persistent by virtue of it being written to
*disk*. And there is no need to untar a stage all over again.

By happy coincidence, oftentimes after chrooting one finds an environment that
has everything required to run sshd, but there is no guarantee of that at all.
So one can try start sshd, if it works then all well and good, if not then
that's tough. Either way the human running the show is on his own with this
one.

I still maintain that the doc dev is correct in refusing to document such a
thing - it's way too unreliable and uncertain to even warrant a mention.

--
alan dot mckinnon at gmail dot com
 
Old 12-09-2009, 09:35 PM
Alan Mackenzie
 
Default Problems setting up sshd on an installation kernel

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).
 
Old 12-09-2009, 11:23 PM
Dale
 
Default Problems setting up sshd on an installation kernel

Stroller wrote:


On 9 Dec 2009, at 16:46, Alan Mackenzie wrote:

...
(what? There are people who only boot it once before getting Gentoo
completely installed? ;-).


Yes, absolutely. I would consider this to be the normal scenario.


+1 I have done that several times, even over ssh to another country.




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.


Well, it was totally worth wasting 10 hours of your time not to have
to delete one line of a text file.


FWIW I have in .bashrc:

alias ssg="ssh -o StrictHostKeyChecking=no -o
UserKnownHostsFile=/dev/null"



I do totally sympathise with you on trying to open bugs & improve
Gentoo. I have been brushed off and received snotty responses from
devs on a number of occasions. They're either a bunch of arrogant
knobs, or they simply deal with bugs in a terse manner (which, totally
unintended, happens to offend certain people such as you & I). I
suppose charitably we must assume the latter.


Stroller.



+1 here too. I haven't filed a bug in a while although I have found a
couple. I also very rarely post on -dev. I learned that if you don't
say anything, they don't know you are there to bite on. ;-) Sort of
like a fly on the wall.


Dale

:-) :-)
 
Old 12-10-2009, 04:00 AM
Stroller
 
Default Problems setting up sshd on an installation kernel

On 9 Dec 2009, at 22:35, Alan Mackenzie wrote:

...

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.


You only chroot after untarring the stage 3.

When you do chroot then you emerge grub, the kernel and add sshd to
the default runlevel.


Remove the live CD, reboot.

Job done.

Obviously there's a lot more to do after this to get a *fully working*
operating system, but you should by this stage now be able to boot
from the hard-drive into your embryonic system, and from there you can
add a user, a system logger, cron, perform updates &c.


Stroller.
 
Old 12-10-2009, 09:36 AM
Alan Mackenzie
 
Default Problems setting up sshd on an installation kernel

Hi, Stroller,

On Wed, Dec 09, 2009 at 09:57:18PM +0000, Stroller wrote:

> On 9 Dec 2009, at 19:42, Alan McKinnon wrote:
> >...
> >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. 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. Possible yes, but
> >not supported by default.

> I'd disagree with you on that point, assuming I'm reading you right.

> If a compile fails it shouldn't be an "unsupported" situation. One
> should be able to reemerge the package, possibly after emerging a
> required dependency first. That should work just fine (and surely it
> always does?).

> Likewise it's not at all uncommon to make a mistake during the
> installation process - to miss out an essential kernel driver or
> package, and find that the installation fails to boot. The way I
> interpret your statement is that the supported remedy is to start
> again completely from scratch. Clearly this is not what one does - one
> boots again with the LiveCD, chroots into the installation, makes the
> fix and then reboots again to see if the system is now fixed. Every
> new Gentoo user has to do this a number of times, it is our standard
> advice to them, and we, as experienced users, will still have to do
> the same thing occasionally due to our own oversights.

Thanks! ;-)

> However, I would agree with you that resolving Alan Mackenzie's
> problems with ssh should not be a priority.

For filesystem checking's sake! My personal problem has been solved.
The /dev directory in the newly chrooted system is broken. I simply
asked the project to fix it, provided the fix, and the fix is replacing
6 characters in a file with 6 different characters.

Now, at this stage, people say "it isn't broken, because you can do
everything in it that we've decided you need to do.". Let's just say
this isn't in the spirit of free software. ;-)

How did this breakage happen? I would guess that at the time the
installation procedure was devised, this line

# mount -o bind /dev /mnt/gentoo/dev

worked perfectly OK, since /dev didn't have any subdirectories. Some
time recently, /dev acquired subdirectories (e.g. /dev/pts), but nobody
realised this would render the chrooted system less capable.

Now, how much work would it cost to replace that line in the manual with

# mount --rbind /dev /mnt/gentoo/dev

, compared with the cost of all this correspondence? Instead, the
maintainer spent all his energy telling me I'm stupid for wanting to do
what I wanted to do.

> The "standard" procedure should be written for a user sitting in front
> of the machine on which Gentoo is being installed. Installing via SSH
> is an "advanced" procedure and should be considered to be undertaken
> by users who know what they're doing. The requirement to rarely remove
> a line from ~/.ssh/known_hosts is really not much hassle.

The machine I was installing on was a laptop with no available desk top
to place it on. Therefore I decided to get SSH up and running as early
as possible so as to do the bulk of the installation from my nice comfy
desktop, monitor and keyboard. Starting sshd from inside the chrooted
system was obviously the Right Thing.

> I am somewhat surprised that Mr Mackenzie managed to waste as much
> time as 10 hours attempting to SSH into the "wrong" environment, ....

That's starting from "ssh doesn't work", realising that the ssh server
was validating my password (or key, I've forgotten which), and then doing
nothing. It's the time taken to go through sshd_config looking for
stupidities. It's the time taken to read various manual pages, try out
various methods of dumping debug info, to the point of getting the vague
irritating error message: "file not found". It's the time taken to set
up logging facilities, on the (false) hypothesis that it couldn't find a
logging file. It's the time taken to post my problem on
comp.os.linux.setup, and fail to get an answer there. It's the time
taken to post the problem again on this mailing list, and get the answer
from Joshua, to whom I'm most grateful.

> .... as it has never occurred to me to do it that way around, and
> Florian posted appropriate advice to resolve the problem less than 2
> hours after Alan's original post.

> I think this is typical of the kind of mistake we all make and learn
> from - we have all wasted 10 hours on some occasion, only to kick
> ourselves afterwards. When we do this we learn never again to make the
> same mistake.

With all due respect, it wasn't my mistake, or if you disagree here
we'll just have to agree to disagree ;-). /dev is broken.

> On 9 Dec 2009, at 16:46, Alan Mackenzie wrote:
> >However, setting up /dev completely (with --rbind) costs nothing, adds
> >capability, and takes nothing away.

> It is not clear to me that this is the "obvious" and "optimal"
> solution. It may be. I cannot foresee whether it may introduce side-
> effects.

I can. There won't be any. Think about it, before /dev/ acquired
subdirectories, having a fully functional /dev didn't have negative side
effects. So why should restoring it to full functionality have side
effects now?

> Stroller.

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 12-10-2009, 01:23 PM
Neil Bothwick
 
Default Problems setting up sshd on an installation kernel

On Thu, 10 Dec 2009 10:36:41 +0000, Alan Mackenzie wrote:

> The machine I was installing on was a laptop with no available desk top
> to place it on. Therefore I decided to get SSH up and running as early
> as possible so as to do the bulk of the installation from my nice comfy
> desktop, monitor and keyboard. Starting sshd from inside the chrooted
> system was obviously the Right Thing.

Surely starting sshd from the live environment is The Right Thing if you
want to get SSH running as soon as possible? That's how I've always done
it.


--
Neil Bothwick

Some people are born mediocre, some people achieve mediocrity, and some
people have mediocrity thrust upon them. - Joseph Heller, "Catch-22"
 
Old 12-10-2009, 03:52 PM
Joshua Murphy
 
Default Problems setting up sshd on an installation kernel

On Thu, Dec 10, 2009 at 10:27 AM, Willie Wong <wwong@math.princeton.edu> wrote:
> On Thu, Dec 10, 2009 at 10:36:41AM +0000, Penguin Lover Alan Mackenzie squawked:
>> How did this breakage happen? *I would guess that at the time the
>> installation procedure was devised, this line
>>
>> * * # mount -o bind /dev /mnt/gentoo/dev
>>
>> worked perfectly OK, since /dev didn't have any subdirectories. *Some
>> time recently, /dev acquired subdirectories (e.g. /dev/pts), but nobody
>> realised this would render the chrooted system less capable.
>
> Just to be pedantic.
>
> Not subdirectories. 'mount --bind' binds the directory tree. What /dev
> picked up was submounts, which is why you issued 'mount --rbind' as a
> workaround. (The mount manpage I think has something about devpts.)
>
> I wonder if 'mount -t devpts devpts /dev/pts' is a better workaround
> for your problem, though.
>
> Cheers,
>
> W
>
> --
> M: Hot almond milk. Best stuff on earth.
> Sortir en Pantoufles: up 1098 days, 14:03

That one only works if the kernel of your install disk is configured
to allow multiple instances of devpts to be mounted
(CONFIG_DEVPTS_MULTIPLE_INSTANCES) ... I'm in no way certain if that's
enabled on the Gentoo generated livecds, currently.

--
Poison [BLX]
Joshua M. Murphy
 

Thread Tools




All times are GMT. The time now is 07:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org