[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Karsten M. Self wrote:
> on Thu, Dec 15, 2005 at 01:38:29PM -0500, Steve Brueckner
> (steve@xxxxxxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.