FedoraThis forum is for the discussion of the Fedora Project.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
You need to set up the school machine to do XDMCP.
You could always run VNC on it and connect with the VNC client. Run vncserver :x, where x is a display number like 1. Then run VNCViewer on your Windoze box and connect to machine:x that you chose in the previous step.
You can also connect via SSH, have X-win32 running and start an X app and X-win32 should catch it and display the X session, but X Forwarding needs to be enabled inthe /etc/ssh/sshd_config file.
Your post said you used to do it using X-win so I assumed you were still using WinDoze. Sorry.
You should have everything you need to connect in FC2. You can still get redirected X by the SSH method, you don't need X-Win32 since FC2 has an X server already running.
To do XDMCP, log in as any user and issue the command
Code:
X -query my.XDMCP.server
where my.XDMCP.server is either the name or IP address of the school XDMCP server.
>>>Here does "server" refer to the machine I am connecting too? I need to stop X before issuing this command?<<<
actually, it's referring to the X server on the machine you're issuing the command *FROM*. you can run one mor more X sessions on one or more virtual displays. if your machine is in graphical mode, it's using at least one of them, and by default it's display 0.
X is a little counter-intuitive as far as what it considers a "server" vs "client". (oversimplifying a bit) the machine with the monitor in front of you is a "display server" and doles out screen real estate for "clinet" programs running on the remote machine to use in displaying their output.
try bumping the display number, as in:
X :1 -query 192.168.1.101
note the ":1" after "X" - you can try higher numbers until one works - depends how many displays your machine has X servers running on, but by default it's usually just :0 on vt7 - do an X --help for more details.
also, you might be interested in the existence of Xnest and gdmXnest which wil run a remote desktop in a window on your own X desktop. just to get you started, here's a command line i use (from within X) to get a desktop on my subnet:
it works remotely too, but of course then it depends on their firewall, X authentication, that sort of thing. if it helps - the xdmcp is happening on udp port 177 and the xsessions themselves happen on tcp 6000 and up (i.e. <remote-ip>:0 = 6000, <remote-ip>:11 = 6011 - apologies if you know this already...)
so at that point, it becomes a question of what the firewall will pass and what the xdm/X servers are configured to respond to. just 'cause it works on campus doesn't necessarily mean they'll let it out of their subnet and open it to the big bad internet.
assuming you had a laptop and plugged it in on site and got it to work there, it should work identically from another location by simply using the external address of the server, *IF* they allow that.
if not, you have to talk to them. if it's not open to the world, perhaps they have a vpn that you could get access to? that would effectively get you inside their network, which should then allow a connection, generally.
another alternative - just tried this on my gf's dsl connection (just gave her a spankin' new fc2 box - am i a nice guy, or what? <g>) - you can ssh in if you have that and run something like this:
FYI: i tried putting it all on an ssh command line, and it fails. i think it's because when passing a command on the ssh command line, you don't fully log in and the environment isn't set up, but i didn''t pursue the details - yet, anyway. probably some switch i'm leaving out.
it being solaris, it's probably unlikely that they have gdmXnest, in which case you're back to experimenting with display numbers - assuming they have Xnest itself on the remote box, that is. just to test it, i pasted the stuff in the quotes above and added ":15" to the line like so:
but in both of the above cases, you're actually running the Xnest pgm on the other box and shipping the entire display back to your box, as opposed to running Xnest on your box and connecting to the remote box. more data across the line. to make this work, use "ssh -XC <remote-ip>" - the -X pumps the X connection back to your box (if they allow that - if not, you'll likely get a message right when you log in) and the -C compresses the stream - that actually helps quite a bit in most cases that i've used it.
sorry for the wordy post. i'm still sort of working this stuff out in my head myself.
Let me ask you this, if i am use to use X-Win32 using windows and i am able to get the remote login/password screen, it means that school in fact, has it open to the world right?
and i get the traditional black screen with an "x" cursor. so i scanned udp port 177 and it's closed - hope i don't get a visit from the fbi <g> - i don't normally scan ports on machines i'm not responsible for 'cause network admins can be understandably sensitive about that. anyway, 177 is closed. that's sufficient reason for there to be no login screen appearing.
i don't have x-win32, and i don't use windows much anymore, tho i have access to it either thru a vm or terminal server, so i'm hard put to say what the difference is, but here's my guesses at the possibilities:
- do you already have vpn software running and configured on the windows side? if there's a vpn involved, then you have access to the internal nework. that changes things. it's even possible, tho somewhat unlikely that the hostname maps to an internal ip. try pinging it when logged into windows, then ping it when logged into linux. if the windows one is an addy internal to their network, and the linux one isn't, then you pretty much must have a vpn going on the windows side. if so, you need to reproduce the vpn connection on the linux side. that depends on what software you're/they're using for that, but it'd be likely either some flavor of ipsec or pptp - which can both generally be made to work, tho sometimes they're a bit of a pain.
fwiw, from where i sit, rohan.sdsu.edu=130.191.3.100
- perhaps there's some flavor of authentication configured in your x-win32 that punches thru? if so, i don't off the top of my head know what mechanism it's using, but then again, i'm only just finding out enuff about this stuff to be dangerous. assuming you're talking about the x-win32 from starnet, these things from the feature list catch my eye right away:
--------------
1) Integrated SSH Connection Module
X-Win32 now includes StarNetSSH, a SSH implementation derived from the open source PuTTY SSH.
2) IPsmarts
Useful when connecting though a NAT router to a host on the Internet.
--------------
maybe there's something in the x-win32 connection config that you're not reproducing when trying to connect? i'm thinking like maybe an ssh tunnel or something that it's doing automatically for you.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.