Remote Access

Aus Doc-Wiki

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Goal

You might want to use our pool infrastructure - which means any pool client c001 to c048 - from a remote location, for example from home. This is totally fine!

Strategy

Shell
shell.stud.informatik.uni-goettingen.de - usable by every student. These machines are powerful enough to not require you to hop forward to a physical pool client machine.
login.informatik.uni-goettingen.de
usable only by staff members with Gwdg-Account

You might use those login machines as a gateway from the outside world into the pool - basically to any computer c001 to c048.

This gateway approach is necessary as the pool computers have local, non-routeable IP-addresses like 172.27.x.y.

For accomplishing access to a pool machine you need to "hop" forward one time. On login you'll see a list of currently running computers. E.g.:

System load of less used clients:
c011          up      16:01,     0 users,  load 0.00, 0.01, 0.05
c018          up      15:46,     0 users,  load 0.00, 0.01, 0.05

Simply jump to any of them. "ssh c011" would work in this example.

Hint: If you know the target machine already you might combine these two separate into a single one --> Remote Access/Single Command

Usually the computers in the pool shutdown itself when nobody is logged in. To supply some computers to the above user several pool computers are running continuously to be reachable for this specific use case. This is: c031..c036 which can be found in the first row in room -1.101. These computers are usable locally also without limitation. If they are in use in the very moment when you login remotely they may not be listed as available because of this very fact.

Please note that these clients reboot automatically early in the morning to clean up things - but only if nobody is logged in...

Problems with shared resources

System resources are limited, those login machines are a shared source in more intense way than those pool computers are.

It is considered unfriendly behavior to stress a shared resource in such a manner that other users can not work anymore.

One usual trigger element for this kind or problems is Java.

Killing a problematic process

If you have the suspicion that you have produced such bad background processes do the following:

First get a terminal with top running

Alternatively go to a "classic" physical console. This does also work very often if the GUI is not usable for some reason.

In that Terminal:

Help for top:

Only if you are sure that you are the only user on this physical machine: simple turn it off. This is acceptable because the Operating System is not stored locally but the machine performs remote boot. No files on disk can be damaged by a forced power cycle.

Problems with X forwarding

tbw

See also

Links

Meine Werkzeuge
Namensräume
Varianten
Aktionen
Navigation
Werkzeuge