Xen users - Dec 2005 - RE: ssh in rc.local stalls xenU [SOLVED]

Karsten M. Self wrote:
> on Thu, Dec 15, 2005 at 01:38:29PM -0500, Steve Brueckner
> (steve@atc-nycorp.com) wrote: 
>> I''m using Fedora Core 4.  I need to create an ssh port
forwarding
>> tunnel to my xen0 domain when my xenU domain starts up, so I added
>> this to the xenU''s /etc/rc.d/rc.local:
>> 
>> ssh -v -f -L 5500:localhost:5501 xen0_ip tail -f /dev/null
>> 
>> This causes my VM to pause for about 3 minutes during boot.
>> Furthermore, the ssh tunnel never gets created.  The ssh command is
>> stalling at "Connecting to (xen0_IP) port 22"
> 
> It would be useful to see what''s happening on the remote (well,
> local) server side.  Check sshd''s logs, and/or run it manually in
> debug mode and watch its output as the connection is being attempted:
> 
>     sshd -ddDe
> 
> <ctrl>-c to exit when done.
> 
>> I have null-passphrase authentication keys working, so I can execute
>> the tunnel manually after I log in.  So why won''t the tunnel
work
>> before I log in? 
>> 
>> When I try the same trick on the bare-metal host machine and ssh to a
>> different physical machine, it works fine: no 3-minute stall and the
>> ssh tunnel is created fine.
> 
> A three-minute timeout sounds suspiciously like a network timeout.
> rc.local runs _after_ all other rc scripts, so networking should be
> up and running.  
> 
> You might want to ammend your script to check networking status,
> _before_ the ssh command is executed: 
> 
>    ifconfig; route -n; ping localhost
> 
> Check also that /etc/hosts has a proper localhost entry.
> 
>> So what is it about Xen or my xenU domain that breaks ssh before
>> login, but not after login?  And what is it about Xen or my xenU
>> domain that breaks ssh before login, while it works fine for a
>> physical host?
> 
> Logs and debug output would be helpful here.
> 
Ah, I should have thought of this earlier.  My custom SELinux policy
disables networking for unconfined_t, so it puts ssh into sshd_t (which
allows networking).  But it only puts ssh into sshd_t when started by root;
there was no transition specified in my policy that ssh should go into
sshd_t when started by initrc_t.  A couple of lines in my
domains/program/ssh.te fixed it:

role initrc_t types sshd_t;
domain_auto_trans(initrc_t, sshd_exec_t, sshd_t)

So, the network was in fact up but I was shooting myself in the foot.  This
is definitely not a Xen-related issue.  Thanks for your responses; I
appreciate the help.

 - Steve

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

on Thu, Dec 15, 2005 at 04:51:52PM -0500, Steve Brueckner (steve@atc-nycorp.com)
wrote:
> Karsten M. Self wrote:
> > on Thu, Dec 15, 2005 at 01:38:29PM -0500, Steve Brueckner
> > (steve@atc-nycorp.com) wrote: 
> >> I''m using Fedora Core 4.  I need to create an ssh port
forwarding
> >> tunnel to my xen0 domain when my xenU domain starts up, so I added
> >> this to the xenU''s /etc/rc.d/rc.local:
> >> 
> >> ssh -v -f -L 5500:localhost:5501 xen0_ip tail -f /dev/null
> >> 
> >> This causes my VM to pause for about 3 minutes during boot.
> >> Furthermore, the ssh tunnel never gets created.  The ssh command
is
> >> stalling at "Connecting to (xen0_IP) port 22"
> > 
> > It would be useful to see what''s happening on the remote
(well,
> > local) server side.  Check sshd''s logs, and/or run it
manually in
> > debug mode and watch its output as the connection is being attempted:
<...>
> Ah, I should have thought of this earlier.  My custom SELinux policy
> disables networking for unconfined_t, so it puts ssh into sshd_t (which
> allows networking).  But it only puts ssh into sshd_t when started by root;
> there was no transition specified in my policy that ssh should go into
> sshd_t when started by initrc_t.  A couple of lines in my
> domains/program/ssh.te fixed it:
> 
> role initrc_t types sshd_t;
> domain_auto_trans(initrc_t, sshd_exec_t, sshd_t)
> 
> So, the network was in fact up but I was shooting myself in the foot.  This
> is definitely not a Xen-related issue.  Thanks for your responses; I
> appreciate the help.
SOP for us is to disable SELinux when using Xen for a number of reasons,
as documentation indicates.

You can set ''selinux=0'' as a Linux boot parameter to do this
globally,
and might want to add that as a debug/test step to isolate SELinux
issues from other possibilities, if you must run SELinux.


Cheers.

-- 
Karsten M. Self <karsten@xensource.com>
XenSource, Inc.
2300 Geng Road #250                                +1 650.798.5900 x259
Palo Alto, CA 94303                                +1 650.493.1579 fax

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users